OPC UA Portal

Check this page for whitepapers, how-to articles, presentations and more information about the emerging OPC UA standards.

In order to obtain OPC UA specifications documents, you will need to be a member of the OPC Foundation.

• Video Tutorial: Secure OPC UA Connectivity with Cogent DataHub
• DataHub V8 and You - Common Questions & Answers
• What Can Cogent DataHub V8 Do For You?
• Analyzing OPC UA Communications Using Wireshark
• Introduction to OPC UA Seminar
• Is Your OPC Tunnel up to OPC Spec?
• Accessing Wonderware System Platform via OPC UA

Other OPC UA Articles

Here is a paper that appeared in the Industrial Ethernet Book in February 2007.

By John Weber, President, Software Toolbox Inc., Nathan Pocock, VP Development, Software Toolbox Inc.

Is your existing OPC DA server delivering the data you need to your HMI/SCADA system the way you need it to? Then it’s not obsolete.  As shown in Figure 1, OPC UA in large part seeks to address the issues of sharing information in more complex data structure formats with the Enterprise level MES and ERP systems in a way they can understand.   OPC UA does this by providing the means to handle complex data structures and transport them in a secure, reliable, service oriented architecture (SOA).  But the data from the plant floor devices still has to come from somewhere.  That “somewhere” is for now OPC DA Servers and will continue to be because of the large installed base of OPC DA servers.

At the Level 1 and 2 plant automation systems, OPC DA is and will continue to be the most recommended method of communications between hardware and software systems within those layers. OPC UA expands the horizons of where data gathered with OPC DA can and will go.  It does this because OPC UA sits on top of OPC DA servers, gathers data through the OPC DA interface, and serves it up in a Service Oriented Architecture to upstream business systems.

Will there come a day where there are OPC UA Servers that talk directly to devices? Yes, that will eventually happen as this is one of the design goals with OPC UA, to provide a complete top-to-bottom implementation that can be used to retrieve the data from the plant-floor, and provide it to services at the Enterprise level. However, if you can easily put an OPC-UA/DA interface or wrapper on top of your existing OPC-DA solutions, and move data where you need to upstream in the way you need to, are you going to be keen to rush out and replace your OPC DA servers? Probably not.  That would require an upgrade to your HMI/SCADA clients which will take time and money.  The OPC Foundation is working to release OPC UA-DA wrappers that will enable existing OPC DA servers to communicate with OPC UA clients as suppliers release them, thus protecting your investment and allowing you to move forward.  Similarly, OPC DA clients will be able to use a wrapper to talk to OPC UA enabled servers.

We don’t see our fellow OPC Foundation member companies suddenly dropping support for their OPC DA products.  They may take advantage of the OPC Foundation’s promotion of the new standard to let you know about their plans for OPC UA and to get your attention to get you to become a customer.  All suppliers use new technology announcements as a means to show they are staying current.  A healthy supplier of OPC DA products that wants to remain healthy and retain your loyalty isn’t likely to just obsolete their DA products right away.  They will offer a clear migration path forward and support their OPC DA products for many years to come.

People are afraid that Windows Vista is going to pull COM and DCOM out from under them and their existing OPC DA investments will fail.  That’s simply not true.  Too much of Windows software depends on COM/DCOM still and will for many years.  The surest way for Microsoft to insure that no one in manufacturing upgrades to Windows Vista would be to pull the plug on these technologies.  Although OPC-UA does provide a binary, web services based transport that is secure and firewall friendly, you still may not need to just rush out and go to OPC-UA.  If your systems are working reliably and delivering the results you need, and you don’t need to move data to upstream Enterprise level systems where COM/DCOM are not an option, then you may do well to continue on with your existing systems.   If you are having problems with DCOM, consider all your options.  Moving to OPC-UA may be one of them.  There are also a number of tunneling products on the market that essentially replace DCOM for you, and a wealth of information and tutorials on setting up DCOM that help many users get things going without having to buy additional software.

As with each new release of Microsoft Windows, a wide variety of new technologies become available for both end-users, network administrators and developers alike. Windows Vista, according to many experts, is the single-most biggest Operating System change Microsoft has made to date.

So which  new technology exists within Vista that should matter to me? Well, one of the most important that has been touched-upon already within this document.  Windows Vista contains a technology they call Windows Communication Foundation (WCF) which is a new system that you could say, is intended to replace DCOM as the transport allowing data to be exchanged between software/hardware whether they are running on the same computer/device, or at different locations over the LAN or even the Internet.

What is WCF? In short, it’s an extensible architecture that allows you (the end-user and/or administrators) to configure underlying protocols for exchanging data and for remote procedure calls (RPC).  In street talk, WCF provides new tools for Windows applications to talk to each other.  Furthermore, applications that sit atop WCF are unaware of the underlying protocols that are being used as the transport below them. In addition to this, Microsoft is providing several protocols each with different goals in mind, such as Speed (binary), Security (encryption and integrity), and extensibility (Soap/Xml as raw-text). An API also exists for developers to create their own proprietary protocols that can be plugged straight into WCF.   The beauty of WCF is that you can build web-services that are unaware of the transport that carries the data.  This is a big leap forward from pre-Windows Vista operating systems.

So how does this fit in with OPC UA? While OPC UA was being designed and developed it was a goal to work with WCF for the reasons previously mentioned. However, at the time OPC UA decisions were made, release dates for Windows Vista were not known and WCF specifications weren’t set yet, so the OPC Foundation had to make a decision: wait, or create specialized protocols that can be used as a default and that also can be used on non-Windows Vista computers,). The OPC Foundation chose to not wait and go ahead and provide 2 key protocols: a highly optimized, performance conscious binary transport; and an XML transport.  Remember, OPC UA will eventually allow you to choose your underlying protocol whether it is provided by the OPC Foundation, using WCF or a custom protocol developed by a 3rd party.

OPC UA is an extensible architecture, meaning that it has been designed such that layer within its architecture can contain inter-changeable elements that will seamlessly work with those layers above and below it. Windows Vista adds to this capability by providing WCF which allows OPC UA to leverage existing technology seamlessly.

Before answering questions on performance, it is crucial to understand some key differences between how OPC UA exchanges data vs. OPC DA.

OPC UA digitally signs all messages before transmitting them. On the receiving end, the packet can be validated to ensure that it has not been tampered-with while in-transport. Furthermore, OPC UA can encrypt the data that is being sent. OPC UA can also encode simple types such as Booleans, Integers and Float’s etc. but also complex types such as Structures containing nested types of x-levels deep. Lastly, OPC UA requires each outgoing packet to be confirmed by the recipient otherwise the packet will be buffered and resent later.

OPC DA does not do any of the above. A given in technology though is that more capabilities can require additional overhead   Of course the CPU builders depend on that so there is a reason to buy their new chips! But how does this translate in REAL performance?  Some insight into where things stand on this come from some testing done by the OPC Foundation in the form of laboratory testing and running controlled tests where an existing OPC DA Server would provide data:

• OPC Data Client (written in C++)
• OPC UA Client (written in C# .NET)

All tests were conducted such that the OPC DA Server communicated to one Client only so as to keep the tests as pure as possible.  The tests included varying the number of items being used within a test, as well as the varying the frequency of generating new data values, which in turn causes the server to “push” the data to the clients.

The test was simple: measure the throughput of data between the OPC Server and Clients. The results were interesting but aren’t conclusive because at the time of the tests, there was debug code in the UA Client application and the API used was not a release build.   The tests did find that yes, a classic OPC DA Client could consume data faster, but keep in mind that the OPC DA client wasn’t doing any of the security checks that the OPC UA client was doing.  Another interesting finding was that for large, complex data sets, OPC-UA was faster, which makes sense because it was designed with complex data in mind.  OPC DA tends to be more tag or item oriented and thus complex structures can be more difficult to move with OPC DA.

A more important point about performance is to take some perspective and remember that OPC UA is targeted for Enterprise level applications.  Remember how we stated earlier that OPC DA is still a great fit for the HMI level?  The super high performance that is often desired is usually found at the HMI level.  As you go higher up the Enterprise chain, performance demands are eased, but security becomes even more important.  If you look at things in these terms, it’s not really relevant to ask OPC UA to be faster than OPC DA since the typical use case for OPC UA is a situation where performance constraints are often in seconds, not milliseconds like at the HMI level!

In summary, OPC UA will create opportunities for you to do more with your existing installed base of OPC-DA Servers and the valuable data they deliver.  You won’t have to tear out your existing OPC servers and replace them, and your vendor’s shouldn’t be rushing out to drop support.  For HMI/SCADA to device communications, OPC DA will remain the preferred method of connectivity and OPC UA will open the gates to the Enterprise.

John Weber is President & Founder of Software Toolbox Inc., located in Charlotte, NC USA with customers in 100+ countries.  Nathan Pocock is VP of Development for Software Toolbox, has been developing with OPC technologies for 6 years and has been working with .NET technologies since their inception, leading .NET development for Software Toolbox Inc.  Software Toolbox is a leading supplier of OPC client and server development tools and client/server OPC products as well as add-ins for all major HMI products.