Revision as of 07:39, 3 February 2015 (view source) Karl (Talk | contribs) ← Older edit		Revision as of 07:51, 3 February 2015 (view source) Karl (Talk | contribs) Newer edit →
Line 1:		Line 1:
	=OPC UA Infrastructure - Server Discovery=		=OPC UA Infrastructure - Server Discovery=
		+
		+	<div class="toccolours mw-collapsible" style="width:100%">
		+	{{:Server Discovery}}
		+	</div>
		+
	{{:Server Discovery}}		{{:Server Discovery}}
	<br><br>		<br><br>

---

Revision as of 07:51, 3 February 2015

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.

---

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

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.

---

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)

---

OPC UA Infrastructure - Transport Mappings

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.

---

Advanced Transport Capabilities

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.

---

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.

---

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.

---

OPC UA Infrastructure - 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.

---

Advanced Information Access Capabilities

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.

---

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.

---

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.

---

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.

---

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

---

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.

---

OPC UA Infrastructure - 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. 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

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

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.

---

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.

---

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.

---

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.

---

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.

---

OPC UA Infrastructure - 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.

---

Advanced Robustness Capabilities

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.

---

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.

---

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

---

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.

---

OPC UA Base Information Models: Overview

The OPC UA Object Model provides a consistent way for representing object-based information models in the AddressSpace. Information models may be defined by standards organizations, vendors or end-users. A number of "Base Information Models" are specified as part of the OPC UA standard and include Objects that are common in multiple application domains. Definitions exist for alarms, analog and discrete data, historical data and events, and more. Data, alarms and events, and their history can be integrated into a single OPC UA Server. For example, OPC UA Servers are able to represent a temperature transmitter as an Object that is composed of a temperature value, a set of alarm parameters, and a corresponding set of alarm limits.

OPC UA Base Information Models: Data Access

Introduction

Data Access is an information model for real-time data, i.e. data that represent current state and behaviour of the underlying industrial or business process. Access is provided with Read, Write and Subscription Services. Typical sources are sensors, control devices, position transducers and more.

Such information is typically used by Clients for user displays, or to monitor and control the process.

Examples include:

• device data such as sensor measurement or actuator state
• energy consumption, energy price
• calculated data
• business data
• dynamically-changing system data (such as stock quotes)
• diagnosis data

In automation systems the data is often located on I/O cards or on other devices such as controllers and input/output modules, connected by serial links via field buses or other communication links. The DA model therefore also defines codes that specify the quality of the physical connection.
Note – Data Access is specified in OPC UA Part 8.

Required Data Access Capabilities

OPC UA Data Access is represented by a set of advanced capabilities. The key functionalities for Data Access, however are already part of the required Information Access capabilities (see InfoAccess All).

Advanced Data Access Capabilities

Data Access

Description
DataAccess in general is the ability to access real-time data. The data are Variables with a type that reflects the main classification (e.g., analog or discrete).

Usage Considerations

• User Displays
• Process monitoring and control

---

Array Data

Description
Array Data refer to continuously-variable physical quantities where each individual data point consists of multiple values represented by an array (e.g., the spectral response of a digital filter).

Usage Considerations
Typical examples are the data provided by process and laboratory analyser devices like Particle Size Monitor or Gas Chromatograph.

---

OPC UA Base Information Models: Alarms & Conditions

Introduction

Conditions define some state in a system that requires interaction with an operator or users. An example would be a Dialog that is displayed when something occurs that an operator needs to respond to, such as mounting archive device. Alarms are specific conditions that represent abnormal states of a process or system. This includes unsolicited notifications when the Alarm state changes. Some common examples are:

• a temperature exceeding a configured limit
• infringing safety limits of equipment
• a device needing maintenance
• a batch process that requires a user to confirm some step in the process before proceeding

State-driven notifications have great advantages when dealing with large systems that have hundreds to millions of conditions. Alarm clients can subscribe for alarm notifications for specific areas in a plant. They will receive notifications whenever the state of a condition changes and where each notification includes enough information to identify the type and source. Such notifications will typically be used to help identify faulty equipment, create maintenance work orders and improve on operator's effectiveness.
Some state changes require actions like acknowledging the state change. An example is an Alarm becoming active when a measurement device exceeds a configured limit.
Note – Alarms & Conditions is specified in OPC UA Part 9.

Alarms and Conditions Capabilities

Conditions

Description
Support the Condition Information Model and the notification mechanisms about condition states. Support for a refresh method.

Usage Considerations Conditions represent information that is of interest in a server. This information unlike events has a state associated with it and is not just a transitory notification
The client can obtain a current list of the system state with the use of the refresh method.

---

Alarms

Description
Support the Alarm information model and the notification mechanisms about the Alarm state. It also includes the management of transitions between various states by an alarm, such as shelving, acknowledgement, confirmation and the addition of comments.
The Alarm model builds on the condition model.

Usage Considerations
Indicate areas of the process that require immediate attention. Examples are:

• safety limits of equipment
• event detection, and
• abnormal situations.

In addition to operators, other client applications may collect and record alarm information for later audit or correlation with other historical data.

---

Instances

Description
By default the notification of events generated by transition between states are the only way to detect alarm & condition situations. When instances are supported, a client can browse the address space and discover the items that the server considers of interest, such as alarms.

Usage Considerations

• In some systems clients may want to access some aspects of alarm or condition information in manner other than via the event notifications. For example a client may need to know the possible error state an object could encounter. In these systems the server would have to expose Alarm and Condition instances, to allow the client to browse the Alarm and Conditions.
• Allows using Clients that are able to access data but not events.
• Allows enabling and disabling of Alarms

---

Exclusive Alarms

Description
The sub-states in the alarm model can function in two different modes: exclusive or non-exclusive. Exclusive means that only one sub-state can be active at a time. For example, if a temperature exceeds the HighHigh limit the associated exclusive LevelAlarm will be in the HighHigh sub-state and not in the High sub-state anymore.

Usage Considerations
All Alarm system include at least one of the alarm models (exclusive or non-exclusive).

---

NonExclusive Alarms

Description
The sub-states in the alarm model can function in two different modes: exclusive or non-exclusive. Non-exclusive means that more than one sub-state can be active at a time. For example, if a temperature exceeds the HighHigh limit the associated non-exclusive LevelAlarm will be in both the High and the HighHigh sub-state.

Usage Considerations
All Alarm system include at least one of the alarm models (exclusive or non-exclusive).

---

Previous States

Description
An extension of the Alarm and Condition model where previous states will be retained until they are acknowledged and/or confirmed.

Usage Considerations

• Domains, where all transition in an alarm model must be individually responded to by one or more operators.
• Safety critical systems that require that all Alarms be acknowledged even if it the original problem goes away and the Alarm returns to the inactive state.

---

Dialogs

Description
A specialized Condition model where a Server can interact with a User. The information flow starts with the Server sending a message (a dialog prompt) and a number of possible responses. The User selects one of these responses which the Client then sends to the Server.

Usage Considerations
Dialogs are typically used in states that require intervention by a Client. For example, a Server monitoring a paper machine indicates that a roll of paper has been wound and is ready for inspection. The Server would activate a Dialog Condition indicating to the user that an inspection is required. Once the inspection has taken place the user responds by informing the Server of an accepted or unaccepted inspection allowing the process to continue.

---

OPC UA Base Information Models: Historical Data Access

Introduction

Historical Data Access addresses the handling of historical time series data. The AddressSpace of HDA Servers contains Historical Nodes representing the history of Variables and Properties. HDA Clients deal with historical data by accessing these Nodes with the HistoryRead and HistoryUpdate Services. There are several types of Historian servers. Some key types supported by OPC UA are:

• Simple trend data servers, providing little other than simple raw data storage. (Data would typically be the types of data available from a Data Access server.
• Complex data compression and analysis servers, providing data compression as well as raw data storage. They are capable of providing summary data or data analysis functions, such as average values, minimums and maximums etc. They can support data updates and history of the updates. They can support storage of annotations along with the actual historical data storage.

Note – Historical Access is specified in OPC UA Part 11, Aggregates are specified in OPC UA Part 13.

Historical Data Access Capabilities

Base Access

Description
The AddressSpace includes Variables that represent historized Variable values. Read access is provided via ReadHistory.

Usage Considerations
Simple trending packages that just desire values over a given time frame or they may produce complex reports that require data in multiple formats.

---

Aggregation

Description
Aggregates are used to derive values from raw data over a defined time range. There are several defined aggregates as well as the ability for vendors to provide custom aggregates.

Usage Considerations

• Interpolated data is required.
• Raw historical data needs to be normalized before it can be used.
• Summarized trending and reporting.

---

Insert-Update

Description
Ability to modify existing historized Variable values or add historized Variable values that are not in time series order.

Usage Considerations

• Storage of data received late.
• Correction of incorrect value.

---

Delete

Description
Ability to permanently remove historized Variable values.

Usage Considerations

• Removal of out of service data.
• Removal of redundant data.

---

Annotations

Description
Annotations are additional meta data (notes) that can be inserted into an archive at a specific time.

Usage Considerations
Record, alongside the data, abnormal conditions or readings such as when maintenance or recalibration was done.

---

OPC UA Base Information Models: Historical Event Access

Introduction

Historical Event Access addresses the handling of historical time series events. The AddressSpace of HEA Servers contains Historical Nodes representing the history of Event Sources (Objects or Views). HEA Clients deal with historical events by accessing these Nodes with the HistoryRead and HistoryUpdate Services.
Examples of historical events are:

• Notifications
• System alarms
• Operator action events
• System triggers (such as new orders to be processed)

Note – Historical Access is specified in OPC UA Part 11.

Historical Event Access Capabilities

Base Access

Description
This capability indicates the base support of historical time series events including reading.

Usage Considerations

• Retrieval of SOE data.
• Root cause analysis.

---

Insert-Update

Description
Modify existing historized Events or add historized Events that are not in time series order.

Usage Considerations

• Storage of Events received late.
• Inserting missing Events.
• Correction of incorrect Events.

---

Delete

Description
Ability to permanently remove historized Events.

Usage Considerations

• Removal of out of service data.
• Removal of redundant data.

---

OPC UA Base Information Models: Programs

Introduction

OPC UA Programs represent long-running, often complex and stateful functions in a server or underlying system. When comparing Methods and Programs: a Method, for example, may be used to perform a calculation or reset a counter. A Program example would be to run and control a batch process, execute a machine tool part program, or manage a domain download. Programs can represent any level of functionality within a system or process in which client control or intervention is required and progress monitoring is desired. The execution time of a Program is not bound to the lifetime of a session.
Note – the Programs Information Model is specified in OPC UA Part 10.

Program Capabilities

Program Execution Model

Description
Understand and support the Programs Information Model. This includes all Methods to invoke or control Program execution and the handling of transition events.

Usage Considerations
Consistent monitoring and control of long-running activities.

---

OPC UA Base Information Models: Certificate Management

Introduction

Certificate Management deals with management and distribution of certificates and trust lists for OPC UA applications. In the context of capabilities we differentiate two roles:

• CertificateManager - an OPC UA application that provides the certificate management functions - and
• CertificateReceiver - an OPC UA application that receives its certificates and trust lists from the CertificateManager.

A GDS typically supports certificate management functions.
There are two primary models for Certificate management: pull and push management. In pull management, the application acts as a Client and uses the CertificateManager Methods to request and update Certificates and Trust Lists. In push management the application acts as a Server and exposes Methods which the CertificateManager can call to update the Certificates and Trust Lists as required.
Note – the Certificate Management Information Model is specified in OPC UA Part 12

Certificate Management Capabilities

Certificate Manager

Description
An application that manages certificates and trust lists for OPC UA Applications.

Usage Considerations

• Provides centralized management and automated renewal or update of certificates and trust lists. Supports 1st time set up
• Renews expired or compromised certificates
• Updates Trust Lists
• Supports revocation

---

Certificate Receiver

Description
This capability identifies the support of Push or Pull Model in an OPC UA Client or an OPC UA Server.

Usage Considerations
The OPC UA Application is able to interact with a global certificate manager to renew or update certificates and trust lists.

---

OPC UA Base Information Models: Redundancy

Introduction

OPC UA enables Servers, Clients and networks to be redundant. OPC UA provides the data structures and Services by which Redundancy may be achieved in a standardized manner.
Generally speaking, we can apply redundancy to: servers/clients, communication paths and signals. Although the specification limits redundancy support to client/server redundancy, product vendors can incorporate other kinds of redundancy into the framework proposed by the specification. For example, a server can establish wireless connection as the means of recovery from cable connection failure or a server can use many data sources bound to a variable to provide continuous updating of the variable value even if one of the sensors has been damaged.
Note – Redundancy is defined in OPC UA Part 4, the Information Model is specified in OPC UA Part 5.

Redundancy Capabilities

Server Transparent Failover

Description
Server failover is transparent to the Client: the Client does not care or even know that failover has occurred.

Usage Considerations

• No Client code required to keep connection operational.
• Clients able to determine
  • which Servers are in the redundant set
  • the service level of each server
  • which Server is currently responsible for the client session
  • Client-Server connection information is synchronized across servers

---

Server Non-Transparent Failover

Description
Client is aware that Server failover has occurred. When a Server fails, the number of actions required by Client depends on the failover mode supported by the Server.
There are four failover modes: Cold, Warm, Hot and HotAndMirrored. Failover for this type of redundancy requires the Client to monitor Server status and to switch to a backup Server if it detects a failure. The failover method tells the Client what it must do when connecting to a Server and when a failure occurs. Cold redundancy requires a Client to reconnect to a backup Server after the initial Server has failed. Warm redundancy allows a Client to connect to multiple Servers, but only one Server will be providing values. In hot redundancy multiple Servers are able to provide data and a Client can connect to multiple Servers for the data.

Usage Considerations
Client must use failover mode to determine required actions to take when Server fails.

---

Backup Client

Description
Enables backup clients to monitor the active client’s session with the server. Backup clients are able to instruct the server to transfer subscriptions if the active client has failed.

Usage Considerations

• Client failover requires server capabilities.
• Possible to achieve no data loss upon recovery from client failover

---

Multiple Network Paths

Description
Enables access to the same Server via different network paths.

Usage Considerations

• If transparent, then handled by the network infrastructure
• If non-transparent, then a Server exposes different endpoints for each path.

---

Standard Models: Overview

New Information Models can be created based on the OPC UA Data Model and eventually derived from OPC UA Base Information Models. Standards such as ISA 88 (also IEC 61512, batch processing), ISA 95 (also IEC 62264, MES layer) or the Common Information Model (CIM) with IEC 61970 for energy management and IEC 61968 for energy distribution define the semantics of the data in domains addressed by them. Initially this takes place independent of the data transfer specification. OPC UA – also published as IEC 62541 – enables exchange of information models of any complexity – both instances and types (metadata). It thus complements the standards referred to above and enables interoperability at the semantic level.

Standard Models: Device Integration (DI)

Introduction

OPC UA for Devices (short-name DI) provides a generic way to expose the structure of a Device and its components. Device parameters can be grouped according to their functional purpose (e.g. Configuration, Maintenance, and Diagnostics). It enables systems to configure, troubleshoot, and operate a device without any prior knowledge of the device. OPC UA for Devices is the base for more specialized models, e.g. for Analyzer Devices (ADI), Field Device Integration (FDI), or for PLCs (PLCopen).

DI Capabilities

Device Model

Description
Understand and support the OPC UA for Devices base Information Model. This includes all the Device Type and the ability of functional grouping.

Usage Considerations
Consistent look at devices irrespective of the underlying device protocols.

---

Communication Model

Description
The Communication Model adds Network and Connection information elements.

Usage Considerations
Consistent communication topology.

---

Host Model

Description
The Device Integration Host Model finally adds additional elements and rules required for host systems to manage integration for a complete system.

Usage Considerations
Reflecting the topology of the system with the devices as well as the connecting communication networks.
Prepare modifications or reconfiguration in offline mode.

---

Standard Models: Analyzer Devices (ADI)

Introduction

The OPC UA companion specification for Analyser Devices (ADI) defines a data model for process and laboratory analysers. It allows integrating analysers into the supervisory control and tracing systems seamlessly. This Information Model is also referred to as the ADI Information Model. The model is intended to provide a unified view of analyzers irrespective of the underlying device. Reduction of the maintenance cost is a value of this approach, because any replacement of the analysers has very limited impact on the upper systems – it is a “plug and play” solution. Analyzers can be further refined into various groups, but the specification is generic and defines the ADI Model that can be applied to all the groups of analyzers. ADI is based on OPC UA for Devices (DI).

ADI Capabilities

Analyzer Device Model

Description
Understand and support the OPC UA for AnalyzerDevices base Information Model.
This includes Methods for configuration, the states and transitions

Usage Considerations
Determine the process state/behaviour by measuring selected physical values that are characteristic for it. The measurement results are process data that can be used to control, trace and optimize the production process.

---

Standard Models: Field Device Integration (FDI)

Introduction

FDI is a standard device integration technology. One of its core elements is the Electronic Device Description Language (EDDL) which is used to completely specify a (field) device with its parameters and behaviour. The FDI Information Model (IEC62769-5) specifies how each individual device together with the communication topology is exposed using OPC UA. The Information Model is driven largely by the Device Definitions and is based on OPC UA for Devices (DI). A secondary OPC UA model has been specified for the so-called FDI Communication Servers (IEC62769-7). Each FDI Communication Server represents a specific Fieldbus Protocol. The OPC UA Interface makes the protocol-specifics transparent to the FDI Server.

FDI Capabilities

FDI Host

Description
Understand and support the OPC UA for FDI Information Model (IEC62769-5).

Usage Considerations
Support third-party Tools that contain an FDI Client and communicate with the automation system’s FDI Server. Third-party tools may also be applications running on handheld devices.
Allow interoperation with OPC UA Clients that are not FDI-aware. Examples are HMI Clients, MES or ERP Clients.

---

FDI Communication Server

Description
Understand and support the OPC UA for FDI Information Model for Communication Server (IEC62769-7).

Usage Considerations
Integrate devices with protocols that are not natively known to the FDI Host.

---

Standard Models: PLC open

Introduction

IEC 61131 is a standard for programmable controllers. IEC 61131-3 focusses on programming languages for industrial automation. With its worldwide support, it is independent of any single company. The PLCopen OPC UA Information Model maps the IEC 61131-3 software model to an OPC UA information model. This mapping assures that an IEC 61131-3 control program on different control platforms from different control suppliers is represented the same way. A visualization program used for different controllers running the same control program must only be configured once. The PLCopen OPC UA Information Model is based on OPC UA for Devices (DI). PLCopen also defines Function Blocks to use OPC-UA client functionality in an IEC61131-3 controller. With these Function Blocks a controller can exchange complex data structures horizontally with other controllers independently from fieldbus system or vertically with OPC-UA interfaces in an MES/ERP system in order to collect data or write new production orders to the cloud. It allows a production line to be independently active in combination with integrated OPC UA Security features. OPC-UA client functionality in a controller does not provide hard deterministic real time and so it’s not a deterministic fieldbus – but UA provides fast, secured communication providing modelling mechanism for information models.

PLCopen Capabilities

PLC Information Model

Description
The controller supports the PLCopen OPC UA information model.

Usage Considerations
OPC UA servers which represent their underlying manufacturer specific controllers in a similar, IEC 61131-3 based manner provide a substantial advantage for client applications as e.g. visualizations or MES.

---

Function Blocks

Description
The controller supports the PLCopen OPC UA function blocks.

Usage Considerations
Fieldbus-independent communication between controllers or controllers and field devices that support OPC UA.
Vertical communication from controller with applications in MES or ERP level.

---

Standard Models: MTConnect - Process information from numerically controlled machine tools

Introduction

This companion standard provides the model for numerically controlled machine tools.
<TBD>

MTconnect Capabilities

Number 1

Description
<TBD>

Usage Considerations
<TBD>

Number 2

Description
<TBD>

Usage Considerations
<TBD>

Standard Models: Enterprise Control System Integration (ISA-S95)

Introduction

This companion standard provides the model ... <TBD>.

ISA-95 Capabilities

Number 1

Description
<TBD>

Usage Considerations
<TBD>

Number 2

Description
<TBD>

Usage Considerations
<TBD>