OPC Unified Architecture
From Wikipedia, the free encyclopedia
OPC Unified Architecture is the most recent OPC specification from the OPC Foundation and differs significantly from its predecessors. After 3 years of specification work and another year of prototyping the first version of Unified Architecture is now being released.
Contents |
[edit] Innovations
Although the original binding to COM/DCOM helped OPC to distribute well but nevertheless had also its drawbacks.
- frequent configuration issues with DCOM
- no configurable timeouts
- only available for the Windows Operating System
- security not really applicable
- no control over DCOM (COM/DCOM is kind of a blackbox, developers have no access to sources and therefore have to live with bugs or insufficient implementations)
That and various other conclusions generated the decision to develop a new and independent communication stack for OPC UA which replaces COM/DCOM. The outstanding characteristics of this communication stack are
- portable ANSI C implementation
- scalability from embedded controllers up to Mainframes
- the stack can be compiled for 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 "real" security.
- configurable timeouts for each service
- chunking of big datagrams
This communication stack mirrors only the beginning of various innovations. The OPC UA architecture is a Service Orientated Architecture (SOA) and is based on different logical levels.
All of the Base Services defined by OPC are abstract method decriptions which are protocol independent and found the basis for the whole OPC UA functionality. The transport layer 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 anymore, but a so-called Full Mesh Network based on nodes instead. These nodes can additionally transmit all varieties of meta information.The easiest comparison of a node would be an object, known thru object orientated programming (OOP). It can own attributes for read access (DA, HAD), methods which can be called (Commands) and triggered events which can be transmitted (AE, DA DataChange). The nodes get used for process data as well all other types of meta data. The used OPC namespace contains now also the type model used for description of all possible data types. Based on the above, other organizations e.g. like EDDL are specifying their own information source. Client software has the ability to verify which of the so-called Profiles a server supports. This is necessary to obtain information if a server only supports the DA functionality or additionally the AE, HAD, etc.. functions. Additionally, information can be obtained whether a server supports i.e. the EDDL profile and therefore the client knows that there are also EDDL-specific device descriptions available. Additional new and important features of OPC UA are:
- Redundancy support
- Heartbeat for connections in both directions. That means the server as well as the client recognized interruptions.
- Buffering of data and acknowlegements of transmitted data. Lost connections don't lead to lost data anymore. Lost datagrams can get fetched repeatedly.
[edit] Protocols
As described before there are two protocols. An application programmer will recognize this only via the different URL he has to pass for binary protocol opc.tcp://Server and http://Server for WebService. Otherwise OPC UA works completely transparent to the API.
1. Binary protocol
- best performance, the least overhead
- takes minimum resources (no XML Parser, SOAP and HTTP required -> important for embedded devices)
- best possible interoperability (binary is explicitly specified and allows less degrees of freedom during implementation as XML does)
- only one single TCP port (4840) gets used for communication and can get tunneled or enabled through a Firewall easily
2. WebService (SOAP)
- best supported from available tools. It can be easily used i.e. from JAVA or .Net environments
- Firewall-friendly. Port 80 (http) und 443 (https) will usually work without additional configuration.
Since the available ANSI C stack supports both protocols, the expectation is given that most of the final products may communicate via the more effective binary protocol.
[edit] Specifications
The OPC UA specification is a multi-part specification and consists of the following parts
- Concepts
- Security Model
- Address Space Model
- Services
- Information Model
- Service Mappings
- Profiles
- Data Access
- Alarms and Conditions
- Programs
- Historical Access
In contrast to the COM based specifications are the UA specifications no pure application specs. They describe typically UA internal mechanisms which get handled through the communication stack and are normally only out of interest for those which port a stack to a specific target or those which want to implement their own UA stack. The OPC UA application developers code against the OPC UA API and therefore will mainly use the API documentation instead. Nevertheless, part 3, 4, and 5 may be out of interest for the application developers as well.
[edit] OPC UA communication stack
The architecture of an UA application, independent whether it is for the server or client part, is structured into the following levels.
The green parts equalize to the former COM Proxy/Stubs and get provided by the OPC Foundation. New is the portability level which allows it in an easy way to port the UA ANSI C stack also to other target platforms. A port layer for Windows and Linux gets also provided by the OPC Foundation. As described before, based on the API the applications can be developed, similar to how it was when coding against COM in the past. At the OPC UA DevCon in October 2006 in Munich the first prototypes have been presented live. The company ascolab GmbH, which also developed the ANSI C stack for the OPC Foundation, presented various prototypes and demonstrated impressively the interoperability between a Windows/.NET UA Client and a Linux UA Server. Additionally, various UA Server have been shown on a Beckhoff PLC and an embedded test board from Euros. Whereby the Beckhoff PLC is based on Windows XP Embedded and the embedded controller is based on the real-time operating system Euros.
[edit] OPC UA security
UA Security consists of authentication and authorization, encryption and data integrity via signatures. For that, the OPC Foundation hasn't reinvented the wheel but oriented itself at the Web Service Security specifications. For Web Services the WS Secure Conversation gets used and is therefore compatible to .Net and other SOAP implementations. For the binary variant, the algorithms of WS Secure Conversation have been followed and also converted to a binary equivalent. This gets now named as UA Secure Conversation.
As visible on the figure above, there is also a mixed version where the code is binary but the transport layer is SOAP. This compromises efficient binary coding and Firewall-friendly transmission. Binary coding always requires UA Secure Conversation. The authentication uses x509 certificates exclusively. It relies on the application developer to what certificate store the UA application gets bound to. For instance, it is possible to use the Poublic Key Infrastructure (PKI) of an Active Directory.
[edit] OPC UA APIs
For UA developers, the possibility gets provided to code against a C API, a comfortable C++ API or a .NET API, directly. All APIs support the same functionality. The communication stack and APIs get provided by the OPC Foundation.
[edit] .net Implementation
The .Net implementation uses only the lower part of the ANSI C stack and implements the rest of the stack natively in .Net. That means only the handling of the socket and the Message-Chunking gets integrated from the ANSI C stack. The de-serialization takes place directly in .Net and therefore gets converted directly into .Net structures and objects. This processes a better performance than de-serialzing into a C structure first and then copying the data to a .Net structure afterwards.
[edit] JAVA Implementation
Various stacks for JAVA are already in development. But similar to .Net there are principially 3 variants. Currently it's hard to determine which one is the fastest.
1. Mostlikely, the fastest variant (in terms of engineering time) currently is to make use of the complete ANSI C stack and encapsulate it via JNI.
- - A drawback is that you lose the simple JAVA portability. Although the stack can be ported to different operating systems, it needs to get compiled for those individually
- - The data needs to get copied to the JNI boundary.
- + This method uses the performance of C during de-serialization.
2. The code gets based on the network layer directly (similar to the current .Net implementation) and de-serialzed in JAVA.
- + Saves one data copy execution
- - still depending on the C stack.
3. Complete implementation in JAVA.
- + Best portability option
- - Takes the most engineering effort to implement
Alternatively, there is the simple variant to only support the WebService protocol. For that a SOAP Toolkit, which supports WS Security, is needed.
