AVEVA™ PI System™ Feedback Portal

Welcome to our new feedback site!


We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.

To start, take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas and comments are visible to all other users.


This page is for feedback specifically for AVEVA PI System. For links to our other feedback portals, please see the tab RESOURCES below.

Add a new idea Subscribe
Status No Status
Product PI Integrators
Categories AVEVA™ PI Integrator for Business Analytics
Created by Guest
Created on Aug 16, 2022

RELATED IDEAS

Azure IoT Hub: allow Integrator to use device-level connection string

As an Azure IoT Administrator, I would like to only give the Integrator minimum permissions to my IoT hub in order to minimize security concerns and reduce management overhead for shared access keys. Currently I can specify a device ID in the Integrator's Admin > Targets page, but this still requires a connection string for the IoT hub as opposed to the individual IoT device. I instead want to be able to use the device-level connection string.
  • Attach files
  • Guest
    Reply
    |     Aug 16, 2022
    It is vitally important that we can send data through the appropriate device level in the near future as we have multiple customers in the pipeline that will need the ability to authenticate at a device level into the same IOT Hub. Access at the IOT hub level should be reserved for device provisioning services and should not be done by things that are sending data to the IOT hub. 1. Providing read access to the IOT Hub level allows to ability to read the registry and the created devices. This is a major security concern as it now allows PI Integrator to see more than it should. 2. Providing the shared key to the IOT Hub level instead of the device level effectively removes the management of devices sending data to us. The PI integrator is sending data to the IOT hub, therefore it is a device and it should use a device-level connection so we can use the normal security and management tools to manager each of the PI integrators sending data to our IOT hub as-well-as allowing other non-PI devices to send data using the same IOT hub. Sharing the IOT Hub level shared key, means that I now have to manage which PI integrator devices have these keys as it is not tied to an IOT Hub device. 3. Because the PI integrator needs the shared key of the IOT Hub, then I have to mitigate these security concerns of keeping track of which PI integrators, at each customer site that sends us data, has which shared key that I created and making sure no one is sharing the same key with more than one customer PI integrator, and so on. This is both a security risk and management irritation, both of which are effectively solved when using device level access keys. 4. To mitigate these security risks and management irritations, I will have to create a separate IOT hub just for PI integrators (more than one PI integrators because we have multiple customers) and then I still have to manage the shared keys I create which are tied to the IOT hub level instead of the device level. I’m hoping that these above concerns can be resolved over the next few months so I don’t have to keep dealing with these security and management concerns. Using the Azure SDK it is very trivial to implement the few lines of code to establish a connection to the IOT Hub at a device level.