Sequence of Capabilities

From UaCapabilities
This is the approved revision of this page, as well as being the most recent.
Jump to: navigation, search

Contents


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.

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

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:

  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

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

Global Discovery Client Facet.

-


Transport Mappings

Introduction

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

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.

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

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

Client Server

Core Server Facet

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 Subscriber

Eventing Profile

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

Subscribe to individual areas

Multiple notification areas

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

Call arbitrary Methods

Expose Methods and support invocation

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
  • 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

Conformance Testing

Client Server

Create and manage durable subscriptions

Durable storage of data and events while Client is disconnected

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
  • 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

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.

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.

SecurityLayers.jpg

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

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).
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

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

Client Server

Use of X.509v3 certificates to identify the Client user

Use of X.509v3 certificates to authenticate a user

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

Client Server

Use of Kerberos tickets to identify the Client user

Use of Kerberos tickets to authenticate a user

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>

  • 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.


Robustness

Introduction

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

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

Core Client Facet

Core Server Facet

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
  • 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

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

Client Server

Subscribe to and process audit events issued by a Server

Support of Audit Events

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
  • 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


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.

UA fw BaseModels.JPG


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

URN:          https://opcfoundation.org/wiki/index.php/Data_Access#Data_Access

Discovery ID: DA


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

Conformance Testing

Client Server

Array Data

URN:          https://opcfoundation.org/wiki/index.php/Data_Access#Array_Data

Discovery ID: DA


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.


Conformance Testing

Client Server

Client is able to process the array data defined in the OPC UA Data Access specification.

Provide access to Variables with array data as defined in the OPC UA Data Access specification.


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

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Conditions

Discovery ID: AC


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.


Conformance Testing

Client Server

Use/understand the Condition model including the Refresh Method

Support Conditions including the Refresh Method

Alarms

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Alarms

Discovery ID: AC


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.


Conformance Testing

Client Server

Ability to handle alarms

Conditions with active/inactive state

Instances

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Instances

Discovery ID: AC


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

Conformance Testing

Client Server

Exclusive Alarms

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Exclusive_Alarms

Discovery ID: AC


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).


Conformance Testing

Client Server

Ability to use the exclusive alarm model

Exclusive: Only one sub-state active at a time

NonExclusive Alarms

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#NonExclusive_Alarms

Discovery ID: AC


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).


Conformance Testing

Client Server

Ability to use non-exclusive Alarms

Support of non-exclusive Alarms

Previous States

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Previous_States

Discovery ID: AC


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.

Conformance Testing

Client Server

Ability to list and acknowledge states that are older than the current state

Server maintains previous states that have not been acknowledged

Dialogs

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Dialogs

Discovery ID: AC


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.


Conformance Testing

Client Server

Client dialog support

Server uses dialogs


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

URN:          https://opcfoundation.org/wiki/index.php/Historical_Data_Access#Base_Access

Discovery ID: HD


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.


Conformance Testing

Client Server

Aggregation

URN:          https://opcfoundation.org/wiki/index.php/Historical_Data_Access#Aggregation

Discovery ID: HD


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.

Conformance Testing

Client Server

Read from history by specifying one of the supported aggregates

Support aggregate processing

Insert-Update

URN:          https://opcfoundation.org/wiki/index.php/Historical_Data_Access#Insert-Update

Discovery ID: HD


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.

Conformance Testing

Client Server

Support the following profiles:

also recommended:

Support the following profiles:

Delete

URN:          https://opcfoundation.org/wiki/index.php/Historical_Data_Access#Delete

Discovery ID: HD


Description
Ability to permanently remove historized Variable values.

Usage Considerations

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

Conformance Testing

Client Server

Use HistoryUpdate Service to delete historical data values

Supports deleting historical values

Annotations

URN:          https://opcfoundation.org/wiki/index.php/Historical_Data_Access#Annotations

Discovery ID: HD


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.


Conformance Testing

Client Server

Clients is able to retrieve and insert annotations

Support storage and retrieval of annotations


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

URN:          https://opcfoundation.org/wiki/index.php/Historical_Event_Access#Base_Access

Discovery ID: HE


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

Usage Considerations

  • Retrieval of SOE data.
  • Root cause analysis.

Conformance Testing

Client Server

Read historized events

Provide read access to historized events

Insert-Update

URN:          https://opcfoundation.org/wiki/index.php/Historical_Event_Access#Insert-Update

Discovery ID: HE


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.

Conformance Testing

Client Server

Client is able to modify an archive with historized events:

Server allows modifying its archive with historized events:

Delete

URN:          https://opcfoundation.org/wiki/index.php/Historical_Event_Access#Delete

Discovery ID: HE


Description
Ability to permanently remove historized Events.

Usage Considerations

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

Conformance Testing

Client Server

Client supports deletion of historized events

Server allows deletion of historized events


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

URN:          https://opcfoundation.org/wiki/index.php/Programs#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.


Conformance Testing

Client Server
  • Manage Programs using the ProgramType Methods
  • Monitor the execution state by subscribing for program transition events
  • Evaluate the result data after execution ended.

Server Profile for Programs


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

URN:          https://opcfoundation.org/wiki/index.php/Certificate_Management#Certificate_Manager

Discovery ID: GDS


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

Conformance Testing

Client Server

--

Certificate Receiver

URN:          https://opcfoundation.org/wiki/index.php/Certificate_Management#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.


Conformance Testing

Client Server

CertificateReceiver role for Clients

CertificateReceiver role for Servers


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

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#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

Conformance Testing

Client Server

Nothing needed in the Client.

Transparent failover

Server Non-Transparent Failover

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#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.


Conformance Testing

Client Server

Switch to a backup Server if failure is detected

Non-transparent redundancy

Backup Client

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#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

Conformance Testing

Client Server

Client redundancy

Server support for redundant Clients

Multiple Network Paths

URN:          https://opcfoundation.org/wiki/index.php/Redundancy#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.

Conformance Testing

Client Server

TBD

TBD


Industry Standard Models


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.

UA fw StandardModels.JPG


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

URN:          https://opcfoundation.org/wiki/index.php/Device_Integration_Model_(DI)#Device_Model

Discovery ID: DI


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.


Conformance Testing

Client Server
  • BaseDevice_Client_Facet
  • DeviceIdentification_Client_Facet
  • BaseDevice_Server_Facet
  • DeviceIdentification_Server

Communication Model

URN:          https://opcfoundation.org/wiki/index.php/Device_Integration_Model_(DI)#Communication_Model

Discovery ID: DI


Description
The Communication Model adds Network and Connection information elements.

Usage Considerations
Consistent communication topology.


Conformance Testing

Client Server
  • DeviceCommunication_Client_Facet
  • DeviceCommunication_Server_Facet

Host Model

URN:          https://opcfoundation.org/wiki/index.php/Device_Integration_Model_(DI)#Host_Model

Discovery ID: DI


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.


Conformance Testing

Client Server
  • DeviceIntegrationHost_Client_Facet
  • Locking_Client_Facet
  • DeviceIntegrationHost_Server_Facet
  • Locking_Server_Facet


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

URN:          https://opcfoundation.org/wiki/index.php/Analyzer_Device_Integration_(ADI)#Analyzer_Device_Model

Discovery ID: ADI


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.


Conformance Testing

Client Server

Analyser Client Profile

  • Level1 Analyser Server Profile

optional:

  • Level2 Analyser Server Profile (advanced configuration)


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

URN:          https://opcfoundation.org/wiki/index.php/Field_Device_Integration_(FDI)#FDI_Host

Discovery ID: FDI


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.


Conformance Testing

Client Server
  • Interpret and execute FDI user interface descriptions (UID)
  • Load, host, and run FDI user interface Plug-Ins (UIP)
  • Expose the information of an FDI package following the FDI information model
  • Allow access to elements of the device via the FDI information model

FDI Communication Server

URN:          https://opcfoundation.org/wiki/index.php/Field_Device_Integration_(FDI)#FDI_Communication_Server

Discovery ID: FDIC


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.


Conformance Testing

Client Server

Client (FDI Host / Server) is able to use FDI Communication Server

Support the FDI Communication Server information model to represent a specific device protocol


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

URN:          https://opcfoundation.org/wiki/index.php/PLCopen_Model_(IEC61131-3)#PLC_Information_Model

Discovery ID: PLC


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.


Conformance Testing

Client Server

TBD

TBD

Function Blocks

URN:          https://opcfoundation.org/wiki/index.php/PLCopen_Model_(IEC61131-3)#Function_Blocks

Discovery ID: PLC


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.


Conformance Testing

Client Server

TBD

TBD


Auto-ID

Introduction

This companion standard provides the model for a common integration standard for Auto-ID devices, in particular Optical readers, OCR readers, RFID readers, and Real-Time Locating (RTL) systems.

Auto-ID Capabilities

Optical Reader

URN:          https://opcfoundation.org/wiki/index.php/Auto-ID_Automatic_identification_systems#Optical_Reader

Description
<TBD>

Usage Considerations
<TBD>

RFID Reader

URN:          https://opcfoundation.org/wiki/index.phpAuto-ID_Automatic_identification_systems#RFID_Reader

Description
<TBD>

Usage Considerations
<TBD>

OCR Reader

URN:          https://opcfoundation.org/wiki/index.php/Auto-ID_Automatic_identification_systems#OCR_Reader

Description
<TBD>

Usage Considerations
<TBD>


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

URN:          https://opcfoundation.org/wiki/index.php/MTConnect_-_Process_information_from_numerically_controlled_machine_tools#Number_1

Discovery ID: MTC


Description
<TBD>

Usage Considerations
<TBD>

Number 2

URN:          https://opcfoundation.org/wiki/index.phpMTConnect_-_Process_information_from_numerically_controlled_machine_tools#Number_2

Discovery ID: MTC


Description
<TBD>

Usage Considerations
<TBD>


Enterprise Control System Integration (ISA-S95)

Introduction

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

ISA-95 Capabilities

Number 1

URN:          https://opcfoundation.org/wiki/index.php/Enterprise-Controlsystem_Integration_Model_(ISA-95)#Number_1

Description
<TBD>

Usage Considerations
<TBD>

Number 2

URN:          https://opcfoundation.org/wiki/index.phpEnterprise-Controlsystem_Integration_Model_(ISA-95)#Number_2

Description
<TBD>

Usage Considerations
<TBD>


MDIS - MCS-DCS Interface Standardization

Introduction

MDIS.JPGThe MDIS (Master Control Station (MCS) - Distributed Control System (DCS) Interface Standardisation) is an international joint oil and gas industry network group.

MDIS was formed with a vision to optimize the MCS and DCS communications of platform topside systems, by defining and establishing a standard for the interface, in order to simplify implementation of data communication links, whilst increasing the data quality. By implementing the MDIS standard the operator should benefit from simplified implementation and testing of the MCS - DCS interface, reduced risk of interface failures and reliable control and monitoring via the DCS. It includes oil and gas operators, DCS vendors and Subsea vendors.
Platform


MDIS selected OPC UA based on several requirements:

  • Information modeling capabilities
  • Multi-platform support
  • Redundancy and Robust Communications
  • Independent Organization Support
  • Independent Testing and Certification

The MDIS companion standard includes information models to represent the common pieces of subsea equipment, such as valves, choke valves, instruments and discrete IO to name a few. The companion specification includes support for two different architectures. It also defines interface an information model specific testing.

MDIS Capabilities

Number 1

URN:          https://opcfoundation.org/wiki/index.php/MDIS_-_MCS-DCS_Interface_Standardization#Number_1

Discovery ID: MDIS


Description
<TBD>

Usage Considerations
<TBD>

Number 2

URN:          https://opcfoundation.org/wiki/index.phpMDIS_-_MCS-DCS_Interface_Standardization#Number_2

Discovery ID: MDIS


Description
<TBD>

Usage Considerations
<TBD>


CNC Systems Information Model

Introduction

Computerized Numerical Control (CNC) systems are used to control machine tools and machining centers. The CNC system is mainly responsible for generating a relative movement between a tool (e.g cutting tool) and a workpiece. Therefore, the CNC system implements functionality to provide setpoints to a machine tool’s drives that realize the generated movement physically.

CNC systems are in most cases executed in combination with Programmable Logic Controllers (PLC). Whereas the CNC is responsible for the tool path generation, the PLC implements auxiliary functionality (mostly logical operations like activating lubrication at a certain time) and controls the peripheral devices.

Main objective of the OPC UA companion standard for CNC systems is to have an Information Model that results in a clearly defined and structured CNC data interface. That means that both data items and its composition are specified. However, manufacturer- and use case-specific extensions are possible as well.

The focus is on data that is situated within the CNC kernel but not within the PLC of a CNC system. Hence, this Information Model addresses applications like HMIs, PDA/MDA systems, diagnosis and monitoring applications, but not necessarily MES or ERP systems as the two latter ones mostly need summarized data.

PDF Flyer: OPC UA for CNC Systems

CNC Systems Capabilities

CNC Basic

URN:          https://opcfoundation.org/wiki/index.php/CNC_Systems_Information_Model#CNC_Basic

Discovery ID: CNC


Description
Understand and support the OPC UA for CNC Information Model. Support the interface structure and the access of all data provided by the CNC system, namely parameters, state data, process and command data, and alarm notifications that are defined by this companion standard.

Usage Considerations

  • Setup: The CNC data interface provides data that can be used for setting up a production system controlled by a CNC. This refers first of all to production commissioning data (e.g. job description, tool data etc.) but implies to a certain extent as well CNC configuration data (e.g. axis parameters, cycle time etc.), as needed for engineering.
  • Operation: The CNC data interface may be used for operating a production system controlled by a CNC and therefore serves as a connection point for user interfaces.
  • Observation: The CNC data interface may be used for observing a production system controlled by a CNC and therefore serves as a connection point for monitoring and diagnosis applications and for user interfaces.

Conformance Testing

Client Server
  • Base CNC Data Interface Server Facet
  • Model Change Server Facet

CNC Data Interface Client Facet

CNC Files

URN:          https://opcfoundation.org/wiki/index.php/CNC_Systems_Information_Model#CNC_Files

Discovery ID: CNC


Description
Support the file access mechanisms. Files are transferred from the Maschine Interface to the CNC kernel or the PLC, maybe as well to the drives and peripheral devices holding configuration data (e.g. tool parameters) or process information in form of part programs or similar.

Usage Considerations
CNC systems handle several types of files, e.g. configuration and part program files.


Conformance Testing

Client Server

File Access Server Facet

CNC Data Interface Client Facet (Client File Access Conformance Unit)