1 Scope

This document provides an Information Model enabling data interoperability between systems in the field, including Controller-to-Controller, Controller-to-Device, Device-to-Device and Controller/Device-to-Compute. It includes base Information Models for devices and controllers, ensuring smooth, high-speed information flow for critical factory and process systems. These systems can include safety systems. It is expected that the Information Models specified in this document will be extended to include other specific device or system types, such as motion control. For a complete overview, see OPC 10000-80.

This initial scope includes Controller-to-Controller using PubSub for data exchange. A future release will include Controller-to-Device and Device-to-Device. A future release will also include Client Server for data exchange.

2 Normative references

The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments and errata) applies.

OPC 10000-1 – OPC Unified Architecture - Part 1: Overview and Concepts

https://opcfoundation.org/documents/10000-1/

OPC 10000-2 – OPC Unified Architecture - Part 2: Security Model

https://opcfoundation.org/documents/10000-2/

OPC 10000-3 – OPC Unified Architecture - Part 3: Address Space Model

https://opcfoundation.org/documents/10000-3/

OPC 10000-4 – OPC Unified Architecture - Part 4: Services

https://opcfoundation.org/documents/10000-4/

OPC 10000-5 – OPC Unified Architecture - Part 5: Information Model

https://opcfoundation.org/documents/10000-5/

OPC 10000-6 – OPC Unified Architecture - Part 6: Mappings

https://opcfoundation.org/documents/10000-6/

OPC 10000-7 – OPC Unified Architecture - Part 7: Profiles

https://opcfoundation.org/documents/10000-7/

OPC 10000-8 – OPC Unified Architecture - Part 8: Data Access

https://opcfoundation.org/documents/10000-8/

OPC 10000-12 – OPC Unified Architecture - Part 12: Discovery and Global Services

https://opcfoundation.org/documents/10000-12/

OPC 10000-14 – OPC Unified Architecture - Part 14: PubSub

https://opcfoundation.org/documents/10000-14/

OPC 10000-16 – OPC Unified Architecture - Part 16: State Machines

https://opcfoundation.org/documents/10000-16/ OPC 10000-16

OPC 10000-17 – OPC Unified Architecture - Part 17: Alias Names

https://opcfoundation.org/documents/10000-17/

OPC 10000-18 – OPC Unified Architecture - Part 18: Role-Based Security

https://opcfoundation.org/documents/10000-18/

OPC 10000-20 – OPC Unified Architecture - Part 20: File Transfer

https://opcfoundation.org/documents/10000-19/

OPC 10000-23 – OPC Unified Architecture - Part 23: Common ReferenceTypes

https://opcfoundation.org/documents/10000-23/

OPC 10000-26 – OPC Unified Architecture - Part 26: LogObject Model

https://opcfoundation.org/documents/10000-26/

OPC 10000-80 – OPC Unified Architecture - Part 80: OPC UA FX Overview

https://opcfoundation.org/documents/10000-80/

OPC 10000-83 – OPC Unified Architecture - Part 83: OPC UA FX Offline Engineering

https://opcfoundation.org/documents/10000-83/

OPC 10000-84 – OPC Unified Architecture - Part 84: OPC UA FX Profiles

https://opcfoundation.org/documents/10000-84/

OPC 10000-100 – OPC Unified Architecture - Part 100: Devices

https://opcfoundation.org/documents/10000-100/

OPC 10000-110 – OPC Unified Architecture - Part 110: Asset Management Basics

https://opcfoundation.org/documents/10000-110/

3 Terms, definitions, abbreviated terms, and conventions

3.1 Terms and definitions

For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-2, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7, OPC 10000-8, OPC 10000-14, OPC 10000-17, OPC 10000-80, OPC 10000-100, OPC 10000-110 as well as the following apply.

All used terms are italicised in the specification as described in OPC 10000-1.

3.1.1 AggregatingServer

Server collecting information from underlying Servers and sourcing to higher-level Servers or applications

3.2 Abbreviated terms

• QoS Quality of Service

• LLDP Link Layer Discovery Protocol

• SKS Security Key Service

3.3 Conventions used in this document

3.3.1 Usage of Other column in type definitions

In all type definitions, the “Other” column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are shown in Table 1.

If multiple characteristics are defined, they are separated by commas. Throughout this document, the short name is used.

3.3.2 Usage of Asset and FunctionalEntity

Clause 6.3 defines an Asset as an Object either derived from FxAssetType or an Object of any type that implements the required Interfaces. Asset (plural Assets) is used throughout this document to designate an instance of such an Object, regardless of whether derived from the type or implementing the Interfaces.

Clause 6.4 defines a FunctionalEntity as an Object either derived from FunctionalEntityType or an Object of any type that implements the required Interface. FunctionalEntity (plural FunctionalEntities) is used throughout this document to designate an instance of such an Object, regardless of whether derived from the type or implementing the Interfaces.

3.3.3 Usage of Instance of a type

In this document, the name of a type without the addition of “Type” is used to indicate an instance of the type. For example, the following phrase, “an instance of ConnectionConfigurationSetType,” can be replaced with “a ConnectionConfigurationSet”. The phrase “instances of ConnectionEndpointType” can be replaced with “ConnectionEndpoints”.

3.3.4 ConformanceUnits and Node definitions

Each Node defined in this document references at least one ConformanceUnit. (defined in OPC 10000-84). If a Server supports the ConformanceUnit, it shall expose the Nodes related to the ConformanceUnit in its AddressSpace. If two Nodes are exposed, all References between the Nodes defined in this document shall be exposed as well.

The relations between Nodes and ConformanceUnits are defined at the end of the tables defining Nodes, one row per ConformanceUnit.

4 OPC UA FX Information Model Overview

4.1 Overview

This document provides a detailed description of Connection functionality and the related Information Model for OPC UA FX. For an overview, please see OPC 10000-80.

4.2 AutomationComponent model

This model is provided to model AutomationComponents in OPC UA FX. In OPC UA FX, an AutomationComponent is an entity that performs one or more automation functions and provides connection capabilities defined in this document. The AutomationComponentType is composed of two major sub-models: the asset model and the functional model. It also provides information related to OfflineEngineering (see OPC 10000-83) and general metadata such as communication capabilities and health status. Figure 1 illustrates this model. For a formal definition of the AutomationComponentType, see 6.2.

Asset information is typically used to describe physical items, but it can also include items that are not physical, such as firmware or licenses. FunctionalEntities encapsulate logical functionality, which can include function blocks, IO module functionality, drive functionality, sensor functionality, actuator functionality, or more complex logical items. FunctionalEntities can be related to Assets, and the representation of such relationships is included in the model. Both Assets and FunctionalEntities can be nested. The Information Model also includes relationships between FunctionalEntities. For a detailed description of the asset model, see the definition of FxAssetType in 6.3. For a detailed description of the FunctionalEntity model, see the definition of FunctionalEntityType in 6.4. For a description of the available ReferenceTypes in this Information Model, see 11.1.

The Information Model is defined to be used either as a base for modelling an AutomationComponentType or for extending an existing Information Model with OPC UA FX-defined functionality. When used as a base model, it is expected that it will require subtyping to add information specific to a component or model, such as variables, or to provide context, e.g., to describe the temperature value in a device that represents a temperature sensor reading. Examples of extending the existing model and using the base model are provided in Annex B.

The AutomationComponentType also includes information related to the offline configuration. For a detailed description of OfflineEngineering, see OPC 10000-83.

4.3 Asset model

4.3.1 Overview

This Information Model provides a general model for Assets in an OPC UA FX system (illustrated in Figure 2). An Asset is defined as a component with a lifecycle, where the lifecycle includes version information. FxAssetType (see 6.3) provides a base concept of the asset model defined in this document. The OPC UA FX Information Model supports the modelling of hard Assets and soft Assets. A hard Asset represents physical hardware like devices, controllers, modules, hardware components, or other hardware-based products. A soft Asset represents firmware, software, licenses, etc. The asset model can model an actual physical device or a virtual representation of the physical device. The asset model is capable of defining a simple Asset, such as a sensor or a complex Asset, such as a machine with multiple nested and/or related Assets.

The asset model is designed to support the nesting of Assets into higher-level devices. The asset model could be used as a base model for plant-wide asset management systems.

4.3.2 Asset information

The asset model (illustrated in Figure 3) requires that Assets provide a minimum level of information. This includes Asset type identification as well as the unique identification of Asset instances. It also contains vendor information and information from the model defined in OPC UA Devices (see OPC 10000-100). The asset model supports functionality to verify the identity and compatibility of the Assets. For a complete description of the FxAssetType, see 6.3.

4.3.3 Asset model relationships

The asset model provides a means for representing the relationships between Assets. It also supports the concept that there might be multiple types of relationships between various Assets. These types of relationships might be used to provide multiple views of the asset model. For example:

Asset management view

Physical hierarchy view

Maintenance view

Interconnected view (network, electrical, hydraulic)

Vendors or end-users are free to create their own view of the Asset relationships. The asset model makes use of specific ReferenceTypes to represent these relationships. OPC 10000-5 and OPC 10000-23 define some base ReferenceTypes, but this document further extends the available list of ReferenceTypes (see 11.1). Figure 4 illustrates some possible views that an asset model can include. Some Assets could contain other Assets (blue speech bubble), while some are just related to each other (orange lightning bolts). There could be network views showing the network topology (yellow dashed lines), which can be derived from LLDP or other input (see OPC 10000-82). There could be a list of sensors or other devices that require routine maintenance (solid red line). There might be a list of all software Assets that an engineer is responsible for (purple dash-dot lines), and the software Asset might be related to the hardware on which it is executed (green dash-dot-dot lines). All of these Assets might be part of a single plant.

The asset model can be as complex or as simple as a specific installation requires. This basic asset model can be part of a plant-wide asset management system or might be a simple asset model used for identity verification. OPC UA FX expects that this model will be extended and that it can operate with other higher-level asset management systems. The asset model might be dynamic during operation.

OPC UA FX defines a minimum asset model that all AutomationComponents are required to support.

4.4 Functional model

4.4.1 Overview

FunctionalEntities encapsulate logical functionality. The OPC UA FX Information Model defines an Object Model for FunctionalEntities. Figure 5 illustrates the Object Model, which includes general information about the FunctionalEntityType, its input variables, output variables, and diagnostic information. FunctionalEntities can be nested or have relationships to other FunctionalEntities. The Object Model also includes a representation of Connections (communication) between FunctionalEntities.

FunctionalEntities are designed to describe the functionality of any complexity, ranging from the acquisition of a single measured value to controlling an entire machine or production line. FunctionalEntities can be preconfigured and fixed, e.g., in a device such as a drive, or they can be dynamically created during engineering or at run time, e.g., in a programmable device such as a controller.

4.4.2 FunctionalEntityType

The FunctionalEntityType defines the base information and functionality that all FunctionalEntities provide. The FunctionalEntityType provides data and methods to control and monitor its functionality. This includes input, output, and configuration data. A FunctionalEntity also provides identification information and methods to perform functionality-related verifications. An important part of the FunctionalEntity model is the interaction between FunctionalEntities, which is modelled as a Connection. The FunctionalEntity part of the model includes information such as status, diagnostics, and other information to help represent this Connection:

• Identification properties: Identity – When establishing a Connection between FunctionalEntities, it could be essential to confirm identity, e.g. to check that the other FunctionalEntity is the one that is expected. For an overview of verification, see 5.2.

• Input data – describes the values that are produced by another FunctionalEntity and consumed by this FunctionalEntity.

• Output data – describes the values that are produced by the processing of this FunctionalEntity and are available for other FunctionalEntities to consume.

• Configuration data – describes any value that is used to set up and configure functionality.

• Diagnostic data – describes information related to the status of its functionality, including the status of any Connections. This could include the generation of Events or Alarms related to problems or issues encountered by the FunctionalEntity.

4.4.3 FunctionalEntity type hierarchy

A FunctionalEntity can be of varying degrees of complexity and can represent different granularity and abstraction levels, from primitive functionality to an entire application. Various providers could define FunctionalEntities. For example:

• there are primitive FunctionalEntities that only generate output data, like a temperature sensor or only receive input data, like a relay;

• more complex FunctionalEntities like a motion axis can receive control data, perform a calculation or action, provide status/feedback data, expose methods for operation and have different operating modes, including closed-loop controls;

• or FunctionalEntities on the process application level, representing an entire application, such as a paper machine or a boiler, where the FunctionalEntity has multiple nested SubFunctionalEntities.

This document defines the FunctionalEntityType base type. Various companion standards can provide extensions to this document. Manufacturers or suppliers can provide further extensions to FunctionalEntities. They can group them or structure them into a nested hierarchy. Finally, machine builders or end-users can provide FunctionalEntities for their individual automation solutions (see Figure 6 for examples of possible derivations).

The model is defined using OPC UA Interfaces. An Information Model defined in another standard can add support for FunctionalEntities by including these Interfaces or deriving from the FunctionalEntityType.

4.5 Relationships between FunctionalEntities and Assets

Assets can be related to FunctionalEntities. A single Asset might be related to zero or more FunctionalEntities. A FunctionalEntity might be related to zero or more Assets. The models for both FunctionalEntities and Assets are independent. Specific References only link them (see Figure 7 for an illustration and 11.1 for details on ReferenceTypes).

Figure 7 also illustrates an AutomationComponent, which provides a grouping of related FunctionalEntities and Assets.

4.6 FunctionalEntities and applications

Functionality from different FunctionalEntities (in different AutomationComponents) can be used to construct applications. An application can involve communication between one or more FunctionalEntities. FunctionalEntities can be arranged into hierarchies or any type of organisation. The details required in a FunctionalEntity for an application are application-specific, but the base functional model is required to describe the interaction between the FunctionalEntities so that all interactions can be represented in the same manner.

A FunctionalEntity can interact with other FunctionalEntities by exchanging data. This exchange of data can be for control or monitoring purposes. Information related to these interactions is represented in the FunctionalEntity by Connections (see Figure 8).

The process of establishing a Connection can include identity and compatibility verification, identifying the information to be exchanged, establishing exclusive access (locking) to the information, setting ConfigurationData, configuring the communication, and finally, enabling the communication. An established Connection is represented on a connected FunctionalEntity by the ConnectionEndpoint. For more information, see the definition of the ConnectionEndpointType in 6.6.

The FunctionalEntity can group input data and output data for easier configuration or as the application requires.

A FunctionalEntity exposes ControlGroups to allow the selection between available uses of a FunctionalEntity. The selected use might restrict access to data; it might lock a value from being changed or only to be changed by a specific entity or Role. Multiple ControlGroups might reference overlapping data. ControlGroups might be created dynamically or be pre-configured as part of an application. ControlGroups might be nested. For more information, see the definition of the ControlGroupType in 6.5. ControlGroups use a Controls Reference defined in OPC 10000-23 to indicate who owns the ControlGroup.

Transportation of data between FunctionalEntities can be accomplished using existing OPC UA communication models. The FunctionalEntity includes Connection information that reflects the established communication model, represented by ConnectionEndpoints. For more information, see 6.6.

4.7 ConnectionManager

4.7.1 Overview

A ConnectionManager is an optional entity that interacts with multiple AutomationComponents to establish Connections between FunctionalEntities. The ConnectionManager can execute on any Server supporting the OPC UA FX Information Model. In the OPC UA FX Information Model, the ConnectionManager is represented by the ConnectionManagerType, which defines functionality and interfaces to manage the establishment of Connections between FunctionalEntities.

Several ConnectionManagers within a network could establish Connections independently of each other. For example, a ConnectionManager on a controller can establish Connections from the controller to its associated IO devices. In contrast, another ConnectionManager on a line controller could establish Connections between FunctionalEntities on the controllers. Figure 9 illustrates possible deployments of a ConnectionManager. It also illustrates ConnectionConfigurationSets, which contain the information needed to establish Connections.

For a conceptual overview of how Connections are established by a ConnectionManager and the main ObjectTypes used in this process, see 5.5.

This document defines the core functionality of a ConnectionManager with respect to the process of establishing and closing Connections, reporting errors related to it, and the ConnectionConfigurationSets. This document does not define the implementation of a ConnectionManager. It can be implemented as a standalone application that monitors and manages Connections. It can be integrated into a vendor application, which establishes and closes Connections according to the overall application. The vendor application can also monitor the state of established Connections and trigger a re-establishment of Connections.

NOTE For simplicity in this document, we will describe that a ConnectionManager monitors a Connection, with it being understood that this could be some other application.

4.7.2 Creating / Monitoring / Closing Connections

Connections to be created are part of a ConnectionManager configuration (ConnectionConfigurationSet).

An AutomationComponent and the included FunctionalEntities report the status of Connections that are part of the FunctionalEntity, and Clients can monitor this status. Some ConnectionManagers could provide the following:

know when to create a Connection,

respond to an application that knows when to create a Connection.

respond to external or internal commands.

monitor the Connections they create.

Possible reasons for monitoring Connection status include:

• An application or ConnectionManager monitors ConnectionEndpoints on AutomationComponents to decide whether it needs to (re)establish or close Connections. For example:

• On startup, it checks if the desired Connections already exist. For Connections that do not exist, it could trigger the establishment processing.

• At runtime, it would check if any Connections were cleaned up (see 5.5.4) or disappeared (e.g. restarted application). If so, it could trigger establishment processing on the Connection.

• It might determine, for application-defined reasons, that a Connection needs to be closed, and it could trigger the close Connection processing.

• Vendor-specific diagnostic applications monitor Connections defined in ConnectionConfigurationSets on a ConnectionManager and the ConnectionEndpoints on AutomationComponents to present comprehensive Connection information to the operator or engineers, including identification information, current status and last error information.

ConnectionManagers can expose capabilities that describe the functionality they provide (see 6.7.2).

5 OPC UA FX Information Model concepts

5.1 Overview

OPC UA provides the concepts for standard communication between Servers and Clients as well as Publishers and Subscribers, but additional concepts are required for OPC UA FX. These concepts include Connection establishment and bidirectional communication. The establishment of Connections further requires concepts such as identity and compatibility verification of Asset and FunctionalEntity, establishing control via ControlGroup selection, setting ConfigurationData, and communication configuration. These concepts are mapped to existing OPC UA communication models and are provided by the OPC UA FX Information Model. This clause conceptually describes the functionality provided in the overview of the Objects defined by the OPC UA FX Information Model.

5.2 Identity and compatibility verification

5.2.1 Overview

In an industrial automation system, device identity and compatibility refer to the process and mechanisms used to check that AutomationComponents (e.g., controllers, drives, IO devices) in a system allow operation that is consistent or compatible with what was expected by system engineering.

It is a common practice that various properties of communicating AutomationComponents are verified to check that:

• AutomationComponents present in a system are either consistent with system engineering (i.e., match expectations);

• their communication interfaces and exhibited application behaviour are compatible with system engineering expectations.

There are several scenarios where the verification of various properties of an AutomationComponent is utilised in an automation system:

• ensuring that AutomationComponents match system engineering expectations during commissioning or initiating communication (e.g., detecting missing Assets like IO modules in a modular IO system);

• replacing or updating an AutomationComponent or any of its subcomponents.

Identity and compatibility verification can be done at any time (and executed by any AutomationComponent or tool that knows expected properties and their values) as long as the AutomationComponents can be accessed via Client Server services. In an automation system, verification is typically done before AutomationComponents participate in the industrial control application or process. It is crucial to ensure that the participating AutomationComponents will supply output data (to a consuming AutomationComponent) and use the input data (from a producing AutomationComponent) in an expected way.

This document defines verification modes and a verification Method for Assets, which provides the possibility to verify an Asset’s identity and whether or not it performs at a level that is compatible with what is expected by system engineering. For FunctionalEntities, a verification Method is defined, which can be used to verify instance-specific properties (e.g., identity properties) to ensure that they are consistent with what is expected by system engineering.

The subsequent clauses provide the general concepts for identity and compatibility verification.

5.2.2 Asset verification

5.2.2.1 Overview

Asset verification provides functionality to verify whether a given Asset’s type and instance information match or are compatible with what was expected by system engineering.

Applicable use cases include:

• commissioning an automation system (e.g., a machine) to ensure all Assets in an engineered system are from the expected manufacturer and are the expected model;

• prior to or at the initiation of data communication between AutomationComponents to ensure nothing has been (adversely) changed (e.g., during maintenance or shutdown);

• after conducting a firmware update to ensure the updated Asset is compatible with what was engineered;

• after replacing an Asset to ensure that the Asset has been replaced by one that is compatible or identical to what was engineered;

• verification of the instance of an Asset (e.g., serial number), which is often a requirement in certain applications and industries (e.g., pharmaceutical).

5.2.2.2 Asset identity

Asset identity refers to an Asset’s properties that make unambiguous identification possible. The IAssetRevisionType VerifyAsset Method provides the possibility to verify an Asset’s identity. See 6.3.3 for a detailed description.

5.2.2.3 Asset compatibility

This clause introduces the concept of Asset compatibility, which allows an Asset to report if it is compatible with what was expected by system engineering.

An important use case is AutomationComponent replacement. If an identical replacement (same manufacturer, model, and firmware) is unavailable, the vendor could be shipping a compatible substitute with updated hardware or firmware.

Asset compatibility verification provides functionality to verify whether a specific Asset’s properties match or are compatible (e.g., a newer firmware that is backwards compatible) with what was expected by system engineering.

Knowledge about Asset (and/or firmware) compatibility typically only exists with the vendor of a specific Asset. Thus, compatibility can only be determined by vendor-specific tools or a vendor’s Asset.

The IAssetRevisionType VerifyAsset Method, combined with the AssetVerificationModeEnum AssetCompatibility, allows verifying an Asset’s compatibility; see 6.3.3 for a detailed description.

5.2.3 FunctionalEntity verification

FunctionalEntity verification ensures that a given FunctionalEntity conforms to what was expected by system engineering. This verification includes checking the FunctionalEntity’s author, identifier, or version (issued by the author of a FunctionalEntity). It also supports checking any Variables defined by the application.

It can include checking, for instance, specific additional properties (e.g., the existence and values of optional properties that can represent the configuration of optional functionality or whether a FunctionalEntity is part of a specific application).

The IFunctionalEntityType Verify Method provides the possibility to verify instance-specific properties of a FunctionalEntity; see 6.4.3 for a detailed description.

5.3 ControlGroups

A FunctionalEntity can support multiple operating modes or groupings of functionality. An example might be a simple PID function block that supports cascade. In non-cascade mode, an HMI can set a setpoint, but the ability to externally set the setpoint is blocked in cascade. ControlGroups allow a FunctionalEntity to advertise these different groupings or modes.

A FunctionalEntity might define multiple (even nested) ControlGroups. These ControlGroups might be mutually exclusive, or they might be concurrently active. A ControlGroup might be related to just part of the functionality exposed by a FunctionalEntity.

Selecting a ControlGroup for control will often result in the locking of configuration or restricted access to ConfigurationData as defined by the FunctionalEntity (when the ControlGroup was defined). ControlGroups expose what restriction would occur if the given ControlGroup were selected for control. Locking can restrict access to Variables or Methods to a specific application/user. It can also just block all access to Variables or Methods. What occurs with the selection of a ControlGroup is defined as part of the ControlGroup. For example, all changes to some configuration parameters might need to be blocked as long as communication is occurring, or all changes to some configuration parameters might need to be restricted to a specific application. Any ControlGroup can reference any Variable / Method, and multiple ControlGroups might reference the same Variable / Method.

The ControlGroup provides a standard mechanism to configure what would be restricted or blocked, and with what application or functionality the restriction/block is associated. ControlGroups might be configured by product vendors and be related to the functionality provided by the AutomationComponent (e.g., a drive vendor or function block library vendor). It could also be defined by a system integrator that defines an application that will be using the FunctionalEntity.

5.4 ConfigurationData

ConfigurationData describes a collection of Variables within a FunctionalEntity that are used to set up and configure its functionality. As part of establishing a Connection between FunctionalEntities, some configuration might be required. This configuration is separate from the configuration required for the actual communication. The EstablishConnections Method allows any of the FunctionalEntity’s ConfigurationData to be set.

ConfigurationData can contain Variables that have the AccessLevelEx Attribute NonVolatile bit set to TRUE (see OPC 10000-3). After a power cycle, such Variables are initialised to the last value written before the power cycle.

OPC UA FX defines the concept of the storage of Variables (see 6.4.6). Variables that do not have the AccessLevelEx Attribute NonVolatile bit set can be configured to be part of the storage and are initialised to the stored value following a power cycle.

Variables that are not stored and do not have the AccessLevelEx Attribute NonVolatile bit set have an unspecified value (e.g., vendor-specific value) after a power cycle.

It is up to the provider of the FunctionalEntity whether to provide NonVolatile ConfigurationData or to support storage of Variables.

5.5 Logical connections

5.5.1 Overview

The logical functionality of an AutomationComponent is represented by one or more FunctionalEntities described in 4.4. An important part of the functional model is the data exchange between FunctionalEntities using logical connections. Figure 8 illustrates this interaction.

A logical connection is represented by two ConnectionEndpoints, one on each FunctionalEntity that is part of the connection. Figure 28 provides a more detailed view of the Objects involved.

Logical connections are configured using ConnectionConfigurationSets.

The following types of logical connections are supported (see Figure 10):

Bidirectional connections describe bidirectional data exchange between two FunctionalEntities.

Unidirectional connections with heartbeat describe unidirectional data exchange in one direction and a heartbeat message (for logical connection monitoring) in the opposite direction between two FunctionalEntities.

Unidirectional connections describe unidirectional data exchange between two FunctionalEntities.

Autonomous publisher describes data published by a FunctionalEntity, where the related subscribing ConnectionEndpoint(s) are unknown to the logical connection.

Autonomous subscriber describes data subscribed by a FunctionalEntity, where the related publishing ConnectionEndpoint(s) are unknown to the logical connection.

Auditing reports problems and changes triggered by an external application. A subscription within a Connection is considered a source of data (for source of data, see OPC 10000-4). Changes in the values of Variables from a data source do not generate AuditEvents.

5.5.2 Generation, deployment, and modification

This document defines the required data model for logical connection configuration information, represented by the ConnectionConfigurationSetType and additional ObjectTypes it utilises.

The ConnectionManagerType (see 6.7) exposes configuration information related to the establishment of logical connections. The configuration information is typically generated by an engineering tool based on offline or online information.

OfflineEngineering (see OPC 10000-83) offers the concept of Descriptors that describe the AutomationComponents; see Figure 11, label 1. Using these Descriptors or retrieving information online from the AutomationComponents, application engineers use vendor-specific engineering tools to generate the configuration data for logical connections (see Figure 11, label 2). All configuration data represented by one or more logical connections is defined in a ConnectionConfigurationSet. The instances can also include configuration information for the utilised OPC UA communication model (e.g., PubSub or Client Server [future]).

The engineering tool and ConnectionManager could reside on separate devices or be located on the same device.

ConnectionConfigurationSets can be deployed to the ConnectionManager (see Figure 11, label 3) using functionality defined in Annex F or vendor-specific means.

A ConnectionConfigurationSet can allow changes. For example, addressing information that is only available at commissioning time or communication-related properties like the PublishingInterval for data exchange can be modified by a system integrator. The changes that can be made can be restricted by the generator of the ConnectionConfigurationSet. The ConnectionManager exposes the ConnectionConfigurationSets (see 6.86.8), representing sets of logical connections to be established. Using generic tools (Clients), the ConnectionConfigurationSets can be modified as restricted (see Figure 11, label 4).

The ConnectionManager provides optional Methods to interact with these sets of logical connections, i.e., for editing and committing updates to sets (see 6.7.4) and to trigger processing (establishment for all logical connections) of sets (see 6.7.5). The ConnectionManager can also provide vendor-specific means.

5.5.3 Establishing and closing Connections

As introduced in 4.7, logical connection establishment can be executed by a ConnectionManager. If present on a Server, the ConnectionManager is represented in the Information Model by a well-known instance of ConnectionManagerType (see 6.7). To start the establishment of logical connections, the ConnectionManager could be triggered by vendor-specific means or by a Client using the ProcessConnectionConfigurationSets Method. It could also be an application that is always executing. The ConnectionManager calls the EstablishConnections Method on the AutomationComponents to establish the logical connections.

For each logical connection to be established, the ConnectionConfigurationSet includes:

• address information, e.g., Server address, BrowsePath to the AutomationComponent, FunctionalEntity, etc.,

• optional parameters to be used for verifying the Assets and FunctionalEntities,

• optional parameters to be used for establishing control,

• optional parameters to be used for configuring the application behaviour,

• the definition of the data to be exchanged via the logical connection,

• communication model-specific properties for the utilised OPC UA communication model (e.g., PubSub or Client Server [future]).

For more details on the ConnectionConfigurationSetType, see 6.8. For details on ConnectionManager functionality, see 6.7.

The ConnectionManager could be triggered to close logical connections by vendor-specific means or by a Client invoking the ProcessConnectionConfigurationSets Method. The ConnectionManager calls the CloseConnections Method on the AutomationComponents to close the logical connections.

5.5.4 Cleaning up Connections

5.5.4.1 Overview

A consumer of data can always detect data loss (e.g., caused by loss of network communication or a faulty producer), but in many industrial control applications, it is of interest to the application producing the data whether the consumer(s) of that data are still available. OPC UA FX provides a configurable clean-up of logical connections and all associated resources.

5.5.4.2 Operation

The lifetime of a logical connection on an AutomationComponent can be tied to its Status (see 6.6.2), which is, in turn, tied to the reception of data or heartbeat messages. A configurable CleanupTimeout (see 6.6.2) allows the deletion of all resources allocated to a specific ConnectionEndpoint once its status indicates loss of data reception.

This revision of the specification supports logical connections that utilise the PubSub communication model and hence builds on the usage of either DataSetMessages or heartbeat messages (see OPC 10000-14).

5.5.5 Persistent and preconfigured objects

Establishing logical connections can involve creating several Objects within the AutomationComponents.

Persistence refers to the ability of AutomationComponents to store configuration, which allows these Objects to be restored after a power cycle or other restart. Individual logical connections can be marked for persistence (see IsPersistent in 6.6.2).

An AutomationComponent can provide preconfigured Objects (e.g., PublishedDataSet or ConnectionEndpoint). An example might be a FunctionalEntity that includes a preconfigured PublishedDataSet that is used as part of a logical connection. The other parts of the logical connection (e.g., ConnectionEndpoint, WriterGroup, DataSetWriter) are all created during connection establishment. If the Connection is not marked for persistence, the other parts are deleted on clean-up or on a power cycle, and the preconfigured Objects will remain.

5.5.6 Relationship to OPC UA communication models

5.5.6.1 Overview

Connections between FunctionalEntities are designed to exchange data by utilising OPC UA communication models. This revision of the specification supports the PubSub communication model as defined in OPC 10000-14. Future revisions will support the Client Server communication model.

5.5.6.2 PubSub

5.5.6.2.1 Overview

This clause illustrates how Connections utilise the PubSub communication model, focusing on three use cases relevant in the context of industrial automation and the design of AutomationComponents. These are just illustrations, and additional or different uses might also apply. The grey-blue boxes in these illustrations are defined in this document, while the yellow blocks are defined in OPC 10000-14.

5.5.6.2.2 Single Connection using unicast network messages

This use case, illustrated in Figure 12, describes a single logical connection between two FunctionalEntities located on the AutomationComponents A and B, each containing a Publisher, a Subscriber, and a single PubSubConnectionEndpoint. Both FunctionalEntities could be publishing data (bidirectional Connection), or only one could be publishing data while the other publishes a heartbeat (unidirectional connection with heartbeat).

Figure 12 illustrates the logical connection between the two FunctionalEntities FE_A1 and FE_B1. Each FunctionalEntity contains a PubSubConnectionEndpoint (Con_A1 and Con_B1), which references a DataSetReader and a DataSetWriter.

The PubSub instances are configured to exchange data between AutomationComponents AC_A and AC_B using unicast NetworkMessages.

5.5.6.2.3 Multiple Connections using unicast network messages

This use case, illustrated in Figure 13, typically applies to AutomationComponents that host multiple FunctionalEntities and/or nested FunctionalEntities.

Figure 13 illustrates two Connections, each between two PubSubConnectionEndpoints. Each PubSubConnectionEndpoint on AC_A (and similarly on AC_B) references a DataSetWriter (and DataSetReader) that is located under the same WriterGroup (and ReaderGroup).

The PubSub instances are configured to exchange data between AC_A and AC_B using unicast NetworkMessages. This use case is called aggregated because a single NetworkMessage aggregates multiple DataSetMessages (one per logical connection). Aggregation reduces the required network bandwidth.

5.5.6.2.4 Multiple Connections using multicast network messages

This use case, illustrated in Figure 14, could be applied to an AutomationComponent (AC_A) communicating with multiple AutomationComponents (AC_B and AC_C). To minimise network bandwidth usage in specific topologies, AC_A can aggregate published data into a single NetworkMessage, which is sent via multicast to the associated AutomationComponents AC_B and AC_C. In turn, AC_B and AC_C publish an individual NetworkMessage back to AC_A. Multicast can also help with scaling issues in the device (less processing of network messages is required).

5.5.6.2.5 DataSetMetaData

Connections are configured by an engineering tool on behalf of Descriptors and are deployed to a ConnectionManager (see 5.5.2). Independent of the lifetime of a Connection, another engineering tool can update a FunctionalEntity, including its preconfigured DataSets. In addition, the Descriptor can describe a different version of the FunctionalEntity to be connected at runtime. This can result in misinterpretation of the exchanged data.

To prevent this error scenario, PubSub provides the DataSetMetaData. DataSetMetaData describes the content and semantics of a DataSet. In addition, the DataSetMetaData provides the details defining the contract between the Publisher and the Subscriber, including how to encode and decode the DataSetMessage. Thus, Subscribers must know about the PublishedDataSet’s DataSetMetaData. For the concepts of the DataSetMetaData and its definition, see OPC 10000-14.

Any change to a PublishedDataSet regarding its content but also its semantics (e.g., engineering units) would generate changes to its DataSetMetaData, indicated by a change in its ConfigurationVersion (see OPC 10000-14). Depending on the chosen UADP header layout, the ConfigurationVersion of an individual Publisher or a GroupVersion combining the ConfigurationVersions of all Publishers belonging to a WriterGroup is transmitted with the NetworkMessage. Any mismatch between the transmitted version and the one configured at the Subscriber will cause the Subscriber to go into Error. To resolve the Error, the Subscriber needs an update of the DataSetMetaData. OPC 10000-14 offers multiple ways to accomplish this.

5.6 Health

Assets, FunctionalEntities, ConnectionEndpoints, and ConnectionConfigurationSets provide general health status and diagnostic conditions. This health status is aggregated from child objects to parent objects (e.g., from ConnectionEndpoints to the FunctionalEntity, from FunctionalEntities to the AutomationComponent, or from ConnectionConfigurationSets to the ConnectionManager). The aggregated health status allows a Client to easily detect whether diagnostic conditions are present somewhere in the Information Model. If the aggregated health status is “good”, a Client does not have to check other Objects in the tree. If a status other than “good” is reported, aggregated health status indicates the elements (e.g., Assets) which need more investigation (see 6.2.2).

5.7 AliasNames and OPC UA FX

AliasNames is a concept in OPC UA (defined in OPC 10000-17) that allows defining alternate names for Objects, Variables or Methods in an AddressSpace (see Figure 15). These names can be grouped into categories. The FindAlias method returns the ExpandedNodeId for the actual Object/Variable/Method. AliasNames are most commonly used for configuration management, but can also be used for DataSet/topic discovery and many other uses.

In OPC UA FX, AliasNames can be used to define a configuration for information used by the ConnectionManager. AliasNames allow offline engineering tools to assign alternate names to Variables or Objects that are used in the configuration (see Figure 16). These alternate names could be assigned and used long before the actual configuration is available. They can be exchanged between vendors, allowing vendors to configure Connections without having all the required data defined. The resolution of this configuration information into the actual Server / NodeId of the Node identified by the AliasName happens at runtime. The aggregation of AliasNames into a Global Discovery Server (GDS) happens automatically for Servers that are registered with a GDS. An AggregatingServer can also collect AliasNames.

5.8 Aggregation of OPC UA FX Servers

AggregatingServers can be used to collect information from multiple underlying Servers and add additional functionality to the information and/or source the information for higher-level applications, offloading the underlying Servers. The Information Model that is defined in this document can be aggregated. This clause provides some explanation regarding the aggregation of AutomationComponents and ConnectionManagers.

The AutomationComponent(s) can be reflected in a higher-level Server. This reflection can include Assets and FunctionalEntities, but it is expected that the communication model (between FunctionalEntities) will only exist in the actual Servers, not in the AggregatingServer. Any actions performed against the AutomationComponent in the AggregatingServer are expected to be passed down and performed on the actual Server, including any method calls. Also, only the status/configuration information from a ConnectionEndpoint would be mirrored. ControlGroup information can be displayed in an AggregatingServer. Still, all data just reflects data from the underlying Servers, so changes to values would only occur in the underlying Server and could only be made if no locks are in place. Any writes or Method calls made against an AutomationComponent on an AggregatingServer would need to be applied against the AutomationComponent in the underlying Server. The value in the AggregatingServer would only be updated due to mirroring the change in the underlying Server. The value would not be directly updated in the AggregatingServer.

An AggregatingServer can add functionality, such as the generation of Alarms or historization. It can also be the source of data for higher-level applications such as HMIs or advanced control applications. Multiple AutomationComponents from multiple Servers could be included under a single AggregatingServer.

An AggregatingServer can expose a ConnectionManager, but only one well-known ConnectionManager is allowed on a Server. This single ConnectionManager can reflect the ConnectionConfigurationSets from the underlying Servers. It can directly execute any commands it receives or pass the commands down to the underlying Servers.

5.9 Well Known Roles

All Servers supporting OPC UA FX should support the well-known Roles as defined in OPC 10000-3. The well-known Role ConfigureAdmin should be extended as indicated in Table 2.

All Servers supporting OPC UA FX should support the additional well-known Role as defined in Table 3.

For a detailed description of Roles, see OPC 10000-3, OPC 10000-14, and OPC 10000-18.

6 OPC UA FX ObjectTypes

6.1 OPC UA FX ObjectTypes overview

This document defines several ObjectTypes that can be used to create an OPC UA FX Information Model. It also specifies a number of Interfaces that can be applied to existing Information Models, allowing existing models to be used as part of an OPC UA FX system. For additional guidance on mapping this model to existing Information Models, see Annex B. For an overview of the main OPC UA FX ObjectTypes, see Figure 17.

Since the OPC UA FX Information Model supports small embedded devices as well as powerful controllers, it includes many optional items. Some of these items are mandatory for controller-level Profiles but optional for embedded device Profiles. For a complete list of Profiles related to OPC UA FX, see OPC 10000-84.

6.2 AutomationComponentType

6.2.1 Overview

The AutomationComponentType ObjectType provides for a grouping of Assets and FunctionalEntities in a given model. It exposes a Method that is used to establish Connections between FunctionalEntities. An overview of the AutomationComponentType is illustrated in Figure 18.

6.2.2 AutomationComponentType definition

The AutomationComponentType is the base ObjectType for an OPC UA FX device, controller, PLC, instrument, etc. It includes information related to the current Asset, the available functionality, its capabilities (including communication-related capabilities) and any related offline information. The AutomationComponentType is formally defined in Table 4 and Table 5.

The components of the AutomationComponentType have additional subcomponents, which are defined in Table 6.

FunctionalEntities provides a Folder for the FunctionalEntities that this AutomationComponent exposes. The Folder shall be restricted to hold only instances of a type derived from FunctionalEntityType or instances that implement the IFunctionalEntityType Interface. The Folder may be empty. FunctionalEntities can reference other FunctionalEntities, but FunctionalEntities that are directly referenced from this Folder are considered top-level FunctionalEntities.

Assets provides a Folder for assets. It shall include all assets that are referenced from the FunctionalEntities of this AutomationComponent. An Asset might be a complex type that includes other Assets. Assets directly referenced from this Folder are considered top-level Assets. For more details on the asset model, see 6.3. The Folder shall be restricted to hold only instances of FxAssetType or a subtype of it, or instances that implement the IVendorNameplateType, ITagNameplateType, and IAssetRevisionType Interfaces. The Folder may be empty; however, typically, there is at least one entry in this Folder. For examples of Assets, see Annex D.

Objects may be added/removed to/from the FunctionalEntities or Assets Folders during operation, in which case the Server shall generate GeneralModelChangeEvent to reflect these changes.

The optional PublisherCapabilities provide the Publisher capabilities associated with this AutomationComponent. They apply to all instances in the FunctionalEntities Folder. An individual FunctionalEntity can further restrict these capabilities. If an AutomationComponent supports being a Publisher as defined in OPC 10000-14, then an instance of this Object shall be provided.

The optional SubscriberCapabilities provides the general Subscriber capabilities associated with this AutomationComponent. They apply to all instances in the FunctionalEntities Folder. An individual FunctionalEntity can further limit these capabilities. If an AutomationComponent supports being a Subscriber as defined in OPC 10000-14, then an instance of this Object shall be provided.

ComponentCapabilities is an AutomationComponentCapabilitiesType Folder that describes the functionality provided by an AutomationComponent (e.g., number of supported Connections, etc.).

The optional ConformanceName provides the URL to the product’s listing on the OPC Foundation website, under which the result of the conformance testing for this product can be found. The product's name may be different from the name of the AutomationComponent since conformance testing may be done for a product family, but this shall be described on the OPC Foundation product page. The DisplayName of the instance of the AutomationComponent shall be able to be resolved on the Website to the specifics of the product that was tested. Furthermore, at least one Asset listed in this AutomationComponent shall include IVendorNameplateType information on the related OPC Foundation product page.

Descriptors is a Folder that can contain AcDescriptors. Typically, at least one AcDescriptor is included, but depending on the system's architecture, additional AcDescriptors might be added. These added AcDescriptors describe added FunctionalEntities or added Assets or added combinations of Assets and FunctionalEntities. The additions can result from application developers adding functionality, integration of this AutomationComponent into a larger piece of Equipment, or the addition of modular Assets to the system. This Folder may also contain other Folders that can be used to organise the AcDescriptors.

AggregatedHealth provides the aggregated health of the AutomationComponent; this includes an aggregation of the health of all included Assets and FunctionalEntities. For the definition of the AggregatedHealthType and the aggregation rules, see 9.1.

AutomationComponentLog exposes a LogObject for the AutomationComponent. The LogObject (see OPC 10000-26) can be accessed to obtain the log of activity related to this AutomationComponent. Events can be mapped to LogRecords (see OPC 10000-26) for the LogObject. LogObject records can also be generated without the generation of an Event. If the LogObject is supported, the AutomationComponent shall produce LogRecords for all calls of the EstablishConnections and CloseConnections Methods. The LogObject configuration would determine if the LogRecords are stored. The LogRecords shall include the optional TraceContext information if it is provided by the client invoking the EstablishConnection or CloseConnection calls. In addition, it is recommended that for errors, the AdditionalData field includes the error information as described in the OPC 10000-26 Log Event EventType clause.

Diagnostics is a FunctionalGroup (Folder) that contains Variables that report diagnostic statistics and counters (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

EstablishCallCount diagnostics counter Variable provides a count of the number of EstablishConnections calls received.

EstablishCallFailedCount diagnostics counter Variable provides a count of the number of EstablishConnections calls that failed (any command).

CloseCallCount diagnostics counter Variable provides a count of the number of CloseConnections calls received.

CloseCallFailedCount diagnostics counter Variable provides a count of the number of CloseConnections calls that failed.

The IsHostedBy ReferenceType (see OPC 10000-23) indicates the Assets used to execute the functionality provided by a FunctionalEntity. There may be multiple IsHostedBy References from one FunctionalEntity to multiple Assets. An example is a drive axis FunctionalEntity, which has IsHostedBy References to a drive inverter Asset and a motor Asset. Another example is an input FunctionalEntity having IsHostedBy References to the input module, the head, and the firmware Assets of a modular device.

Figure 19 illustrates an example of the usage of IsHostedBy.

If Eventing is supported, the AutomationComponent shall generate Events of SystemStatusChangeEventType (see OPC 10000-3) if the ServerState changes (e.g., following a power cycle).

6.2.3 AcDescriptorType definition

An instance of AcDescriptorType is used to represent a Descriptor. This Object shall include either a DescriptorFile or the pair of DescriptorIdentifier and DescriptorVersion. It may include all three.

The AcDescriptorType is formally defined in Table 7.

The optional DescriptorIdentifier provides a globally unique identifier of the Descriptor of the AutomationComponent. It can be used to retrieve the Descriptor from the vendor’s product listing on the OPC Foundation Website (i.e., the OPC Marketplace).

The optional DescriptorVersion provides the version of the Descriptor used to describe this AutomationComponent.

The optional DescriptorFile exposes the Descriptor (defined in OPC 10000-83) directly from the AutomationComponent.

If both the DescriptorFile and the DescriptorIdentifier are provided, the value of the DescriptorIdentifier Variable exposed in the Object shall match the value of DescriptorIdentifier provided in the manifest of the DescriptorFile. If, in addition, the DescriptorVersion is provided, the value of the DescriptorVersion Variable exposed in the Object shall match the value of DescriptorVersion provided in the manifest of the DescriptorFile.

6.2.4 EstablishConnections method

6.2.4.1 Overview

The EstablishConnections Method establishes one or more Connections. The ConnectionManager typically calls it. It allows for creating ConnectionEndpoints, establishing control, verifying FunctionalEntity and Asset compatibility, applying ConfigurationData, and configuring the communication model to be used for data exchange. It is recommended that this Method be restricted to Client connections that have the well-known Role ConnectionAdmin as defined in Clause 5.9.

6.2.4.2 EstablishConnections signature

The signature of this Method is specified below; the arguments are defined in Table 8.

Signature

	EstablishConnections (
	  [in] 2:FxCommandMask				CommandMask,
	  [in] 2:AssetVerificationDataType[]		AssetVerifications,
	  [in] 2:ConnectionEndpointConfigurationDataType[]	
								ConnectionEndpointConfigurations,
	  [in] 2:ReserveCommunicationIdsDataType[]	ReserveCommunicationIds,
	  [in] 2:CommunicationConfigurationDataType[]	CommunicationConfigurations,
							
	  [out] 2:AssetVerificationResultDataType[]	AssetVerificationResults,
	  [out] 2:ConnectionEndpointConfigurationResultDataType[]	
							ConnectionEndpointConfigurationResults,
	  [out] 2:ReserveCommunicationIdsResultDataType[]	
								ReserveCommunicationIdsResults,
	  [out] 2:CommunicationConfigurationResultDataType[]	
								CommunicationConfigurationResults
	  );

The possible Method result codes are formally defined in Table 9.

The possible StatusCodes for the AssetVerificationResults VerificationStatus are formally defined in Table 10.

The possible StatusCodes for the ConnectionEndpointConfigurationResults FunctionalEntityNodeResult are formally defined in Table 11.

The possible StatusCodes for the ConnectionEndpointConfigurationResults ConnectionEndpointResult are formally defined in Table 12.

The possible StatusCodes for the ConnectionEndpointConfigurationResults EstablishControlResult are formally defined in Table 13.

The possible StatusCodes for the ConnectionEndpointConfigurationResults ConfigurationDataResult are formally defined in Table 14.

The possible StatusCodes for the ConnectionEndpointConfigurationResults ReassignControlResult are formally defined in Table 15.

The possible StatusCodes for the ConnectionEndpointConfigurationResults CommunicationLinksResult are formally defined in Table 16.

The possible StatusCodes for the ConnectionEndpointConfigurationResults EnableCommunicationResult are formally defined in Table 17.

The possible StatusCodes for the ReserveCommunicationIdsResults Result are formally defined in Table 18.

The possible StatusCodes for the CommunicationConfigurationResults Result are formally defined in Table 19.

The EstablishConnections Method representation in the AddressSpace is formally defined in Table 20.

6.2.4.3 EstablishConnections behaviour

6.2.4.3.1 Overview

A Client calling the EstablishConnections Method may provide multiple commands and the required Arguments for each command. If multiple commands are provided in a single call, the individual commands shall be processed in the order VerifyAssetCmd, VerifyFunctionalEntityCmd, ReserveCommunicationIdsCmd, CreateConnectionEndpointCmd, EstablishControlCmd, SetConfigurationDataCmd, ReassignControlCmd, SetCommunicationConfigurationCmd, EnableCommunicationCmd, which is illustrated in Figure 20.

A Client may issue the same command in consecutive EstablishConnections Calls, e.g., to apply large configuration data in multiple Calls with SetConfigurationDataCmd.

If the processing of a command results in an error, the processing of the command sequence shall be stopped at the command that caused the error, and the EstablishConnections Method Call shall be aborted, as described in 6.2.4.3.11.

An AutomationComponent may support individual commands in EstablishConnections Method Calls or may require that certain commands be bundled in a single EstablishConnections Method Call. If an AutomationComponent requires bundled commands, the CommandBundleRequired capability shall be provided and set to TRUE (see 6.2.6). The set of bundled commands is defined as follows: CreateConnectionEndpointCmd, EstablishControlCmd, SetConfigurationDataCmd, ReassignControlCmd, and SetCommunicationConfigurationCmd. The commands CreateConnectionEndpointCmd and SetCommunicationConfigurationCmd are mandatory in the bundle; the remaining commands are optional. An AutomationComponent requiring bundled commands shall return Bad_InvalidArgument for any command in the set of bundled commands that is issued individually, i.e., not issued in a bundle.

How the commands are processed is described in Clauses 6.2.4.3.2 to 6.2.4.3.10.

6.2.4.3.2 Command VerifyAssetCmd

If CommandMask VerifyAssetCmd is set, the EstablishConnections implementation shall execute the IAssetRevisionType VerifyAsset Method for each element in the AssetVerifications array. The VerifyAsset Method shall be called on each AssetToVerify, supplying the VerificationMode, ExpectedVerificationVariables and ExpectedAdditionalVerificationVariables as Method Arguments.

The StatusCode returned by the VerifyAsset Method and the values of its output Arguments VerificationResult, VerificationVariablesErrors, and VerificationAdditionalVariablesErrors shall be stored in the appropriate elements in AssetVerificationResults (see 10.6).

Once all array processing is complete, if at least one of the following conditions is true:

AssetToVerify was unknown or invalid,

at least one of the returned AssetVerificationResults VerificationResult equals NotSet, Mismatch, or Compatible when ExpectedVerificationResult requires Match,

at least one VerifyAsset Method execution returned an error,

then the EstablishConnections implementation shall abort processing of additional commands as described in 6.2.4.3.11.

The possible StatusCodes related to the command VerifyAssetCmd are formally defined in Table 10. The StatusCodes related to individual verification Variables are formally defined in Table 33 and Table 34.

6.2.4.3.3 Command VerifyFunctionalEntityCmd

If CommandMask VerifyFunctionalEntityCmd is set, the EstablishConnections implementation shall execute the FunctionalEntityType Verify Method for each element in ConnectionEndpointConfigurations with a non-empty ExpectedVerificationVariables array. For elements with a null or empty ExpectedVerificationVariables array, the VerificationStatus shall be set to Good_NoData, VerificationResult to NotSet, and VerificationVariablesErrors to null or empty. The Method shall be called on the FunctionalEntity identified by FunctionalEntityNode, supplying the ExpectedVerificationVariables as Method Argument.

The StatusCode returned by the Verify Method shall be stored in VerificationStatus, and the values of its output Arguments VerificationResult and VerificationVariablesErrors in VerificationResult and VerificationVariablesErrors (see 10.15).

If the FunctionalEntityNode was not found, the VerificationVariablesErrors shall be set to null or empty, and the VerificationResult shall be set to Mismatch.

Once all array processing is complete, if any one of the following conditions applies:

• at least one FunctionalEntityNode was not found;

• at least one VerificationResult equals Mismatch;

• at least one VerificationResult equals NotSet, and VerificationVariablesErrors is populated;

• at least one Verify Method execution returned an error;

the EstablishConnections implementation shall abort the processing of subsequent commands as described in 6.2.4.3.11.

The possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for VerificationStatus are formally defined in Table 44. The possible StatusCodes for VerificationVariablesErrors are formally defined in Table 45.

6.2.4.3.4 Command ReserveCommunicationIdsCmd

6.2.4.3.4.1 General

If CommandMask ReserveCommunicationIdsCmd is set, the EstablishConnections implementation shall reserve communication model identifiers for each element in ReserveCommunicationIds.

6.2.4.3.4.2 PubSub

For a PubSub communication model, a structure of type PubSubReserveCommunicationIds2DataType (see 10.43.4) shall be used.

The EstablishConnections implementation shall reserve the requested number of IDs for both WriterGroups and DataSetWriters for each requested TransportProfileUri. For additional details, see OPC 10000-14 ReserveIds Method, including error definitions.

If any error occurs, the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

The EstablishConnections implementation shall return the default value for each requested TransportProfileUri for the PublisherId, the reserved WriterGroupIds, and DataSetWriterIds in the output Argument ReserveCommunicationIdsResults. Additionally, if the RequestTransportSpecificInfo is set to TRUE in the request for the given TransportProfileUri, it shall also return a non-null TransportSpecificInfo. In the case of UDP-UADP, this will be a UDP port number used to receive UDP unicast traffic.

The possible StatusCodes for the ReserveCommunicationIdsResults Result are formally defined in Table 18.

6.2.4.3.4.3 Client Server

This clause may be defined in a future version of this document.

6.2.4.3.5 Command CreateConnectionEndpointCmd

If CommandMask CreateConnectionEndpointCmd is set, the EstablishConnections Method shall create a ConnectionEndpoint or shall verify and update a preconfigured ConnectionEndpoint for each element in ConnectionEndpointConfigurations (see 10.14) with the Parameter defined in ConnectionEndpoint (see 10.16).

The EstablishConnections implementation shall set ConnectionEndpointConfigurationResults ConnectionEndpointResult on errors as specified in Table 12.

If IsPreconfigured is set to FALSE, the EstablishConnections implementation shall create a ConnectionEndpoint in the ConnectionEndpoints Folder of the FunctionalEntity identified by FunctionalEntityNode. The created ConnectionEndpoint shall be of the subtype specified in ConnectionEndpointTypeId. The BrowseName shall be set to Name, and all Variables shall be set according to Parameter. The appropriate entries in InputVariables and OutputVariables shall be populated.

If IsPreconfigured is set to TRUE, a preconfigured ConnectionEndpoint (see 5.5.5) shall exist with a BrowseName that matches Name in the ConnectionEndpoints Folder of the FunctionalEntity identified by FunctionalEntityNode. Its ConnectionEndpointTypeId, InputVariables and OutputVariables shall match what is specified in Parameter. IsPersistent, CleanupTimeout, and RelatedEndpoint of the preconfigured ConnectionEndpoint shall be set according to Parameter.

The implementation shall return the NodeId of the ConnectionEndpoint in the corresponding element in ConnectionEndpointConfigurationResults. If additional commands in the EstablishConnections Method sequence are present, this NodeId shall be used.

The EstablishConnections implementation shall stop processing this command on the first error and abort processing as described in 6.2.4.3.11.

The possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for the ConnectionEndpointResult are formally defined in Table 12.

6.2.4.3.6 Command EstablishControlCmd

If CommandMask EstablishControlCmd is set, the EstablishConnections implementation shall call the EstablishControl Method on each element in ControlGroups for each element in ConnectionEndpointConfigurations. If ControlGroups is null or empty, EstablishControlResult shall be set to null or empty (see 10.15).

This command shall pass the ApplicationUri of the Session associated with the EstablishConnections Method Call as LockContext Argument to EstablishControl (see 6.5.3).

The EstablishConnections implementation shall stop processing this command on the first error and shall abort processing as described in 6.2.4.3.11.

The possible StatusCodes for the EstablishControlResult are formally defined in Table 13. The possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for the ConnectionEndpointResult are formally defined in Table 12.

6.2.4.3.7 Command SetConfigurationDataCmd

If CommandMask SetConfigurationDataCmd is set, the EstablishConnections implementation shall apply the Value to the Key for each element in ConnectionEndpointConfigurations and each element in ConfigurationData. If the ConnectionEndpoint related to ConfigurationData has IsPersistent set, SetStoredVariables (see 6.4.6.3) shall be called for all Variables indicated by Key having the NonVolatile bit in the AccessLevelEx Attribute not set. If ConfigurationData is empty, ConfigurationDataResult shall be set to null or empty (see 10.15).

The EstablishConnections implementation shall stop processing this command on the first error and abort processing as described in 6.2.4.3.11.

The possible StatusCodes for the ConfigurationDataResult are formally defined in Table 14. The possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for the ConnectionEndpointResult are formally defined in Table 12.

6.2.4.3.8 Command ReassignControlCmd

If CommandMask ReassignControlCmd is set, the EstablishConnections implementation shall call the ReassignControl Method on each element in ControlGroups for each element in ConnectionEndpointConfigurations. If ControlGroups is null or empty, ReassignControlResult shall be set to null or empty (see 10.15).

This command shall pass the string representation of the NodeId of the ConnectionEndpoint as LockContext Argument to ReassignControl.

The EstablishConnections implementation shall stop processing this command on the first error and shall abort processing as described in 6.2.4.3.11.

The possible StatusCodes for the ReassignControlResult are formally defined in Table 15. The possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for the ConnectionEndpointResult are formally defined in Table 12.

6.2.4.3.9 Command SetCommunicationConfigurationCmd

6.2.4.3.9.1 General

If CommandMask SetCommunicationConfigurationCmd is set, the EstablishConnections implementation shall apply the communication model configuration supplied in CommunicationConfigurations in an atomic operation.

6.2.4.3.9.2 PubSub

The communication configuration applied in the case of a PubSub communication model is a structure of the type PubSubCommunicationConfigurationDataType (see 10.10.3).

The result of applying the communication configuration in the case of a PubSub communication model is a structure of the type PubSubCommunicationConfigurationResultDataType (see 10.11.3).

The EstablishConnections implementation shall process the supplied PubSubConfiguration with RequireCompleteUpdate and ConfigurationReferences in an atomic operation according to the behaviour of the CloseAndUpdate Method specified by OPC 10000-14. It shall set the overall processing result in the Result field of the result structure and the returned ChangesApplied, ReferenceResults, ConfigurationValues, and ConfigurationObjects in other corresponding fields of that structure.

If an error is returned, the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

The SetCommunicationConfigurationCmd will apply the PubSubConfiguration, including the values of all Enabled flags for the configuration elements. Depending on the values of the Enabled flags, this may result in overall enabled PubSub communication without passing the EnableCommunicationCmd or parts of the PubSub communication being enabled while others are disabled.

The EstablishConnections implementation shall create the ToDataSetReader and ToDataSetWriter References according to the link information supplied in ConnectionEndpointConfigurations CommunicationLinks (see 10.13). If the PubSub configuration model is not exposed by this Server, this Reference may point to a Node that is not accessible. If the Reference cannot be created, an appropriate StatusCode shall be set in the appropriate element in ConnectionEndpointConfigurationResults CommunicationLinksResult, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

The EstablishConnections implementation shall verify the SubscribedDataSet associated with the referenced DataSetReader for each element in ConnectionEndpointConfigurations having a ToDataSetReader Reference.

If ExpectedSubscribedDataSetVersion MajorVersion is 0 (for the definition of MajorVersion, see OPC 10000-14), no verification shall be performed. If ExpectedSubscribedDataSetVersion MinorVersion is 0 (for the definition of MinorVersion, see OPC 10000-14), the verification for MinorVersion shall be skipped. If the ExpectedSubscribedDataSetVersion does not match the version of the associated SubscribedDataSet, the appropriate element in ConnectionEndpointConfigurationResults CommunicationLinksResult shall be set to Bad_ConfigurationError, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11

If InputVariableIds is used, and at least one Variable is not contained in the associated SubscribedDataSet, the appropriate element in ConnectionEndpointConfigurationResults CommunicationLinksResult shall be set to Bad_NoMatch, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

The EstablishConnections implementation shall verify the PublishedDataSet associated with the referenced DataSetWriter for each element in ConnectionEndpointConfigurations having a ToDataSetWriter Reference.

If ExpectedPublishedDataSetVersion MajorVersion is 0, no verification shall be performed. If ExpectedPublishedDataSetVersion MinorVersion is 0, the verification for MinorVersion shall be skipped. If the ExpectedPublishedDataSetVersion does not match the version of the associated PublishedDataSet, the appropriate element in ConnectionEndpointConfigurationResults CommunicationLinksResult shall be set to Bad_ConfigurationError, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11

If OutputVariableIds is used, and at least one Variable is not contained in the associated PublishedDataSet, the appropriate element in ConnectionEndpointConfigurationResults CommunicationLinksResult shall be set to Bad_NoMatch, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

The EstablishConnections implementation shall verify that ConnectionEndpoints with their IsPersistent Property set to TRUE reference a DataSetReader and/or DataSetWriter which are persisted, including all parent Objects, i.e., WriterGroup, ReaderGroup, PubSubConnection and PublishSubscribe (see NotPersisted in OPC 10000-14). If the IsPersistent Property is set to FALSE, the EstablishConnections implementation shall verify that the DataSetReader and/or DataSetWriter are not persisted (see NotPersisted in OPC 10000-14). Otherwise, Bad_InvalidState shall be set in the appropriate element in ConnectionEndpointConfigurationResults CommunicationLinksResult, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

If communication configuration exceeds capabilities (PublisherCapabilities, SubscriberCapabilities or ComponentCapabilities) of the AutomationComponent, FunctionalEntities, InputData or OutputData, or if communication configuration cannot be applied, Bad_ConfigurationError shall be set in the Result field of the result structure, and the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

In the ConnectionEndpointConfigurationResults, the possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for the ConnectionEndpointResult are formally defined in Table 12. The possible StatusCodes for the CommunicationLinksResult are formally defined in Table 16.

The possible StatusCodes for the CommunicationConfigurationResults Result are formally defined in Table 19.

Standard OPC UA Diagnostics can be used to obtain additional information related to any PubSub configuration errors.

6.2.4.3.9.3 Client Server

This clause may be defined in a future version of this document.

6.2.4.3.10 Command EnableCommunicationCmd

6.2.4.3.10.1 General

If CommandMask EnableCommunicationCmd is set, the EstablishConnections implementation shall enable all communication model-specific Objects related to the ConnectionEndpoints in an atomic operation.

6.2.4.3.10.2 PubSub

The EstablishConnections implementation shall enable the DataSetReader and DataSetWriter referenced by ToDataSetReader and/or ToDataSetWriter References for each element in ConnectionEndpointConfigurations. It shall also ensure that the parent Objects (WriterGroup, ReaderGroup, PubSubConnection, and PublishSubscribe) are enabled.

If enabling any communication model-specific Objects fails, the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

If enabling a ConnectionEndpoint would lead to multiple DataSetReaders being enabled that reference the same TargetVariable(s), the EstablishConnections implementation shall abort processing as described in 6.2.4.3.11.

The possible StatusCodes for the FunctionalEntityNodeResult are formally defined in Table 11. The possible StatusCodes for the ConnectionEndpointResult are formally defined in Table 12. The possible StatusCodes for the EnableCommunicationResult are formally defined in Table 17.

6.2.4.3.10.3 Client Server

This clause may be defined in a future version of this document.

6.2.4.3.11 Abort

The EstablishConnections implementation shall abort processing if one of the issued commands fails; see the individual command behaviour descriptions in Clauses 6.2.4.3.2 to 6.2.4.3.10. No further commands requested for this Method Call shall be executed. The result of the commands executed with this Method Call shall be rolled back according to Table 21.

The Method shall set the appropriate StatusCodes for not executed commands to Bad_NothingToDo and return with an Uncertain result.

There is no rollback provided by the Method over multiple Method calls; such a rollback is the responsibility of the caller of the Method (e.g., the ConnectionManager). The caller of the Method can use the CloseConnections Method to issue a complete rollback.

6.2.5 CloseConnections method

6.2.5.1 CloseConnections signature

This Method disables one or more Connections. Optionally, it also removes these Connections. It is recommended that this Method has the execute privilege for the well-known Role ConnectionAdmin as defined in Clause 5.9.

The signature of the Method is described below, and the arguments are described in Table 22.

Signature

	CloseConnections (
	  [in] 0:NodeId[]			ConnectionEndpoints,
	  [in] 0:Boolean			Remove,
	  [out] 0:StatusCode[]		Results
	);

The possible Method result codes are formally defined in Table 23.

The possible Results StatusCodes are formally defined in Table 24.

The CloseConnections Method representation in the AddressSpace is formally defined in Table 25.

6.2.5.2 CloseConnections behaviour

The Method implementation shall disable all communication model Objects for each element in ConnectionEndpoints in an atomic operation. For additional details on ConnectionEndpoints, see 6.6, and PubSubConnectionEndpoints, see 6.6.3.

If PubSub is used as the communication model for a ConnectionEndpoint, the Method implementation shall only disable the DataSetReader and DataSetWriter referenced by ToDataSetReader and/or ToDataSetWriter References if no further References from other ConnectionEndpoints exist. Their parent Objects (WriterGroup, ReaderGroup, PubSubConnection, and PublishSubscribe) shall be left in their current state.

The behaviour of the Client Server communication model may be defined in a future version of this document.

The CleanupTimeout processing shall be disabled.

If Remove is TRUE, the Method implementation shall remove what has been dynamically created by the EstablishConnections Method Call(s) related to the ConnectionEndpoints. This includes any configuration specific to the utilised communication model, all related communication model Objects if not referenced from other ConnectionEndpoints, the ConnectionEndpoints, and all persisted items. In addition, all ControlGroups-based restrictions placed on Objects shall be released. Preconfigured Objects or Objects referenced by other ConnectionEndpoints shall not be removed.

What occurs with the ConfigurationData that was applied when establishing the ConnectionEndpoints is vendor-specific.

6.2.6 AutomationComponentCapabilitiesType

The AutomationComponentCapabilitiesType extends the FolderType defined in OPC 10000-5. It shall be restricted to holding only Variables that reflect the capabilities of the AutomationComponentType.

The AutomationComponentCapabilitiesType is formally defined in Table 26.

<Capability> - is an OptionalPlaceholder (defined in OPC 10000-3 ) to indicate that additional capabilities may be added by this document, by a companion specification or by a vendor application. These capabilities shall include a Description, and they follow all of the rules associated with an OptionalPlaceholder.

The optional SupportsPersistence indicates whether this AutomationComponent supports persistent Connections. For additional details on persistence, see 6.6. If this capability is not present or set to FALSE, the AutomationComponent does not support persistent Connections.

The optional MaxFunctionalEntities indicates the maximum number of FunctionalEntities that the AutomationComponent can support.

The optional MaxConnections indicates the maximum number of Connections that the AutomationComponent can support. This number may be further restricted based on the type of Connections being provided (i.e., a high-speed Connection might further reduce the number of available Connections).

The optional MinConnections indicates the minimum number of Connections that the AutomationComponent can always guarantee. MinConnections shall be less than or equal to MaxConnections (if both exist). The actual number of Connections that might exist may be some number between the MinConnections and the MaxConnections.

The optional MaxConnectionsPerCall indicates the maximum number of Connections that can be established in a single EstablishConnections Call (see 6.2.4). MaxConnectionsPerCall shall be less than or equal to MaxConnections (if both exist).

If MaxFunctionalEntities, MaxConnections, and MaxConnectionsPerCall are not present, then no limit is specified.

The optional CommandBundleRequired indicates whether this AutomationComponent requires a single Method Call for bundled commands when EstablishConnections is called (see 6.2.4.3.1). If the capability is not present or set to FALSE, the AutomationComponent supports individual calls.

6.2.7 PublisherCapabilitiesType

The PublisherCapabilitiesType is a subtype of the BaseObjectType. It is used to contain the various Publisher capabilities that can be supported. An instance of this ObjectType groups the capabilities and can be deployed as part of any Object that desires to expose a range of capabilities that are supported by that Object.

It is formally defined in Table 27.

SupportedPublishingIntervals provides the supported intervals for publishing. An empty array indicates that no restrictions are defined by this instance.

SupportedQos provides the supported Quality of Service settings. An empty array indicates that no restrictions are defined by this instance.

PreconfiguredPublishedDataSets provides the names of preconfigured PublishedDataSets (see 5.5.5), where the name is the string part of the BrowseName of a PublishedDataSet that is listed in the PublishedDataSets Folder tree of the PublishSubscribe Object (see OPC 10000-14). If PublisherCapabilities is referenced from a FunctionalEntity (see 6.4.2) or OutputData (see 6.4.5), a preconfigured PublishedDataSet shall only reference OutputVariables of this FunctionalEntity and its sub-FunctionalEntities. If the PublisherCapabilities is referenced from an AutomationComponent, a preconfigured PublishedDataSet shall only reference OutputVariables from FunctionalEntities that are part of the AutomationComponent. When the preconfigured PublishedDataSet is used in a ConnectionConfigurationSet, Connections shall be established to one or more of the FunctionalEntities whose variables are present in the DataSet. An empty array indicates that no preconfigured PublishedDataSets are defined by this instance.

PreconfiguredDataSetOnly, if set to TRUE, indicates that the Publisher supports publishing of preconfigured PublishedDataSets only. If set to FALSE, the Publisher supports publishing of customised PublishedDataSets as well as preconfigured PublishedDataSets.

6.2.8 SubscriberCapabilitiesType

The SubscriberCapabilitiesType is a subtype of the BaseObjectType. It is used to contain the various Subscriber capabilities that can be supported. An instance of this ObjectType groups the capabilities and can be deployed as part of any Object that desires to expose a range of capabilities that are supported by that Object.

It is formally defined in Table 28.

SupportedPublishingIntervals provides the intervals for publications, which this Subscriber is able to receive. An empty array indicates that no restrictions are defined by this instance.

SupportedQos provides the supported Quality of Service settings. An empty array indicates that no restrictions are defined by this instance.

SupportedMessageReceiveTimeouts provides the supported timeouts for receiving messages. An empty array indicates that no restrictions are defined by this instance.

PreconfiguredSubscribedDataSets provides the names of preconfigured StandaloneSubscribedDataSets (see 5.5.5), where the name is the string part of the BrowseName of a StandaloneSubscribedDataSet that is listed in the SubscribedDataSets Folder tree of the PublishSubscribe Object (see OPC 10000-14). If SubscriberCapabilities is referenced from a FunctionalEntity (see 6.4.2) or InputData (see 6.4.4), a preconfigured StandaloneSubscribedDataSet shall only reference InputVariables from the FunctionalEntity and its sub-FunctionalEntities. If the SubscriberCapabilities is referenced from an AutomationComponent, a preconfigured StandaloneSubscribedDataSet shall only reference InputVariables from FunctionalEntities that are part of the AutomationComponent. When the preconfigured StandaloneSubscribedDataSet is used in a ConnectionConfigurationSet, Connections shall be established to one or more of the FunctionalEntities whose variables are present in the DataSet. An empty array indicates that no preconfigured StandaloneSubscribedDataSets are defined by this instance.

PreconfiguredDataSetOnly, if set to TRUE, indicates that the Subscriber only supports subscribing with preconfigured StandaloneSubscribedDataSets. If set to FALSE, the subscriber supports subscribing with customised SubscribedDataSets as well as preconfigured StandaloneSubscribedDataSets.

6.3 FxAssetType definition

6.3.1 Overview

Figure 21 provides an illustration of the FxAssetType model. The figure includes an illustration of the nodes that are added via the Interfaces.

6.3.2 FxAssetType definition

The FxAssetType provides general information as defined in OPC 10000-100. It also includes additional information that is defined as an Interface. Being defined as an Interface allows other device models to include what is required for OPC UA FX Asset modelling without having to implement the FxAssetType Object directly. Conformance testing shall test that the required information, defined by the Interfaces included in the FxAssetType, is available, not that the Object is of FxAssetType. Any Object that implements all of the Interfaces defined in FxAssetType is considered an Asset.

Additional References are defined as part of the model to show relationships between Assets, within Assets, and between Assets and FunctionalEntities and the overall AutomationComponent model (see 11.1).

The FxAssetType is formally defined in Table 29.

The components of the FxAssetType have additional subcomponents, which are defined in Table 30

The display name of the Asset should be used to provide the name that an operator/engineer would expect for the Asset.

For examples of how to apply the OPC UA FX Information Model to other models, see Annex B. For examples of FxAssetType models, see Annex D.

The following are the definitions associated with the IVendorNameplateType interface; they are enclosed in quotes and included here for clarity. Their formal definition is in OPC 10000-100. Additional notes are provided for recommended usage within this model.

• “Manufacturer provides the name of the company that manufactured the item to which this Interface is applied.”

• “ManufacturerUri provides a unique identifier for this company. This identifier should be a fully qualified domain name; however, it may be a GUID or similar construct that ensures global uniqueness.”

• “Model provides the name of the product.”

• “ProductCode provides a unique combination of numbers and letters used to identify the product. It may be the order information displayed on type shields or in ERP systems.”

• “HardwareRevision provides the revision level of the hardware of an Asset.”

• “SoftwareRevision provides the version or revision level of the software component, the software/firmware of a hardware component, or the software/firmware of the Device.”

• “DeviceRevision provides the overall revision level of a hardware component or the Device. As an example, this Property can be used in ERP systems together with the ProductCode Property.”

• “DeviceManual allows specifying the address of the user manual for an Asset. It may be a pathname in the file system or a URL (Web address).”

• “DeviceClass indicates in which domain or for what purpose a certain ComponentType is used. Examples are “ProgrammableController”, “RemoteIO”, and “TemperatureSensor”. This standard does not predefine any DeviceClass names. More specific standards that utilise this Interface will likely introduce such classifications.”

• Within this model, this information is typically used for display purposes only. It is recommended that if this Property is provided, the string should be from some standardised dictionary.

• “SerialNumber is a unique production number of the manufacturer of the Asset. This is often stamped on the outside of a physical component and may be used for traceability and warranty purposes.”

• “ProductInstanceUri is a globally unique resource identifier provided by the manufacturer. This is often stamped on the outside of a physical component and may be used for traceability and warranty purposes. The maximum length is 255 characters. The syntax of the ProductInstanceUri is: <ManufacturerUri>/<any string>, where <any string> is unique among all instances using the same ManufacturerUri.”

• Within this model, ProductInstanceUri, SerialNumber, or both shall be provided for Assets listed directly in the Assets Folder of the AutomationComponent.

• “RevisionCounter is an incremental counter indicating the number of times the configuration data within an Asset has been modified.”

• Within this model, this configuration data may be one of the items defined in this document, but more likely, it is a configuration item that has been added to the asset model either as part of a companion specification or as part of an instance.

The following two definitions are from the ITagNameplateType interface. They are enclosed in quotes and included here for clarity. Their formal definition is in OPC 10000-100. Additional notes are provided for recommended usage within OPC UA FX.

“AssetId is a user-writable alphanumeric character sequence uniquely identifying a component. The ID is provided by the integrator or user of the device. It typically contains an identifier in a branch use case or a user-specific naming scheme. This could be, for example, a reference to an electric scheme.“

“ComponentName is a user-writable name provided by the integrator or user of the component.”

The following two definitions are from the IDeviceHealthType interface. They are enclosed in quotes and included here for clarity. Their formal definition is in OPC 10000-100. Additional notes are provided for recommended usage within OPC UA FX.

“The DeviceHealthEnumeration DataType is an enumeration that defines the device condition.”

“DeviceHealthAlarms shall be used for instances of the DeviceHealth AlarmTypes specified in OPC 10000-100.” AlarmType instances can also be defined in other specifications, such as OPC 10000-110 or this document.

The IDeviceHealthType Interface shall be implemented on top-level Assets and any other Assets that maintain their own status information. DeviceHealth of the top-level Assets is aggregated into AggregatedDeviceHealth (see 9.1.2). Whether nested Assets aggregate their DeviceHealth into DeviceHealth of their parent Asset is vendor-specific and is further described in OPC 10000-110 (e.g., for redundant nested Assets, one might fail without the parent Asset failing).

SoftwareUpdate is an AddIn (see OPC 10000-100) that defines support for firmware or software updates. This optional AddIn should be included in any Asset that includes firmware or software that can be upgraded or changed. For a definition of the AddIn concept, see OPC 10000-3.

The following definitions are associated with the IAssetRevisionType interface (see 7.3).

The MajorAssetVersion shall be updated for major changes in an Asset that may break compatibility with previous versions.

The MinorAssetVersion shall be updated for minor changes in an Asset that should not change the behaviour of the Asset regarding compatibility. Higher numeric values of MinorAssetVersion should be backwards compatible with lower ones, e.g., behaviour that is present in MinorAssetVersion 12 shall still be supported by MinorAssetVersion 13 or greater. An incremented MinorAssetVersion may add new behaviour which is not present in a lower MinorAssetVersion while retaining existing functionality.

The BuildAssetNumber and SubBuildAssetNumber reflect detailed information about the version of the Asset. Together with the MajorAssetVersion and MinorAssetVersion, they provide the capability to unambiguously identify a specific version of an Asset.

The following definitions are associated with the IAssetExtensionsType interface (see 7.4).

Connectors is a Folder used to group and list physical- or software-based connectors (instances of AssetConnectorType) that can be used to link multiple Assets. A connector provides more information about an Asset connection than a simple Reference can. For a formal definition of the AssetConnectorType, see 6.3.4.

Diagnostics is a FunctionalGroup (Folder) that contains Variables that report diagnostic statistics and counters (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

The UpTime Variable provides the module's uptime since the last power-on.

The CurrentCPUUtilization Variable provides the current CPU utilisation in percent (the calculation is vendor-specific).

The MaxCPUUtilization Variable provides the maximum CPU utilisation in percent since the last power-on (the calculation is vendor-specific).

The CurrentMemoryUtilization Variable provides the current memory utilisation in percent (the calculation is vendor-specific).

The MaxMemoryUtilization Variable provides the maximum memory utilisation in percent since the last power-on (the calculation is vendor-specific).

6.3.3 VerifyAsset method

The VerifyAsset Method allows a Client to verify whether an Asset’s identity and functionality meet the expectations of system engineering.

Three different modes are available for Asset verification (see VerificationMode). Each mode depends on a set of mandatory and optional Variables (see definition of AssetVerificationModeEnum in 10.4) to be present for verification. The VerifyAsset Method also accepts additional Variables for verification.

An Asset implementing the VerifyAsset Method shall at least support the VerificationMode AssetCompatibility and expose the corresponding mandatory and implemented optional Variables in its Information Model. If at least one of the optional Variables, SerialNumber and/or ProductInstanceUri, is provided, then the VerificationModes AssetIdentity and AssetIdentityAndCompatibility shall be supported.

The signature of this Method is specified below; the arguments are defined in Table 31.

Signature

	VerifyAsset (
	[in] 2:AssetVerificationModeEnum	VerificationMode,
	[in] 0:KeyValuePair[]			ExpectedVerificationVariables,
	[in] 2:NodeIdValuePair[]			ExpectedAdditionalVerificationVariables,
	[out] 2:AssetVerificationResultEnum	VerificationResult,
	[out] 0:StatusCode[]			VerificationVariablesErrors,
	[out] 0:StatusCode[]			VerificationAdditionalVariablesErrors
	);
	

The possible Method result codes are formally defined in Table 32. The order in which checks are performed is vendor-specific. A bad result code in the Method (an error code in Table 32) shall result in all output arguments listed in the Method signature being empty/null. The check of provided Variables (Bad_InvalidArgument) shall take precedence over the actual checks related to the values of provided Variables.

The VerificationVariablesErrors StatusCodes are formally defined in Table 33.

The VerificationAdditionalVariablesErrors StatusCodes are formally defined in Table 34.

The VerifyAsset Method representation in the AddressSpace is formally defined in Table 35.

6.3.4 AssetConnectorType definition

The AssetConnectorType provides information about physical connections that are part of an Asset. An example of these connections might be slots in which cards can be mounted or sockets to which cables can be connected. For additional examples, see Annex D. It is expected that subtypes of this type that provide or require additional Properties or Variables will be created. Figure 22 provides an illustration of the AssetConnectorType.

The AssetConnectorType is an abstract type and must be subtyped. It is formally defined in Table 36.

Id provides the (physical) ID of the connector, representing the physical location of the connector in the Asset. The use of this ID can be further explained or defined in subtypes.

Name provides the physical label that is associated with this connector. The use of Name can be further explained or defined in subtypes. For example, it might be the name of the target of this connector, the DisplayName would be slot1, and the Name would be Pump1.

Figure 23 provides an illustration of some of the possible subtypes of the AssetConnectorType.

Some connector types are used to link other Assets, while other AssetConnectorTypes might be used to indicate physical connections.

6.3.5 SlotType definition

The SlotType represents a physical slot to which a module can be attached, e.g., in a modular Asset like a PLC backplane or modular IO device.

The SlotType is formally defined in Table 37.

Id is from AssetConnectorType and is mandatory in SlotType. It shall start at 1 and increment by 1 for each physical slot in a rack or device.

The optional LogicalId represents the “logical slot number” that might be assigned to a physical ID. For example, module 3 is physically plugged into slot 3, but internally it is used as slot 8.

Each Slot that has a module plugged into it shall have a HasPhysicalComponent Reference (see OPC 10000-23) or a subtype of it, or an IsPhysicallyConnectedTo Reference or a subtype of it, indicating the Asset that occupies the Slot.

6.3.6 SocketType definition

The SocketType represents a physical socket where a cable can be connected.

The SocketType is formally defined in Table 38.

Name is from AssetConnectorType and is mandatory in SocketType. It represents the label that would be associated with a Socket.

The optional Kind is a MultiStateValueDiscreteType that describes the type of socket, e.g., RJ-45 or M12. The MultiStateValueDiscreteType has two properties: EnumValues and ValueAsText. An enumeration (SocketKindEnum) is defined (see 10.47) that provides a default list of Kind values. The configured list of EnumValues for a Socket can use the list provided by the default enumeration, extend the default list, or create its own list of EnumValues. A companion specification may define a different or extended list of Kind EnumValues.

6.3.7 ClampType definition

The ClampType represents a wire connection, such as a twisted pair or single wire connection, where the wire needs to be connected to some termination connection.

The ClampType is formally defined in Table 39.

Name is from AssetConnectorType and is mandatory in ClampType.

The optional Kind is a MultiStateValueDiscreteType that describes the type of clamp, e.g., screw connector, thumb connector, etc. The MultiStateValueDiscreteType has two properties: EnumValues and ValueAsText. An enumeration is defined (see 10.8) that provides a default list of Kind EnumValues. The configured list of EnumValues for a Clamp can use the default list, can extend the default list, or can create its own list of EnumValues. A companion specification may define a different or extended list of Kind EnumValues.

6.3.8 ClampBlockType definition

The ClampBlockType represents a wire connection block, where the block contains a number of termination points for twisted pair or single wire connections.

The ClampBlockType is formally defined in Table 40.

Name is from AssetConnectorType and is mandatory in ClampBlockType.

The optional BlockSize is the maximum number of clamps that this block can support.

The optional Kind is a MultiStateValueDiscreteType that describes the type of clamp, e.g., screw connector, thumb connector, etc. The MultiStateValueDiscreteType has two properties: EnumValues and ValueAsText. An enumeration is defined (see 10.8) that provides a default list of Kind EnumValues. The configured list of EnumValues for a ClampBlock can use the list provided by the default EnumValues, extend the default list, or create its own list of EnumValues. A companion specification may define a different or extended list of Kind EnumValues.

<Clamp> are entries for each Clamp that is in use with the details of that specific clamp in the block.

6.4 FunctionalEntityType definition

6.4.1 Overview

FunctionalEntityType is the base type for the definition of all functionality in an OPC UA FX Information Model. A FunctionalEntity can provide InputData, OutputData, ConfigurationData, diagnostic information and Methods for manipulating or sharing the data. It is expected that other models will subtype the FunctionalEntityType. It can have SubFunctionalEntities and relationships to other Objects defined in this model or other models. A FunctionalEntity may be implemented using the IFunctionalEntityType Interface. It does not need to be an instance of FunctionalEntityType or an instance of a subtype of FunctionalEntityType.

The FunctionalEntityType is illustrated in Figure 24.

6.4.2 FunctionalEntityType definition

The FunctionalEntityType is formally defined in Table 41. Most of this ObjectType is obtained from the IFunctionalEntityType Interface (see 7.2). The description of the components and properties in a FunctionalEntityType is in this clause; the IFunctionalEntityType only references this clause. For examples of extending FunctionalEntityType or utilising it in an existing model, see Annex B. Annex C provides a description of how to apply SafetyData to FunctionalEntities.

The components of the FunctionalEntityType have additional subcomponents, which are defined in Table 42.

The FunctionalEntityType is a base ObjectType. It is expected that companion specifications or vendors will define subtypes of FunctionalEntityType. Subtypes will define additional Variables that would exist in InputData, OutputData and ConfigurationData. The subtypes might also add Objects and Methods or define nested FunctionalEntityType instances. In addition, the information in the FunctionalEntityType may be directly used in an existing ObjectType, either via the AddIn concept or the Interface concept defined in OPC 10000-3. For an illustration of how this can be accomplished, see B.3.

The optional AuthorUri is a string that is a URI that resolves to the website of the company responsible for this FunctionalEntity.

The optional AuthorAssignedIdentifier provides a unique code used to identify the author-defined type of this FunctionalEntity. This Property is maintained by the author. The semantic of the AuthorAssignedIdentifier is author-specific.

The optional AuthorAssignedVersion provides the version of this FunctionalEntity. The semantic of the AuthorAssignedVersion is author-specific. This identifier is provided to allow additional information beyond what the AuthorAssignedIdentifier provides. For example, some authors might have more than one version of the motor controller model or the PID controller algorithm.

The optional ApplicationIdentifier – provides application information consisting of two properties: a localised Name that is intended to be human-readable and a unique identifier that is intended to be machine-readable. For a definition of the ApplicationIdentifierDataType, see 10.3. The ApplicationIdentifier shall be used as follows:

Name provides the name of the application in which this FunctionalEntity is used. The name is given by the system integrator, manufacturer or end-user that created the application.

UniqueIdentifier provides a unique identifier for the application in which FunctionalEntity is used. UniqueIdentifier is maintained by the creator of the identifier. This field is of ApplicationId DataType to allow the creator to create any type of identifier. An ApplicationId DataType allows the field to contain a string, integer, GUID, or ByteString. It is up to the creator of the identifier to choose which of these types is used.

The optional ApplicationIdentifier is specified as an array since it may indicate multiple levels of application and thus have multiple values. For example, the product vendor of an advanced alarm control creates a FunctionalEntity and assigns to it an identifier. A system integrator customises it with settings for boiler alarming and assigns an additional identifier. The end-user may further deploy an instance of the configured FunctionalEntity on “Boiler #5” and provide an additional identifier.

The optional InputData provides a grouping of information in this FunctionalEntity. It provides a reference to all data that this FunctionalEntity can use as input to its processing. The InputsFolderType is defined in 6.4.4.

The optional OutputData provides a grouping of information in this FunctionalEntity. It provides a reference to all data that this FunctionalEntity can use as output from its processing. The OutputsFolderType is defined in 6.4.5.

The optional ConfigurationData provides a grouping of information in this FunctionalEntity into logical groupings that are considered configuration information (for additional information, see 5.4). The ConfigurationDataFolderType is defined in 6.4.6.

The ConfigurationData Folder may also contain two FunctionalGroups (Configuration or Tuning) to further organise configuration information.

The optional Configuration FunctionalGroup contains Variables representing the configuration items of the FunctionalEntity (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

The optional Tuning FunctionalGroup contains Variables that can be used to optimise the behaviour of the FunctionalEntity (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

The optional Capabilities is a FunctionalEntityCapabilitiesType Folder that describes the functionality provided by a FunctionalEntity (see 6.4.7).

The optional PublisherCapabilities provide the Publisher capabilities associated with this FunctionalEntity. They also apply to all sub-FunctionalEntities of this FunctionalEntity. The PublisherCapabilities for the FunctionalEntity shall describe additional restrictions of the PublisherCapabilities defined in the AutomationComponent. It can also be further restricted by the PublisherCapabilities provided in OutputData (see 6.4.5) or a sub-FunctionalEntity. The restrictions for a sub-FunctionalEntity only apply if the Connection is established with the sub-FunctionalEntity or if OutputData defined in the sub-FunctionalEntity are part of the Connection. If a Connection utilises data from multiple sub-FunctionalEntities and the requested settings do not meet the PublisherCapabilities of all utilised sub-FunctionalEntities, a Server shall report an error (Bad_ConfigurationError). If an entry is an empty array, then it shall not change the settings defined in the AutomationComponent (or FunctionalEntity if defined in a sub-FunctionalEntity).

The optional SubscriberCapabilities provide the Subscriber capabilities associated with this FunctionalEntity. They also apply to all sub-FunctionalEntities of this FunctionalEntity. The SubscriberCapabilities for the FunctionalEntity shall describe additional restrictions of the SubscriberCapabilities defined in the AutomationComponent. It can also be further restricted by the SubscriberCapabilities provided in InputData (see 6.4.4) or a sub-FunctionalEntity. The restrictions for a sub-FunctionalEntity only apply if the Connection is established with the sub-FunctionalEntity or if InputData defined in the sub-FunctionalEntity are part of the Connection. If a Connection utilises data from multiple sub-FunctionalEntities and the requested settings do not meet the SubscriberCapabilities of all utilised sub-FunctionalEntities, a Server shall report an error (Bad_ConfigurationError).. If an entry is an empty array, then it shall not change the settings defined in the AutomationComponent (or FunctionalEntity if defined in a sub-FunctionalEntity).

The ConnectionEndpoints Folder provides a container for all Connection-related information that this FunctionalEntity might contain. For details on the ConnectionEndpointsFolderType, see 6.4.8. For details on the ConnectionEndpointType that this Folder contains, see 6.6. If the FunctionalEntity does not expose ConnectionEndpoints, the Folder may be missing.

The ControlGroups Folder provides a container for all ControlGroupType instances this FunctionalEntity might contain. For the concepts, see 5.3. For details on the ControlGroupsFolderType, see 6.4.9. For details on the ControlGroupType that this Folder contains, see 6.5.

The optional OperationalHealth indicates the operational health of the FunctionalEntity. It aggregates the health of its SubFunctionalEntities and the health of ConnectionEndpoints. For the definition of the OperationalHealthOptionSet, see 10.34.

The aggregation rules are defined as follows:

SubOperationalWarning is set to TRUE if at least one SubFunctionalEntity has OperationalWarning or SubOperationalWarning set to TRUE.

SubOperationalError is set to TRUE if at least one SubFunctionalEntity has OperationalError or SubOperationalError set to TRUE.

The lower 16 bits of OperationalHealth are set to the result of a logical OR of CommHealth in the ConnectionEndpoints Folder of the FunctionalEntity, and the lower 16 bits of the OperationalHealth of all SubFunctionalEntities.

All top-level FunctionalEntities shall implement OperationalHealth. The OperationalHealth of the top-level FunctionalEntities is aggregated into the AggregatedOperationalHealth (see 9.1.2) Variable of the AggregatedHealth Variable in the AutomationComponent (see 6.2.2).

The optional OperationalHealthAlarms Folder shall be restricted to hold only instances of Alarms. No UAFX-specific Alarms are defined in this release, but base OPC UA Alarms can be used. In future versions of this document, UAFX-specific Alarms will be defined.

The Operational FunctionalGroup contains Variables and Methods useful during normal operation, like process data (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

The Status FunctionalGroup contains Variables which describe the general health of the FunctionalEntity (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

The Diagnostics FunctionalGroup contains Variables and Methods for diagnostics. For UAFX, this includes diagnostics defined by UAFX (see OPC 10000-100 Recommended FunctionalGroup BrowseNames).

The optional <SubFunctionalEntity> allows for the nesting of FunctionalEntities. A FunctionalEntity can have any number of SubFunctionalEntities. SubFunctionalEntities are identified by the HasSubFunctionalEntity ReferenceType. They may be of FunctionalEntityType or another ObjectType that implements the IFunctionalEntityType Interface.

The OperationalConnectionCount provides the number of current ConnectionEndpoints with a Status of Operational in this FunctionalEntity.

The ExistingConnectionCount provides the number of ConnectionEndpoints that currently exist in this FunctionalEntity.

The ErrorConnectionCount provides the number of current ConnectionEndpoints with a Status of Error in this FunctionalEntity.

The FailedConnectionCount provides the number of transitions to the Error state for any ConnectionEndpoint in this FunctionalEntity.

The CleanedUpConnectionCount provides the number of ConnectionEndpoints that have been removed due to the expiration of the CleanupTimeout in this FunctionalEntity.

The TotalEstablishAttemptsCount provides the total number of attempts to create a ConnectionEndpoint that failed or succeeded in this FunctionalEntity.

The FailedEstablishAttemptsCount provides the total number of attempts to create a ConnectionEndpoint that failed due to an error in this FunctionalEntity.

The FailedVerificationCount provides the number of calls to Verify that returned a bad StatusCode in this FunctionalEntity.

6.4.3 Verify method

The Verify Method allows a Client to verify whether a FunctionalEntity meets the expectation of system engineering (e.g., whether it is of the expected author, but also if it implements any optional Variables required by a Client application). It also supports verifying any Variables defined by the application. The Verify Method should process all provided NodeIdValuePairs, but it is also acceptable to stop processing on the first NodeIdValuePair that results in a Mismatch or NotSet.

The signature of this Method is specified below; the arguments are defined in Table 43.

Signature

	Verify (
	[in] 2:NodeIdValuePair[]				ExpectedVerificationVariables,
	[out] 2:FunctionalEntityVerificationResultEnum	VerificationResult,
	[out] 0:StatusCode[]				VerificationVariablesErrors
	);

The Method result codes are formally defined in Table 44.

The VerificationVariablesErrors StatusCodes are formally defined in Table 45.

The Verify Method representation in the AddressSpace is formally defined in Table 46.

6.4.4 InputsFolderType

The InputsFolderType is a subtype of the FolderType defined in OPC 10000-5.

The InputsFolderType is formally defined in Table 47.

The InputsFolderType provides for the grouping of input variables. It shall be restricted to hold only Variables, SubscriberCapabilities or nested <InputGroup>. The InputsFolder may be empty.

The optional SubscriberCapabilities shall only be present on InputData of the FunctionalEntity. It provides the Subscriber capabilities associated with the InputData and describes additional restrictions of the SubscriberCapabilities defined in the FunctionalEntity or AutomationComponent. The restrictions for InputData only apply if the Connection is established with Variables referenced in InputData or any subfolders. If an entry is an empty array, then it shall not change the settings defined in the AutomationComponent, FunctionalEntity or if defined in a sub-FunctionalEntity.

<InputGroup> allows for the nesting of Folders. Nested instances can be used to create a structure of input groups.

<InputVariable> is a reference to input Variables in this FunctionalEntity. The Variables shall be Organized in this Folder, or the Folder shall reference the Variable via subtypes of the HasChild Reference (HasProperty, HasComponent or other subtypes). The BrowseNames of Variables in this Folder shall be unique within this Folder; the use of nested <InputGroup> can be used to help accomplish this.

When using PubSub for periodic data with a fixed layout, Strings, ByteStrings, and variable-size arrays can cause problems. Without a defined maximum size for the Variables in a data packet, the fixed size of the data packet cannot be calculated. If using PubSub periodic data with a fixed layout, then the following apply:

Any Variables that are included in this Folder that have a DataType of String shall include a MaxStringLength property.

Any Variables that are included in this Folder that have a DataType of ByteString shall include a MaxByteStringLength property.

It is also recommended that any arrays be defined to have fixed dimensions.

6.4.5 OutputsFolderType

The OutputsFolderType is a subtype of the FolderType defined in OPC 10000-5.

The OutputsFolderType is formally defined in Table 48.

The OutputsFolderType provides for the grouping of output variables. It shall be restricted to hold only Variables, PublisherCapabilities or nested <OutputGroup>. The OutputsFolder may be empty.

The optional PublisherCapabilities shall only be present on OutputData of the FunctionalEntity. It provides the Publisher capabilities associated with the OutputData and describes additional restrictions of the PublisherCapabilities defined in the FunctionalEntity or AutomationComponent. The restrictions for OutputData only apply if the Connection is established with Variables referenced in OutputData or any subfolders. If an entry is an empty array, then it shall not change the settings defined in the AutomationComponent, FunctionalEntity or if defined in a sub-FunctionalEntity.

<OutputGroup> allows for the nesting of Folders. Nested instances can be used to create a structure of output groups.

<OutputVariable> is a reference to output Variables in this FunctionalEntity. The Variables shall be Organized in this Folder, or the Folder shall reference the Variable via subtypes of the HasChild Reference (HasProperty, HasComponent or other subtypes). The BrowseNames of Variables in this Folder shall be unique within this Folder; the use of nested <OutputGroup> can be used to help accomplish this.

When using PubSub for periodic data with a fixed layout, Strings, ByteStrings, and variable-size arrays can cause problems. Without a defined maximum size for the Variables in a data packet, the fixed size of the data packet cannot be calculated. If using PubSub periodic data with a fixed layout, then the following apply:

Any Variables that are included in this Folder that have a DataType of String shall include a MaxStringLength property.

Any Variables that are included in this Folder that have a DataType of ByteString shall include a MaxByteStringLength property.

It is also recommended that any arrays be defined to have fixed dimensions.

6.4.6 ConfigurationDataFolderType

6.4.6.1 Overview

The ConfigurationDataFolderType is used to organise ConfigurationData Variables and provides the Methods for supporting the storage of Variables (see 5.4). A ConfigurationDataFolder may contain sub-Folders derived from FunctionalGroupType.

The ConfigurationDataFolderType is illustrated in Figure 25.

6.4.6.2 ConfigurationDataFolderType definition

The ConfigurationDataFolderType extends the FunctionalGroupType defined in OPC 10000-100.

The ConfigurationDataFolderType is formally defined in Table 49.

<ConfigurationVariable> represents the optional configuration data. The Variables in this Folder shall be Organized in this Folder, or the Folder shall reference the Variables via subtypes of the HasChild Reference (HasProperty, HasComponent or other subtypes). The BrowseNames of Variables in this Folder shall be unique within this Folder. All Variables in this folder shall be configuration data.

The FunctionalGroupType, as defined in OPC 10000-100, includes the ability to have nested FunctionalGroups. It is expected that configuration data will often be organised into a tree of FunctionalGroups. This will also assist with the uniqueness requirement for BrowseNames.

The optional Methods SetStoredVariables, ClearStoredVariables, and ListStoredVariables allow for the maintenance of storage for configuration Variables. If storage is supported, SetStoredVariables, ClearStoredVariables, and ListStoredVariables shall be supported.

6.4.6.3 SetStoredVariables method

The optional SetStoredVariables Method allows a Client to store current values of configuration Variables for the FunctionalEntity and its SubFunctionalEntities.

The FunctionalEntity shall apply the stored values to the configuration variables after a power cycle.

The signature of this Method is specified below; the arguments are defined in Table 50.

Signature

	SetStoredVariables (
	  [in] 0:NodeId[]		VariablesToStore,
	  [out] 0:StatusCode[]	Results
	);

The possible Method result codes are formally defined in Table 51.

The Results StatusCodes are formally defined in Table 52.

The SetStoredVariables Method representation in the AddressSpace is formally defined in Table 53.

6.4.6.4 ClearStoredVariables Method

The optional ClearStoredVariables Method allows a Client to clear the Variable from the list of Variables that are to be restored.

The signature of this Method is specified below; the arguments are defined in Table 54.

Signature

	ClearStoredVariables (
	  [in] 0:NodeId[]		VariablesToClear,
	  [out] 0:StatusCode[]	Results
	);

The possible Method result codes are formally defined in Table 55.

The Results StatusCodes are formally defined in Table 56.

The ClearStoredVariables Method representation in the AddressSpace is formally defined in Table 57.

6.4.6.5 ListStoredVariables

The optional ListStoredVariables Method allows a Client to list the Variables that are currently in storage.

The signature of this Method is specified below; the arguments are defined in Table 58.

Signature

	ListStoredVariables (
	  [out] 2:NodeIdValuePair[]		StoredVariables
	);

The ListStoredVariables Method representation in the AddressSpace is formally defined in Table 59.

6.4.7 FunctionalEntityCapabilitiesType

The FunctionalEntityCapabilitiesType extends the FolderType defined in OPC 10000-5. It shall be restricted to holding only Variables that reflect the capabilities of the FunctionalEntity.

The FunctionalEntityCapabilitiesType is formally defined in Table 60.

<Capability> - is an OptionalPlaceholder (defined in OPC 10000-3 ) to indicate that additional capabilities may be added by this document, by a companion specification or by a vendor application. These capabilities shall include a Description, and they follow all of the rules associated with an OptionalPlaceholder.

If the optional FeedbackSignalRequired is present and set to TRUE, the FunctionalEntity requires a feedback signal for all Connections. A feedback signal is represented by the reception of either data or a heartbeat. The following connection types (see 5.5.1) support feedback: bidirectional, unidirectional with heartbeat, unidirectional Subscriber, and autonomous Subscriber. If FeedbackSignalRequired is missing or set to FALSE, the connection types unidirectional Publisher and autonomous Publisher are also supported.

6.4.8 ConnectionEndpointsFolderType

The ConnectionEndpointsFolderType extends the FolderType defined in OPC 10000-5. It shall be restricted to hold only instances of ConnectionEndpointType or subtypes of ConnectionEndpointType. It may be empty.

The ConnectionEndpointsFolderType is formally defined in Table 61.

The optional CommHealth aggregates the Status of all ConnectionEndpoints contained in the Folder. The aggregation rules are defined as follows:

If at least one ConnectionEndpoint established at this FunctionalEntity has its Status set to Error, the CommHealth CommError bit shall be set.

If at least one ConnectionEndpoint established at this FunctionalEntity has its Status set to Initial, the CommHealth CommInitial bit shall be set.

If at least one ConnectionEndpoint established at this FunctionalEntity has its Status set to PreOperational, the CommHealth CommPreOperational bit shall be set.

For the definition of the CommHealthOptionSet, see 10.9.

6.4.9 ControlGroupsFolderType

The ControlGroupsFolderType extends the FolderType defined in OPC 10000-5. It shall be restricted to holding only instances of ControlGroupType (see 6.5). The ControlGroupsFolder may be empty.

The ControlGroupsFolderType is formally defined in Table 62.

6.5 ControlGroupType

6.5.1 Overview

The ControlGroupType is used to manage the control of the functionality provided by a FunctionalEntity or part of it. ControlGroups are used when some part of a FunctionalEntity is to be “controlled” by another FunctionalEntity or application. ControlGroups can be used by an application to help understand how the Variables (inputs, outputs, configuration) and Methods are logically related to each other in the application. ControlGroups utilise the LockingServices defined in OPC 10000-100. The ControlGroupType is illustrated in Figure 26.

6.5.2 ControlGroupType definition

ControlGroups are part of the FunctionalEntity model and are independent of any communication model (Client Server, PubSub, etc.). A ControlGroup is used to identify the usage of parts of the FunctionalEntity. ControlGroups may result in a restriction on the grouped items. The restriction can include Objects (input and configuration Variables) and Method invocations. The restriction can block all changes to Variables or restrict changes to only the lock-owner (application or user). The lock-owner of the restrictions may be unrelated to the caller of the EstablishControl Method.

A Variable, Object, or Method may be referenced from more than one ControlGroup. Multiple ControlGroups might exist with different combinations.

ListToRestrict and ListToBlock each have their own instances of LockingServices. When a ControlGroup is assigned to a user or application, the Variables or Methods in ListToBlock or ListToRestrict are associated with that user or application (that user or application becomes the lock owner). The LockingServices exposed in ListToBlock and ListToRestrict (InitLock, RenewLock, ExitLock) can only be called by the lock-owner. An administrative user with appropriate rights may override a Lock and release it.

The ControlGroup also exposes EstablishControl, ReassignControl, and ReleaseControl Methods. EstablishControl will acquire the Lock for both ListToRestrict and ListToBlock. ReassignControl can be used to change the lock owner to a different user or application. ReleaseControl will release the Lock. A user or application different from the lock owner shall not be able to successfully call EstablishControl on another ControlGroup that references the same Variables or Methods in ListToBlock or ListToRestrict.

The EstablishConnections Method supports commands to establish control (EstablishControlCmd) and reassign control (ReassignControlCmd). The CloseConnections Method will release any Locks that may have been acquired as part of connection establishment. The functionality provided by EstablishConnections (ReassignControlCmd) and CloseConnections is the same as that provided by the individual Methods in the ControlGroup, except they operate on the Locks as the lock-owner. If a ControlGroup is assigned to a ConnectionEndpoint, only those having the rights to call EstablishConnections or CloseConnections can reassign or release control (i.e., the EstablishConnections and CloseConnections Methods act as the ConnectionEndpoint).

One or more Clients may call EstablishControl on separate ControlGroups that do not share any Variables or Methods (in ListToRestrict or ListToBlock). For examples of ControlGroups, see Annex D.3.

The FunctionalEntity may provide Variables in its InputData, OutputData and ConfigurationData Folders. A ControlGroup may include any combination of the input, output, and configuration Variables from the FunctionalEntity. A FunctionalEntity may provide information in InputData, OutputData and ConfigurationData that are not part of any ControlGroup.

ControlGroups are primarily used for locking, but they may also be used to merely provide a subset of FunctionalEntity configuration related to a specific described set of controls. The described grouping of functionality may be nested to allow further organisation of the functionality. For example, a simple PID may be modelled as a FunctionalEntity; it can be run in cascade mode where another FunctionalEntity provides the setpoint input, or it can allow an operator to enter setpoints via an HMI. In this case, two ControlGroups could be provided by the PID FunctionalEntity, and the choice of ControlGroup would lock the functionality into a specific mode. More complex FunctionalEntities might also restrict which ControlGroups are available based on configuration settings.

The ControlGroupType is formally defined in Table 63.

ListToBlock is a group of items that are to be blocked from any changes to Variables or executing Methods. This could be any Variables or Methods in the hierarchical structure of instances in the FunctionalEntity. Once an EstablishControl Call is made, the values of Variables in this list can no longer be modified, and Methods in this list can no longer be executed.

ListToRestrict is a group of items that are to be restricted to allow only the lock owner (see OPC 10000-100) to change Variables or execute Methods. This could be any Variables or Methods in the hierarchical structure of instances in the FunctionalEntity.

ListOfRelated is a group of items that are part of the ControlGroup that are not blocked or restricted (i.e., it is Objects, Variables, Methods).

A Variable, Method or Object shall not be included in more than one of the lists within a ControlGroup.

IsControlled is a flag that indicates if the ControlGroup is currently controlled. When this bit is set, the controlling entity can be determined by following the Controls Reference or by the information in the Lock Object (i.e., the Lock LockingClient) in either the ListToRestrict Folder or the ListToBlock Folder.

The optional EstablishControl Method invokes the LockingServices in both the ListToBlock and ListToRestrict groups. The Lock LockingClient is set to the LockContext parameter unless this parameter is a null String, in which case it is set to the ApplicationUri of the Client connection used to call this Method.

The optional ReassignControl Method will assign all active Locks in the ControlGroup to a different LockingClient.

The Locks can be assigned to a ConnectionEndpoint. In this case, the following applies:

• All Locks automatically call the ExitLock Method if the associated ConnectionEndpoint is being removed.

• The Lock LockingUser shall be set to “UAFX”.

• The Locks are automatically renewed as long as the Status of the ConnectionEndpoint is different from Error.

• A Controls Reference (see OPC 10000-23) shall be added with a SourceNode of the ConnectionEndpoint and the TargetNode of the ControlGroup.

If the lock is assigned to the Client connection, the Controls Reference (see OPC 10000-23) shall have a SourceNode of the Object associated with the Client connection (see OPC 10000-100) and a TargetNode of the ControlGroup.

The optional ReleaseControl Method calls the ExitLock Method on all established Locks and removes the Controls Reference. It also clears the IsControlled flag.

Calling the ExitLock Method on the Locks does not affect the IsControlled flag and associated Controls Reference; it will only release the Lock on the given group of items (ListToBlock, ListToRestrict).

The LockingServices provide a system-wide MaxInactiveLockTime, which a local MaxInactiveLockTime can overwrite in each lock Folder. If the CleanupTimeout is different for each Connection, then a local MaxInactiveLockTime should be specified and related to the ConnectionEndpoint CleanupTimeout. It is important to understand that this timeout will be used to timeout locks and thus must be larger than the CleanupTimeout if a lock is not to be removed before a Connection is removed. The system-wide MaxInactiveLockTime may be used for other applications or deployments of LockingServices, so care should be exercised if a local MaxInactiveLockTime is not used.

A ControlGroup can contain additional nested ControlGroups. The specified Methods of ControlGroupType shall not be applied to any nested ControlGroups.

6.5.3 EstablishControl method

This Method shall acquire Locks required by the ControlGroup in the ListToRestrict and ListToBlock. If acquiring any Lock fails, all Locks shall be released, and the appropriate LockStatus shall be returned. If all required Locks can be acquired, the Method shall set the IsControlled flag and create the Controls Reference.

It is recommended that this Method be restricted to Client connections that have the well-known Role ConnectionAdmin as defined in Clause 5.9.

EstablishControl shall set Lock LockingClient to the LockContext Argument.