OPC UA: An End-User’s Perspective (Part 2)

See Part 1

4. OPC UA uses an 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 DA (Data Access) specification communicates real-time values, the OPC HDA (Historical Data Access) specification communicates archived values, the OPC A&E (Alarms and Events) specification communicates various process and system events (such as a temperature that exceeds a pre-specified limit), and so on. In addition, Classic OPC implements each specification separately; essentially in a different executable. Thus, it is time-consuming for people 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. Thus, when an application uses OPC UA to send a temperature reading, the receiver is able to 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 is able to associate all the data together so that the OPC Client does not need to redo the association work. For example, in DCOM-based OPC, an End-User who is interested in a pressure reading would have had 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, the End-User 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, one could create a pump that is 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. One could even associate P&ID 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.

5. Improving Existing Specifications

As OPC evolved over the years, the OPC Foundation provided constant updates and improvements to the specifications. OPC UA continues this tradition. After consulting nd-users, integrators, and vendors, the OPC Foundation decided on various additions to the specifications to handle the most common challenges. OPC UA includes mechanisms to quickly inform users of broken communication, identify lost data, and even provide for redundancy.

OPC UA uses a poll-report-by-exception mechanism. Thus, the OPC Client polls the OPC Server for changes. The server then responds with any data changes. A failure to respond would immediately tell the OPC Client that the communication is no longer active. In addition, updates can come as quickly as the polling itself. However, unlike common protocols that must poll each point individually and consume precious bandwidth, OPC UA enables the OPC Server to respond with any data that changed. Thus a single efficient poll can bring back a large amount of data that includes all the changes in the process as well as the health of the OPC Server itself. By contrast, before OPC UA, DCOM communication sent all changes to the OPC Client by exception. Thus, an OPC Client did not have to poll the OPC Server periodically. While this was efficient, many programmers overlooked the possibility that no updates would be received when communication breaks. As a result, the OPC Client would wait for updates that would never arrive. Various companies overcame these difficulties, but some did not and blamed DCOM instead.

OPC UA also enables an easier implementation of redundancy. OPC UA Servers can update a set of clients. By contrast, DCOM-based OPC Servers could only update OPC Clients that explicitly subscribed to the data. As well, since the OPC Client can easily tell when communication with an OPC Server fails (as above), the OPC Client can now quickly failover to a standby OPC Server. In DCOM-based implementations, most vendors relied on third party OPC redundancy applications that cost them additional funds.

6. Backwards Compatibility and Tunneling

The OPC Foundation has promised to supply the industry with two simple software applications that will enable people to quickly convert their DCOM-based OPC products to OPC UA. These software applications are called “wrappers.” Wrappers will ensure that any new OPC UA product will communicate with an existing DCOM-based OPC product. As a result, there is no need to contemplate whether or not one should wait for OPC UA products. It is easy to implement DCOM-based OPC products today and rest assured that future OPC UA products will communicate with the old software.

Two wrappers will be available: one for OPC Clients and the other for OPC Servers. The first wrapper will convert a DCOM-based OPC Server to an OPC UA Server. Thus, an OPC UA Client will be able to connect to the existing DCOM-based OPC Server without any changes. The second wrapper will convert a DCOM-based OPC Client to an OPC UA Client. So an existing DCOM-based OPC Client application (such as an HMI) will be able to communicate with an OPC UA Server that could be purchased a year from now. Using wrappers, OPC is sure to ease the transition from the old to the new technology.

Wrappers will tunnel OPC to places where DCOM-based OPC can’t penetrate on its own. For example, when an OPC Client and Server are separated by NAT (Network Address Translation), DCOM will not be able to make the connection. However, by converting the DCOM-based call to OPC UA at the source, and converting it back from OPC UA to DCOM at the destination, the call will transport the required data. Tunneling will likely be the first form of OPC UA implementation as OPC UA products begin to emerge.

Image 3: OPC UA wrappers will enable legacy DCOM-based OPC products to communicate with new OPC UA products. The wrappers will also make it possible for two DCOM based applications to eliminate DCOM from their communication.

7. Shop Floor to Top Floor: OPC to the Enterprise

OPC UA introduces an object model to industrial data, and Web Services will enable the 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 easily able to obtain production figures directly from automation equipment.

Image 4: OPC UA will enable data to move from the shop floor to the top floor.

Plant-floor data will finally find its way to the Business LAN (Local Area Network) and enable a variety of applications to benefit from the newly available data. For instance, CMMS (Computer Maintenance Management Systems) or EAMS (Enterprise Asset Management Systems) such as Maximo, Indus, IFS, and Ivara will be able to obtain equipment condition data so they can implement a CBM (Conditions Based Maintenance) program. ERP (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.

8. 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. So, 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.

9. Conclusion

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 people, 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, President, OPC Training Institute, has more than 15 years of leadership experience building global OPC and security awareness and acceptance. An accomplished engineer, his vision and capable expertise have been a driving force in making the OPC Training Institute the world's largest OPC training company. Randy's success is due to the priority he has placed on educating industry about OPC standards. Education continues to be his focus today. His significant impact in the industry continues to be felt as ....... See Details....