OPC UA, seen through the eyes of users

With the new OPC UA industrial communication standard, plant floor data will finally find its way to the business LAN.

4OPC Unified Architecture (UA) represents the OPC Foundation's most recent set of specifications for process control and automation system interconnectivity. Randy explains OPC UA from the perspective of those who will benefit most from this connectivity: end users.

OPC is an industrial communication standard that allows manufacturers to use data to optimize production, make operation decisions quickly, and generate reports. OPC enables plants to automate data transfers from a control system such as a Programmable Logic Controller (PLC), distributed control system, or analyzer to an industrial software application such as a Human Machine Interface (HMI), historian, production system, or management system.

OPC is typically found in Level 3 and higher networks. Thus, OPC transfers process control data between the control (Level 2) network and the operations/manufacturing (Level 3) network. It also exchanges data between the operations/manufacturing network and the business (Level 4) network. This is depicted in Figure 1. In essence, OPC is the Modbus of the new century. It is not a replacement for low-level communication standards such as 4 to 20 mA, HART, PROFIBUS, or Foundation Fieldbus. Instead, organizations use OPC in high-level communication.

Figure 1: OPC exchanges data between the control and operations/manufacturing networks and between the operations/manufacturing and business networks.
(Click graphic to zoom by 1.7x)

Note that OPC is no longer an acronym. When OPC was first released in 1996, it served as an acronym for OLE for Process Control and was restricted to the Windows Operating System (OS). OPC is now available on other OSs and enjoys significant adoption outside of process control. So the original name OLE for Process Control is no longer appropriate, and OPC no longer stands for anything. OPC is just OPC.

The first form of OPC (now called Classic OPC) relied on Distributed Component Object Model (DCOM) for its data transportation. DCOM was very powerful and versatile but posed a problem for those who did not understand how to configure it. Instead of DCOM, OPC UA relies on Web services for its data transportation. OPC UA also uses objects to help with data description. All this will ensure that OPC UA will be even better suited to penetrate the entire plant enterprise. Of course, with all the new connectivity that OPC UA offers, the new challenge will be system security.

Moving to Web services

The change to Web services in OPC UA is something most end users will notice immediately. Two of the biggest advantages for Web services are ease of communication between networks and independence from specific OSs. The challenge for the plant itself will be implementing security to keep data safe.

Perhaps the biggest technical advantage of Web services is that they enable OPC to communicate over a single port using a protocol that most firewalls will allow to pass by default. This should make it easier for integrators to set up a system for communication between networks. Many firewalls are already configured to let Web traffic pass across port 80. This will make it easier for IT to open the ports necessary to implement OPC communication. Previously, DCOM required multiple ports to establish communication. While this was possible to configure, a significant portion of automation personnel did not take the time to learn how to do it. Nevertheless, opening port 80 releases communication for a plethora of applications, not just those needed for operations, so emphasis on security will be required immediately.

In addition, Web services are not bound to any specific OS. Thus, vendors will have an easier time implementing OPC servers on their automation hardware and non-Windows OSs. Vendors are already working on PLCs that include an embedded native OPC server that does not require an external computer. However, this implementation might not be as simple as it seems because automation applications (HMI, historian, automation and process control, and others) typically require a PC anyway. Nevertheless, it would be possible to have a PLC communicate with a software application using OPC without requiring an intermediate computer that uses Windows.

Object-oriented data model

Classic OPC has a fairly simple data model. Each of the OPC specifications handles a different aspect of the data. For example, the OPC Data Access (DA) specification communicates real-time values; the OPC Historical Data Access (HDA) specification communicates archived values; the OPC Alarms and Events (A&E) specification communicates various process and system events such as a temperature that exceeds a prespecified limit; and so on. In addition, Classic OPC implements each specification separately, essentially in a different executable. Thus, it is time-consuming for end users to match item names with real-time data and item names with historical data. Even worse, automated applications may not be able to do it at all.

OPC UA provides a unified data model, shown in Figure 2. Thus, when an application uses OPC UA to send a temperature reading, the receiver can retrieve the real-time value, any associated historical values, and even alarms and events. All this data is available from pointing at a single OPC item. The OPC server can associate all the data together so that the OPC client does not need to redo the association work.

Figure 2: With the unified data model offered by OPC UA, users can obtain the information they need by pointing at a single OPC item.
(Click graphic to zoom)

For example, in DCOM-based OPC, end users interested in a pressure reading would have to point to the OPC DA server to look at the real-time value. Then they would have to point to an OPC HDA server to trend the pressure over the past shift. If they wanted to take a look at associated events, they would have to point to the OPC A&E server. But with OPC UA, end users can simply point to a pressure reading, view its real-time value, look at the past shift’s trend (historical data), and view all the associated events by connecting to a single OPC UA server.

OPC UA also provides the ability to create more complex objects. For example, engineers could create a pump composed of various temperature, level, pressure, flow, and vibration readings. Included would be the history of all values as well as a picture of the pump. Engineers could even associate process and instrumentation schematic diagrams and maintenance orders. This presents a powerful mechanism for integrators from various companies to share data without having to recreate it in their different proprietary software applications.

Shop floor to top floor: OPC to the enterprise

OPC UA introduces an object model to industrial data, and Web services will enable OPC applications to transport the data across firewalls, networks, and the Internet. A variety of applications will be able to supply the enterprise with data. An HMI will be able to pass equipment events to the maintenance system. The historian will be able to pass calculations to various engineering systems. As well, inventory management systems will be able to easily obtain production figures directly from automation equipment.

Plant floor data will finally find its way to the business LAN and enable a variety of applications to benefit from the newly available data, as shown in Figure 3. For instance, computer maintenance management systems or enterprise asset management systems such as Maximo, Indus, IFS, and Ivara will be able to obtain equipment condition data so that they can implement a conditions-based maintenance program. Enterprise resource planning applications such as SAP, Oracle, PeopleSoft, JD Edwards, and Baan will be able to obtain inventory information or even send production orders without any manual intervention.

Figure 3: A variety of industrial applications will benefit from data made available through OPC UA.

Security: The new challenge for automation

OPC UA makes it relatively easy for a multitude of applications to connect with each other. So the new challenge for automation personnel will be to secure their systems from unwanted connections. Web services will make it easy to cross firewalls and networks. Unwanted connections from people and applications will become far more common. However, unlike IT systems, automation systems are responsible for production and safety. Therefore, security will quickly rise to the forefront. Automation personnel will have to learn how to secure their systems in a way that still enables them to provide access to those who need it.

It remains to be seen how vendors will enable their applications with the three pillars of secure connectivity: authentication, authorization, and encryption. Various products that are already in the planning stages still do not include the necessary facilities for proper security. These applications use “security by obscurity,” which essentially relies on a hacker’s inability to understand how a system works to make it behave inappropriately. Both process and attitudes toward security will have to change.

Unifying the promise

OPC UA unifies the existing OPC specifications. It enables plants to replace the existing reliance on DCOM with Web services. It also introduces the concept of objects, which enables workers in a range of roles at the plant to access the same data in different ways. This enables them to produce a variety of reports and analytical calculations without having to cobble together data from many different sources.

The challenge for companies implementing OPC UA is to ensure their data is secure from unauthorized access. However, given all the promise that OPC UA holds, most industries will experience a sharp increase in OPC’s penetration of their plants.

Randy Kondor is a computer engineer and the president of the OPC Training Institute, the world’s largest OPC training company. Since 1996, Randy has been involved within the OPC industry and is a strong supporter of the OPC Foundation. He continues to dedicate himself to spreading the OPC Foundation’s message about system interoperability and intervendor cooperation. Randy has a B.Sc. in Computer Engineering from the University of Alberta.

OPC Training Institute