OPC and OPC UA – How to get Windows to talk to industrial devices
What is OPC? We have many ways to integrate field devices with control systems and other equipment to exchange data. OPC communication – we’ll explain what “OPC” means in a minute – can ease integration without requiring multiple drivers or other extras.
What is OPC?
We have many ways to integrate field devices with control systems and other equipment to exchange data. OPC communication – we’ll explain what “OPC” means in a minute – can ease integration without requiring multiple drivers or other extras. Today, let’s learn more about this intriguing concept.
Even if you’ve never heard of it, OPC shows up a lot to integrate smart devices into various platforms. So you need to understand OPC and OPC UA, how they differ, and how they can help in the fourth industrial revolution.
History of the OPC protocol
Before we started standardizing, we often had problems with equipment integration. Many vendors had – and some still have – proprietary protocols that blocked devices from other brands. Then along came Microsoft. By the 90s, Microsoft had gained a foothold in automation with its Component Object Model (COM) and Distributed Component Object Model (DCOM) software.
In 1995, Fisher-Rosemount (now Emerson Automation Solutions), Rockwell Automation, Intellution, and Opto 22 formed a group to develop a solution based on COM and DCOM. They based it on Microsoft’s Object Linking and Embedding (OLE) and called it OLE for Process Control, or OPC. A year later, they released the first product of this collaboration, OPC DA (Data Access), during the annual ISA event. In the same year, they created the OPC Foundation in the U.S.
1990s – Microsoft in the industrial branch with COM and DCOM
1995 – Creation of OPC
1996 – Launch of the OPC DA (Data Access) and creation of the OPC Foundation
1998 – Foundation conversion of current solutions to web services
1999 – Launch of OPC AE (Alarms and Events)
2001 – Launch of OPC HDA (Historical Data Access)
2003 – Launch of OPC Complex Data, Data eXchange and XML-DA specifications; creation of OPC UA
2004 – Release of OPC Commands specification
2006 – Release of OPC UA version 1.0
2007 – Development of OPC certification program and testing labs
2009 – Launch of OPC UA for equipment analysis (ADI)
2010 – Release of OPC UA IEC61131 and first equipment with OPC UA
2012 – Launch of IEC 62541
2013 – Launch of OPC UA 1.02 and OPC UA for ISA-95
Note: At this point, we’ll refer to the first iteration of OPC as OPC Classic.
Limitation of OPC Classic
As you can imagine, OPC Classic only works on Windows, the most popular system. But other operating systems have become increasingly common, such as Linux and the macOS. Therefore, OPC Classic won’t suit customers who don’t have Windows platforms.
To solve this, the Foundation developed OPC UA, which we’ll go over a little later. For now, let’s review OPC Classic’s derivatives.
What is OPC DA?
In 1996, the group that would become the OPC Foundation launched its first product, OPC Data Access.
DA brings client and server together with specifications related to the acquisition of real-time process data. It focuses on keeping communication constant between various types of equipment, such as interfaces and controllers. By communication, we mean the exchange of data representing values, information quality, and timestamps, setting aside events and history.
What is OPC AE?
Around 1999, the Foundation launched OPC AE (Alarms and Events, sometimes written as A&E). This product works like DA, but for alarms and events instead of process data.
However, the AE server doesn’t generate alarms and events itself. It reports the alarms and events generated by devices equipped and set up with such configurations.
What is OPC HDA?
In 2001, we had the emergence of OPC HDA (Historical Data Access) to handle historical process data. As you can probably guess, you would use it with DA. The DA server would collect its data and send it to the HDA server. There, you could access it to review process patterns or create tables and reports on the history of your process.
Example of OPC Classic application
Consider a project that needs level measurement for several tanks in the plant. However, the plant has little structure to support typical meter setups. So let’s use free-wave radar level meters with wireless communication.
Typically, in this type of application the customer requests a test to see the technology in operation. So we’ll demonstrate using field devices in a mesh network. We’ll also use a gateway to manage the network and convert signals into standard output. The gateway in question has several protocols for integration with the control system.
With OPC Classic, you can download a HART server free of charge or use a proprietary server. Then, you install the OPC server software on a designated server and connect with the gateway using a communication port. Once you have it all set up, the control system collects data through the OPC client and makes it available for operators to view.
DCOM firewall problems
Although OPC Classic had a lot of benefits, it did have a significant problem with its DCOM protocol.
As I said earlier, OPC developed from Microsoft’s COM and DCOM protocols. DCOM, an extension of the COM protocol, would communicate between devices and with distributed systems.
However, the DCOM protocol had a configuration issue that caused a lot of problems with firewalls. This problem and the limitation of the Windows operating system led to the creation of OPC UA.
What is OPC UA?
UA means Unified Architecture. Its launch in 2008 brought new possibilities for the OPC structure by expanding its reach.
The UA protocol ensures interoperability between digital systems, a solution fully in line with new concepts such as the Internet of Things (IoT) and Industry 4.0. You can read more about those concepts in this article.
Concepts aside, UA supports all functions of OPC Classic. However, while OPC Classic only works with Windows systems, UA has a lot more flexibility. Systems such as Apple, Android, and Linux work with UA.
You’ll find several equivalent functions between Classic and UA, such as hierarchical data, access permissions, and event notifications. In addition, UA works with many types of hardware such as traditional computers, programmable logic controllers, micro controllers, and cloud-based servers.
Message format and security
UA uses two message formats, binary and XML. Binary is more common at the equipment level, because it requires less power and provides more speed. The format’s designers created it with efficient encoding and decoding in mind.
The XML format performs high-level information exchange. Clients who use UA can interpret the data like any other XML data. Much larger than UA’s binary, this format has the power to serialize and deserialize data.
As for security, OPC Classic assigns all security to the Microsoft COM and DCOM protocols. But UA has its own security scheme, using public key infrastructure (PKI) and certificates exclusively for industrial standard x.509. It also uses authentication, encryption, and more security measures.
UA uses two types of transport protocols between client and server, OPC TCP and SOAP/HTTP(s).
The TCP protocol is dedicated to UA clients, so only they can read the transmitted information. The client and the server exchange data securely packaged in binary structures.
The SOAP protocol envelops messages and sends them using HTTP(s). Unlike TCP, you can use an ordinary browser to pull up your data, giving you nearly limitless possibilities for data work. You’ll see this standard widely implemented in the industrial field.
Benefits and use in IIoT
UA offers many advantages, such as connectivity between platforms, security, and expandability. Several discussions on the Internet point to UA as the great key to unlock IIoT systems. MQTT, another standard that frequently appears in discussions, has less transparency.
UA greatly softens the issue of integration between vendors. Now we must wait for vendors to make all their data available in this protocol.