OPC Unified Architecture

OPC Unified Architecture, shortly OPC UA, is an industrial M2M communication protocol. As the newest of all OPC specifications of the OPC Foundation OPC UA is considerably different from his predecessors, especially by the ability to machine data (process values ​​, measured values, parameters, etc.) not only portable, but also machine-readable, semantically describe.

After over three years of work specification to a year prototype implementation, the first version of the Unified Architecture in the fall of 2006 was passed. In February 2009, a revised version of parts 1 to 5 and 8, and the first version of parts 6 and 7 was published.

Innovations

The original binding to COM / DCOM has indeed made ​​a big contribution to the spread of OPC, but also had major drawbacks:

  • Common configuration issues DCOM
  • No configurable timeouts
  • Binding to the Windows operating system
  • No "real" Security
  • No control what happens ( COM / DCOM is a black box, developers do not have the source code and errors are shipped )

For these and other reasons, it was decided to develop its own communication stack for OPC UA, which replaces COM / DCOM. The main features of this communication stacks are:

  • In addition to a portable ANSI C implementation are both C # - as also supports a Java implementation.
  • Scalability of embedded control software to operational or management information systems
  • The stack can be compiled for both multi-threaded operation as well as for the single-threaded / single-task operation, which is important for porting on embedded devices.
  • Our own security implementation, based on the latest standards, provides for "real" security.
  • Configurable timeouts for each service call
  • Chunking of large data packets

However, this communication stack is only the beginning of many innovations represents the OPC UA architecture is a service-oriented architecture (SOA ), whose structure consists of several layers.

All defined by OPC basic services ( Base Services) are abstract methods descriptions that are protocol- independent, and form the basis for the entire OPC UA functionality.

The transport layer, these methods are carried out by means of a protocol that serialisert the data / deserialized and sends over the network. Currently two protocols are intended: a highly optimized and high-performance TCP protocol with binary coding and a web services based protocol. Other protocols are possible and can be supplemented, 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, in addition to the user data of a node also meta and diagnostic information is represented with the. A node is similar to an object in 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 invoked by a command. Further events are supported, that can be sent (AE, DA Data Change) to share certain information between devices. An event has among other things a reception time, a message and a severity level. The above-mentioned nodes are used for both user data as well as all other types of metadata. The thus modeled OPC address space now includes a type model with which all data types are specified.

Then sitting up specify various other organizations such as EDDL own information models. Clients have the option to check, which supports so-called " Profiles" server. This can be checked whether a server supports only DA functionality or even AE, HDA, etc. It can also be read if a server, for example, supports the EDDL profile, and thus knows a client that also EDDL specific device descriptions are available.

Other new and important feature of OPC UA are

  • Redundancy
  • Heartbeat to monitor the connection in both directions, ie both server and client notice interruptions.
  • Buffering of data and acknowledgments of the transmitted data. Disconnections no longer result in data loss. Lost data can be requested again.

Protocols

As already mentioned, there are two protocols. As an application developer you will notice that only the to be passed URL: opc.tcp :/ / server binary protocol and http://Server for web service. Otherwise, OPC UA works completely transparent to the API.

1 binary protocol

  • Best performance, the least overhead
  • Consumes the least resources (no XML parser, SOAP, and HTTP necessary → important for embedded devices )
  • Best interoperability (binary is specified precisely, not so many degrees of freedom as with XML)
  • A single TCP port ( 4840 ) is used for communication and can also be easily tunneled or enabled in a firewall.

Second web service ( SOAP)

  • Best tool support. Can be used, for example, net easily from Java and..
  • Firewall - friendly. Port 80 (http ) and 443 (https ) usually work without further configuration.

Since the provided ANSI C stack dominates both protocols, it is expected that most products will communicate with the efficient binary protocol.

Specifications

The OPC UA specification is a multipart specification consists of the following parts:

In contrast to the COM -based specifications, the specifications are not pure UA- user specifications. They describe mostly UA internals that are traded on the communication stack, and are only interesting for people who are porting the stack or want to implement your own UA stack.

The OPC UA application developers rely on an OPC UA API and are therefore mainly use the API documentation. Interesting for users but are Part 3, 4, and 5

OPC UA communication stack

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

The green parts correspond to the former COM proxy / stubs and are provided by the OPC Foundation. New porting layer, which makes it possible to port is easily the UA ANSI C Stack on other platforms. A port Layer for Windows and Linux is also provided by the OPC Foundation. The applications are based on the API developed like it was the case with COM.

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

Next were presented on an embedded test board various UA server on a Beckhoff PLC ( PLC) and of EUROS Embedded Systems GmbH. Where the Beckhoff PLC based on Windows XP Embedded and Embedded Controller on the real- time operating system EUROS.

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

UA Security

UA Security includes authentication and authorization, encryption and data integrity by signing. The OPC Foundation has not reinvented the wheel here, but is geared to the Web service security specifications. For Web Services WS Secure Conversation is used directly and is thus compatible with. Net and other SOAP implementations. For the binary version of the algorithms WS Secure Conversation were taken and also converted into a binary equivalent. This is now referred to as UA Secure Conversation.

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

For authentication, X.509 certificates are used. It is up to the application developer, to which certificate store the UA application is connected. It is e.g. possible, the Public Key Infrastructure ( PKI) of an Active Directory to use.

For UA developers there will be the opportunity to sit directly on a C- API, a more convenient C API or. NET API. All APIs have the same functionality, and, as far as is practicable in the languages, similar in use to be.

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

. NET implementation

The. NET implementation uses only the lowest part of the ANSI C stack and implemented otherwise the rest of the stack. NET. That is, only the socket handling and message chunking is done by the ANSI C stack, which takes place in deserializing. NET and thus results directly. NET objects. This approach is more efficient compared with deserialization in a C - structure and then copying to a. NET object.

Java Implementation

Various prototypes for Java are already in development. Basically, there are 3 variants as well as in. Net. Currently it is hard to estimate what is the fastest version.

1 The fastest (in terms of development time ) variant is currently to use the full ANSI C stack and these encapsulate via JNI.

  • - One disadvantage is that one loses the simple Java portability. The stack can indeed be ported to different operating systems, but needs to be recompiled.
  • - The data must be copied to the JNI boundary.
  • One uses the speed advantages of C during deserialization.

2 It is like the current. Net implementation directly on the network layer and deserialized into Java.

  • One saves umkopieren once
  • - Also depends on the C stack.

3 Complete implementation in Java.

  • Best portability
  • - Most effort

Alternatively, there's the simple version to use only the web service protocol. This requires a SOAP toolkit that supports WS-Security.

OPC UA Wrapper

To use existing DCOM OPC devices and software, the OPC Foundation called wrapper available. This " translate" DCOM OPC to OPC UA and OPC UA in DCOM OPC.

Standardization

OPC UA was also published as an IEC standard IEC 62541. So far there part 1 to 10 as Ed. 1.0 before. Work on Part 11 - Historical Access, 13 - Aggregates and 100 - OPC UA for Devices have been started. The expected output date is July 2014.

OLE for Process Control Machine to Machine Communications protocol Parameter (disambiguation) Distributed Component Object Model Device Description Language
407676
de