Related
Recommended
Roger Palmen

I've written this blog post many times in my head, as frequently new issues or limitations of the OPC-UA options for PI pop up. After my latest learning i decided to write this down so that some awareness is created on the limitations. I always hoped OPC-UA would bring benefits over the classic OPC-DA connectivity, but as things stand to date, i have severe doubts. And especially as there is no clear vision / roadmap on datacollection i think this is a really big problem for PI. If we cannot collect data into PI scaleable and reliable, the future of PI is doubtful. OPC-UA should be the only protocol one would need in a modern environment, but PI does not provide a proper way to connect to OPC-UA


Below a brief list of major issues and limitations i've encountered while dealing with OPC-UA.

  • Connector-level redundancy / failover is not supported by Gen2 OPC-UA Collector, only by Gen1 OPC-UA connector
  • Source-level redundancy / failover is not supported by either Gen1 or Gen2 OPC-UA Connectors, except for 'transparent' source failover supported by the OPC-UA server (which i have not seen anywhere)
  • Failover only fires when connection to ALL datasources is lost
  • PI Adapter for OPC-UA does not support redundancy / failover (yet...)
  • PI Adapter for OPC-UA is not scaleable when used with PI Data Archive, as using PI Web API endpoint adds limitation of 100K data streams
  • Routing feature of Gen2 connector does not really do routing all data sources are combined into a single data stream to the destination(s)
  • Tag renaming on PI Connector Gen1 and Gen2 cannot be done without data loss
  • Advice only mode leaves slowly updating data stale and/or incorrect

And then there is a long list of defects and functional limitations to add to this.

  • It's now April 2024 and I found this post while trying to figure out my very first OPC UA Adapter. Looks like Roger is now is no longer working with PI but this post is still relevant.

    As I go through the process I keep wonder if it's just me. There's now a decent video on youtube on Adapter install yet it still leave a tons of question unanswered. It is, at best, very incomplete, the need for a Web API on the DA server end is implied but never spelled out. Also, speaking for myself, the lack of a "adapter configuration utility" is not a plus. I still haven't found a good way to migrate existing OPC DA Interface tags to OPC UA Connector/Adapter.

     

  • Hey Roger,

    Let me try to address a few of the items pointed out here - grouping them by category

    Failover

    Server-level failover

    Unfortunately, very very few OPC UA Server actually support redundancy as it is defined in the OPC UA specs. In my experience, the only large vendor that supports true redundancy (transparent or not) is Siemens. Most others do not (Kepware, Matrikon, Prosys, Ignition, Rockwell, Emerson, UnifiedAutomation (technically it could, it's available in the SDK but I have not seen it implemented in actual solutions)). They often provide some redundancy options (2 copies of the same server), but they do not abide by the specs and thus OPC UA clients can't consider them redundant (using ServiceLevel to determine what server to connect to).

    Anyhow, totally fair, if you have a server that does support non-transparent failover, you can only use OPC UA Connector 2.x. This is a feature that is being worked on the PI Adapter for OPC UA.

    Client-Level Failover

    This is definitely the main downside of the PI Connector 2.x. Not much more to say about this, other than acknowledging that it is really not ideal. This is a feature that is being actively worked on at this time for the PI Adapter (both server and client level redundancy).

     

    Scalability (PI Adapter)

    I don't think this is really fair assessment. You can easily spin up multiple PI Web API instances to process your OMF messages if you are sending this much events to a PI Server. If you really have a need for this and need architecture guidance, you can reach out and we can discuss this. It is relatively straight-forward.

    Routing

    I am not sure if I understand the issue correctly here. Yes, if you have a single PI Connector Relay and multiple PI Connectors feeding into it, the Relay will send all of the data to PI. What functionality / issue are you alluding to? Do you have a multiple connectors, one relay, and multiple PI Servers and want to send specific data from specific PI Connectors to specific PI Servers. If that is the case, you could simply have multiple relays. Anyhow, this is not a request I have heard much. Would love to hear more about your use case / pain points on this. Maybe there is a better approach.

    Tag Renaming

    Oh boy, that's a big one. There are definitely a couple high priority bugs with this one, but for OPC UA 2.x, you can rename tags without data loss. Say you have the connector sending data to the default name, you then add a custom name on the DCM (in the data selection), it will rename the tags for you. Then you can rename them again to whatever else, and it will rename them again to whatever other tags you want.

    For OPC UA 1.x (tags-only) and the PI Adapter, it doesn't perform the rename for you, so you would have some data loss during the restart to map the nodes to the new streams in PI. If your OPC UA Server has History, then you may not end up with any data gap, but there will be a short period of time where the connector wasn't collecting data. With the Adapter, you can also perform an on-demand history recovery to cover the gap, assuming your server has historical data.

     

    Data read by subscription only (not poll / direct read)

    There is no good workaround for this one. Technically, you can set the PI Connector / Adapter to subscribe to timestamp changes with the OPC UA Server (StatusValueTimestamp), but practically, this never really works, because the OPC UA Server won't actually update the timestamp and send an event to the client.

    This is problematic for slow changing points where it does not make sense to use STEP.

    As far as I know, there is nothing currently in the work to address this.

    It's both a limitation on the way OPC UA works (all data should really be coming from MonitoredItems (subscription)), but there is also no good solution implemented in the Connectors nor Adapter to address this in a different way.

    I feel your pain on this one Slight smile I have also been pushing this hard internally.

     

    Long list of defects / functional limitations

    I am not aware of too many high impact limitations besides the ones mentioned previously. Do you have anything specific in mind?

    A couple of issues around buffer corruption (which can be reprocessed, btw) is all I can really think of. Oh, and the lack of quality logging (but that's mostly for us to worry about Slight smile )

     

    -Gabriel

  • Thank you for inquiring and bumping up this thread. If you're looking for failover capabilities and buffering functionality, AVEVA Adapter for OPC UA should be suitable for your needs. The latest version of the adapter offers both server-level and client-level failover. As for buffering, in the event that your adapter's connectivity to the data endpoint (whether it be Edge Data Store, AVEVA PI Server, AVEVA Data Hub, or any combination of those three) is lost, the adapter will buffer data for as long as it takes to reestablish a connection or until you run out of disk space. That being said, I would like to hear more about your specific architecture and data throughput expectations to ensure that this is the best fit for you.

  • Hi,

    Can we review this discussion now that we are over a year further down the track. Is there any progress on the issues raised by the OP? As far as we can see, and I’m open to correction, there has been no update to V2 PI connector since we installed it 2 years ago. Is the OPC UA connector being developed any further? The failover limitation is a major stumbling block for us. In addition we frequently experience buffering failures.

  • I added an idea for an OPC UA Interface (as opposed to the adapter and connectors that are out there currently) https://pisystem.feedback.aveva.com/ideas/PIINTF-I-290