OPC Communication
Introduction
In recent years, the OPC Foundation has defined a number of software interfaces to standardize the information flow from the process level to the management level. The main use cases are interfaces for industrial automation applications like HMIs and SCADA systems to consume current data from devices and to provide current and historical data and events for management applications.
Also Read: What is OPC ?
According to the different requirements within industrial applications, three major OPC specifications have been developed: Data Access (DA), Alarm & Events (A&E), and Historical Data Access (HDA). Access to current process data is described in the DA specification, A&E describes an interface for event-based information, including acknowledgement of process alarms, and HDA describes functions to access archived data. All interfaces offer a way to navigate through the address space and to provide information about the available data.
OPC uses a client–server approach for the information exchange. An OPC server encapsulates the source of process information like a device and makes the information available via its interface. An OPC client connects to the OPC server and can access and consume the offered data. Applications consuming and providing data can be both client and server. The following figure shows a typical use case of OPC clients and servers.
Classic OPC interfaces are based on the COM and DCOM technology from Microsoft.
The advantage of this approach was the reduction of the specification work to the definition of different APIs for different specialized needs without the requirement to define a network protocol or a mechanism for interprocess communication. COM and DCOM provide a transparent mechanism for a client to call methods on a COM-object in a server running in the same process, in another process, or on another network node. Using this technology available on all PCbased Windows operating systems reduced the development time of the specifications and products and the time-to-market for OPC. This advantage was important for the success of OPC.
The two main disadvantages are the Windows-platform-dependency of OPC and the DCOM issues when using remote communication with OPC. DCOM is difficult to configure, has very long and non-configurable timeouts, and cannot be used for internet communication.
OPC Data Access
The OPC Data Access interface enables reading, writing, and monitoring of variables containing current process data. The main use case is to move real-time data from PLCs, DCSs, and other control devices to HMIs and other display clients. OPC DA is the most important OPC interface. It is implemented in 99% of the products using OPC technology today. Other OPC interfaces are mostly implemented in addition to DA.
OPC DA clients explicitly select the variables (OPC items) they want to read, write, or monitor in the server. The OPC client establishes a connection to the server by creating an OPCServer object. The server object offers methods to navigate through the address space hierarchy to find items and their properties like data type and access rights.
For accessing the data, the client groups the OPC items with identical settings such as update time in an OPCGroup object. The following figure shows the different objects the OPC client creates in the server.
When added to a group, items can be read or written by the client. However, the preferred way for the cyclic reading of data by the client is monitoring the value changes in the server. The client defines an update rate on the group containing the items of interest. The update rate is used in the server to cyclic check the values for changes. After each cycle, the server sends only the changed values to the client.
OPC provides real-time data that may not permanently be accessible, for example, when the communication to a device gets temporarily interrupted. The Classic OPC technology handles this issue by providing timestamp and quality for the delivered data. The quality specifies if the data is accurate (good), not available (bad), or unknown (uncertain).
OPC Alarm & Events
The OPC A&E interface enables the reception of event notifications and alarm notifications. Events are single notifications informing the client about the occurrence of an event. Alarms are notifications that inform the client about the change of a condition in the process. Such a condition can be the level of a tank. In this example, a condition change can occur when a maximum level is exceeded or is fallen below a minimum level. Many alarms include the requirement that the alarm has to be acknowledged. This acknowledgement is also possible via the OPC A&E interface.
OPC A&E thus provides a flexible interface for transmitting process alarms and events from different event sources.
To receive notifications, the OPC A&E client connects to the server, subscribes for notifications, and than receives all notifications triggered in the server. To limit the number of notifications, the OPC client can specify certain filter criteria.
The OPC client connects by creating an OPCEventServer object in the A&E server in the first step and by generating an OPCEventSubscription used to receive the event messages in the second step. Filters for these event messages can be configured separately for each subscription. The following figure shows the different objects the OPC client creates in the server.
In contrast to OPC DA, there is no explicit request for specific information like reading values; however, all process events are supplied and the client can limit the quantity of the events by setting certain filter criteria, for example, filter by event types, by priority, or by event source.
OPC Data Historical Access
Where OPC Data Access gives access to real-time, continually changing data, OPC Historical Data Access provides access to data already stored. From a simple serial data logging system to a complex SCADA system, historical archives can be retrieved in a uniform manner.
The OPC client connects by creating an OPCHDAServer object in the HDA server. This object offers all interfaces and methods to read and update historical data. A second object OPCHDABrowser is defined for browsing the address space of the HDA server.
The main functionality is the reading of historical data in three different ways. The first mechanism reads raw data from the archive, where the client defines one or more variables and the time domain he wants to read. The server returns all values archived for the specified time range up to the maximum number of values defined by the client. The second mechanism reads values of one or more variables for specified timestamps. The third read mechanism computes aggregate values from data in the history database for the specified time domain for one or more variables. Values include always the associated quality and timestamp.
In addition to the read methods, OPC HAD also defines methods for inserting, replacing, and deleting data in the history database.
Other OPC Interface Standards
OPC specified several additional standards as base specifications or for specialized needs. Base specifications are OPC Overview and OPC Common defining interfaces and behavior that is common to all COM-based OPC specifications. Figure 1.5 gives an overview for all Classic OPC specifications.
OPC Security specifies how to control client access to servers to protect sensitive information and to guard against unauthorized modification of process parameters.
OPC Complex Data, OPC Batch, and OPC Data eXchange (DX) are extensions to OPC DA. Complex Data defines how to describe and transport values with complex structured data types. OPC DX specifies the data exchange between Data Access servers by defining the client behavior and the configuration interfaces for the client inside a server. OPC Batch extends DA for the specialized needs of batch processes. It provides interfaces for the exchange of equipment capabilities corresponding to the S88.01 Physical Model and current operating conditions.
OPC Commands defines mechanisms to call methods or to execute programs via OPC. This specification was never released since it was finished after OPC UA was started. But its content and functionality is completely incorporated into UA.
OPC XML-DA
OPC XML-DA was the first platform-independent OPC specification replacing COM/DCOM with HTTP/SOAP and Web Service technologies. Thus a vendorand platform-neutral communication infrastructure was introduced and widely accepted functionality of OPC Data Access was retained.
Since typical Web Services are stateless, the functionality was reduced to the minimum set of methods to exchange OPC Data Access information, without the need for methods to create and modify a context for communication. Only eight methods were needed to cover the key features of OPC Data Access.
The eight services are the following:
- GetStatus to verify the server status
- Read to read one or more item values
- Write to write one or more item values
- Browse and GetProperties to get information about the available items
- Subscribe to create a subscription for a list of items
- SubscriptionPolledRefresh for the exchange of changed values of a subscription
- SubscriptionCancel to delete the subscription.
OPC XML-DA was designed for internet access and enterprise integration. But based on its platform-independence, it was mainly implemented in embedded systems and on non-Microsoft platforms. But due to its high resource consumption and limited performance, it was not as successful as expected for this type of applications.
Introduction to OPC UA
To reach the defined goals, the OPC Unified Architecture builds on different layers shown in the following figure
The fundamental components of OPC Unified Architecture are transport mechanisms and data modeling.
The transport defines different mechanisms optimized for different use cases. The first version of OPC UA is defining an optimized binary TCP protocol for high performance intranet communication as well as a mapping to accepted internet standards like Web Services, XML, and HTTP for firewall-friendly internet communication. Both transports are using the same message-based security model known from Web Services. The abstract communication model does not depend on a specific protocol mapping and allows adding new protocols in the future.
The data modeling defines the rules and base building blocks necessary to expose an information model with OPC UA. It defines also the entry points into the address space and base types used to build a type hierarchy. This base can be extended by information models building on top of the abstract modeling concepts. In addition, it defines some enhanced concepts like describing state machines used in different information models.
The UA Services are the interface between servers as supplier of an information model and clients as consumers of that information model. The Services are defined in an abstract manner. They are using the transport mechanisms to exchange the data between client and server.
This basic concept of OPC UA enables an OPC UA client to access the smallest pieces of data without the need to understand the whole model exposed by complex systems. OPC UA clients also understanding specific models can use more enhanced features defined for special domains and use cases. The following figure shows the different layers of information models defined by OPC, by other organizations, or by vendors.
To cover all successful features known from Classic OPC, information models for the domain of process information are defined by OPC UA on top of the base specifications. DA defines automation-data-specific extensions such as the modeling of analog or discrete data and how to expose quality of service. All other DA features are already covered by the base. Alarm & Conditions (AC) specifies an advanced model for process alarm management and condition monitoring. Historical Access (HA) defines the mechanisms to access historical data and historical events. Programs (Prog) specifies a mechanism to start, manipulate, and monitor the execution of programs.
Other organizations can built their models on top of the UA base or on top of the OPC information model, exposing their specific information via OPC UA. Examples for standards already working on mappings to OPC UA are Field Device Integration (FDI) combining Electronic Device Description Language (EDDL), and Field Device Tool (FDT) both used to describe, to configure, and to monitor devices and PLCopen, a standard for PLC programming languages.
Additional vendor-specific information models will be defined using directly the UA base, the OPC models, or other OPC-UA-based information models.
OPC UA Specifications
The OPC UA specifications are partitioned in different parts also required for IEC standardization. OPC UA will be known as IEC 62541 standards. The following figure shows an overview of all specification parts split into the core specifications defining the base for OPC UA and the access type specific parts mainly specifying the OPC UA information models.
The first two parts are not normative. The concepts part UA Part 1 gives an overview about OPC UA and UA Part 2 describes the security requirements and the security model for OPC UA.
Most important to understand how to model and access information are part 3 and 4. These two specifications are the key documents for the design and development of OPC UA applications.
The Address Space Model in UA Part 3 specifies the building blocks to expose instance and type information and thus the OPC UA meta model used to describe and expose information models and to build an OPC UA server address space.
The abstract UA Services defined in [UA Part 4] represent the possible interactions between UA client and UA server applications. The client uses the Services to find and access information provided by the server. The Services are abstract because they are defining the information to be exchanged between UA applications but not the concrete representation on the wire and also not the concrete representation in an API used by the applications. The following figure shows the layered communication architecture of OPC UA.
The mapping of the UA Services to messages, the security mechanisms applied to the messages, and the concrete wire transport of the messages are defined in UA Part 6. Only implementers of UA stacks need to completely understand this specification. Since the OPC Foundation supplies proper UA stacks, typical UA application architects and programmers do not need to read this specification.
The base information model specified in UA Part 5 provides the framework for all information models using OPC UA. It defines the following:
- The entry points into the address space used by clients to navigate through the instances and types of an OPC UA server
- The base types building the root for the different type hierarchies
- The built-in but extensible types like object types and data types
- The Server Object providing capability and diagnostic information.
The profiles are defining useful subsets of OPC UA features in UA Part 7. Such a subset must be implemented completely by an UA application to ensure interoperability for the defined subset. The specification defines the subsets on two levels. The first level are Conformance Units defining a small set of functionality that is always used together and can be tested with Compliance Test Tools and verified as unit. The second level are Profiles composed of a list of conformance units. A profile must be implemented completely and will be verified as complete set during the certification of OPC UA products. The list of supported and used Profiles is exchanged during the connection establishment between client and server and allows the applications to determine if the needed features are supported by the communication partner.
The DA information model defines how to represent and use automation data and specific characteristics like engineering units in UA Part 8.
The AC information model specifies process alarm and condition monitoring specific state machines and types of events in UA Part 9.
The Programs information model defines a base state machine for the execution, manipulation, and monitoring of programs in UA Part 10.
The HA information model in UA Part 11 specifies the use of the history access Services and how to present information about the configuration of data and event history.
The aggregates used to compute aggregated values from raw data samples are specified in UA Part 13. The aggregates are used for historical access as well as the monitoring of current values.
UA Part 12 defines how to find servers in the network and how a client can get the necessary information to be able to establish a connection to a certain server.
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.
Also Read: What is OPC ?
