AVEVA™ PI System™ Feedback Portal

Welcome to our 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 Connectors
Categories General
Created by Brent Bregenzer
Created on Aug 20, 2022

RELATED IDEAS

Have option to enable exception on Connectors.

There are use cases where data is sent over networks with latency (satellite link, for example) so being able to filter out noise at the connector is important.  This is also important when a connector sends data to a local PI Server in the field (low latency), but then PItoPI is used to send snapshot updates to a central PI Server over a high latency link.
  • Attach files
  • sahilp
    Reply
    |     Sep 9, 2022

    Its clear that data transfer between the connector and the relay is compressed (I think the relevant KB makes mention of zipping data), but apart from the network performance between the connector and the relay, the PI training videos on youtube also point out that another big advantage of exception filtering is to store only useful data in the PIDA (HDD usage) and also to transfer less data to our various clients (network usage from PIDA to remote clients). I think its an important feature.

    Also (at least in the case of OPC UA gen 2) its possible to switch to TagsOnly mode and make use of the deadband column in the TagsOnly file, but this is a clumsy approach compared to the traditional interfaces which exception values can be managed in a central way from the PIDA. I also have anecdotal evidence that switching to TagsOnly significantly increase RAM consumption on both the relay and the connector (I have a ticket to investigate this).

    It would be great if the exception filtering can be managed in a central way through excdev parameter with which most admins are already familiar. Apart from the "familiarity" aspect, keeping all tag configs in a central location makes disaster recovery a straight forward matter of backing up the PIDA only. With connectors tagsonly mode, the csv also needs to be backed up.

  • Gabriel Verreault
    Reply
    |     Aug 20, 2022
    PI Connectors with the relay configuration (2.x) compress the data before sending it to the relay which would allow for a reduction of network traffic
  • Dan.Louchbaum
    Reply
    |     Aug 20, 2022
    For Hi Speed connectors on manufacturing network, but PI DA on Enterprise network, significant traffic routes through the firewall. Compression helps the data recorded but not the traffic, which is why Exception is very important.
  • Gabriel Verreault
    Reply
    |     Aug 20, 2022
    In response to Dan Louchbaum, "For Hi Speed connectors on manufacturing..." In my comment about compression, I meant that every event sent by the connector to the relay (this is not a PI Event, an 'event' can contain thousand of data values), are compressed (file compressed), so it would limit the bandwidth usage between the 2 components
  • KPRoth
    Reply
    |     Aug 20, 2022
    In addition to latency, there are also bandwidth related costs to be considered. One example is passing data back from a field site over a cellular m2m link, where bandwidth is paid for by the megabyte. Another example, which I'm specifically running into with the PI Connector for GE e-terraHabitat (HabConnect), is when the resulting snapshot stream is being routed through the OWL Pi Transfer Service (and their data diode network security device) from a SCADA or DMZ Pi server out to a Corporate Network Pi server. The OWL device is purchased based on the expected transfer bandwidth. I want to add that I find it disappointing that PI Interfaces (including the one for e-terraHabitat) tended to support Exception Deviation settings to pre-filter snapshot data, but that PI Connectors do not support this mechanism. It seems clear that there are many benefits to adding the option to support exception deviation to connectors.