OPC Unified Architecture

from Wikipedia, the free encyclopedia

OPC Unified Architecture ( OPC UA ) is a standard for data exchange as a platform-independent, service-oriented architecture ( SOA ). As the latest generation of all specifications of the open platform communications (OPC) from the OPC Foundation OPC UA differs significantly from its predecessors in particular, by the ability to machine data ( control values , measured values , parameters , etc.) not only to transport, but also machine-readable, semantically describe .

After more than three years of specification work and one year of prototype implementation, the first version of the Unified Architecture was adopted in autumn 2006. In February 2009, a revised version of Parts 1 to 5 and 8 and the first version of Parts 6 and 7 were published.

Innovations

The original link to COM / DCOM made a major contribution to the spread of OPC, but it also had decisive disadvantages:

  • Common DCOM configuration problems
  • No configurable timeouts
  • Binding to the Windows operating system
  • Security weaknesses, since authentication was done via the local user table
  • No control over what happens (COM / DCOM is a black box , developers have no source code and are exposed to errors)

For these and other reasons, the decision was made to develop a separate communication stack for OPC UA, which replaces COM / DCOM. The most important features of this communication stack are:

  • In addition to a portable ANSI-C implementation, both a C ++ and a Java implementation are supported.
  • Scalability of embedded control software up to operational or management information systems
  • The stack can be compiled for both multithreaded and single-threaded / single-task operation, which is important for porting to embedded devices.
  • Our own security implementation based on the latest standards
  • Configurability of timeouts for each service call
  • Chunking of large data packets

The OPC UA architecture is a service-oriented architecture (SOA), the structure of which consists of several layers.

OPC UA architecture

All basic services (base services) defined by OPC are abstract method descriptions that are protocol-independent and provide the basis for the entire OPC UA functionality.

The transport layer executes these methods using a protocol that serializes / deserializes the data and sends it over the network. Two protocols are currently planned for this: a highly optimized and high-performance TCP protocol with binary coding and a protocol based on web services. Further protocols are possible and can be added if necessary.

The OPC information model is no longer just a hierarchy of folders, items and properties. It is a so-called full mesh network of nodes, with which meta and diagnostic information are represented in addition to the useful data of a node. A node is similar to an object from object-oriented programming. A node can have attributes that can be read (Data Access (DA), Historical Data Access (HDA)). It is possible to define and call methods . A method has call arguments and return values. It is called by a command. Furthermore, events support, that can be sent (AE (Alarms & Events) DA DataChange,) to exchange certain information between devices. An event has, among other things, a time of receipt, a message and a severity level. The nodes mentioned above are used for the user data as well as for all other types of metadata . The OPC address space modeled with it now also contains a type model with which all data types are specified.

Based on this, various other organizations such as B. EDDL's own information models . Clients have the option of checking which so-called “profiles” a server supports. This can be used to check whether a server only supports DA functionality or also AE, HDA etc. It can also be read whether a server supports e.g. B. supports the EDDL profile, and thus a client knows that EDDL-specific device descriptions are also available.

Other new and important features of OPC UA are

  • redundancy
  • Heartbeat for connection monitoring in both directions, d. H. both the server and the client notice interruptions.
  • Buffering of data and acknowledgments of transmitted data. Connection interruptions no longer lead to data loss. Lost data can be requested again.

A development towards real-time capability is OPC UA over TSN .

Logs

As mentioned, there are two protocols. As an application developer, you only notice this from the URL to be transferred: opc.tcp: // server / for binary protocol and http: // server for web service. Otherwise, OPC UA works completely transparently on the API.

  1. Binary protocol
    • best performance, least overhead
    • Uses the fewest resources (no XML parser, SOAP and HTTP necessary → important for embedded devices)
    • best interoperability (binary is precisely specified, not as many degrees of freedom as with XML)
    • A single TCP port (4840) is used for communication and can also be easily tunneled or activated in a firewall.
  2. Web service ( SOAP )
    • best tool support. Can e.g. B. can also easily be used from Java and .NET .
    • Firewall friendly. Port 80 (http) and 443 (https) usually work without any further configuration.

Since the ANSI-C-Stack provided can handle both protocols, it is expected that most products will communicate with the efficient binary protocol.

Specifications

The OPC UA specification is a multipart 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
  14. PubSub

In contrast to the COM-based specifications, the UA specifications are not purely user specifications. They mostly describe UA internals that are handled by the communication stack and are only of interest to people who want to port the stack or implement their own UA stack.

The OPC UA application developers rely on an OPC UA API and will therefore mainly use the API documentation. However, parts 3, 4 and 5 are of interest to users.

OPC UA communication stack

The structure of a UA application, whether server or client, is divided into the following layers.

Structure of the OPC UA communication stack

The green parts correspond to the former COM proxy / stubs and are provided by the OPC Foundation. The porting layer is new, which makes it easy to port the UA-ANSI-C stack to other platforms. A port layer for Windows and Linux is also provided by the OPC Foundation. The applications are developed based on the API, similar to what was also the case with COM.

The first prototypes were already demonstrated at the OPC UA DevCon in October 2006 in Munich. The company ascolab GmbH, which also developed the ANSI-C stack for the OPC Foundation, presented various prototypes and demonstrated the interoperability between a Windows / .NET UA client and a Linux UA server.

Next UA servers were on a Beckhoff - PLC (based on Windows XP Embedded) and EUROS Embedded Systems GmbH on an embedded test board (based on their own real-time operating system introduced EUROS).

In October 2012, showed Fraunhofer IOSB-INA and the Institute of Industrial Information Technology of the Technical University of OWL that OPC UA is such scaling capable of a server with only 15 kilobytes of RAM and 10 kilobytes of ROM that can be implemented directly on a chip.

UA security

UA Security includes authentication and authorization, encryption and data integrity through signing. It is based on the web service security specifications. WS Secure Conversation is used directly for web services and is therefore compatible with .Net and other SOAP implementations. For the binary variant, the algorithms from WS Secure Conversation were adopted and also converted into a binary equivalent. This is now referred to as UA Secure Conversation .

OPC UA protocols

As you can see from the picture, there is also a mixed variant in which binary coding is used, but SOAP is used for the transport. This represents a compromise between efficient binary coding and firewall-friendly transmission. Binary coding always requires UA Secure Conversation.

X.509 certificates are used for authentication . It is up to the application developer to decide which certificate store the UA application is connected to. It is Z. B. possible to use the Public Key Infrastructure (PKI) of an Active Directory.

OPC UA APIs

For UA developers, there will be the option to set up directly on a C-API, a more comfortable C ++ API or a .NET API. All APIs will have the same functionality and, as far as the programming languages ​​allow, they will be similar in application.

The communication stack and these APIs are provided by the OPC Foundation.

Some manufacturers of APIs

The frameworks from the various manufacturers each have advantages and disadvantages. Mostly trial versions can be downloaded for testing. The subtleties can be found in the architecture, the documentation of the software and the pricing model. It is worth making a corresponding comparison and test. Some of the downloads already contain examples of implementation and test applications, which make it easier for you to get started. Functionally, the OPC UA interface should then be able to do the same everywhere (conforming to the specification).

Unified Automation

Unified Automation is based in Germany and offers training on the subject, as well as workshops on the use of their APIs for ANSI C, .NET, C ++ or Java. When installing the APIs offered, various test applications (client and server) are available, as well as the UAExpert (an OPC UA client), which provides good services for getting to know the OPC UA environment and for testing your own applications.

Softing

Softing, a German company that works closely with Siemens and offers APIs for C ++ or .NET.

OPC Labs

OPC Labs is a company headquartered in the Czech Republic that offers APIs for OPC UA for a wide variety of platforms and programming languages.

C ++ implementation

There are various implementations under an open source license. The OPC Foundation uses the AnsiC Stack as a reference implementation, which is under a dual license (proprietary for members, GPL for all others).

The open62541 project offers an almost complete implementation of the OPC UA specification and is licensed under the Mozilla Public License . In addition to Linux and Windows, it also supports OS X, QNX and various embedded systems.

The ASNeG project provides a C ++ OpenSource OPC UA Application Server and an OPC UA Web Server (in beta) (so far only with support for the basic functionalities).

.NET implementation

The .NET implementation only uses the lowest part of the ANSI-C stack and otherwise implements the rest of the stack in .NET, i.e. H. only the socket handling and message chunking is taken over by the ANSI-C-Stack, the deserialization takes place in .NET and thus leads directly to .NET objects. This procedure is more efficient compared to deserialization into a C structure and subsequent copying into a .NET object.

Java implementation

There are now a number of Java implementations. The OPC UA stack is now provided as a Java implementation by the OPC Foundation, which provides almost the full range of functions. There are also a number of Java SDKs from the companies Unified-Automation, HB-Softsolution or Prosys. The opcua4j project provides an OpenSource SDK (previously only with support for the basic functionalities) based on the official OPC UA stack. Ignition has completely re-implemented the OPC UA stack and an SDK (in beta) in Java and provides it as open source. In addition, there has been an open source implementation developed by the Eclipse Foundation under the name " Milo " since 2016 .

JavaScript implementation

The node-opcua project offers a special variant. It has implemented the OPC UA stack in JavaScript, so that it can be used on the basis of NodeJS in the V8 JavaScript RuntimeEngine.

Python implementation

  • opcua is a Python implementation of OPC UA Client and Server for Python 2 and 3 and is available under the LPGL 3.0 license. The corresponding Python project was previously called "freeopcua".
  • The S2OPC C implementation includes a Python wrapper PyS2OPC .

OPC UA wrapper

The OPC Foundation provides so-called wrappers for the use of existing DCOM OPC devices and software . These "translate" DCOM OPC into OPC UA and OPC UA into DCOM OPC.

Norms and standards

OPC UA was also published as the IEC 62541 series of standards. So far, parts 1, 2, 13 and 100 are available as Ed. 1.0 and part 3 to 10 as Ed. 2.0 before. Part 12 has not yet been included in the IEC series of standards.

Overview of the IEC 62541 series of standards
number Issue date English title German title Edition
IEC / TR 62541-1 February 2010 OPC Unified Architecture - Part 1: Overview and Concepts OPC Unified Architecture - Part 1: Overview and Concepts 1.0
IEC / TR 62541-2 February 2010 OPC Unified Architecture - Part 2: Security Model OPC Unified Architecture - Part 2: Model for IT security 1.0
IEC 62541-3 July 2010 OPC Unified Architecture - Part 3: Address Space Model OPC Unified Architecture - Part 3: Address space model 2.0
IEC 62541-4 October 2011 OPC Unified Architecture - Part 4: Services OPC Unified Architecture - Part 4: Services 2.0
IEC 62541-5 October 2011 OPC Unified Architecture - Part 5: Information Model OPC Unified Architecture - Part 5: Information Model 2.0
IEC 62541-6 October 2011 OPC Unified Architecture - Part 6: Mapping OPC Unified Architecture - Part 6: Protocol images 2.0
IEC 62541-7 July 2012 OPC Unified Architecture - Part 7: Profiles OPC Unified Architecture - Part 7: Profiles 2.0
IEC 62541-8 October 2011 OPC Unified Architecture - Part 8: Data Access OPC Unified Architecture - Part 8: Data Access 2.0
IEC 62541-9 July 2012 OPC Unified Architecture - Part 9: Alarms and conditions OPC Unified Architecture - Part 9: Alarms and States 2.0
IEC 62541-10 July 2012 OPC Unified Architecture - Part 10: Programs OPC Unified Architecture - Part 10: Programs 2.0
IEC 62541-11 March 2015 OPC Unified Architecture - Part 11: Historical Access OPC Unified Architecture - Part 11: Historical Access 1.0
IEC 62541-12 July 2015 OPC Unified Architecture - Part 12: Discovery OPC Unified Architecture - Part 12: Discovery 1.03
IEC 62541-13 March 2015 OPC Unified Architecture - Part 13: Aggregates OPC Unified Architecture - Part 13: Calculations 1.0
IEC 62541-14 April 2018 OPC Unified Architecture - Part 14: PubSub OPC Unified Architecture - Part 14: PubSub 1.0
IEC 62541-100 April 2019 OPC Unified Architecture - Part 100: Devices OPC Unified Architecture - Part 100: Devices 1.02

literature

  • Wolfgang Mahnke, Stefan-Helmut Leitner, Matthias Damm: OPC Unified Architecture. Springer Verlag, 2009, ISBN 978-3-540-68898-3 (English)
  • J. Lange, F. Iwanitz, T. Burke: OPC From Data Access to Unified Architecture , VDE Verlag, 2010, ISBN 978-3-8007-3217-3 (German)
  • M. Schleipen (Ed.): Practical Guide OPC UA , Vogel Communications Group, 2018, ISBN 978-3-8343-3413-8 (German)

Web links

Individual evidence

  1. ^ Unified Architecture. In: OPC Foundation. Retrieved January 25, 2019 (American English).
  2. Smallest OPC UA server comes from Lemgo , accessed on July 18, 2015
  3. OPC Foundation AnsiC Stack. Retrieved April 4, 2017 .
  4. open62541 OPC UA stack. Retrieved April 4, 2017 .
  5. ASNeG - open source OPC UA application server. Retrieved September 11, 2015 .
  6. opcua4j - open source implementation of an opc ua server in java. code.google.com, accessed November 15, 2014 .
  7. milo: Eclipse Milo ™ - an open source implementation of OPC UA (IEC 62541). In: GitHub.com. Eclipse Foundation, February 2, 2018, accessed February 6, 2018 .
  8. node-opcua - pure nodejs OPCUA SDK. Retrieved November 15, 2014 .
  9. python-OPC UA. Retrieved January 15, 2020 .
  10. freeopcua. Retrieved January 15, 2020 .
  11. iec.ch , Voting Result: 65E / 474 / NP