Introduction↗
On June of this year, the OPC foundation held a developer conference about OPC Unified Architecture [OPC UA]. This is a major evolution within the OPC World that is intended to replace all the current OPC standards of OPC DA.
This document summarizes the 2.5 days of presentations on OPC UA I assisted with about 140 other developers/users.
OPC Unified Architecture.↗
Current OPC-DA is already a successful communication protocol that succeeded to improve Interoperability, Performance and Connectivity at the plant floor level.
OPC UA is not just an update of the existing standard but is really a very ambitious evolution. It clearly abandons the COM/DCOM technology that linked OPC to Microsoft Company to enter the wider world of web services. It also gives to automation data a bigger audience within the enterprise by allowing a simple embedded device to be seen up to the central ERP System.
Why a new Architecture?↗
If we stay at the architecture level, the main motivations that have conducted to OPC UA are:
The current architecture is split into a lot of pieces defined at different time and that are not always very well integrated together.
- Data Access
- Alarms and Events
- Historical Data Access
- Batch
- Complex Data
- XML Data Access
- …
OPC totally relies on COM/DCOM Microsoft technology, which is not so easy to use (DCOM Configuration/Security may be a real nightmare) and that has started to become obsolete from Microsoft point of view.
Service Oriented Architecture (SOA) allows increasing the connectivity between acquisition systems (Other platforms than Windows can be used: UNIX, Linux …). It also increases the visibility of the automation world within the enterprise organization and will allow better integration with already existing ERPs.
Service Oriented Architecture↗
OPC UA is based on Web Services Architecture and thus relies on existing industry standards. This choice of architecture,
- Allows cross platform developments. (UA is available in C, C#, Java)
- Ensure the interoperability with other systems and within the enterprise.
- Facilitate accessibility over a network and internet.
Those already familiar with Web Services will immediately point out the performance issues of SOAP over HTPP. This aspect is already taken into account, and 2 transport protocols are available:
- SOAP over HTPP for Internet based communications.
- OPC Binary over TCP for Intranet based communications
This service-based architecture allows connections such as the following one that has been demonstrated during the conference.
Main Changes in OPC UA↗
This section gives a summary of the main changes present in OPC UA.
Object Model↗
As explain above OPC DA specifications are split in different parts (DA, HAD, Events, Complex Data…) which were written almost independently. This led to implementations that were not fully compatible with one another and required manual synchronization between different address spaces.
With OPC UA, the object model has been unified. Everything is now centralized within a single OPC UA Object, which provides all the services in a logical and standardized way.
Address Space↗
The Address Space has been extended and is no longer a static parent-child structure.
It is now a true network model based on a full mesh. An unlimited number of named or typed relationships can be defined between any objects within the Address Space. You can even reference objects on other OPC servers over the network.
To simplify navigation through complex networks, Views can be used to present a specific hierarchy.
Robustness↗
In OPC DA, robustness was provided largely by the COM infrastructure. However, HTTP communication over the Internet does not provide the same level of reliability. For OPC UA, the decision was made not to rely on the underlying infrastructure for robustness. As a result, numerous mechanisms were defined to provide reliability at the application level.
- Subscription Update Features.
- Keep-alive (heartbeat) messages, allowing clients to detect a failed server or channel.
- Sequence Numbers in each update message, allowing client re-sync to obtain missed messages.
- Decouples callback channel from notification mechanism, allowing callback channel to be reset without loss of data.
- Redundancy has been designed for easy (optional) redundancy of both Clients and Servers (e.g. re-sync request can be sent to a backup server).
Security↗
The SOA model used for OPC–UA, and the ambition to increase the visibility of OPC within the enterprise up to the ERP level may also increase the sensitivity against security threats. We certainly do not want to switch off thea whole production line because someone in the enterprise has received a virus through an email.
That is why security is a very important part of OPC-UA (2nd part of the whole specifications documents). Security has not been added around OPC-UA but has really been built inside the whole architecture. It uses state-of-the-art existing standards (X.509 Certificates, PKI, WS-Secure Conversation, XML Encryption, WS Security, …).
- UA Clients present credentials to UA Servers (x509 certificates on both sides).
- UA Servers require authentication and authorization (Access control can be fine-grained down to the property level).
- Optional message signing and encryption can also be used.
UA Server Chaining↗
OPC-UA Clients and Servers can be chained in order to aggregate data using different information models appropriate to the needs of the clients that depends on its level within the enterprise hierarchy.
Complex Data Features↗
Complex data are now fully supported. The server tells the clients how to parse structured data. XML data can be described using XML schemas. Binary data can also be described using the OPC binary data description language. Device specific data descriptions (e.g. Fieldbus Foundation OD) can also be accessed.
Methods & Programs↗
Methods are now part of the base OPC-UA. They can be seen as synchronous invocations similar to blocking calls.
Programs are new in OPC world. They are built on top of Methods. They represent executable components of objects. Their execution time may vary from milliseconds to indefinitely. The invocation of a Program is asynchronous and thus non-blocking. Results are returned using notifications. The client can control the execution.
Services & Profiles↗
Profiles are defined to allow servers with different capabilities. Clients can discover server profiles dynamically and adapt themselves.
Services partitioned into services sets are integrated directly within the data model.
Diagnostics↗
Standardized diagnostic data items are defined within the Address Space. Custom diagnostic items can also be defined by deriving them from the appropriate object types.
Performance↗
Performance is one of the first concerns that comes to mind when discussing Web Services architecture. It can be particularly cooncerning for professionals working in the data-acquisition field. The OPC Foundation has taken this issue into account and has published the results of several performance tests. In summary from performance point of view analyzes done so far show that:
- UA Binary over TCP is between 2x-4x faster than DCOM, depending on packet size.
- UA Binary over TCP is Comparable to COM for larger data sets, but half the speed for small packets
- UA Binary over TCP with UA Security (Encryption) is comparable to DCOM with out any security
- UA Binary is 4x - 20x times Faster then XML over HTTP depending on data types and message sizes
- Data types make little difference using XML over HTTP
- XML over HTTP with WS-SecureConversation is 2x-4x slower than XML over HTTP without WS-SecureConversation
Note: Java implementation has not been tested yet.
DA – UA Migration↗
The OPC Foundation does not want to undermine the confidence that users currently have in existing OPC products. At the same time, it wants to bring OPC UA to market as quickly as possible. That’s why they propose different tools to support the migration:
- Client Proxies
- Server Wrappers
- UA SDK
- Client Library
- Server Library
- UA Stack
- Sample Applications
- Configuration Tools
The use of these migration tools will allow existing OPC-DA products to communicate with the OPC-UA world.
However, it is also clear that many new functionalities will only be accessible only to native OPC-UA products, such as the new Address Space features and Programs.
As explained above, a native OPC-UA implementation is the ultimate goal.
Compliance - Certification↗
An OPC Certification is going to be setup in order to improve:
- Reliability
- Security
- Interoperability
- Maintainability
- Plug-N-Play
- …
Compliance will be supported through several mechanisms:
- The Compliance Test Tool (CTT) which can be used for self-certification.
- Annual Interoperability Sessions (IOP), held at different locations.
- Independent Certification Laboratories.
Two logos are available to distinguish between the different certification levels.
With Self Certification or Interoperability Session
With Independent Certification
And the OPC Foundation Web Site will host the information about the different product certifications.