UA Ansi C Server Professional  1.3.2.233
 All Data Structures Functions Variables Typedefs Enumerations Enumerator Groups Pages
OPC UA Software Layers

OPC UA uses a similar client–server concept like Classic OPC. An application that wants to expose its own information to other applications is called UA server and an application that wants to consume information from other applications is called UA client. But it is expected that much more applications will be both UA server and UA client in one application than in Classic OPC. One reason is that more UA servers will be integrated directly in devices. Implementing also a UA client enables device to device communication. Another reason is the use of OPC UA as configuration interface, where UA clients are also UA servers to be configured via OPC UA.

A typical OPC UA application is composed of three software layers shown in the following figure. The complete software stack can be implemented with C/C++, .NET, or JAVA. OPC UA is not limited to these programming languages and development platforms, but only these environments are currently used for implementing the OPC Foundation UA Stack deliverables.

An OPC UA Application is a system that wants to expose or to consume data via OPC UA. It contains the specific functionality for the application and the mapping of this functionality to OPC UA by using an OPC UA Stack and an OPC UA Software Development Kit (SDK).

An OPC UA client or server SDK implements common OPC UA functionality that is part of the application layer, since the UA Stacks implement only the communication channels. An OPC UA SDK reduces the development effort and facilitates faster interoperability for an OPC UA application.

An OPC UA Stack implements the different OPC UA transport mappings defined in UA Part 6. The Stack is used to invoke UA Services across process or network boundaries. OPC UA defines three Stack layers and different profiles for each layer. The message encoding layer defines the serialization of Service parameters in a binary and a XML format. The message security layer specifies how the messages must be secured by using the Web Service security standards or a UA binary version of the Web Service standards. The message transport layer defines the used network protocol, which could be UA TCP or HTTP and SOAP for Web Services. The following figure illustrates the different UA communication stack layers. The implementation of the layers in a UA Stack and the resulting API for the applications is not part of the OPC UA specification. The UA Stacks provide language-dependent APIs for UA client and UA server applications, but the Services and their parameters are similar and based on the abstract Service definition in UA Part 4.

With implementations in ANSI C/C++, .NET, and JAVA, the main development environments and programming languages are covered by UA Stacks developed and maintained by the OPC Foundation.

OPC UA is much more flexible and has much more features than all Classic OPC specifications together, but it incorporates all successful concepts of existing OPC specification, fixes known issues in existing standards, and adds standardization for a lot of additional use cases.

It was an important design goal to allow an easy migration from Classic OPC to OPC UA. For this reason most features known from Classic OPC can be found in OPC UA using sometimes slightly different terminology. It is not possible to expose all UA features with Classic OPC interfaces, but it is no problem to map Classic OPC features to OPC UA.

OPC UA allows a simple mapping and offers migration strategies to integrate OPC products based on previous OPC standards. One part of the migration strategy does not even require a change in existing products. Wrappers and proxies provided by the OPC Foundation are able to translate the different Classic OPC interfaces into OPC UA and vice-versa. This first level in the migration strategy can be used by vendors to support OPC UA for legacy products.

The second level of migration to OPC UA is the integration of OPC UA directly into existing products without adding OPC UA specific features. This step does not require changes in interfaces used between systems and their OPC communication components today. It is much easier to integrate new components if the existing interfaces of a system do not have to be changed. The advantage over the use of wrappers or proxies is a better performance and less configuration and engineering efforts by removing an additional software layer. The direct integration will make it easier to remove potential limitations of wrappers and proxies and allows an iterative development approach by adding OPC UA features step by step.

The third level may require changing internal interfaces of the product to support all features of OPC UA that are of interest for the product. OPC UA will allow systems to make product features available in a standard way, which they can not expose today without the new options provided by OPC UA.

For end users, it is important to have the wrappers and proxies available to migrate the large installed base of Classic OPC products to OPC UA. End users can install wrappers and proxies for tunneling Classic OPC through firewalls, including secure transmission over the internet and authenticated access, so they simply add value to existing industry proven solutions.

These components are only a first step. For vendors it is much more important that OPC UA offers abstract, modular, and simple base concepts in all areas of the standard, allowing an easy migration of existing OPC functionality to OPC UA. The very powerful concepts for extending this base enable vendors to expose more and more of their system features via OPC UA. This leads to an iterative development and improvement process.