OPC Unified Architecture

Last updated

OPC Unified Architecture (OPC UA)
OPC-UA protocol logo, 2022.png
International standardIEC62541, OPC Unified Architecture (Core, Field eXchange, Devices, Asset Management, XML Datatype Mapping)
Developed by OPC Foundation
IntroducedJuly 28, 2006;18 years ago (2006-07-28)
Industry Operational technology and Information technology
Compatible hardware PLC, field devices, Windows, Linux, IIOT
Website https://opcfoundation.org/about/opc-technologies/opc-ua/

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]

Contents

History

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 as 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]

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 and Global Services
  13. Aggregates
  14. PubSub
  15. Safety
  16. State Machines
  17. Alias Names
  18. Role-Based Security
  19. Dictionary Reference
  20. File Transfer
  21. Device Onboarding
  22. Base Network Model
  23. Common Reference Types
  24. Scheduler


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]

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 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.

Built-in data types

The OPC UA standard defines 25 built-in data types:

OPC UA built-in data types
Built-in type C/C++ equivalent DetailsNodeId type
Booleanbool0/1 (false or true)0 (numeric)
SByteint8_t-128 to 127
Byteuint8_t0 to 255
Int16int16_t-32768 to 32767
UInt16uint16_t0 to 65535
Int32int32_t-2147483648 to 2147483647
UInt32uint32_t0 to 4294967295
Int64int64_t-9223372036854775808 to 9223372036854775807
UInt64uint64_t0 to 18446744073709551615
FloatfloatIEEE single precision (32 bit) floating point value
DoubledoubleIEEE double precision (64 bit) floating point value
StatusCodeuint32_t
Stringuint8_t* / std::string3 (string)
DateTimeint64_tnumber of 100 nanosecond intervals since 1/1/1601 (UTC)
GUIDimplementation dependent16-byte number used as a unique identifier 4 (GUID)
ByteString(same as String)5 (byte string)
XmlElement(same as String)
NodeIdnamespace index and NodeId type
ExpandedNodeId(similar to NodeId)
QualifiedNamenamespace index and string
LocalizedTextstring and a locale indicator
NumericRangestring (e.g. "0:4,1:5" for [0..4][1..5] array)
Variant(built-in data types only)
ExtensionObjectscalars of any type
DataValuea composite of a value, timestamps and status code
DiagnosticInfodetailed error/diagnostic information

OPC UA APIs

UA 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 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.[ when? ] 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-serialize in Java. This saves one data copy execution, but still depends on the C stack.
  3. 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. [8]
  4. Apache PLC4X project provides pure-Java, open-source implementation of UA client as well as network level frame descriptions which can be used for cross-language implementations. [9]

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 [10] is a standard for OPC Unified Architecture.

IEC 62541 Overview
IDrelease datetitle
IEC/TR 62541-12016OPC Unified Architecture – Part 1: Overview and Concepts
IEC/TR 62541-22016OPC Unified Architecture – Part 2: Security Model
IEC 62541-32020OPC Unified Architecture – Part 3: Address Space Model
IEC 62541-42020OPC Unified Architecture – Part 4: Services
IEC 62541-52020OPC Unified Architecture – Part 5: Information Model
IEC 62541-62020OPC Unified Architecture – Part 6: Mappings
IEC 62541-72020OPC Unified Architecture – Part 7: Profiles
IEC 62541-82020OPC Unified Architecture – Part 8: Data Access
IEC 62541-92020OPC Unified Architecture – Part 9: Alarms and Conditions
IEC 62541-102020OPC Unified Architecture – Part 10: Programs
IEC 62541-112020OPC Unified Architecture – Part 11: Historical Access
IEC 62541-122020OPC Unified architecture – Part 12: Discovery and global services
IEC 62541-132020OPC Unified Architecture – Part 13: Aggregates
IEC 62541-142020OPC Unified architecture – Part 14: PubSub
IEC 62541-1002015OPC Unified Architecture – Part 100: Device Interface

See also

Related Research Articles

In distributed computing, a remote procedure call (RPC) is when a computer program causes a procedure (subroutine) to execute in a different address space, which is written as if it were a normal (local) procedure call, without the programmer explicitly writing the details for the remote interaction. That is, the programmer writes essentially the same code whether the subroutine is local to the executing program, or remote. This is a form of client–server interaction, typically implemented via a request–response message passing system. In the object-oriented programming paradigm, RPCs are represented by remote method invocation (RMI). The RPC model implies a level of location transparency, namely that calling procedures are largely the same whether they are local or remote, but usually, they are not identical, so local calls can be distinguished from remote calls. Remote calls are usually orders of magnitude slower and less reliable than local calls, so distinguishing them is important.

<span class="mw-page-title-main">Serialization</span> Conversion process for computer data

In computing, serialization is the process of translating a data structure or object state into a format that can be stored or transmitted and reconstructed later. When the resulting series of bits is reread according to the serialization format, it can be used to create a semantically identical clone of the original object. For many complex objects, such as those that make extensive use of references, this process is not straightforward. Serialization of objects does not include any of their associated methods with which they were previously linked.

<span class="mw-page-title-main">SOAP</span> Messaging protocol for web services

SOAP is a messaging protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on application layer protocols, most often Hypertext Transfer Protocol (HTTP), although some legacy systems communicate over Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG) designed to facilitate the communication of systems that are deployed on diverse platforms. CORBA enables collaboration between systems on different operating systems, programming languages, and computing hardware. CORBA uses an object-oriented model although the systems that use the CORBA do not have to be object-oriented. CORBA is an example of the distributed object paradigm.

Distributed Component Object Model (DCOM) is a proprietary Microsoft technology for communication between software components on networked computers. DCOM, which originally was called "Network OLE", extends Microsoft's COM, and provides the communication substrate under Microsoft's COM+ application server infrastructure.

<span class="mw-page-title-main">Inter-process communication</span> How computer operating systems enable data sharing

In computer science, inter-process communication (IPC), also spelled interprocess communication, are the mechanisms provided by an operating system for processes to manage shared data. Typically, applications can use IPC, categorized as clients and servers, where the client requests data and the server responds to client requests. Many applications are both clients and servers, as commonly seen in distributed computing.

In distributed computing, an object request broker (ORB) is a concept of a middleware, which allows program calls to be made from one computer to another via a computer network, providing location transparency through remote procedure calls. ORBs promote interoperability of distributed object systems, enabling such systems to be built by piecing together objects from different vendors, while different parts communicate with each other via the ORB. Common Object Request Broker Architecture) standardizes the way ORB may be implemented.

Message-oriented middleware (MOM) is software or hardware infrastructure supporting sending and receiving messages between distributed systems. MOM allows application modules to be distributed over heterogeneous platforms and reduces the complexity of developing applications that span multiple operating systems and network protocols. The middleware creates a distributed communications layer that insulates the application developer from the details of the various operating systems and network interfaces. Application programming interfaces (APIs) that extend across diverse platforms and networks are typically provided by MOM.

Open Platform Communications (OPC) is a series of standards and specifications for industrial telecommunication. They are based on Object Linking and Embedding (OLE) for process control. An industrial automation task force developed the original standard in 1996 under the name OLE for Process Control. OPC specifies the communication of real-time plant data between control devices from different manufacturers.

The OPC Foundation is an industry consortium that creates and maintains standards for open connectivity of industrial automation devices and systems, such as industrial control systems and process control generally. The OPC standards specify the communication of industrial process data, alarms and events, historical data and batch process data between sensors, instruments, controllers, software systems, and notification devices.

The OPC Data Access Specification is the first of a group of specifications known as the OPC Classic Specifications.

This group of standards, created by the OPC Foundation, provides COM specifications for communicating data from devices and applications that provide historical data, such as databases. The specifications provides for access to raw, interpolated and aggregate data.

.NET Remoting is a Microsoft application programming interface (API) for interprocess communication released in 2002 with the 1.0 version of .NET Framework. It is one in a series of Microsoft technologies that began in 1990 with the first version of Object Linking and Embedding (OLE) for 16-bit Windows. Intermediate steps in the development of these technologies were Component Object Model (COM) released in 1993 and updated in 1995 as COM-95, Distributed Component Object Model (DCOM), released in 1997, and COM+ with its Microsoft Transaction Server (MTS), released in 2000. It is now superseded by Windows Communication Foundation (WCF), which is part of the .NET Framework 3.0.

Thrift is an IDL and binary communication protocol used for defining and creating services for programming languages. It was developed by Facebook. Since 2020, it is an open source project in the Apache Software Foundation.

Inductive Automation is a supplier of web-based industrial automation software based in Folsom, California, US. The Ignition SCADA platform is the company's main product line.

Component Object Model (COM) is a binary-interface technology for software components from Microsoft that enables using objects in a language-neutral way between different programming languages, programming contexts, processes and machines.

Sercos III is the third generation of the Sercos interface, a standardized open digital interface for the communication between industrial controls, motion devices, input/output devices (I/O), and Ethernet nodes, such as PCs. Sercos III applies the hard real-time features of the Sercos interface to Ethernet. It is based upon the Ethernet standard. Work began on Sercos III in 2003, with vendors releasing first products supporting it in 2005.

<span class="mw-page-title-main">OpenComRTOS</span> Real-time operating system

OpenComRTOS is a commercial network-centric, formally developed real-time operating system (RTOS), aimed mainly at the embedded system market.

<span class="mw-page-title-main">Thing Description</span>

The Thing Description (TD) (or W3C WoT Thing Description (TD)) is a royalty-free, open information model with a JSON based representation format for the Internet of Things (IoT). A TD provides a unified way to describe the capabilities of an IoT device or service with its offered data model and functions, protocol usage, and further metadata. Using Thing Descriptions help reduce the complexity of integrating IoT devices and their capabilities into IoT applications.

References

  1. Braun, Roland; Mendoza, Francisco (17 November 2021). "Geräteintegration für OPC UA angeschlossene Feldgeräte". Atp Magazin. 63 (11–12). doi:10.17560/atp.v63i11-12.2567. ISSN   2364-3137. S2CID   246122846.
  2. "OPC Foundation Reference Implementation". GitHub .
  3. Mahnke, Wolfgang; Leitner, Stefan-Helmut https://library.e.abb.com/public/75d70c47268d78bfc125762d00481f78/56-61%203M903_ENG72dpi.pdf OPC Unified Architecture – The future standard for communication and information modeling in automation], 3/2009 ABB Review 3/2009, page 56-61
  4. "Unified Foundation – OPC Foundation". OPC Foundation. Retrieved 13 December 2021.
  5. "Members".
  6. The world's smallest OPC UA server comes from Germany
  7. Massaro, Simone What is OPC UA and how does it affect your world?, 5/15/2008 planetengineering.com
  8. "OPC Unified Architecture (UA) client and/or server functionality in any JVM-based project". 26 February 2016. Retrieved 22 August 2016.
  9. "PLC4X OPC-UA client connection options".
  10. "IEC Webstore for IEC 62541" . Retrieved 1 June 2018.

Literature