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.

  • Hello,

    The best way I found is to decommission the PI OPC UA connector and install KepServerEX, by PTC and add the OPC Connectivity Suite. Returning to an reliable, and flexible PI OPC DA Interface with the KepServerEX OPC as data source.

  • Good list. Unfortunately its the tip of the iceberg in my opinion.

     

    For me the biggest issues are related to the RAM (Reliability, Availability, Maintainability) of the system. There are way too many KB articles or tickets where the "corrective action" is to restart either the connector service, or delete the DCM routing and put it back.

     

    Don't get me started on buffer corruption. I wish I knew why OSI/AVEVA felt they had to re-invent the wheel with the Tau buffer. The pibufss has been around for ages and is super reliable and stable. I've never experienced any issue with pibufss. Instead with Tau if you restart the connector (as required by some KB to solve an issue) then you will be sitting with buffer corruption. I've actually given up on the possibility of 0% data loss.

     

    The Tau buffer also re-invented the wheel on exception and compression. Compression is not supported. Exception only works in tags only mode (https://customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=OPCUAConnectorExceptionCompressionsetup).

     

    As for tag only mode, I am not sure if I am unique in the world, but changing the connector from normal mode into tags only mode pushed the RAM consumption from 1.5GB to over 3GB. I also have a funny feeling that it is eating more on the Relay machine as well.

     

    As Roger has mentioned, OPC UA is the protocol of the future (especially w.r.t. cyber security) and as customers we are pushing for adoption, but we seem to be getting let down by PI. We are left with hard choices: the Connectors are not robust and very resource intensive (bigger computers = more money); Adaptors are limited to 100k, but more what would prevent me from adopting is that they are still new at a time when the connector technology is not yet mature either.

     

    P.S. - Roger, I don't like the use of the ellipsis in the title - I came here looking for answers, and found more questions Stuck out tongue closed eyes

  • Hello together.

    From my point of view -as a programmer - the whole connector is a great desaster. Not only the price is a cheek for this piece of software. Because uf the concept you cannot stop/start a single datasource. All configurations are packet together. So there is no chance to simple move a datasource from one collector to another on a other computer. Also the interface is unidirectional. Why the hell they don't support the given OPCUA features? I don't even want to list the problems mentioned above. Tons of suggestet workarrounds for not solved bugs. Especially the buffering and renaming topics. OsiSoft/AVEVA should see that OPCUA ist one of the important protocols now and in the future.

    Now i feel better...

  • Not that patching is critical, but the subsequent reboots do help in obfuscating any issues with long-running interfaces / collectors.

  • Not sure if just Google Chrome is still the only option, now that Microsoft Edge also uses the same Chromium framework. But did not test, nor has this been updated yet by Aveva, so still a grey area.