OPC Unified Architecture

OPC Unified Architecture is the most recent OLE for process control (OPC) specification from the OPC Foundation and differs significantly from its predecessors. The first version of Unified Architecture was released in 2006, after 3 years of specification work and another year of prototyping. The Foundation's goal for this project was to provide a path forward from the original OPC communications model (namely COM/DCOM) to a cross-platform service-oriented architecture (SOA) for process control, while enhancing security and providing an information model.^[1]

Innovations

Although the original binding to COM/DCOM helped OPC to distribute well, it had several drawbacks:

• Frequent configuration issues with DCOM;
• No configurable time-outs;
• Microsoft Windows only;
• Security;
• No control over DCOM (COM/DCOM is kind of a black box, developers have no access to sources and therefore have to deal with bugs or insufficient implementations).

These drawbacks along with a number of other considerations pushed the decision to develop a new and independent stack for OPC UA, which replaces COM/DCOM. The main characteristics of this communication stack were:

• Multi-platform implementation, including portable ANSI C, Java and .NET implementations;
• Scalability: from smart sensors and smart actuators to mainframes;
• Multi-threaded, as well as single-threaded/single-task operation—necessary for porting the stack to embedded devices;
• Security, based on new standards;
• Configurable time-outs for each service;
• Chunking of big datagrams.

This communication stack reflects the beginning of various innovations. The OPC UA architecture is a service-oriented architecture (SOA) and is based on different logical levels.

OPC Base Services are abstract method descriptions, which are protocol independent and provide the basis for OPC UA functionality. The transport layer puts these methods into a protocol, which means it serializes/deserializes the data and transmits it over the network. Two protocols are specified for this purpose. One is a binary TCP protocol, optimized for high performance and the second is Web service-oriented.

The OPC information model is a so-called Full Mesh Network based on nodes. These nodes can include any kind of meta information. Think of nodes as objects, as in object-oriented programming (OOP). This object can own attributes for read access (DA, HDA), methods that can be called (Commands), and triggered events that can be transmitted (AE, DataAccess, DataChange). Nodes hold for process data as well all other types of metadata. The OPC namespace contains the type model.

Client software can verify which Profiles a server supports. This is necessary to obtain information if a server only supports DA functionality or additionally AE, HDA, etc. Additionally, information can be obtained about whether a server supports a given profile. New and important features of OPC UA are:

• Redundancy support
• Heartbeat for connections in both directions (to indicate whether the other end is "alive"). This means that both server and client recognize interrupts.
• Buffering of data and acknowledgements of transmitted data. Lost connections don't lead to lost data anymore. Lost datagrams can be refetched.

Protocols

OPC UA supports two protocols.^[2] This is visible to application programmers only via changes to the URL. The binary protocol is opc.tcp://Server and http://Server is for Web Service. Otherwise OPC UA works completely transparent to the API.

The binary protocol offers the best performance/least overhead, takes minimum resources (no XML Parser, SOAP and HTTP required which is important for embedded devices, offers best interoperability (binary is explicitly specified and allows fewer degrees of freedom during implementation) and uses only TCP port 4840 communication easing tunneling or easy enablement through a firewall.

The Web Service (SOAP) protocol is best supported from available tools, e.g., from JAVA or .Net environments, and is firewall-friendly, using standard http/https ports.

ANSI C supports both protocols.

Specifications

The OPC UA specification is a multi-part specification and consists of the following parts:

1. Concepts
2. Security Model
3. Address Space Model
4. Services
5. Information Model
6. Mappings
7. Profiles
8. Data Access
9. Alarms and Conditions
10. Programs
11. Historical Access
12. Discovery
13. Aggregates

In contrast to the COM-based specifications, the UA specifications are not pure application specifications. They describe typically UA internal mechanisms, which get handled through the communication stack and are normally only of interest for those that port a stack to a specific target or those that want to implement their own UA stack.

The OPC UA application developers code against the OPC UA API and therefore mainly use API documentation. Nevertheless, part 3, 4, and 5 may be of interest for application developers.^[3]

UA communication stack

The architecture of a UA application, independent whether it is the server or client part, is structured into the following levels.

The green parts equalize to the former COM Proxy/Stubs and get provided by the OPC Foundation. New is the portability level, which simplifies porting the UA ANSI C stack also to other target platforms. A port layer for Windows and Linux gets also provided by the OPC Foundation.

At the OPC UA DevCon in October 2006 in Munich the first prototypes were presented live. Various UA Servers have been shown on a Beckhoff programmable logic controller and an embedded test board from Euros. The Beckhoff PLC is based on Windows XP Embedded and the embedded controller is based on the real-time operating system Euros. The company Embedded Labs Ltd demonstrated an OPC-UA Server based on their own C++ UA Stack executing on a single chip ARM microcontroller with 64kB RAM.

UA security

UA Security consists of authentication and authorization, encryption and data integrity via signatures. For Web Services the WS-SecureConversation gets used and is therefore compatible to .NET and other SOAP implementations. For the binary variant, the algorithms of WS-SecureConversation have been followed and also converted to a binary equivalent. This is named as UA Secure Conversation.

As visible on the figure above, there is also a mixed version where the code is binary but the transport layer is SOAP. This compromises efficient binary coding and firewall-friendly transmission. Binary coding always requires UA Secure Conversation. The authentication uses X.509 certificates exclusively. It relies on the application developer to choose which certificate store the UA application gets bound to. For instance, it is possible to use the public key infrastructure (PKI) of an Active Directory.

OPC UA APIs

UA developers can code against a C API, a C++ API or a .NET API, directly. All APIs support the same functionality. The communication stack and APIs are provided by the OPC Foundation as well as by third parties.

.NET implementation

The .NET implementation uses ANSI C for the lower levels and implements the rest natively in .NET. That means only the handling of the socket and the Message-Chunking gets integrated from the ANSI C stack. De-serialization takes place directly in .NET and therefore gets converted directly into .NET structures and objects. This provides better performance than de-serializing into a C structure first and then copying the data to a .NET structure afterwards.

Java implementation

Various stacks for Java were being developed. Similar to .NET, there are principally three variants:

1. Encapsulate the complete ANSI C stack via JNI, which complicates portability. Although the stack can be ported to different operating systems, it needs to get compiled for those individually. Also, the data needs to get copied to the JNI boundary, but benefits from the performance of C during de-serialization.
2. Code directly on the network layer (similar to the current .Net implementation) and de-serialze in Java. This saves one data copy execution, but still depends on the C stack.
3. Write everything in Java. This is the most portable, but takes the most engineering effort to implement.

Alternatively, there is the simple variant to only support the WebService protocol. For that, a SOAP Toolkit that supports WS-Security is needed.

IEC 62541

IEC 62541 is a standard for OPC Unified Architecture.

IEC 62541 Overview

ID	release date	title
IEC/TR 62541-1	02/2010	OPC Unified Architecture - Part 1: Overview and Concepts
IEC/TR 62541-2	02/2010	OPC Unified Architecture - Part 2: Security Model
IEC 62541-3	07/2010	OPC unified architecture - Part 3: Address Space Model
IEC 62541-4	10/2011	OPC unified architecture - Part 4: Services
IEC 62541-5	10/2011	OPC unified architecture - Part 5: Information Model
IEC 62541-6	10/2011	OPC unified architecture - Part 6: Mappings
IEC 62541-8	10/2011	OPC unified architecture - Part 8: Data Access

See also

• OLE for process control
• OPC Foundation
• OPC Data Access

References

1. ^ Mahnke, Wolfgang; Leitner, Stefan-Helmut OPC Unified Architecture - The future standard for communication and information modeling in automation, 3/2009 ABB Review 3/2009, page 56-61
2. ^ Leitner, Stefan-Helmut; Mahnke, Wolfgang OPC UA – Service-oriented Architecture for Industrial Applications, 11/2006 Softwaretechnik-Trends (ISSN 0720-8928)
3. ^ Massaro, Simone What is OPC UA and how does it affect your world?, 5/15/2008 planetengineering.com

Literature

• Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag 2009; ISBN 978-3-540-68898-3

External links

• OPC Foundation
• OPC Unified Architecture e-Book
• The OPC Programmer's Connection
• Introduction to OPC UA Address Space modeling
• OPC-UA Stack for microcontrollers