Difference between revisions of "Sequence of Capabilities"

From UaCapabilities
Jump to: navigation, search
Line 1: Line 1:
=OPC UA Infrastructure=
=OPC UA Infrastructure=
{{uaCollapsible|Server Discovery|{{Main:Server Discovery}}|mw-collapsed}}
{{uaCollapsible|Server Discovery|{{:Server Discovery}}|mw-collapsed}}
{{uaCollapsible|Transport Mapings|{{Main:Transport Mappings}}|mw-collapsed}}
{{uaCollapsible|Transport Mapings|{{:Transport Mappings}}|mw-collapsed}}
{{uaCollapsible|Data Model and Services|{{Main:Data Model and Services}}|mw-collapsed}}
{{uaCollapsible|Data Model and Services|{{:Data Model and Services}}|mw-collapsed}}
=OPC UA Base Information Models=
=OPC UA Base Information Models=

Revision as of 07:19, 3 February 2015


OPC UA Infrastructure

Server Discovery


An OPC UA Client wishing to connect to an OPC UA Server needs the address of the Server. UA Discovery defines the means to find OPC UA Servers, their supported protocols, security policies and other capabilities.

UA fw Discovery.JPG

Discovery has to consider different configurations

  • Client and Server on the same host
  • on the same network or
  • on completely different locations in a system (a plant, an enterprise).

Furthermore, Servers may be installed on different types of host devices like a sensor, a control device, or a workstation. A single device may host more than one Server.

Servers may have multiple endpoints if they support multiple addresses, protocols, or multiple levels of security. Clients can discover these endpoints and choose the proper one based on a system-wide policy or based on manual selection.

Note - Discovery is specified in [OPC UA Part 12, the Discovery Services are specified in OPC UA Part 4.

Required Discovery Capabilities

Local Discovery

Clients may be pre-configured by some out-of-band mechanism. Without pre-configuration, Clients have to support the following discovery mechanisms:

  • Allow manual entry of a DiscoveryUrl.
  • Use FindServers Service to obtain the DiscoveryUrls of Servers on the local or a remote host.
  • Use FindServersOnNetwork to obtain the DiscoveryUrls of Servers on the same multicast Subnet.
  • Discover a Server's Endpoint using the Server's DiscoveryUrl.

All Servers have to support a discovery endpoint that provides Clients the following usages:

  • Locate Servers on the local host (Local Discovery): Clients can detect and choose end points of OPC UA servers located on the local host.
  • Locate Servers on a known remote host (Remote Discovery): This is for clients that know the name of the remote target host. Clients can use the host address to discover the Servers on this remote host.

Conformance Testing

Client Server

The ability to discover Servers and their endpoints on a known host. See Discovery Client Facet

Servers have to provide the services FindServers and GetEndPoints as outlined by the corresponding conformance units in Core Server Facet.

Local Discovery Server

The OPC Foundation delivers a Local Discovery Server (LDS) which provides the necessary infrastructure to publicly expose multiple OPC UA Servers available on a given host system. It listens on the OPC UA port 4840. If only a single OPC UA Servers is installed on a host, an LDS is not needed and the OPC UA Server itself will listen on port 4840. The existence of an LDS is transparent for Clients that use the Discovery Services. They always connect to port 4840 and have to be prepared to find more than one Server on a single host.

Advanced Discovery Capabilities

Subnet Discovery

URN:          https://opcfoundation.org/wiki/index.php/Server_Discovery#Subnet_Discovery

Subnet discovery is based on the multicast DNS protocol that allows OPC UA Clients to find OPC UA Servers connected to the local subnet. The list of Servers can be filtered by capability acronyms.

Usage Considerations

  • Automatic detection instead of querying each node on the network
  • Filtering by capability to lookup the appropriate Servers.
  • Requires that the network has multicasting enabled.
  • The Local Discovery Server with multicast extension (LDS-ME) available from the OPC Foundation enables subnet discovery.

Conformance Testing

Client Server

The Subnet Discovery Client Facet includes two alternative Conformance Units (CUs) for this capability:

  1. With LDS: Conformance Unit Discovery Client Find Servers on Network
  2. Without LDS: Conformance Unit Discovery Client Find Servers on Network using mDNS
  1. With LDS: Servers register themselves by calling the Register2 Service.
  2. Without LDS: Servers announce themselves using mDNS as defined in Subnet Discovery Facet.

Global Discovery

URN:          https://opcfoundation.org/wiki/index.php/Server_Discovery#Global_Discovery

Global discovery is useful for large systems with multiple servers on multiple subnets. It requirs an enterprise wide DiscoveryServer called a Global Discovery Server. The Global Discovery Server (GDS) is an OPC UA Server which provides the Methods to search for Servers in the enterprise.
All GDS implementations have to provide the standard global discovery information model. It is therefore transparent for Clients that support global discovery which commercial GDS is installed in a plant.

Usage Considerations

  • Enables a Client to find OPC UA Servers within an enterprise.
  • Clients can search with a capability filter to lookup the appropriate Servers.
  • It will be common that a GDS also supplies global certificate and trust list management for the OPC UA application it manages.
  • One or more Global Discovery servers can be used to maintain discovery information of installed OPC UA applications.
  • Requires a commercial Global Discovery Server (GDS)

Conformance Testing

Transport Mapings


UA fw Transport.JPG

OPC UA is a set of layered specifications broken into multiple parts. The base and functional parts of OPC UA are described in abstract terms. A separate implementation part defines the mapping to existing protocol and security technologies on which interoperable software can be built.
This layering is on purpose to isolate the architectural framework from the inevitable changes in the technology used to implement it. So as new technologies arrive, OPC UA will be able to advance with them. It will be possible to add new over-the-wire protocols, and to add new security and encryption technologies without changing the functional elements of OPC UA.
To support different application domains with different requirements, OPC UA already today defines multiple mappings for different protocols and encodings. Each mapping consists of three functional layers: Data Encoding, Security Protocol and Transport Protocol. Different mappings are combined together to create Transport Capabilities.

Note - Transport Mappings are specified in OPC UA Part 6.

Required Transport Capabilities

UA_TCP Transport

OPC UA TCP is a required transport. It is a simple, TCP-based protocol that establishes a full duplex channel between Client and Server. UA TCP messages are binary encoded and optimized for high performance intranet communication.

Usage Considerations

  • Offers the best performance with the least amount of overhead.
  • Minimal resource utilization – for example, no XML Parser, SOAP or HTTP required.
  • Preferred in particular for devices at control and field level.

Conformance Testing

Client Server

This required capability does not include a security policy. It is assumed that the communication is secured by means outside the scope of OPC UA.

identical to Client

Advanced Transport Capabilities


URN:          https://opcfoundation.org/wiki/index.php/Transport_Mappings#UA_TCP-Secured

This transport capability supplements the UA_TCP transport with security, including:

  • Authentication of communication partner based on digital certificates that are exchanged during the establishment of a secure channel. This is based on Public Key Infrastructure (PKI) standards.
  • Efficient Data encryption algorithms to provide Confidentiality
  • Efficient Message signatures to provide Integrity

Usage Considerations

  • Application authentication allows restricting access to trusted parties.
  • End-to-end encryption offers uninterrupted protection of data between Client and Server resulting in a higher degree of security than transport protocols that protect messages by establishing secure connection between two hosts (HTTPS, for example).
  • Can be applied to a wide range of devices and application, from control and field devices that require security to enterprise level applications.

Conformance Testing


URN:          https://opcfoundation.org/wiki/index.php/Transport_Mappings#HTTPS-UA_Binary

This transport mapping uses the HTTPS transport for the exchange of binary OPC UA messages. HTTPS is a protocol that provides transport security. This means all bytes are secured as they are sent without considering the message boundaries. Transport security can only work for point to point communication and does not allow untrusted intermediaries or proxy servers to handle traffic. In scenarios where an intermediary is needed, the HTTPS transport cannot ensure security and the applications will have to establish a secure tunnel like a VPN before attempting any OPC UA related communication.

Usage Considerations

  • Requires more resources with more overhead than UA_TCP
  • Firewall friendly: uses standard https ports.
  • Can use a browser as a Client.

Conformance Testing


URN:          https://opcfoundation.org/wiki/index.php/Transport_Mappings#HTTPS-Soap_Xml

This transport maps the OPC UA Services using a SOAP request-response message pattern over an HTTPS connection. (See https binary description for specific issues related to https)

Usage Considerations

  • Requires significantly more resources with more overhead than UA_TCP
  • Firewall friendly: uses standard https ports.
  • XML Web Service compatible
  • Can use a browser as a Client.

Conformance Testing

Data Model and Services


OPC UA has been designed to provide semantic interoperability. This enables Clients and Servers to exchange data with unambiguous shared meaning.

UA fw InfoAccess.JPG

To make this possible, OPC UA provides an information modeling framework that turns date into information and rules how to represent the information in the Address Space. It defines an Object as the fundamental element to represent the data and activity of an underlying system. Objects contain Variables, Methods, and may generate Events. Objects can have relationships to other Objects.
The collection of Objects that the Server makes available to Clients builds the Address Space which is structured according to principles of the Address Space Model.
OPC UA also allows defining semantics for Variable data. In current systems, the data exposed and exchanged are often just simple data points; i.e., just an Integer, a Float, or a Boolean. OPC UA allows specifying that a Float can be seen as currently measured temperature of an article; a Boolean can signify the state of a valve (open or closed). In addition to simple data types, OPC UA also supports structured data types. Structured data allow specifying user-defined, complex data types. An example of a structure is an Address. It contains the country, region, city, city code, street and street number.

Note – The Address Space Model is specified in OPC UA Part 3 The UA Services are used to access the elements in the Server Address Space like browsing, reading or writing a variable value, calling a method or receiving events from the Object.
Note – The OPC UA Services are specified in OPC UA Part 4

Required Information Access Capabilities

The OPC UA Services and the Address Space Model form the core functionality of every OPC UA application. Still, not all Services and not all facets of information modelling are needed by every application. Following are the minimum required elements.

Connect Services

Support or use the Services

  • to create a Secure Channel.
  • to open and close a Session.
  • to keep a Session alive by using periodic requests.

Usage Considerations

  • Server and Client identify and authenticate each other.
  • A connection is established where requests and responses can be efficiently exchanged.

Address Space

The set of Objects and related information that a Server makes available to Clients is exposed as its AddressSpace.

  • The Objects and their components are represented as a set of Nodes and interconnected by References.
  • The Address Space is built according to the rules of the Address Space model.
  • The Address Space includes the standardized entry points (e.g., Objects, Types).
  • The Address Space includes the Server Object including all mandatory components.

Support or use the Services

  • to navigate through the Server Address Space.
  • to read or write Attributes of Nodes in the Address Space.

Usage Considerations

  • Exchange of Objects, both meta data and instance data.

Advanced Information Access Capabilities

Event Data

URN:          https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Event_Data

Events represent specific transient occurrences. Examples are system configuration changes and system errors. Servers expose the types of events they support in the Address Space. When an event occurs, the Server sends an event notification to subscribed Clients.
Each event type includes a set of event fields that define the information provided to Clients when an event occurs. These include among others the event id, time of occurrence, severity, and a message text. Clients select the fields they are interested in.

Usage Considerations
Receive unsolicited notifications of significant occurrences within the system represented by the Server.
Areas of interest include (but are not limited to); configuration change notifications, auditing of security or other changes, general purpose notification, safety limits of equipment, event detection, and abnormal situations.

Conformance Testing

Event Areas

URN:          https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Event_Areas

The events issued by a Server can be organized into notification areas. An area is a grouping of event sources, typically according to areas of operator responsibility. The grouping is server-specific but will often be based on location (all events in hall A) or equipment type (all robots).

Usage Considerations
Monitor / control several, potentially independent areas of a plant.


URN:          https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Methods

Methods represent the function calls of Objects. They are invoked with a standard UA Service and return only after completion (successful or unsuccessful). Execution times for methods may vary, depending on the function that they perform.

Usage Considerations

  • Methods are exposed in the Address Space with their name and argument definitions.

Structured Data

URN:          https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Structured_Data

OPC UA supports arbitrarily complex data structures that can be used as value of a Variable, in Event fields, or as parameter of Methods. The information how to decode structures is provided in the Address Space so that they can be explored and used on the fly.
When used for Variables, the elements of a structure can be exposed as separate (component) Variables with potentially simple data types.

Usage Considerations
Efficient and consistent transfer of data that belong together.

Conformance Testing

Client Server
  • Determine the type and encoding of structures.
  • Read and decode or encode and write arbitrary structures.

Expose Variables with structured types, provide the encoding, provide read/write access

Durable Subscriptions

URN:          https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Durable_Subscriptions

Description Durable subscriptions are OPC UA subscriptions with a very long lifetime and large queues so that monitored data can be collected and stored during times where the Client is disconnected. When the disconnected Client connects and creates a Session it will transfer the Subscription to this Session and receive the queued data and events.

Usage Considerations

  • "Disconnected Client" - i.e. Client can connect only once or a few times a day
  • Stored data and events are available even after server restart


URN:          https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Views

Underlying systems are often large and Clients often have an interest in only a specific subset of the data. They do not need, or want, to be burdened with viewing portions of the Address Space for which they have no interest. To address this problem, OPC UA defines the concept of a View.

Views can be used to subset the complete Address Space for different uses. An example would be the exposure of plant information with an operation view, with a physical layout view, and an electrical interconnection view.

Usage Considerations
Simpler navigation; client only sees objects that are needed for a specific view.

Conformance Testing

Client Server
  • Identify available Views.
  • Use View Ids in OPC UA Services.
  • Subset the Address Space into multiple Views.
  • View Ids can be used in OPC UA Services.



Security is a fundamental aspect of OPC UA. It consists of several individual elements that are integrated in different layers of the OPC UA Framework.

UA fw Security.JPG

OPC UA Security is concerned with the authentication of clients and servers, the authorization of users, the integrity and confidentiality of their communications and the auditing of client server interactions. To meet this goal, security is integrated into all aspects of the design and implementation of OPC UA Servers and Clients. OPC UA security is based on industry standard security algorithms, yet is scalable to meet the environment and application requirements. Communication Layer Security is part of the Transport Mapping Capabilities; see Transport Mappings. The design and implementation of OPC UA’s security standard is based on proven standards. The resulting OPC UA security architecture permeates the application and communication layers atop the transport layer.


All activities in the application layer are based on a secure channel that is created in the communication layer. Applications rely upon it for secure communication in addition to application authentication. The secure channel is responsible for messages integrity, confidentiality and application authentication. The application layer manages user authentication and user authorization. Clients may pass a user identity token to the OPC UA Server. The Server verifies that this user is allowed to access and what resources it is authorized to use.
Note – The OPC UA Security Model is described in OPC UA Part 2.
The Secure Conversation Services and the security elements in Session Services are specified in OPC UA Part 4.
The communication layer security elements are specified in OPC UA Part 6.

Required Security Capabilities

Confidentiality, Integrity, and Authentication

Security in the Communication Layer has to be supported as required for the supported Transport. This includes application authentication and secure communication.

  • The Server is obligated to minimally support user authentication with UserName/Password.
  • Clients have to support UserName/Password or X.509 certificates as required by the Server.

Usage Considerations
Security, including encryption, signing, and user authentication, is a core element for OPC UA applications and is therefore part of the OPC Foundation stacks.
OPC UA has defined profiles for lowest-level embedded solutions that will be secured by means outside the scope of OPC UA.

Advanced Security Capabilities

Application Authentication

URN:          https://opcfoundation.org/wiki/index.php/Security#Application_Authentication

Application authentication allows OPC UA applications to identify each other. Each OPC UA application instance has a digital certificate (instance certificate) assigned that is exchanged during connection setup. The receiver of the certificate checks whether it trusts the certificate. This trust check is accomplished using the concept of TrustLists. TrustLists can be managed by vendor-specific means or by OPC UA Certificate Management.
If HTTPS is used, application authentication is not available. If authentication is required with this transport, it must be based on user credentials.

Usage Considerations

  • Ensures that a server only allows a trusted client to connect and that a client only communicates with trusted servers.
  • Requires that a PKI infrastructure is in place.
  • Not available with HTTPS transport.

Conformance Testing

Client Server

Application authentication is integral part of the security policies (except Security Policy - none).
It shall also be possible to configure for no application authentication, just user authentication and normal encryption/signing:

  • Configure Client application to accept all Server certificates
  • Certificates are just used for message security (signing and encryption)
  • User level is used for authentication

Application authentication is integral part of the security policies (except Security Policy - none).
It shall also be possible to configure for no application authentication, just user authentication and normal encryption/signing:

  • Configure Server application to accept all Client certificates
  • Certificates are just used for message security (signing and encryption)
  • User level is used for authentication


URN:          https://opcfoundation.org/wiki/index.php/Security#UserToken-X509

Enable user authentication by means of a digital certificate (an X.509v3 identity token).

Usage Considerations

  • Must be issued to user and associated with a UA session
  • Requires that a PKI infrastructure is in place.


URN:          https://opcfoundation.org/wiki/index.php/Security#UserToken-Kerberos

Enable user authentication by means of Kerberos tickets.

Usage Considerations

  • Requires a trusted third party, and optionally may use public-key cryptography during certain phases of authentication.
  • Kerberos protocol messages are protected against eavesdropping and replay attacks.
  • Kerberos is the default authentication method for Windows and also available on most Linux platforms.

User Impersonation

URN:          https://opcfoundation.org/wiki/index.php/Security#User_Impersonation

Change the user identity associated with the session to a different user.

Usage Considerations

  • Enables a user to take ownership of a session with the aim to authorize the requested operation.
  • Often needed also when server acts as a client to other servers.

Conformance Testing

Client Server

Use the ActivateSession Service with a different user token to change the current user.

Support the ActivateSession Service with a different user token to change the current user.

User Authorization

URN:          https://opcfoundation.org/wiki/index.php/Security#User_Authorization

Manage user roles to restrict or control OPC UA access to resources represented by a Server.
The way how users are managed and how authorization is actually performed (e.g. using role-based authorization) is outside the scope of OPC UA.

Usage Considerations

  • Restrict certain features to specialists.
  • Authorization can be as coarse-grained as allowing some users full access and others only read access. It can also be much finer grained such as allowing specific actions on specific resources by specific users or roles.

Conformance Testing

Client Server

<no specific requirement>

  • Provide means to administer users and their access permissions.
  • Expose user-specific permissions via the UserAccessLevel attribute.
  • Provide the configured authorization for the respective Services. E.g. reject writing values or calling methods if not allowed for the current user.



UA fw Robustness.JPG

OPC UA includes several features that ensure the robustness of OPC UA communication and that are integrated in different layers of the OPC UA Framework. It includes

  • Error detection and handling on transport and service level,
  • Buffering of data so that they are not lost during a network connection
  • Auditing – i.e., the support for security audit trails with traceability between Client and Server audit logs., and
  • Availability of diagnostic information.

Note – The Robustness features are specified as part of the Services in OPC UA Part 4.

Required Robustness Capabilities

Detection of Errors, Recovery


  • Handle error conditions including violations of resource limits and return status information as specified.
  • Recover from communication failures.
  • Limit the number of client connections, subscriptions and service calls as appropriate for the target platform.
  • Use continuation points if a request cannot be fully answered with a single response.
  • Maintain lifetime of Sessions and Subscriptions based on their configured timer and independent from transport connections.
  • Auto-close the Session based on session timeout and client inactivity.


  • Handle connection failures and perform automatic reconnects.
  • Check and handle all failure codes in service responses.
  • Periodically send requests to keep session alive and verify the server is still alive.

Conformance Testing

Advanced Robustness Capabilities


URN:          https://opcfoundation.org/wiki/index.php/Robustness#Buffering

Sent notifications of subscribed data or events will be buffered for retransmission until acknowledged by the Client. This ensures reliable delivery of these messages even during short network interrupts.
See Data Model and Services::Durable Subscription Capability that offers even more advanced buffering.

Usage Considerations

  • No loss of information during network interrupts.

Conformance Testing

Client Server
  • Acknowledge received notification messages.
  • Use republish services for missing notification messages.

Maintain a retransmission queue of sent notification messages with a minimum size defined in OPC UA Part 4.

Client AuditLog

URN:          https://opcfoundation.org/wiki/index.php/Robustness#Client_AuditLog

The Client maintains an audit log and passes appropriate, human readable audit entry information in requests when calling the Server.
This capability implies that the Client handles OPC UA audit events

Usage Considerations

  • Allows tracking activities that occur as part of normal operation of the system as well as abnormal behaviour.
  • Detect security-related problems in the Server.
  • Allows for traceability between client activities and server audit events.

Audit Events

URN:          https://opcfoundation.org/wiki/index.php/Robustness#Audit_Events

Server generates audit messages as event notifications for operations. Examples include writing to a variable or attempting to connect to a server with invalid credentials.

Usage Considerations

  • Notifies security related actions in a system. It includes failed attempts to connect, successful connects, actions that alter the system, errors or security violations.
  • Clients can subscribe to audit event notifications

Diagnostic Data

URN:          https://opcfoundation.org/wiki/index.php/Robustness#Diagnostic_Data

The collection of diagnostic information can greatly aid in early detection and prevention of potential problems. OPC UA defines Objects with diagnostic information for numerous Server activities.
The collection of diagnostic information can be turned on or off so that it does not unnecessarily impede normal operation.

Usage Considerations

  • Identify current load.
  • Identify security attacks.
  • Identify usage patterns.
  • Identify bottlenecks.
  • Identify bad / inefficient interaction scenarios.

Conformance Testing

Client Server
  • Enable and disable collection of diagnostics.
  • Make use of diagnostic data.
  • Support the diagnostic information model defined in OPC UA Part 5.

OPC UA Base Information Models


Template:Base Information Models

Data Access

Template:Data Access

Alarms & Conditions

Template:Alarms and Conditions

Historical Data Access

Template:Historical Data Access

Historical Event Access

Template:Historical Event Access



Certificate Management

Template:Certificate Management



Industry Standard Models


Template:Industry Standard Models

Device Integration (DI)

Template:Device Integration Model (DI)

Analyzer Devices (ADI)

Template:Analyzer Device Integration (ADI)

Field Device Integration (FDI)

Template:Field Device Integration (FDI)

PLC open

Template:PLCopen Model (IEC61131-3)

MTConnect - Process information from numerically controlled machine tools

Template:MTConnect - Process information from numerically controlled machine tools

Enterprise Control System Integration (ISA-S95)

Template:Enterprise-Controlsystem Integration Model (ISA-95)