Even though the first release of OPC UA communication protocol standard was more than a decade ago (2008), client and server applications leveraging OPC UA have only started being the new standard in the recent years.
OPC UA is a welcome change that addresses the main pain points of OPC Classic. Some of the main changes that directly impact the data collection into OSIsoft's PI System:
- Platform Independence
- OPC UA Servers are not tied to Windows (DCOM) anymore and can run on devices with much smaller footprint across a variety of different platform (PC, cloud-based servers, PLCs, micro controllers) and Operating Systems (Windows, iOS, Android, Linux, etc.)
- There is a reason, why every firewall engineer has nightmares about OPC Classic and its underlying DCOM technologies, and that many referred to OPC as "Oh Please Connect". Since remote connections were not always trivial, many decided to use Tunnelers or to open up DCOM settings to an absurd extent, and it can have serious consequences from a cybersecurity perspective
- Session encryption, message signing, sequenced packets, authentication, user control, and auditing capabilities
- No need to open up thousands of ports in the firewall to allow DCOM communication. OPC UA Client (PI Connector for OPC UA) and servers initiate their session over one user-defined port.
- Asset Modeling and Address Space
- Similar to some of the functionalities that the AF Server adds to the PI Server, OPC UA Server can now contain a vast array of metadata, static attributes, and references between nodes.
Most of the differences were compiled using information available by the OPC UA Foundation
If this is all new to you, I also recommend watching Webinar—Introduction to OPC UA and Migration from Classic OPC to OPC UA (1 hour) from Unified Automation that describes the process from the OPC server side. Once your server uses OPC UA, you can leverage all the functionalities above and the PI Connector for OPC UA.
If one is currently using an OPC Classic technology (OPC DA, OPC HDA) for their data collection solution into the PI System, now is the best time to see if your source system (SCADA, DCS, PLCs, etc.) supports OPC UA or can upgraded to do so.
Some users will decide to use an OPCUA to OPCDA wrapper to stick with what they are comfortable (OPC Classic), but I believe that it is important to learn the new technologies and be able to leverage the additional functionalities of OPC UA and not stick with a technology designed around what the needs were in 1996.
Many DCS and SCADA vendors now have embedded OPC UA Servers to expose the data from their system. This means that if one is to modernize their control system platform, there will be a need to migrate client applications like PI Interfaces from OPC DA to OPC UA.
In 2016, we released the first version of the PI Connector for OPC UA, allowing direct data collection from OPC UA Server, but migrations from OPC DA to OPC UA were definitely a headache and required renaming all PI Points on the PI Data Archive to match the new OPC UA structure very difficult and against many customers PI Point naming conventions.
In 2019, we released version 188.8.131.52 of the PI Connector for OPC UA, allowing much more granular data selection, PI Point renaming, and a distributed architecture allowing the PI Connector to be 2 network zones away from the PI Server, eliminating the need for an additional PI Server in the DMZ with a unidirectional PI-to-PI interface sending the data to the business PI Server.
OPC UA Concepts
In order to transition from OPC DA to OPC UA, it is important to have a mapping file that relating OPCDA ItemIds and OPCUA NodeIds.
In the old days the classic DA Server have used simple “string”-Identifiers. The so-called “ItemID” was a fully qualified name that was unique throughout the whole server (there was only one “namespace”). Furthermore, the classic DA Servers had only capabilities for a simple hierarchy, i.e. a tree-like structure with branches and leaves. Hence, many vendors have used the full folder hierarchy to create unique ItemIDs (e.g. “Folder1.Folder2.Folder3.MyTemperature”). This lead to massive redundant strings, wasting memory and slowing down performance when looking up or searching for individual Items. With OPC UA, this concept has been abandoned and nodes are uniquely identified by their NodeId.
For existing PI Points, the OPC DA ItemId is stored in the InstrumentTag attribute of the PI Point. For each of those ItemId, one would need to obtain the NodeId on the OPC UA Server. In OPC UA, every entity in the address space is a node. To uniquely identify a Node, each node has a NodeId, which is always composed of three elements:
To define a node, the OPC UA Connector uses the XML notation.
In the following migration section, I assume that the PI Connector for OPC UA, PI Connector Relay, and PI Data Collection Manager (DCM) are installed and that both the PI Connector Relay and the PI Connector for OPC UA are registered and routed in the DCM. See What is the recommended procedure for configuring a new PI Connector with the PI Connector Relay and DCM for more details.
Additionally, I assume that the PI Connector for OPC UA is connected to the OPC UA Server and that a secure session between the client and the server can be established - X.509 certificate from the server is trusted on the connector, and X.509 certificate from the connector is trusted on the server. When deciding what 'Security Policy' and 'Message Security Mode' to use for the endpoint, one should always use the most secure one (please, stop using None:None, unless you are troubleshooting an issue that requires inspecting the network traffic in an unencrypted fashion). A good practice is also to only expose the most secure endpoint on the OPC Server itself.
As discussed earlier, one would also need to obtain an OPC DA ItemId -> OPC UA NodeId mapping file
Since the PI Connector for OPC UA is not shipped with an OPC UA client, I strongly recommend getting a robust OPC UA client that will be installed on the PI Connector for OPC UA. I personally recommend using UA Expert, which is the UA reference client and by far the best one I have personally used.
1- Data Selection
Once, the data source has been added, the first step is to perform data selection. In this example, we will connect to an Ignition SCADA Gateway OPC UA module.
On the DCM, select the OPC UA Connector, then navigate to the Data tab, select the data source, and perform the data source content discovery.
Once data source discovery has completed (can take a long time if the source OPC Server is large), we are ready for the data selection process.
To perform the data selection, one can either manually create rules, or use the data selection UI to select what nodes should be brought in to PI as PI Point / AF objects.
2- OPC UA to existing OPC DA PI Point mapping
Export the Tag Naming Worksheet
Open the exported spreadsheet and the PI Points with their instrumenttag, and use VLOOKUP to match the new OPC UA Points to their existing OPC DA PI Points (exported with PI Builder)
Save the Tag Naming Worksheet and Import it back to the connector using the Import function and verify that the connector accepts the custom name.
3- Remove PI Point Prefix
In order to match the custom name to the existing opcda PI Points, it will likely be necessary to not use PI Point Prefix on the destination PI Data Archive(s).
4- Define the behavior for automatically detected model changes on the OPC UA Server
NOTE: Your OPC UA server must implement the GeneralChangeModelEventType so that the connector can react onto these notifications!
See OPC UA - Model Changes and impact on the target PI Server for more details.
5- Stop the PI Interface for OPC DA and start the PI Connector for OPC UA
Note that data density may be slightly different since the PI Connector for OPC UA leverages subscription. For more details on how it works, one of the best resources is Unified Automation's OPC UA Subscription Concept.
You are now all set to use OPC UA and have (hopefully) successfully migrated to OPC UA and you can go back and tightened up your DCOM settings if the old OPC DA nodes (server and clients) will not be decommissioned.