OPC Unified Architecture
OPC Unified Architecture is a machine to machine communication protocol for industrial automation developed by the OPC Foundation. Distinguishing characteristics are:
- Focus on communicating with industrial equipment and systems for data collection and control
- Open - freely available and implementable under GPL 2.0 license
- Cross-platform - not tied to one operating system or programming language
- Service-oriented architecture
- Inherent complexity - the specification consists of 1250 pages in 14 documents
- Offers security functionality for authentication, authorization, integrity and confidentiality
- Integral information model, which is the foundation of the infrastructure necessary for information integration where vendors and organizations can model their complex data into an OPC UA namespace to take advantage of the rich service-oriented architecture of OPC UA. There are over 35 collaborations with the OPC Foundation currently. Key industries include pharmaceutical, oil and gas, building automation, industrial robotics, security, manufacturing and process control.
History
After more than three years of specification work and another year for a prototype implementation, the first version of the Unified Architecture was released in 2006.
The current version of the specification is on 1.04. The new version of OPC UA now has added publish/subscribe in addition to the client/server communications infrastructure.
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;
- Lower security;
- No control over DCOM.
- 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.
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, and are similar to the objects of object-oriented programming. A node can have attributes for read access, methods that can be called, and triggered events that can be transmitted. Nodes hold process data as well all other types of metadata. The OPC namespace contains the type model.
Client software can verify what 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. 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. This is visible to application programmers only via changes to the URL. The binary protocol is opc.tcp://Server andThe binary protocol offers the best performance/least overhead, takes minimum resources, offers best interoperability and uses a single arbitrarily choosable TCP port for communication easing tunneling or easy enablement through a firewall.
The Web Service protocol is best supported from available tools, e.g., from Java or.NET environments, and is firewall-friendly, using standard HTTP ports.
Binary is supported by all implementations, while only.NET implementation supports SOAP.
Specifications
The OPC UA specification is a multi-part specification and consists of the following parts:- Concepts
- Security Model
- Address Space Model
- Services
- Information Model
- Mappings
- Profiles
- Data Access
- Alarms and Conditions
- Programs
- Historical Access
- Discovery and Global Services
- Aggregates
- PubSub
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.
Discussion
The OPC UA protocol specification consists of 14 documents for a total of 1250 pages. Due to this complexity, existing implementations are usually incomplete. In addition, the existence of several serialization formats, as well as the possibility of selectively implementing certain services such as PubSub, eventually lead to a great heterogeneity of the OPC UA connection points. Under these conditions, it is finally difficult to develop client applications that are independent of the specific implementation of each server. In this sense, OPC UA does not achieve its promise of ensuring good interoperability of systems. This can be seen typically in factory and infrastructure projects integrating various PLC technologies, each delivered with a different and limited implementation of the OPC UA protocol.The specification is still evolving, the last specification document volume 14 is dated February 6, 2018, while the first publication of the standard OPC UA dates from 2006.
As a result, despite considerable marketing efforts to support its adoption, OPC UA may be considered at this stage as a standardization attempt rather than an established standard.
UA communication stack
The architecture of a UA application, independent of whether it is the server or client part, is structured into levels.Some parts equalize to the former COM Proxy/Stubs and get provided by the OPC Foundation. The portability level is new; it simplifies porting the UA ANSI C stack to other target platforms. A port layer for Windows and Linux is also provided by the OPC Foundation.
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.There is also a mixed version where the code is binary, but the transport layer is SOAP. This is a compromise between 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 of an Active Directory.
Built-in data types
The OPC UA standard defines 25 built-in data types:| Built-in type | C/C++ equivalent | Details | NodeId type |
| Boolean | bool | 0/1 | 0 |
| SByte | int8_t | -128 to 127 | 0 |
| Byte | uint8_t | 0 to 255 | 0 |
| Int16 | int16_t | -32768 to 32767 | 0 |
| UInt16 | uint16_t | 0 to 65535 | 0 |
| Int32 | int32_t | -2147483648 to 2147483647 | 0 |
| UInt32 | uint32_t | 0 to 4294967295 | 0 |
| Int64 | int64_t | 0 | |
| UInt64 | uint64_t | 0 to 18446744073709551615 | 0 |
| Float | float | IEEE single precision floating point value | 0 |
| Double | double | IEEE double precision floating point value | 0 |
| StatusCode | uint32_t | ||
| String | uint8_t* / std::string | 3 | |
| DateTime | int64_t | number of 100 nanosecond intervals since 1/1/1601 | |
| GUID | implementation dependent | 16-byte number used as a unique identifier | 4 |
| ByteString | 5 | ||
| XmlElement | |||
| NodeId | namespace index and NodeId type | ||
| ExpandedNodeId | |||
| QualifiedName | namespace index and string | ||
| LocalizedText | string and a locale indicator | ||
| NumericRange | string | ||
| Variant | |||
| ExtensionObject | scalars of any type | ||
| DataValue | a composite of a value, timestamps and status code | ||
| DiagnosticInfo | detailed error/diagnostic information |
OPC UA APIs
UA APIs are available in several programming languages. Commercial SDK are available for C, C++, Java, and.NET. Open-source stacks are available at least for C, C++, Java, Javascript and Python .C++/C Implementation
- The project provides an Open Source implementation for OPC UA server and clients and is licensed under the Mozilla Public License v2.0. Besides Linux and Windows, it also supports OS X, QNX and different embedded systems as compilation target.
- The provides an Open Source secured implementation and is licensed under the Apache 2.0 license. It supports Linux, Windows, FreeRTOS, Zephyr, VxWorks and aims to be safe, secure and fast. The core of the software is formally designed with the help of the B-Method.
- The provides a C++ open source OPC UA Application Server and an OPC UA Web Server.
- The project provides an open source server and client implementation in C++.
- The project offers an open source C++/Python implementation.
.NET implementation
Java implementation
Various stacks for Java were being developed. Similar to.NET, there are principally three variants:- 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.
- Code directly on the network layer and de-serialize in Java. This saves one data copy execution, but still depends on the C stack.
- Write a native Java OPC UA stack. This was observed to be the most portable, but estimated to take the most engineering effort to implement. The Eclipse Milo project provides a pure-Java, open-source, implementation of the UA 1.03 client and server specification.
JavaScript implementation
is a complete implementation of the OPC UA for client and server entirely writing in JavaScript for Node.js.Python implementation
- The project provides an implementation mostly in the Python programming language and provides high-level abstractions of an OPC UA client and server which can be used as is or readily extended for custom applications.
- The C-implementation provides a python wrapper .
Rust implementation
TypeScript / JavaScript implementation
is an OPC UA client that works in the browser. It is completely written in TypeScript and compiled to JavaScript. The source code is publicly available and has an MIT license. It includes OPC UA binary data encoding and uses WebSockets as the transport protocol.IEC 62541
IEC 62541 is a standard for OPC Unified Architecture.| ID | release date | title |
| IEC/TR 62541-1 | 2016 | OPC Unified Architecture - Part 1: Overview and Concepts |
| IEC/TR 62541-2 | 2016 | OPC Unified Architecture - Part 2: Security Model |
| IEC 62541-3 | 2015 | OPC Unified Architecture - Part 3: Address Space Model |
| IEC 62541-4 | 2015 | OPC Unified Architecture - Part 4: Services |
| IEC 62541-5 | 2015 | OPC Unified Architecture - Part 5: Information Model |
| IEC 62541-6 | 2015 | OPC Unified Architecture - Part 6: Mappings |
| IEC 62541-7 | 2015 | OPC Unified Architecture - Part 7: Profiles |
| IEC 62541-8 | 2015 | OPC Unified Architecture - Part 8: Data Access |
| IEC 62541-9 | 2015 | OPC Unified Architecture - Part 9: Alarms and Conditions |
| IEC 62541-10 | 2015 | OPC Unified Architecture - Part 10: Programs |
| IEC 62541-11 | 2015 | OPC Unified Architecture - Part 11: Historical Access |
| IEC 62541-13 | 2015 | OPC Unified Architecture - Part 13: Aggregates |
| IEC 62541-100 | 2015 | OPC Unified Architecture - Part 100: Device Interface |
Literature
- Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag 2009;
- Lange, J., Iwanitz, F., Burke, T. OPC From Data Access to Unified Architecture 2010;