Sequence of Capabilities
Contents
- 1 OPC UA Infrastructure
- 1.1 Server Discovery
- 1.2 Introduction
- 1.3 Required Discovery Capabilities
- 1.4 Advanced Discovery Capabilities
- 1.5 Introduction
- 1.6 Required Transport Capabilities
- 1.7 Advanced Transport Capabilities
- 1.8 Introduction
- 1.9 Required Information Access Capabilities
- 1.10 Advanced Information Access Capabilities
- 1.11 Introduction
- 1.12 Required Security Capabilities
- 1.13 Advanced Security Capabilities
- 1.14 Introduction
- 1.15 Required Robustness Capabilities
- 1.16 Advanced Robustness Capabilities
- 2 OPC UA Base Information Models
- 3 Industry Standard Models
OPC UA Infrastructure
Server Discovery
Introduction
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.
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
Client
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.
Server
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
Description
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:
|
|
Global Discovery
URN: https://opcfoundation.org/wiki/index.php/Server_Discovery#Global_Discovery
Description
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
| Client | Server |
|
- |
Transport Mapings
Introduction
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
Description
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
UA_TCP-Secured
URN: https://opcfoundation.org/wiki/index.php/Transport_Mappings#UA_TCP-Secured
Description
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
| Client | Server |
|
identical to Client |
HTTPS-UA_Binary
URN: https://opcfoundation.org/wiki/index.php/Transport_Mappings#HTTPS-UA_Binary
Description
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
| Client | Server |
|
identical to Client |
HTTPS-Soap_Xml
URN: https://opcfoundation.org/wiki/index.php/Transport_Mappings#HTTPS-Soap_Xml
Description
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
| Client | Server |
|
identical to Client |
Data Model and Services
Introduction
OPC UA has been designed to provide semantic interoperability. This enables Clients and Servers to exchange data with unambiguous shared meaning.
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
Description
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
Description
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.
Conformance Testing
Advanced Information Access Capabilities
Event Data
URN: https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Event_Data
Description
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
| Client | Server |
Event Areas
URN: https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Event_Areas
Description
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.
Conformance Testing
| Client | Server |
Methods
URN: https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Methods
Description
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.
Conformance Testing
| Client | Server |
Structured Data
URN: https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Structured_Data
Description
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 |
|
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
Conformance Testing
Views
URN: https://opcfoundation.org/wiki/index.php/Data_Model_and_Services#Views
Description
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 |
|
|
Security
Introduction
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.
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.
|
Required Security Capabilities
Confidentiality, Integrity, and Authentication
Description
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
Description
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).
|
Application authentication is integral part of the security policies (except Security Policy - none).
|
UserToken-X509
URN: https://opcfoundation.org/wiki/index.php/Security#UserToken-X509
Description
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.
Conformance Testing
UserToken-Kerberos
URN: https://opcfoundation.org/wiki/index.php/Security#UserToken-Kerberos
Description
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.
Conformance Testing
User Impersonation
URN: https://opcfoundation.org/wiki/index.php/Security#User_Impersonation
Description
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
Description
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> |
|
Robustness
Introduction
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
Servers:
- 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.
Clients:
- 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
| Client | Server |
Advanced Robustness Capabilities
Buffering
URN: https://opcfoundation.org/wiki/index.php/Robustness#Buffering
Description
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 |
|
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
Description
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.
Conformance Testing
| Client | Server |
|
Maintain an audit log and store audit events issued by a Server |
none |
Audit Events
URN: https://opcfoundation.org/wiki/index.php/Robustness#Audit_Events
Description
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
Conformance Testing
Diagnostic Data
URN: https://opcfoundation.org/wiki/index.php/Robustness#Diagnostic_Data
Description
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 |
|
|
OPC UA Base Information Models
Industry Standard Models
MTConnect - Process information from numerically controlled machine tools
Enterprise Control System Integration (ISA-S95)
