PI System Support: Building Compliant OT Architecture with Modern Components

The key benefit to OPC UA is that it does not rely on (the underlying communication framework between software components) that OPC DA/HDA uses. As such, there is no need to open a wide port range in the firewall in both directions, no need to configure complicated DCOM security configurations and, whilst a third-party tunneller product alleviates both, there is no longer a need for such software.

Speaking of third-party software, for data sources that still only support OPC DA/HDA, there are products out there that convert from OPC DA/HDA to OPC UA, so it is possible to migrate away from PI Interfaces and standardise on the newer PI Connectors or AVEVA Adapters.

OPC UA also supports real time and historical data collection, combining both within the same protocol, so there is no need to have separate data collection services as before with OPC DA and HDA.

The only downside to OPC UA, at least as far as the PI System is concerned, is that the PI Connector and AVEVA Adapter for OPC UA do not support writing back to the OPC UA data source, but the requirement to do so is rare and some might say controversial.

PI Connectors and AVEVA Adapters are quite different from PI Interfaces in terms of how they operate and are configured so it is important to understand the differences.

Both options create PI tags based on data selection and transformation rules within the Connector and Adapter configuration, whereas with PI Interfaces, PI tags are configured in the PI Data Archive first and the PI Interface reads their configuration from the PI Data Archive.

Another difference is Connectors and Adapters do not support tag-based exception reporting: instead deadbands can be configured within the Connector and Adapter. Note that both still support compression.

For the PI Connector for OPC UA, it only supports solicited data collection (i.e. advise), whereas the PI Interface and AVEVA Adapter also support unsolicited data collection (i.e. polling). This means the Connector will only send a value to PI when the value changes on the OPC UA server, whereas the Interface and Adapter can be configured to explicitly read from the OPC UA server and write to PI regardless of if the value changes.

The second generation of PI Connectors and AVEVA Adapters also introduced a new intermediate layer to the data transfer that allows superior network segregation between OT and IT, allowing a better fit within the Purdue Model. For PI Connectors, this component is the PI Connector Relay and for AVEVA Adapters, it is the PI Web API.

Source: AVEVA – PI Connector for OPC UA Gen 2

In terms of key features, there are significant differences between the PI Connector and AVEVA Adapter for OPC UA. At a glance:

• PI Connector Generation 1 supports connector-level failover, but not OPC UA server-level failover.
• PI Connector Generation 2 supports OPC UA server-level failover, but not connector-level. It also supports PI Connector Relay and Data Collection Manager.
• AVEVA Adapters on the other hand support both adapter-level and server-level failover, though the architecture for adapter-level requires a third witness server known as the Client Failover Service. They also write to the PI Data Archive via the PI Web API.

Source: AVEVA™ Adapter for OPC UA

During implementation, PI Connectors are configured using a web browser-based interface, whereas AVEVA Adapters are configured using web API commands. So PI Connector configuration is more user friendly, but AVEVA Adapter setup is more scriptable and controlled.

Whilst PI Connectors and AVEVA Adapters both run on the Windows operating system, but AVEVA Adapters can also run on Linux, and are designed to be super-lean, able to run with very low hardware resources making them suitable for edge devices or containers.

Finally, whereas PI Connectors can generate an AF structure based on the OPC UA hierarchy, something that AVEVA Adapters cannot do, AVEVA Adapters can write time-series directly to AVEVA’s cloud platform, CONNECT Data Services.

There is a well-defined and documented path for migrating PI Interface for OPC DA/HDA to PI Connector or AVEVA Adapter for OPC UA, depending on which of the newer technologies is the best fit:

1. Define the new server architecture for data collection within the bounds of the organisation network layer.
2. Define a high-level migration plan.
3. Configure the PI Connector or AVEVA Adapter to re-use the existing PI tags.