OPC DA. OPC UA. COM. DCOM. What is this… alphabet soup? The terms do get confusing, but if you stick with me we’ll sort it all out. I'll cover a brief history of OPC, what it is used for, and why it is important. Then I’ll explain OPC DA and OPC UA and how they compare.
How It All Started
If you go back far enough, OPC used to be OLE (Object Linking and Embedding) for process control. Because no one remembers OLE and what it stands for, OPC was re-acronymized as Open Platform Communications, which is actually a pretty good definition of what it is.
In the 90s, PC and Windows-based systems became increasingly popular as a lower-cost industrial automation platform. These systems, in conjunction with PLCs, provided an alternative to traditional minicomputer-based systems such as the IBM AS/400 or DEC VAX.
With so many PLCs and other automation devices, SCADA and HMI vendors had to develop protocols from scratch for any device their system was to support. At that time, a specification called the Component Object Model (COM) was also released.
The COM spec was a model software vendors could use to loosely couple the various components in their product. COM allowed two different developers to use each other’s software without knowing the details of it, as long as they had the interface definition. Programs could even discover the functionality of other programs by doing queries on the interface.
The conversation might look something like this:
SCADA software: Hey device driver, do you speak IEC-82950-3 protocol?
Driver: Yes! And here’s a shortcut to call the driver so you don’t have to ask next time.
This Far Side cartoon summarizes it well:
COM allowed software developers and vendors to work independently knowing that in the end, the components would all work together as intended. This model is ideal for the process control world, where a plethora of SCADA and HMI systems need to communicate over a variety of media types using different protocols.
OPC DA is Born
OPC DA (OPC Data Access) arrived in 1995. OPC DA was built on COM, leveraging a technology many developers were already familiar with.
It is important to note that OPC DA, and all of COM for that matter, is built around the concept of an interface. An interface is a specification detailing which properties and functions can be used and what they do.
This way the developer has the freedom to create their software product how they want, yet software users will know what functions are available and how to call them. The interface ensures that the user and developer have common standards on which to develop their products.
What does all that mean? To provide access to their brand of PLC, all a vendor needs to do is provide a driver that implements the OPC DA interface. At that point, all SCADA, HMI, Historians, and other software that understand how to call OPC DA can access that PLC. Each SCADA vendor does not have to write a new driver to talk to the PLC.
This all sounds great. And, in fact, OPC DA has been very successful. Just about every SCADA vendor supports it and there are hundreds of OPC DA servers available to communicate with every process control device imaginable.
To ensure standards are followed and everyone plays nice, the nonprofit OPC Foundation provides tools to validate a vendor’s interface and also offers certification lab services. Almost all vendors providing industrial automation equipment and software are members of the foundation. OPC is the one universally accepted standard for exchanging data between different industrial automation systems.
How does OPC DA work?
The following diagram shows a typical OPC DA configuration.
Let’s say the SCADA client has a tag (or item) that needs its data from a PLC. This item is requested from the OPC server by name. The server grabs the data from the device and, if all goes well, the data is returned to the SCADA.
But not everything goes well all the time. So OPC returns the data as a VQT item. V is the actual item value. Q is the quality of the data, whether it is unavailable, stale, or another issue arose from trying to read the data. T is the timestamp when the data was read.
Other OPC features include the ability to browse items the server has access to, specify a scan rate (how often the server reads the data), and read/write items as a group.
Eventually, other OPC interfaces were developed that were no longer operating at the device driver level: A&E to handle Alarms and Events and HDA to handle Historical Data Access.
All this was a big leap forward, but as Jeremy Clarkson is fond of saying, “There is a problem”. Let’s get into it.
- There is not much security on COM interfaces and it’s difficult to manage security on DCOM interfaces.
- Communication is not platform-independent. It is very much a Windows product.
- Data is often returned in the Least Common Denominator format, typically a character string, which causes all kinds of data conversions to take place.
- The protocol was not designed with the internet and firewalls in mind.
- OPC has a lot of layers that can negatively affect performance.
- There is limited data type handling.
For example, trying to get the DCOM security configuration correct usually has one of two outcomes:
A. Disable all security (permitting any and all access).
B. Purchase an OPC “tunneling” program that handles the remote access for you.
Classic OPC DA was originally designed as a device driver interface, but it evolved into much more than that. Clearly, the OPC needed to meet the changing needs of process control.
Enter OPC UA.
What is OPC UA?
OPC UA (OPC Unified Architecture) is the next evolution of classic OPC. It starts with an abstract data model and builds via layers from there. This approach means tomorrow’s OPC UA may have new features, data types, and more, but can build upon what OPC UA has today.
OPC UA can organize multiple information models that are optimized for a class of client. The data format and needs of a client needing historical access can be and are different from the client simply needing the current VQT of a tag. UA supports this at multiple levels so the ability to handle different client data needs is a fundamental design feature and not just an add-on.
This approach allows other information models to be built in the future. Compare that with OPC classic A&E and HDA. Those interfaces always felt like they didn’t fit in well with the rest of OPC and were never used as much.
What are the key benefits of OPC UA?
1. Platform Independence
OPC UA is built on standard protocols and not on Windows-centric technologies such as COM and DCOM. The initial specification defined an optimized binary TCP protocol for on-premises data access.
Building on that, Web Services, XML, HTTPS, and other internet communications were implemented to allow firewall-friendly access from off-premises. OPC UA uses an Endpoint URL to specify what wire protocol to use. The binary protocol is opc.tcp://Server and http://Server is for Web Service (SOAP).
Otherwise, OPC UA works completely transparent to the API caller. OPC UA servers exist for Linux, Mac, and Windows and can be developed for any OS with basic TCP functions available. All you need is a software development kit (SDK) from the OPC Foundation. Or you can always start from scratch if you enjoy that sort of thing. SDKs exist for .Net, Java, C/C++ and I’m sure many others.
2. Unified Access
Rather than having DA, A&E, HDA specifications, there is a single access point to OPC UA. The client can discover what information models a given OPC UA server supports, and use/not use them as appropriate.
Regardless of the platform, all OPC UA servers must implement the same base services and API that allows this to happen. Regardless of the information model being used by the client, it is independent of the wire protocol specified by the client.
3. Security
If you want to see a grown engineer cry, mention DCOM security configuration. It’s not intuitive... and certainly not platform-independent. Building on industry standards, OPC UA makes use of internet security standards such as X.509 certificates.
Authentication, authorization, and encryption are done via familiar methods. OPC UA applications can choose what certificate store to use. So, for example, you can have a server that runs on Windows and uses Active Directory. If you, as a controls engineer, don’t know a lot about the care and feeding of certificates, your friendly neighborhood IT person does.
4. Flexible Data Types
Since OPC UA is an open service-oriented architecture, any vendor is free to build their own data information model that fits into the OPC world. Data types, structures, objects all can be implemented. The specifications don’t place any practical limitation on what can be built... everything from a simple bit to a complex XML document.
5. Open
The specification is freely available and implementable under the GPL 2.0 license. The OPC Foundation has documents and examples on how to build OPC clients and servers.
IEC-62541 is the specification for OPC UA. As of this writing, it is well over 1300 pages long. It is a big specification by any definition, and as industrial process control continues to evolve, I would expect it to grow as well. Initiatives, such as Industry 4.0, IIoT will all contribute to OPC UA. One of the more exciting trends is seeing PLCs and other devices being delivered with an OPC UA server built-in.
Should I use OPC DA or OPC UA?
If you have a choice, always take OPC UA. There will be times where a legacy device is only supported under the DA specification. However, for future development choose UA-based systems whenever possible.
Every modern SCADA platform has excellent support for OPC UA. Aveva, Inductive Automation, and Kepware have been at the forefront of OPC UA's development and adoption. And that’s good news for us controls engineers. The days of struggling with proprietary device drivers or banging your head over DCOM security settings are passing.
As always, good luck. And if you fancy yourself an expert on OPC, please check out our career page. We’re always looking to hire more control freaks!
COMMENTS