17 Replies Latest reply on Jun 29, 2017 1:38 PM by jamespr Branched to a new discussion.

    PI OPC UA interface

    Johan_Van_Acker

      Hello,

       

       

       

      A custgomer asked us:

       

      Is there already an PI OPC UA interface available?

       

       

       

      As I saw here the UA develpment was stopped in 2013. Any changes on this matter?

       

       

       

      Johan

        • Re: PI OPC UA interface

          Hello Johan,

           

          We are committed to build a PI Interface for OPC UA. Please see this presentation (~25th minute) from the 2012 User Conference. There's no committed schedule yet but it's supposed becoming posted with the PI System Roadmap. To better prioritize the work, we are looking for how many requests we are getting.

           

          I am sure the PI Interface Product Manager would like to comment your question too. I'll contact him.

            • Re: PI OPC UA interface
              Johan_Van_Acker

              On the roadmap no mentioning of the OPC UA interface 

               

              Then we may go for the Kepware OPC UA tunneling and use the standard PI OPC interface.

               

              Johan

                • Re: PI OPC UA interface
                  ccoen

                  Hi Johan,

                   

                  Thanks for your interest in a interface to OPC UA.  I'm the Product Manager for PI Interfaces and PI Connectors.  This is still something we would like to deliver, yet we have had some other priorities and basic technologies to work through first.  We are now developing new interfaces on a new technology called PI Connectors.  This is something we covered at the UC in San Francisco in the spring and will also cover at the UC in Lisbon next week.

                   

                  I'm curious to know the source system underlying the OPC layer.  Is that something you could share with us on this forum or privately?  We're using that information to explore writing a native PI Connector for the most popular systems.  Imagine a native PI Connector that may or may not use OPC UA, but that is tuned to your source system so that you have very little to configure.  That's our goal where there is a good enough use case for many customers.

                   

                  For now, using your OPC server to expose OPC DA would be the most expedient way to go.

                   

                  Regards,

                   

                  Chris

                    • Re: PI OPC UA interface
                      Roger Palmen

                      Johan,

                       

                      Is there any good reason why the customer asks for OPC UA? In general i find it does not resolve any real-world problems, and that customers ask for it because "OPC UA is supposed to be the new version of OPC".

                       

                      Just curious to hear!

                        • Re: PI OPC UA interface
                          Robert Raesemann

                          I haven't had the opportunity to use UA, mainly because PI does not support it, but I was under the impression that it would make things like tunneling through firewalls easier. Currently you have to resort to using a 3rd party tunneler so that you only have to open one port in the firewall. The 3rd party tools are mostly reliable, but I have seen problems with them on occasion, and it is just adding one more point of failure to the mix. It is also an additional cost that could easily be eliminated.

                           

                          It should also simplify security in mixed domain environments, like I seem to encounter on a regular basis. It provides for certificate-based authentication and link encryption based on web standards that I would argue are far superior to the DCOM-based approach that we have been stuck with.

                           

                          It also allows for servers that are not Windows-based, which means that we could ultimately see the OPC interface built into the control device.

                           

                          As I said, I haven't had the opportunity to use it yet, but from what I have read and the presentations that I have seen, it seems to fix a lot of real-world issues that we have to deal with everyday. The people that I have spoken to who have used it have been pretty positive about it. Ultimately I think that OPC DA is just good enough that it lessens the push to move forward. OPC UA is not quite as big of an improvement as moving from DDE to OPC was, but I think that you can make some pretty convincing arguments that it is a pretty big step up.

                           

                          I know that Kepware servers support OPC UA today. If I had access to a PI OPC UA interface, I would have recommended it on the last system that I worked on. I'm pretty much ready to take the plunge as soon as it is available.

                            • Re: PI OPC UA interface
                              Roger Palmen

                              I agree that that arguments given (tunneling through firewalls, mixed domains, non-windows support) are a huge technical benefit of UA. I mainly argue that these arguments just do not manifest sufficiently, or that UA does not solve the underlying issues sufficiently to be of such a benefit that there is significant adaption.

                               

                              I do believe UA will find it's place in the future, but i'm not convinced it will be to resolve the limitations of the DCOM-based 'classic' OPC.

                               

                              Anyone have a 'real' success story of UA? With details on architecture? I just don't know of any...

                              • Re: PI OPC UA interface
                                Rhys Kirk

                                Robert Raesemann

                                I haven't had the opportunity to use UA, mainly because PI does not support it, but I was under the impression that it would make things like tunneling through firewalls easier. Currently you have to resort to using a 3rd party tunneler so that you only have to open one port in the firewall. The 3rd party tools are mostly reliable, but I have seen problems with them on occasion, and it is just adding one more point of failure to the mix. It is also an additional cost that could easily be eliminated.

                                 

                                It should also simplify security in mixed domain environments, like I seem to encounter on a regular basis. It provides for certificate-based authentication and link encryption based on web standards that I would argue are far superior to the DCOM-based approach that we have been stuck with.

                                 

                                It also allows for servers that are not Windows-based, which means that we could ultimately see the OPC interface built into the control device.

                                 

                                As I said, I haven't had the opportunity to use it yet, but from what I have read and the presentations that I have seen, it seems to fix a lot of real-world issues that we have to deal with everyday. The people that I have spoken to who have used it have been pretty positive about it. Ultimately I think that OPC DA is just good enough that it lessens the push to move forward. OPC UA is not quite as big of an improvement as moving from DDE to OPC was, but I think that you can make some pretty convincing arguments that it is a pretty big step up.

                                 

                                 

                                 

                                Robert Raesemann

                                I know that Kepware servers support OPC UA today. If I had access to a PI OPC UA interface, I would have recommended it on the last system that I worked on. I'm pretty much ready to take the plunge as soon as it is available.

                                 

                                Mostly the UA Servers are wrappers around DA, Matrikon has a similar offering. 

                              • Re: PI OPC UA interface
                                dippolds

                                We have new equipment vendors who only interface using OPC UA and have active projects to interface to them.   While new, the future is here and it is unfortunate OSI is not planning a OPC UA interface.

                                  • Re: PI OPC UA interface
                                    mlemus

                                    Hey Sean!

                                    It's Marc Lemus, from Merck!  I'm not with them anymore.  Out in California working for Aera Energy at this point, as a contractor.

                                    I noticed that many OPC Server vendors are offering "gateways" for OPC UA which I believe then makes the OPC UA look like an OPC DA, then PI-OPC can connect.

                                    Seems like an issue but until OSIsoft creates a "connector" we may be stuck with that option.  Specifically TOPServer and Matrikon.

                          • Re: PI OPC UA interface
                            Paul_Booth

                            From what I have read OSI is not pursuing OPC UA, which I think is a shame. Having set up a large number of OPC DA systems, they all have the following problems. Setting the DCOM, always. This always adds to the complexity, hence cost, of implementation, from agreeing security (always non-domain based - developers really should get to grips with the fact that mixed domain is the normal environment for control systems), to getting through firewalls, and interfaces that can't tell when they've locked up. OPC DA, whilst successful, does have built in problems - it is nigh time OPC data collection was released from the Windows shackles! OPC Servers are often just wrappers round native data collection anyway, so if UA is another wrapper, it's one that makes the system better! Using Tunnellers are OK, depending on the throughput you expect, but that's just a wrapper round the communication channel.

                              • Re: PI OPC UA interface
                                pmackow

                                My point exactly.

                                At the moment third-party tunelling layer may be the easiest solution. Maybe there should be an OSIsoft tunnel included in PI-OPCInt setup...

                                 

                                BTW, there is another, old and almost forgotten, communication layer over OPC-DA, namely OPC-XML via HTTP, used mostly in small separated servers like wind farms producing small amount of data. And there is even OSIsoft PI-XML Interface supporting it.

                                • Re: PI OPC UA interface
                                  ccoen

                                  Paul Booth wrote:

                                   

                                  From what I have read OSI is not pursuing OPC UA, which I think is a shame. Having set up a large number of OPC DA systems, they all have the following problems. Setting the DCOM, always. This always adds to the complexity, hence cost, of implementation, from agreeing security (always non-domain based - developers really should get to grips with the fact that mixed domain is the normal environment for control systems), to getting through firewalls, and interfaces that can't tell when they've locked up. OPC DA, whilst successful, does have built in problems - it is nigh time OPC data collection was released from the Windows shackles! OPC Servers are often just wrappers round native data collection anyway, so if UA is another wrapper, it's one that makes the system better! Using Tunnellers are OK, depending on the throughput you expect, but that's just a wrapper round the communication channel.

                                  Hi Paul,
                                  As I wrote in Sept in this thread, we are committed to having OPC UA connectivity to data sources.  We are in development and seeking customers that have source systems supporting OPC UA.  We've gotten a good number of requests from customers so far identifying their source system and may focus on a few of those first.  Testing will be key for this.  From our experience with OPC DA we had to handle many situations where, for many reasons, the OPC server did not follow the standard exactly or had behavior that was not prescribed well enough by the standard.  We expect similar challenges with just about any standard, including OPC UA but time will tell.  So if anyone is willing to test out this connector, let me know what source system you have and we can talk.

                                   

                                  One thing great about PI Connectors is that they are so easy to configure.  For this reason, we may also produce a few specific PI Connectors for very popular systems that serve up OPC UA.  This would allow us to take any behaviors specific to those systems and build it into the connector so that the customer doesn't have to read lots of docs and figure out the right settings for that system.  We haven't committed to any yet but you may see a few like this.

                                   

                                  By the way, we haven't posted this on the roadmap yet, but will in the coming months as we get further along.  Stay tuned.

                                • Re: PI OPC UA interface
                                  jamespr

                                  Team, what are the benefits beside, easy configuration, to use OPC UA vs PI OPC Interface? One particular use case that I see for OPC UA is monitoring the state of the OPC Servers. Since you can write directly to AF, this facilitate the creation of monitoring tools and notifications.