OPC Unified Architecture (OPC UA) | |
Industry: | Operational technology and Information technology |
Standard: | IEC62541, OPC Unified Architecture (Core, Field eXchange, Devices, Asset Management, XML Datatype Mapping) |
Developer: | OPC Foundation |
Homepage: | https://opcfoundation.org/about/opc-technologies/opc-ua/ |
Hardware: | PLC, field devices, Windows, Linux, IIOT |
OPC Unified Architecture (OPC UA) is a cross-platform, open-source, IEC62541 standard for data exchange from sensors to cloud applications developed by the OPC Foundation. Distinguishing characteristics are:[1]
Although developed by the same organization, OPC UA differs significantly from its predecessor, Open Platform Communications (OPC). The Foundation's goal for OPC UA was to provide a path forward from the original OPC communications model (namely the Microsoft Windows-only process exchange COM/DCOM) that would better meet the emerging needs of industrial automation.[3]
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.[4]
The current version of the specification is on 1.04 (22 November 2017[5]). The new version of OPC UA now has added publish/subscribe in addition to the client/server communications infrastructure.
Although the original binding to COM/DCOM helped OPC to distribute well, it had several drawbacks:
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:
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 Mesh Network based on nodes. These nodes can include any kind of meta information, and are similar to the objects of object-oriented programming (OOP). A node can have attributes for read access (DA, HDA), methods that can be called (Commands), and triggered events that can be transmitted (AE, DataAccess, DataChange). 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:
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. In October 2012 the German Fraunhofer-Application Center IOSB-INA and the Institute for industrial Information Technologies (inIT) showed that an OPC UA server is scalable down to 15 kB RAM and 10 kB ROM and therefore usable at chip level.[6]
The OPC UA specification is a multi-part specification and consists of the following parts:
Additionally, part 100 Devices, and part 200 Industrial Automation are also available. These build on the core set of specifications, and adds new common definitions that then are used in different companion specifications. E.g. both OPC UA for Analyser Devices and OPC UA for Machinery builds directly on part 100.
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.[7]
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 consists of authentication and authorization, encryption and data integrity via signatures. For Web Services the WS-SecureConversation gets used and is therefore compatible with .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 (PKI) of an Active Directory.
The OPC UA standard defines 25 built-in data types:
Boolean | bool | 0/1 (false or true) | 0 (numeric) | ||||||||||||||||||||||||||||||||||||||||||||||||
SByte | int8_t | -128 to 127 | |||||||||||||||||||||||||||||||||||||||||||||||||
Byte | uint8_t | 0 to 255 | |||||||||||||||||||||||||||||||||||||||||||||||||
Int16 | int16_t | -32768 to 32767 | |||||||||||||||||||||||||||||||||||||||||||||||||
UInt16 | uint16_t | 0 to 65535 | |||||||||||||||||||||||||||||||||||||||||||||||||
Int32 | int32_t | -2147483648 to 2147483647 | |||||||||||||||||||||||||||||||||||||||||||||||||
UInt32 | uint32_t | 0 to 4294967295 | |||||||||||||||||||||||||||||||||||||||||||||||||
Int64 | int64_t | -9223372036854775808 to 9223372036854775807|-|UInt64|uint64_t|0 to 18446744073709551615|-|Float|float|IEEE single precision (32 bit) floating point value|-|Double|double|IEEE double precision (64 bit) floating point value|-|StatusCode|uint32_t|||-|String|uint8_t* / std::string||3 (string)|-|DateTime|int64_t|number of 100 nanosecond intervals since 1/1/1601 (UTC)||-|GUID|implementation dependent|16-byte number used as a unique identifier|4 (GUID)|-|ByteString|(same as String)||5 (byte string)|-|XmlElement|(same as String)|||-|NodeId||namespace index and NodeId type||-|ExpandedNodeId||(similar to NodeId)||-|QualifiedName||namespace index and string||-|LocalizedText||string and a locale indicator||-|NumericRange||string (e.g. "0:4,1:5" for [0..4][1..5] array)||-|Variant||(built-in data types only)||-|ExtensionObject||scalars of any type||-|DataValue||a composite of a value, timestamps and status code||-|DiagnosticInfo||detailed error/diagnostic information||}OPC UA APIsUA APIs are available in several programming languages. Commercial SDKs are available for C, C++, Java, and .NET. Open-source stacks are available at least for C, C++, Java, Javascript(node), Tcl and Python . .NET implementationThe .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 implementationVarious stacks for Java were being developed. Similar to .NET, there are principally three variants:
Alternatively, there is the simple variant to only support the WebService protocol. For that, a SOAP Toolkit that supports WS-Security is needed. IEC 62541IEC 62541[10] is a standard for OPC Unified Architecture.
See alsoLiterature
|