Design aspects of the OPC unified architecture.

Stopper, Markus ; Katalinic, Branko

1. INTRODUCTION

The OPC Foundation is approaching completion of the first stage of its new Unified Architecture (UA). The new Unified Architecture is meant to unify all of the existing OPC technology (OPCOLE, 2003). Importantly it means open standards and no longer just the proprietary Microsoft standard (OPCDCOM, 2000). OPC vendors are already working through the design and implementation phase of their OPC UA technology products. After three years of specification work and a further year of prototyping the first version of Unified Architecture is now being released considering the following characteristics for the communication stack (OPCUA, 2008):

* multiple platform implementation including portable ANSI C, Java and .NET implementations

* scalability from embedded controllers up to Mainframes

* the stack can support multi-threaded as well as single-threaded/single-task operation, which is necessary for porting the stack onto embedded devices

* an own security implementation, based on new standards, realizes true security (e.g. compare with [OPCSEC, 1998])

* configurable time-outs for each service

* chunking of big datagram's

Consequently perhaps the most obvious change compared to the legacy OPC standard that users will notice right away is that OPC-UA is even not based on Microsoft COM/DCOM. Everyone on the market is embracing open, internet-based communication standards. Naturally, OPC has done the same by basing UA on TCP/IP, HTTP, SOAP, and XML. Not being tied solely to Microsoft platforms makes OPC-UA highly scalable. It is expected to see OPC-UA implemented on everything from embedded field devices through to Unix or mainframe-based enterprise applications (OPCUA, 2008).

All of the base services defined by OPC are abstract method descriptions which are protocol independent and found the basis for the whole OPC UA functionality. The transport layer puts these methods into a protocol, which means it serializes/de-serializes the data and transmits it over the network. Currently there are two protocols specified for this purpose. One is a binary, towards high performance optimized TCP protocol and as second, a Webservice-based one. The OPC information model isn't just a hierarchy based on folders, items and properties any more, but a so-called Full Mesh Network based on nodes instead. These nodes can additionally transmit all varieties of meta information. Additional new and important features of OPC UA are redundancy support, heartbeat for connections in both directions, which means that the server as well as the client recognizes interruptions, and buffering of data and acknowledgements of transmitted data, so lost connections don't lead to lost data anymore. Lost datagram's can get fetched repeatedly (OPCUA, 2008).

2. ARCHITECTURE BASE DESIGN

The OPC Unified Architecture blurs the distinction between Data Access, Historical Data Access or Alarms & Events in a way, that existing OPC applications are largely broken down on functional lines based on which of the OPC specifications are supported. Clients and Servers based on the Unified Architecture will blur this distinction since the transfer of all data, no matter of what its type or purpose, is transferred using the same base UA services.

This mechanism coupled with the support of complex data (arrays, binary structures, XML documents, etc.) leads to a situation where server vendors expose data with complete trustworthiness as it naturally exists in the system. They presently expose only a subset of data forced into an OPC-defined data format. Forward thinking vendors will realize that there will no longer be a need for any proprietary vendor defined interfaces with this capability and they will only expose the data via UA (OPCUA, 2008).

The OPC Foundation has been working with other standards organisations to gear UA as a premier vehicle for conveying and transporting data defined by these other specifications. With the acceptance of UML based models and XML Schema to define and render complex data, many information model specifications are emerging.

It can be expected to see companion specifications emerging that bind the data models described by these and other specifications to OPC UA, thus providing for complete information level interoperability from one application to another. Note also that applications that use this type of data are not the current round of typical factory floor applications that traditionally implement OPC. Instead they are enterprise applications for use at MES and ERP level. It can be expected to see OPC-UA implemented in certain applications far outside the scope of nowadays OPC applications (OPCUA, 2008).

Further robustness and reliability play an important role. Rather than live at the kindness of the underlying internet protocols, the Unified Architecture takes direct responsibility for all of the necessary failure detection and recovery logic making UA viable for mission-critical communication. Beyond robustness and reliability, several redundancy schemes are defined such that vendors may provide this capability in a standard way. It is expected to see OPC-UA used as the native communication method by applications, usurping proprietary vendor protocols and possibly some existing field bus protocols (OPCUA, 2008). Existing OPC applications vary greatly in their compatibility and interoperability with other OPC applications. Although OPC is currently stressing the need for products to be both certified and tested at interoperability workshops, the reality is that only a small percentage of OPC products on the market presently meet that mark. With OPC Unified Architecture, the certification tests cover both servers and clients and will be administered by sanctioned testing labs. These facilities are expected to be available in time to test the very first UA products coming to the market. The certification status of any UA component will be available in real time via electronic certificates issued by OPC directly though the UA interface. OPC-UA applications which are properly certified thus greatly increase the likelihood of true plug-n-play (OPCUA, 2008).

Backward compatibility will ensure quick adoption. The OPC Foundation is providing its members with several code-based deliverables to simplify vendor development and aid with backward compatibility. First, the OPC-UA API provides much of the plumbing and low level generic serialisation and wire support so that vendors need only to code the high level aspects of UA into their applications. The API is expected to be available in several languages supporting multiple popular computing platforms.

In addition to the API, the OPC Foundation is also providing its members with shippable binary adapter modules which allow new OPC-UA clients direct access to all of the legacy COMbased OPC servers, and legacy COM-based OPC clients access to a subset of the features of new OPC-UA servers. The two adapters can even be used together to connect a legacy client to a legacy server, replacing the standard DCOM communication with the new OPC-UA internet-based protocols. With complete backward compatibility ensured, vendors will have much to gain and nothing to loose by adopting the new OPC Unified Architecture (OPCUA, 2008).

Summarized can be said that OPC UA specifies an abstract set of services and the mapping to a concrete technology. OPC UA does not specify an API but only the message formats for data exchanged on the wire. A communication stack is used on client- and server-side to encode and decode message requests and responses. Different communication stacks can work together as long as they use the same technology mapping. The following section gives an overview over the different components of OPC UA clients and servers followed by a section of technology mappings and a section of possible interactions between OPC UA servers (OPCUA, 2008).

3. CLIENT AND SERVER PARTS

An OPC UA client consists of a client implementation using an OPC UA communication stack. The client implementation accesses the communication stack using the OPC UA API. Note that the API is not standardized. It may vary for different programming languages and potentially for different communication stacks. Several communication stacks may exist for different operating systems, programming languages and mappings. The client-side communication stack allows the client to create request messages based on the service definitions. The client-side communication stack communicates with a server-side communication stack. The OPC Foundation standardized only this communication. Thus, everybody can develop his or her own communication stack with its own API as well. The server-side communication stack delivers the request messages to the server implementation via the OPC UA API. Since the OPC UA API realizes the abstract service specifications, it may be the same as on the client-side. The server implementation implements the logic needed to return the appropriate response message. The OPC UA server implementation gets its data from some underlying system. For example, this can be a configuration database, a set of devices or some OPC server (OPCUA, 2008).

4. TECHNOLOGY MAPPING

The OPC UA mapping specification currently defines two mappings: UA Web Services and UA Native. The first mapping uses SOAP and the various WS-* specifications. The second mapping uses only a simple binary network protocol and integrates certain security mechanisms.

The encoding of the data can be done in XML or UA Binary. UA Binary specifies the serialization of data into a byte string. The UA Binary encoding is faster than the XML encoding since the message size is smaller than for the XML encoding. On the other hand, the XML encoding allows generic SOAP-clients to interpret the data in the SOAP message, while they would only get a binary string using the UA Binary encoding. In theory, the encoding of the data is independent of the mapping. However, the XML encoding will typically only be used in the UA Web Service mapping in combination with the various WS*-specifications. The protocol of the UA Web Service mapping is SOAP/HTTP(S) while the UA Native mapping typically runs directly on TCP/IP. For bypassing firewalls, the UA Native mapping also allows putting the binary encoded messages into SOAP messages using HTTP(S). UA messages can also be encoded and transported with other protocols, for example using WCF Binary. However, by using this technology interoperability is lost since only communication with WCF clients is then possible (Resnick, 2008).

5. AGGREGATING SERVERS

Build-into the OPC UA specification is the concept of aggregating servers. An aggregating server aggregates one or more OPC UA server and provides the information of those servers--or an excerpt of the information--in its address space. Thus, a client does not have to access several servers but only one server. This mechanism allows a flexible architecture by chaining several OPC UA servers for different clients with different requirements (OPCUA, 2008).

For example, several OPC UA servers running on small devices will be aggregated by one OPC UA server. Several clients of the distributed computing system may access this server. Another OPC UA server aggregates this server and provides part of the information to the MES system. The MES system could work as an aggregating server, too. OPC UA supports aggregating servers by allowing marking the origin of data.

6. CONCLUSION

OPC UA is an important step to integrate new technologies and concepts into industrial applications. The strong meta model, the open and standardized service-oriented architecture (SOA) and the ability of unifying different kind of OPC servers opens the door for new areas of application. Especially in the field of process automation, it will help to simplify the integration of other applications like MES, HMI or SCADA systems.

6. REFERENCES

OPCDCOM (2000). DCOM on Non-Microsoft Platforms, Software AG, http://www.opcfoundation.org/, 2000

OPCOLE (2003). OPC Specification: Data Access, Alarms & Events, Historical Data Access, OPC Foundation, http://www.opcfoundation.org/, 2003

OPCSEC (1998). OPC, DCOM and Security, Intellution Inc., http://www.opcfoundation.org/, 1998

OPCUA (2008). OPC UA Specification: Parts 1-11, OPC Foundation, http://www.opcfoundation.org/, 2008

Resnick, S., Crane, R. & Bowen C. (2008). Essential Windows Communication Foundation (WCF): for .NET Framework 3.5, ISBN 978-0321440064, March 2008, Addison-Wesley Longman, Amsterdam, Netherlands, 2008