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.

  • One of the topics under "long list of smaller issues" to me is the usage of a web portal to admin the tool, and the requirement to use Google Chrome. This means that there is an additional piece of software that needs to be validated by cyber sec teams and kept up to date, not to mention that Chrome is famous for its resource greed.

     

    For sure ICU has problems, notably taking forever to open when connecting to a DA with lots of interfaces and / or "far away" on the network, but once loaded its pretty snappy and light weight.

     

    Maybe its only me, but with the web portal of the connectors I am not often sure if the page is really up to date with the real status, and if I click refresh in Chrome then sometimes the status is definitely out of sync e.g. connector says stopped and all data sources disappeared, but on the DCM page everything is green and normal. In that situation the only way to guess the real state I found is to check Windows Resource Monitor for network traffic and RAM consumption of the connector service. If the argument is that the DCM should only be used to manage the connector, then my response would be that all the bits and bytes relating to the connector web page should be scrapped, reducing the weight on the system and closing another potential security attack surface and that the DCM should be managed through a specific AVEVA app, not a web UI.

  • If you mean Windows patches, I am not sure that patching is that critical to the working of the system on a day-to-day basis. In any case we do go around all our systems the day after "Patch Tuesday" to make sure WSUS has pushed what needed pushing and to check if the machines need rebooting. This is more to improve our security posture. If a Windows patch is critical to PI functions, then I expect AVEVA to make the appropriate announcement.

     

    For sure managing systems over slow connections is super frustrating, but even if you check OSIsoft's own video on the topic, its not only to manage bandwidth at the connector, but also storage on the DA and bandwidth to all end users.

  • PS: That there is no exception reporting on the collectors has never been an issue so far. Even not when dealing with slow connections. There are often more limiting factors in managing remote devices on slow connections than the datarate from a collector.

    In some past, yes, but currently there are so many options to deal with this.

  • Luckily did not have too many issues with buffer corruption so far! Maybe because we do monthly patching on our redundant pairs that we stay out of the issues.

     

    But same here. That the OPC-UA collectors are flawed is somewhat acceptable. That there is no clear path forward for the designated follow-up, PI Adapters, is what really worries me.

  • Hi Gabriel,

    Thank you so much for responding! Finally found some time to respond on your items.

    I think this discussion is important as i want this to improve. I tried to look at OPC-UA as a step-up from classic OPC-DA with it's known limitations and limited lifetime left for DCOM. But this turned out to be a step back so far, so hoping we get some progress over time. I don't see the PI Adapter to solve this problem if these issues are not acknowledged and targeted.

     

    Failover

    I agree that Server-level failover is vague and non-existent, but now we end up to use 4 KepWare middleware instances to deal with redundancy between 2 redundant OPCservers and 2 redundant OPC-UA collectors (V1). I just spent a lot of money on PI software, and then i need to explain to every site again i need to procure additional software to make this work. This is not world class software from OSIsoft / Aveva. Others solved this problem, so i expect OSI/Aveva to be able to do the same. Or at least try.

    Scaleability / PI Adapter

    Not saying it is impossible to create multiple PI Web API instances. But we could have 100+ OPC-DA interfaces feeding into our 1M+ tags PI Data Archive on a single node. Now we need 11 nodes to do the same. That is a ten-fold step backward. No it's not easy to spin up 10 additional machines as each will cost me another €1000+ a month (if not more...) to run and maintain, adding up to €120K per year for something we did not need using PI Interfaces.

    Routing

    I might not have explained this wrongly. Routing is just the wrong word for what it does. It does not do any routing, it just lists the relay to use, nothing more. So connecting different sources to different targets is not something that you can do, unless you create multiple relays and manage each flow from source to target as a separate stream with separate relays. It's just a nuisance. The relay does have it's purpose, but that's a different story.

    Tag renaming

    There are KB articles for both v1 and v2, and i did pursue a lengthy discussion with techsupport. While theoretically you can do some tag renames, it is just not officially supported. See e.g. this KB: https://customers.osisoft.com/s/knowledgearticle?knowledgeArticleUrl=How-to-rename-tags-PI-Connector-for-OPC-UA-2-x

    No polling

    Good to see we agree on this. Subscription only seemed like a good idea, but the classic OPC-DA interface has quite some workaround to soften the issues and limitations on the server side. In practice, this just does not work or is not under control. Finding out how or if to control how an OPCserver can be adjusted to send data more often, if at all possible, is just not an option. So stepping back to polling seems to be the better option for now... And again here, this is something i can solve with middleware, but not with OSI/Aveva.

     

    Long list of defects / functional limitations

    A long list of smaller issues still bogs down the use of the application. You can absorb some issues, but if the list grows and combines with the other limitations, the question starts if this is sustainable. It adds questions to a large pile.