1. Overview

	The OPC UA Client module for the Edge One™ platform connects to OPC UA Servers. The module includes an easy to use interface to configure the Client connection, and the ability to read and write data on the nodes that Servers make visible to their Clients.

This guide contains the following sections:

1. Overview of the OPC UA protocol.
2. Overview of the OPC UA Client.

For details on the Edge One™ OPC UA Client consult the following guides:

1. OPC UA Client Features provides details on the features supported by the OPC UA Client.
2. OPC UA Client Configuration describes how to create a configure an OPC UA Client project.
3. View and Write Data in the OPC UA Client describes how to view real time data of an OPC UA Client project, and how to write data to its Nodes.

OPC UA Overview

OPC UA (OLE for Process Control (Object Linking and Embedding for process control) Unified Access) is a machine-to-machine communication protocol for information exchange and command and control for industrial processes.

OPC UA is built using a service oriented architecture (SOA) and defines a common infrastructure model to facilitate this information exchange by specifying:

• The information model to represent structure, behaviour and semantics.
• The message model to interact between applications.
• The communication model to transfer the data between end-points.
• The conformance model to guarantee interoperability between systems.

OPC UA is a platform-independent standard through which various kinds of systems and devices can communicate by sending request and response Messages between Clients and Servers or NetworkMessages between Publishers and Subscribers* over various types of networks. It supports robust, secure communication that assures the identity of OPC UA Applications and resists attacks.

OPC UA requires a stateful model and the state information is maintained inside an application Session. Examples of state information are Subscriptions, user credentials, and continuation points for operations.

Sessions are logical connections between Clients and Servers. Servers may limit the number of concurrent Sessions based on resource availability, licensing restrictions, or other constraints. Sessions are independent of the underlying protocols. They only terminate based on Client or Server request, or based on inactivity of the Client. The inactivity time interval is negotiated during Session establishment.

If a Server supports the SecureChannel Service set to communicate with the Client, they verify that all incoming Messages have been signed and/or encrypted according to the security policy. A UA application is expected to ignore any Message that does not conform to the security policy for the channel. A single UA Application Session may only be accessed via a single SecureChannel. This implies that the UA application is able to determine what SecureChannel is associated with each Message.

The relationship between the UA Application Session and the Secure Channel is illustrated in Figure 1. The UA applications use the communication stack to exchange Messages. First, the SecureChannel Services are used to establish a SecureChannel between the two communication stacks, allowing them to exchange Messages in a secure way. Second, the UA applications use the Session Service Set to establish a UA application Session.

Figure 2 illustrates an OPC UA architecture that includes a system acting both as Client and Server.

OPC UA can operate in one of two models:

• Client Server - In this model, OPC UA defines sets of Services that Servers may provide, and individual Servers specify to Clients what Service sets they support. Information is conveyed using OPC UA-defined and vendor-defined data types, and Servers define object models that Clients can dynamically discover. Servers can provide access to both current and historical data, as well as Alarms and Events to notify Clients of important changes. OPC UA can be mapped onto a variety of communication protocols and data can be encoded in various ways to trade off portability and efficiency.
• PubSub - In this model, OPC UA defines a mechanism for Publishers to transfer the information to Subscribers.

OPC UA Services allow Clients to:

1. Issue requests to Servers and receive responses from them.
2. Subscribe to Servers for Notifications which include Alarms, data value changes, Events, and Program execution results.

OPC UA provides a consistent, integrated AddressSpace and service model. This allows a single Server to integrate data, Alarms and Events, and history into its AddressSpace, and to provide access to them using an integrated set of Services. These Services also include an integrated security model.

The OPC UA AddressSpace represents its contents as a set of Nodes connected by References. Nodes may have References to each other, allowing the AddressSpace to represent an interrelated network of Nodes.

Each Node has a unique identifier called the NodeId, which is always composed of three elements:

• Namespace Index - URI that identifies the authority defining the identifiers of NodeIds.
• Identifier Type which can be: numeric (i), string (s), globally unique identifier (guid), or opaque(b) which is a namespace specific format in a ByteString. The OpaqueType describes a binary encoded value that is either a primitive fixed length type or that has a structure too complex to capture in an OPC Binary type dictionary. The OPC Binary Type Description System defines many standard OpaqueTypes that should allow authors to describe most binary encoded values as StructuredTypes.
• Identifier which is identifier of the Node in the address space.

Figure 2 illustrates the model of a Node.

OPC UA also allows Servers to provide Clients with type definitions for the Objects accessed from the AddressSpace. This allows information models to be used to describe the contents of the AddressSpace. OPC UA allows data to be exposed in many different formats, including binary structures and XML or JSON documents. The format of the data may be defined by OPC, other standard organizations or vendors. Through the AddressSpace, Clients can query the Server for the metadata that describes the format for the data. In many cases, Clients with no pre-programmed knowledge of the data formats will be able to determine the formats at runtime and properly utilize the data.

Figure 3 illustrates the Object model.

OPC UA adds support for many relationships between Nodes instead of being limited to just a single hierarchy. In this way, a Server may present data in a variety of hierarchies tailored to the way a set of Clients would typically like to view the data. This flexibility, combined with support for type definitions, makes OPC UA applicable to a wide array of problem domains. OPC UA is not targeted at just the SCADA, PLC and DCS interface, but also as a way to provide greater interoperability between higher level functions.

The OPC UA specifications are layered to isolate the core design from the underlying computing technology and network transport. This allows OPC UA to be mapped to future technologies as necessary, without negating the basic design.

For detailed information, please refer to the OPC UA Specification available on the OPC Foundation website. The specification is organized as a multi -part specification, as illustrated in the table below.

OPC UA Multi-part Specification
Core Specification Parts	Access Type Specification Parts
Part 1 - Overview and Concepts	Part 8 - Data Access
Part 2 - Security Model	Part 9 - Alarms and Conditions
Part 3 - Address Space Model	Part 10 - Programs
Part 4 - Services	Part 11 - Historial Access
Part 5 - Information Model
Part 6 - Service Mappings.	Utility Specification Parts
Part 7 - Profiles	Part 12 - Discovery
Part 14 - PubSub	Part 13 - Aggregates

Parts 1 through 7 and Part 14 specify the core capabilities of OPC UA. These core capabilities define the structure of the OPC AddressSpace and the Services that operate on it. Part 14 defines an OPC UA publish subscribe pattern in addition to the Client Server pattern defined by the Services in Part 4. Parts 8 through 11 apply these core capabilities to specific types of access previously addressed by separate OPC COM specifications, such as Data Access (DA), Alarms and Events (A&E) and Historical Data Access (HDA). Part 12 describes Discovery mechanisms for OPC UA and Part 13 describes ways of aggregating data.

Readers are encouraged to read Parts 1 through 5 of the core specifications before reading Parts 8 through 14. For example, a reader interested in UA Data Access should read Parts 1 through 5 and 8. References in Part 8 may direct the reader to other parts of this specification.

Here is a brief description of each Part.

Core specification parts
Part_1_:_Overview_and_Concepts	presents the concepts and overview of OPC UA.
Part 2 : Security Model	describes the model for securing interactions between OPC UA Applications.
Part 3 : Address Space Model	describes the contents and structure of the Server’s AddressSpace.
Part 4 : Services	specifies the Services provided by Servers.
Part 5 : Information Model	specifies the types and their relationships defined for Servers.
Part 6 : Mappings	specifies the mappings to transport protocols and data encodings supported by OPC UA.
Part 7 : Profiles	specifies the Profiles that are available for OPC UA Applications. These Profiles provide groupings of functionality that can be used for conformance level certification. OPC UA Applications will be tested against the Profiles.

Access_Type_specification_parts
Part 8 : Data Access	specifies the use of OPC UA for data access.
Part 9 : Alarms and Conditions	specifies use of OPC UA support for access to Alarms and Conditions. The base system includes support for simple Events; this specification extends that support to include support for Alarms and Conditions.
Part 10 : Programs	specifies OPC UA support for access to Programs.
Part 11 : Historical Access	specifies use of OPC UA for historical access. This access includes both historical data and historical Events.

Utility_specification_parts
Part 12 : Discovery	specifies how Discovery Servers operate in different scenarios and describes how UA Clients and Servers should interact with them. It also defines how UA related information should be accessed using common directory service protocols such as LDAP.
Part 13 : Aggregates	specifies how to compute and return aggregates like minimum, maximum, average etc. Aggregates can be used with current and historical data.
Part 14 : PubSub	specifies the OPC Unified Architecture (OPC UA) PubSub communication model. The PubSub communication model defines an OPC UA publish subscribe pattern in addition to the Client Server pattern defined by the Services in Part 4.

Back to Top

OPC UA Client

The OPC UA Client architecture models the Client endpoint of client/server interactions. Figure 4 below illustrates the major elements of a typical OPC UA Client and how they relate to each other.

The Client Application is the code that implements the function of the Client. It uses the OPC UA Client API to send and receive OPC UA Service requests and responses to the OPC UA Server. The OPC UA Client API isolates the Client application code from the OPC UA Communication Stack. The OPC UA Communication Stack converts OPC UA Client API calls into Messages and sends them through the underlying communications entity to the Server at the request of the Client application. The OPC UA Communication Stack also receives response and NotificationMessages from the underlying communications entity and delivers them to the Client application through the OPC UA Client API.

Back to Top