Introduction

The following table includes new features and the Mantis issues resolved with this revision.

1 Scope

This document OPC 30090 was created by a joint working group of the OPC Foundation and the FDT Group. It defines an OPC UA Information Model to represent the FDT architectural models. The OPC UA Information Model for FDT represents device information which is provided based on FDT/DTMs.

OPC Foundation

OPC is the interoperability standard for the secure and reliable exchange of data and information in the industrial automation space and in other industries. It is platform independent and ensures the seamless flow of information among devices from multiple vendors. The OPC Foundation is responsible for the development and maintenance of this standard.

OPC UA is a platform independent service-oriented architecture that integrates all the functionality of the individual OPC Classic specifications into one extensible framework. This multi-layered approach accomplishes the original design specification goals of:

Platform independence: from an embedded microcontroller to cloud-based infrastructure

Secure: encryption, authentication, authorization and auditing

Extensible: ability to add new features including transports without affecting existing applications

Comprehensive information modelling capabilities: for defining any model from simple to complex

FDT Group

The FDT Group’s mission is to promote, enhance and support the usage of FDT Technology in Factory Automation, Process Automation and Hybrid Applications, to preserve end users’ and automation manufacturers’ investments by providing state-of-the-art technology that is fully backward compatible, to ensure stability, interoperability and compatibility of FDT based products by ensuring that they are rigorously tested and certified and to continuously maintain the FDT standard consistent with leading-edge technology.

FDT standardizes the communication and configuration interface between all field devices and host systems. FDT provides a common environment for accessing the devices’ most sophisticated features. Any device can be configured, operated, and maintained through the standardized user interface – regardless of supplier, type or communication protocol.

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.

FDT®2.0 Technical Specification, Version 1.01.01,

https://www.fdtgroup.org/resources/?category=fdt-2-1-specifications OPC 10000-1

FDT®3.0 Technical Specification, Version 1.00.00,

https://www.fdtgroup.org/resources/?category=fdt-3-0-specifications

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

OPC 10000-1

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

OPC 10000-3

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

OPC 10000-4

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

OPC 10000-5

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

OPC 10000-6

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

OPC 10000-7

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

OPC 10000-100

3 Terms, abbreviated terms and conventions

3.1 Overview

It is assumed that basic concepts of OPC UA information modelling and FDT specification are understood in this document. This document will use these concepts to describe the OPC UA for Field Device Tool (FDT) Information Model. For the purposes of this document, the terms and definitions given in OPC 10000-1, OPC 10000-3, OPC 10000-4, OPC 10000-5, OPC 10000-7, OPC 10000-100, FDT Specification as well as the following apply.

Note that OPC UA terms and terms defined in this document are italicized in the document.

3.2 Abbreviated terms

3.3 Conventions used in this document

3.3.1 Document conventions

Throughout this document certain document conventions are used.

Italics are used to denote a defined term or definition that appears in the “Terms and definition” clause in this document or in one of the referenced OPC UA documents.

Italics are also used to denote the name of a service input or output parameter or the name of a structure or element of a structure that are usually defined in tables.

3.3.2 Conventions for FDT methods

FDT defines synchronous methods and asynchronous methods. Asynchronous methods are implemented with a set of methods. For example an asynchronous method <MethodName> is implemented with Begin<MethodName>(), Cancel<MethodName>(), and End<MethodName>().

In this document asynchronous methods are indicated by ‘<>’ in front of the name (e.g. <>MethodName).

3.3.3 Conventions for Node descriptions

3.3.3.1 Node definitions

Node definitions are specified using tables (see Table 2).

Attributes are defined by providing the Attribute name and a value, or a description of the value.

References are defined by providing the ReferenceType name, the BrowseName of the TargetNode and its NodeClass.

• If the TargetNode is a component of the Node being defined in the table the Attributes of the composed Node are defined in the same row of the table.

• The DataType is only specified for Variables; “[<number>]” indicates a single-dimensional array, for multi-dimensional arrays the expression is repeated for each dimension (e.g. [2][3] for a two-dimensional array). For all arrays the ArrayDimensions is set as identified by <number> values. If no <number> is set, the corresponding dimension is set to 0, indicating an unknown size. If no number is provided at all the ArrayDimensions can be omitted. If no brackets are provided, it identifies a scalar DataType and the ValueRank is set to the corresponding value (see OPC 10000-3). In addition, ArrayDimensions is set to null or is omitted. If it can be Any or ScalarOrOneDimension, the value is put into “{<value>}”, so either “{Any}” or “{ScalarOrOneDimension}” and the ValueRank is set to the corresponding value (see OPC 10000-3) and the ArrayDimensions is set to null or is omitted. Examples are given in Table 1.

• The TypeDefinition is specified for Objects and Variables.

• The TypeDefinition column specifies a symbolic name for a NodeId, i.e. the specified Node points with a HasTypeDefinition Reference to the corresponding Node.

• The ModellingRule of the referenced component is provided by specifying the symbolic name of the rule in the ModellingRule column. In the AddressSpace, the Node shall use a HasModellingRule Reference to point to the corresponding ModellingRule Object.

If the NodeId of a DataType is provided, the symbolic name of the Node representing the DataType shall be used.

Note that if a symbolic name of a different namespace is used, it is prefixed by the NamespaceIndex (see 3.3.4.2).

Nodes of all other NodeClasses cannot be defined in the same table; therefore, only the used ReferenceType, their NodeClass and their BrowseName are specified. A reference to another part of this document points to their definition.

Table 2 illustrates the table. If no components are provided, the DataType, TypeDefinition and Other columns may be omitted and only a Comment column is introduced to point to the Node definition.

Components of Nodes can be complex that is containing components by themselves. The TypeDefinition, NodeClass and DataType can be derived from the type definitions, and the symbolic name can be created as defined in 3.3.5.1. Therefore, those containing components are not explicitly specified; they are implicitly specified by the type definitions.

The Other column defines additional characteristics of the Node. Examples of characteristics that can appear in this column are show in Table 3.

If multiple characteristics are defined they are separated by commas. The name or the short name may be used.

3.3.3.2 Additional References

To provide information about additional References, the format as shown in Table 4 is used.

References can be to any other Node.

3.3.3.3 Additional sub-components

To provide information about sub-components, the format as shown in Table 5 is used.

3.3.3.4 Additional Attribute values

The type definition table provides columns to specify the values for required Node Attributes for InstanceDeclarations. To provide information about additional Attributes, the format as shown in Table 6 is used.

There can be multiple columns to define more than one Attribute.

3.3.4 NodeIds and BrowseNames

3.3.4.1 NodeIds

The NodeIds of all Nodes described in this standard are only symbolic names. Annex A defines the actual NodeIds.

The symbolic name of each Node defined in this document is its BrowseName, or, when it is part of another Node, the BrowseName of the other Node, a “.”, and the BrowseName of itself. In this case “part of” means that the whole has a HasProperty or HasComponent Reference to its part. Since all Nodes not being part of another Node have a unique name in this document, the symbolic name is unique.

The NamespaceUri for all NodeIds defined in this document is defined in Annex A. The NamespaceIndex for this NamespaceUri is vendor-specific and depends on the position of the NamespaceUri in the server namespace table.

Note that this document not only defines concrete Nodes, but also requires that some Nodes shall be generated, for example one for each Session running on the Server. The NodeIds of those Nodes are Server-specific, including the namespace. But the NamespaceIndex of those Nodes cannot be the NamespaceIndex used for the Nodes defined in this document, because they are not defined by this document but generated by the Server.

3.3.4.2 BrowseNames

The text part of the BrowseNames for all Nodes defined in this document is specified in the tables defining the Nodes. The NamespaceUri for all BrowseNames defined in this document is defined in 14.2.

For InstanceDeclarations of NodeClass Object and Variable that are placeholders (OptionalPlaceholder and MandatoryPlaceholder ModellingRule), the BrowseName and the DisplayName are enclosed in angle brackets (<>) as recommended in OPC 10000-3.If the BrowseName is not defined by this document, a namespace index prefix is added to the BrowseName (e.g., prefix '0' leading to ‘0:EngineeringUnits’ or prefix '2' leading to ‘2:DeviceRevision’). This is typically necessary if a Property of another specification is overwritten or used in the OPC UA types defined in this document. Table 82 provides a list of namespaces and their indexes as used in this document.

3.3.5 Common Attributes

3.3.5.1 General

The Attributes of Nodes, their DataTypes and descriptions are defined in OPC 10000-3. Attributes not marked as optional are mandatory and shall be provided by a Server. The following tables define if the Attribute value is defined by this document or if it is server-specific.

For all Nodes specified in this document, the Attributes named in Table 7 shall be set as specified in the table.

3.3.5.2 Objects

For all Objects specified in this document, the Attributes named in Table 8 shall be set as specified in the Table 8. The definitions for the Attributes can be found in OPC 10000-3.

3.3.5.3 Variables

For all Variables specified in this document, the Attributes named in Table 9 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.3.5.4 VariableTypes

For all VariableTypes specified in this document, the Attributes named in Table 10 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

3.3.5.5 Methods

For all Methods specified in this document, the Attributes named in Table 11 shall be set as specified in the table. The definitions for the Attributes can be found in OPC 10000-3.

4 General information to FDT and OPC UA

4.1 Introduction to FDT

FDT is a technology supporting the data exchange between field devices and automation systems. The technology is based on an interface specification standardized as IEC 62453. The specification defines two main concepts: Device Type Manager (DTM) and Frame Application. A DTM is a software component specific to a field device type. A Frame Application is a software environment (part of the automation system) for integration of DTMs. Within a Frame Application every DTM provides data and services specific to the respective field device. Since the technology is based on a standardized set of interfaces, every DTM may be integrated in every Frame Application. Based on FDT it is possible to integrate communication devices, communication infrastructure devices (e.g. gateways) and field devices, depending on their communication protocols. Support for different communication protocols is provided by means of supplemental communication protocol specifications (e.g. for PROFINET, PROFIBUS, Ethernet IP, TCP, HART and FF) or by means of manufacturer-specific protocol integration.

4.2 Introduction to OPC Unified Architecture

4.2.1 What is OPC UA?

OPC UA is an open and royalty free set of standards designed as a universal communication protocol. While there are numerous communication solutions available, OPC UA has key advantages:

A state of art security model (see OPC 10000-2).

A fault tolerant communication protocol.

An information modelling framework that allows application developers to represent their data in a way that makes sense to them.

OPC UA has a broad scope which delivers for economies of scale for application developers. This means that a larger number of high-quality applications at a reasonable cost are available. When combined with semantic models such as FDT, OPC UA makes it easier for end users to access data via generic commercial applications.

The OPC UA model is scalable from small devices to ERP systems. OPC UA Servers process information locally and then provide that data in a consistent format to any application requesting data - ERP, MES, PMS, Maintenance Systems, HMI, Smartphone or a standard Browser, for examples. For a more complete overview see OPC 10000-1.

4.2.2 Basics of OPC UA

As an open standard, OPC UA is based on standard internet technologies, like TCP/IP, HTTP, Web Sockets.

As an extensible standard, OPC UA provides a set of Services (see OPC 10000-4) and a basic information model framework. This framework provides an easy manner for creating and exposing vendor defined information in a standard way. More importantly all OPC UA Clients are expected to be able to discover and use vendor-defined information. This means OPC UA users can benefit from the economies of scale that come with generic visualization and historian applications. This specification is an example of an OPC UA Information Model designed to meet the needs of developers and users.

OPC UA Clients can be any consumer of data from another device on the network to browser based thin clients and ERP systems. The full scope of OPC UA applications is shown in Figure 1.

OPC UA provides a robust and reliable communication infrastructure having mechanisms for handling lost messages, failover, heartbeat, etc. With its binary encoded data, it offers a high-performing data exchange solution. Security is built into OPC UA as security requirements become more and more important especially since environments are connected to the office network or the internet and attackers are starting to focus on automation systems.

4.2.3 Information modelling in OPC UA

4.2.3.1 Concepts

OPC UA provides a framework that can be used to represent complex information as Objects in an AddressSpace which can be accessed with standard services. These Objects consist of Nodes connected by References. Different classes of Nodes convey different semantics. For example, a Variable Node represents a value that can be read or written. The Variable Node has an associated DataType that can define the actual value, such as a string, float, structure etc. It can also describe the Variable value as a variant. A Method Node represents a function that can be called. Every Node has a number of Attributes including a unique identifier called a NodeId and non-localized name called a BrowseName. An Object representing a ‘Reservation’ is shown in Figure 2.

Object and Variable Nodes represent instances and they always reference a TypeDefinition (ObjectType or VariableType) Node which describes their semantics and structure. Figure 3 illustrates the relationship between an instance and its TypeDefinition.

The type Nodes are templates that define all of the children that can be present in an instance of the type. In the example in Figure 3 the PersonType ObjectType defines two children: First Name and Last Name. All instances of PersonType are expected to have the same children with the same BrowseNames. Within a type the BrowseNames uniquely identify the children. This means Client applications can be designed to search for children based on the BrowseNames from the type instead of NodeIds. This eliminates the need for manual reconfiguration of systems if a Client uses types that multiple Servers implement.

OPC UA also supports the concept of sub-typing. This allows a modeller to take an existing type and extend it. There are rules regarding sub-typing defined in OPC 10000-3, but in general they allow the extension of a given type or the restriction of a DataType. For example, the modeller may decide that the existing ObjectType in some cases needs an additional Variable. The modeller can create a subtype of the ObjectType and add the Variable. A Client that is expecting the parent type can treat the new type as if it was of the parent type. Regarding DataTypes, subtypes can only restrict. If a Variable is defined to have a numeric value, a sub type could restrict it to a float.

References allow Nodes to be connected in ways that describe their relationships. All References have a ReferenceType that specifies the semantics of the relationship. References can be hierarchical or non-hierarchical. Hierarchical references are used to create the structure of Objects and Variables. Non-hierarchical are used to create arbitrary associations. Applications can define their own ReferenceType by creating subtypes of an existing ReferenceType. Subtypes inherit the semantics of the parent but may add additional restrictions. Figure 4 depicts several References, connecting different Objects.

The figures above use a notation that was developed for the OPC UA specification. The notation is summarized in Figure 5. UML representations can also be used; however, the OPC UA notation is less ambiguous because there is a direct mapping from the elements in the figures to Nodes in the AddressSpace of an OPC UA Server.

A complete description of the different types of Nodes and References can be found in OPC 10000-3 and the base structure is described in OPC 10000-5.

OPC UA specification defines a very wide range of functionality in its basic information model. It is not required that all Clients or Servers support all functionality in the OPC UA specifications. OPC UA includes the concept of Profiles, which segment the functionality into testable certifiable units. This allows the definition of functional subsets (that are expected to be implemented) within a companion specification. The Profiles do not restrict functionality, but generate requirements for a minimum set of functionality (see OPC 10000-7).

4.2.3.2 Namespaces

OPC UA allows information from many different sources to be combined into a single coherent AddressSpace. Namespaces are used to make this possible by eliminating naming and id conflicts between information from different sources. Each namespace in OPC UA has a globally unique string called a NamespaceUri which identifies a naming authority and a locally unique integer called a NamespaceIndex, which is an index into the Server's table of NamespaceUris. The NamespaceIndex is unique only within the context of a Session between an OPC UA Client and an OPC UA Server- the NamespaceIndex can change between Sessions and still identify the same item even though the NamespaceUri's location in the table has changed. The Services defined for OPC UA use the NamespaceIndex to specify the Namespace for qualified values.

There are two types of structured values in OPC UA that are qualified with NamespaceIndexes: NodeIds and QualifiedNames. NodeIds are locally unique (and sometimes globally unique) identifiers for Nodes. The same globally unique NodeId can be used as the identifier in a node in many Servers – the node's instance data may vary but its semantic meaning is the same regardless of the Server it appears in. This means Clients can have built-in knowledge of of what the data means in these Nodes. OPC UA Information Models generally define globally unique NodeIds for the TypeDefinitions defined by the Information Model.

QualifiedNames are non-localized names qualified with a Namespace. They are used for the BrowseNames of Nodes and allow the same names to be used by different information models without conflict. TypeDefinitions are not allowed to have children with duplicate BrowseNames; however, instances do not have that restriction.

4.2.3.3 Companion Specifications

An OPC UA companion specification for an industry specific vertical market describes an Information Model by defining ObjectTypes, VariableTypes, DataTypes and ReferenceTypes that represent the concepts used in the vertical market, and potentially also well-defined Objects as entry points into the AddressSpace.

5 Use cases

This information model supports following use cases:

• List topology

• Identify device

• Get list of available device parameters

• Browse device parameters

• Get attributes of a device parameter

• Get Device Status

• Get Device Diagnostics

• Read parameters

• Read offline data

• Read online data

• Write device parameters

• Audit trail

A detailed description of these use cases is provided in Annex B.

6 FDT Information Model overview

The system architecture as shown in Figure 6 has already been defined in FDT2 specification.

The OPC UA server is a Frame Application. The Frame Application is interacting with the DTMs in order to manage the device-specific information and in order to interact with the devices. Frame Applications may support different use cases, for example: vendor-specific service, process control or asset management. Frame Applications may start and terminate the DTMs on demand (e.g. only if a value is read from the respective device).

The OPC UA server is equipped with an OPC UA server interface. In the information model of the OPC UA server the application-specific project information may be represented (depending on the Frame Application) and device-specific information shall be represented. The OPC UA client may browse the information model and may use the services of the OPC UA interface to access the represented information. If device-specific information is accessed, the information is retrieved from the DTMs.

In a multi-client scenario the Frame Application is responsible for managing the access to the DTMs. The approach for managing the access from multiple clients is to use the "multi user access" as specified in FDT2 specification.

Since the contents of the FDT project and the management of multi-client access is specific to the Frame Application, this document focuses on the mapping of the information from the DTM to the ‘Device model’ of OPC UA for Devices. One possible approach for presentation of the project information would be the 'Device Integration Host Model' according to OPC UA for Devices.

7 FDT specific OPC UA ObjectTypes

7.1 General

The OPC UA information model for FDT is based on OPC UA for Devices. This document defines a mapping for device-related information, services and data types.

Services which are defined in OPC UA for Devices, but for which no mapping is defined here (e.g. Locking service), have to be implemented by the OPC UA Server according to the specification in OPC UA for Devices.

7.2 FdtDeviceType

This OPC UA ObjectType is the base for a device type derived from an FDT device type definition. Any manufacturer-specific device type is derived from FdtDeviceType.

Figure 7 shows an overview for the FdtDeviceType with its Properties and related ObjectTypes. It is formally defined in Table 12.

The FdtDeviceType is formally defined in Table 12.

The FdtDeviceType is an abstract type and cannot be used directly.

The definition for DeviceHealth overrides the definition of OPC UA for Devices and makes this member mandatory for FdtDeviceType.

The mapping of FDT information to FdtDeviceType is defined in 12.2.1.

7.3 FdtFunctionalGroupType

FdtFunctionalGroupType is used for representing functional grouping of methods and parameters. It is formally defined in Table 13.

The FdtFunctionalGroupType is a concrete type and can be used directly.

7.4 IFdtDeviceHealthType Interface

IFdtDeviceHealthType defines additional requirements for the IDeviceHealthType interface, which is formally defined in Table 14.

The definition for DeviceHealth overrides the definition of OPC UA for Devices and makes the DeviceHealth member mandatory for IFdtDeviceHealthType.

7.5 IFdtSupportInfoType Interface

7.5.1 Overview

The IFdtSupportInfoType defines additional requirements for the ISupportInfoType interface, which is formally defined in Table 15.

The components of the IFdtSupportInfoType have additional references as defined in Table 16.

Documents provided for a device are exposed as Objects organized in the Documentation folder. In most cases they will represent a product manual, which can exist as a set of individual documents. The BrowseName of each Object in the Documentation Folder will consist of the document label that can be used to identify the document.

Protocol support files (e.g. GSD files, EDS files) provided for a device are exposed as Objects organised in the ProtocolSupport folder.

7.6 Document types

7.6.1 FdtDocumentType

This abstract type describes the information associated with a document provided by a DTM. The FdtDocumentType is formally described in Table 17.

The FdtDocumentType is an abstract type and cannot be used directly.

The MIME type of document is identified by the MediaType property of each Variable.

7.6.2 FdtDocumentFile

This is a type for representing documents, which are provided as files. It is formally defined in Table 18.

The FdtDocumentFile is a concrete type and can be used directly.

The document may be retrieved from the server by using the methods related to the object of type FileType.

7.6.3 FdtDocumentUrl

This is a type for representing documents, which are provided as URL. It is formally defined in Table 19.

The FdtDocumentUrl is a concrete type and can be used directly.

The actual document may be retrieved by the Client from the URL.

7.7 FdtProtocolType

This type is used to specify which protocols an FdtDeviceType requires or supports.

The FdtProtocolType is formally defined in Table 20.

The FdtProtocolType is an abstract type and cannot be used directly.

The property BusCategory shall be used by any instance of FdtProtocolType or its subtypes.

7.8 FdtTransferServiceType

This type is used to specify support for transfer services.

The FdtTransferServiceType is formally defined in Table 21.

The FdtTransferServiceType is a concrete type and can be used directly.

The property SupportedTransfer (defined in 10.4.11) is used to indicate the services supported for the respective device.

7.9 FdtIoSignalInfoType

This type is used to provide information about the IO signals available at the device.

The FdtIoSignalInfoType is formally defined in Table 22.

The FdtIoSignalInfoType is a concrete type and can be used directly.

8 OPC UA EventTypes

8.1 Overview

In order to support audit trail, new audit trail event types are defined (see Figure 11).

8.2 FdtAuditEventType

The FdtAuditEventType is an event type for general events (e.g. for device status update). It is formally defined in Table 23.

8.3 FdtStartMethodEventType

The FdtStartMethodEventType is an event type for indication of start of execution of a command function. It is formally defined in Table 24.

8.4 FdtEndMethodEventType

The FdtEndMethodEventType is an event type for indication of end of execution of a command function. It is formally defined in Table 25.

The property Result is used to indicate the result of the function execution.

8.5 FdtAuditWriteUpdateEventType

The FdtAuditWriteUpdateEventType is used to indicate the change of a parameter value. It is formally defined in Table 26.

The property OldUnit may be used to indicate the unit of the old value. The property NewUnit may be used to indicate the unit of the new value. If the source node of the event has an engineering unit, it is mandatory to provide these properties.

9 OPC UA VariableTypes

9.1 FdtParameter

A specific type FdtParameter is defined, which is an extension of DataItemType (see Table 27).

The FdtParameter is a concrete type and can be used directly.

DisplayFormat is a format string for numerical data, compliant to .NET string format definitions.

If the DataType of the FdtParameter is an Enumeration DataType, then EnumStrings are used according to OPC 10000-3.

EURange and EngineeringUnits are used as defined in OPC 10000-8 for the AnalogueItem variable type.

SemanticInfo provides additional semantic information for the parameter (e.g., a reference to a definition in a device profile).

If the FdtParameter represents a structured data information, then ApplicationId may be used to categorize the use case for the data structure.

The DataRefType properties are used to reference related FdtParameters:

• DataRef, provides references to other data. Information about the type of reference is provided by the SemanticInfo of the DataRefType.

• AlarmDataRef, provides references to alarm information,

• RangeDataRef, provides references to range information, and

• SubstituteDataRef, provides references to substitute value settings.

If the FdtParameter represents alarm information, then AlarmType categorizes the available alarm type.

If the FdtParameter represents range information, then RangeType distinguishes whether the data represents an upper range or a lower range.

If the FdtParameter represents substitute information, then SubstitutionType specifies which value shall be used when a substitute value is needed.

The HasIOSignalRef reference, provides a reference to the description of an IO signal that corresponds to the FdtParameter.

10 OPC UA DataTypes

10.1 DataRefType

The DataRefType provides a reference to a data item. It is formally defined in Table 28.

The representation of DataRefType in the AddressSpace is defined in Table 29.

10.2 FdtDeviceClassificationType

The FdtDeviceClassificationType is used to classify devices. It is formally defined in Table 30.

The representation of FdtDeviceClassificationType in the AddressSpace is defined in Table 31.

10.3 SemanticInfoType

This type describes semantic information associated with data provided by a DTM. The SemanticInfoType is formally defined in Table 32.

The representation of SemanticInfoType in the AddressSpace is defined in Table 33.

10.4 Enumeration datatypes

10.4.1 AlarmType

AlarmType is an enumeration that defines the available alarm types. The values shall be mapped as defined in Table 34.

Its representation in the AddressSpace is defined in Table 35.

10.4.2 ApplicationIdEnumeration

The ApplicationIdEnumeration is an enumeration that defines the use of the FunctionalGroup. Its values are defined in Table 36.

Its representation in the AddressSpace is defined in Table 37.

10.4.3 ClassificationDomainId

ClassificationDomainId is an enumeration that defines the available domains for device classifications. Its values are defined in Table 38.

Its representation in the AddressSpace is defined in Table 39.

10.4.4 ClassificationId

ClassificationId is an enumeration that defines the available classifications for devices. Its values are defined in Table 40.

Its representation in the AddressSpace is defined in Table 41.

10.4.5 DocumentClassification

DocumentClassification is an enumeration that defines the available classes of documents. Its values are defined in Table 42.

Its representation in the AddressSpace is defined in Table 43.

10.4.6 FunctionExecutionResultState

FunctionExecutionResultState is an enumeration that defines the type of result states for execution of a function provided for a device. Its values are defined in Table 44.

Its representation in the AddressSpace is defined in Table 45.

10.4.7 IECDatatype

IECDatatype is an enumeration that defines the IEC type of an IOSignal. Its values are defined in Table 46.

Its representation in the AddressSpace is defined in Table 47.

10.4.8 RangeType

RangeType is an enumeration that defines the available types of range limits. Its values are defined in Table 48.

Its representation in the AddressSpace is defined in Table 49.

10.4.9 SignalTypeEnumeration

SignalTypeEnumeration is an enumeration that defines the type of an IO signal. Its values are defined in Table 50.

Its representation in the AddressSpace is defined in Table 51.

10.4.10 SubstitutionType

SubstitutionType is an enumeration that defines the type of substitution data. Its values are defined in Table 52.

Its representation in the AddressSpace is defined in Table 53.

10.4.11 SupportedTransfer

SupportedTransfer is an enumeration that defines the types of transfers provided for a device. Its values are defined in Table 54.

Its representation in the AddressSpace is defined in Table 55.

11 OPC UA ReferenceTypes

11.1 HasIOSignalRef

The HasIOSignalRef ReferenceType is a concrete ReferenceType that can be used directly. It is a subtype of the NonHierarchicalReferences ReferenceType.

The TargetNode of a Reference of the HasIOSignalRef ReferenceType is providing the IO signal description for the SourceNode.

The SourceNode of References of this type shall be an FdtParameter.

The TargetNode of this ReferenceType shall be an FdtIoSignalInfoType.

The HasIOSignalRef is formally defined in Table 56.

12 Mapping of DataTypes

12.1 Primitive data types

12.1.1 DeviceHealthEnumeration

The datatype DeviceHealthEnumeration defined by OPC UA for Devices shall be mapped to the FDT2 datatype DeviceStatus. The values shall be mapped as defined in Table 57.

12.2 Mapping to OPC DI Types

12.2.1 Device Type

12.2.1.1 General

OPC UA for Devices and FDT use different approaches in regard to representation of device type specific data. Some of the data defined in OPC UA for representation of the device type is available only in instance-specific data of the DTMs (see Figure 12).

The data from FDT may be mapped either to Attributes (table header “Attribute”) or to properties and other child Nodes (table header “BrowseName”) of the corresponding OPC UA Node.

For this reason the device type specific data of OPC is mapped to data on several interfaces of the DTM (see Table 58).

12.2.1.2 Mapping for DeviceType (“Types” standard Object)

All device types provided by DTMs in IDtmInformation shall be represented as subtypes of FdtDeviceType in the “Types” standard Object (see Table 58).

A DTM can provide several icons (list of icons). The rule for selection of the icon and extraction of an image (a specific resolution) from the icon is frame application specific. The selection of the image format in general is implementation specific, all types are allowed that are defined in OPC UA 10000-3.

12.2.1.3 Mapping for Offline Device (“Objects” standard Object)

The information for a device (instance) is based on the information provided by a DTM (instance). The mapping for the device node is defined in Table 59.

The device parameters provide offline identification information based on DTM type information intended for identification. This data may provide values or regular expressions to define ranges of supported values.

In the call to IDtmInformation.GetDeviceIdentInfo() a protocol must be specified. The first entry from the list of INetworkData.ActiveProtocols shall be used.

GetDeviceIdentInfo() may return a list of DeviceIdentInfo where the first entry is used for the parameters as defined below. Exposing the remaining list entries is implementation specific.

12.2.1.4 Mapping for Online Device (“Objects” standard Object online reference)

Device parameters provide identification information based on data read online from the device. This data may be different from the data provided in the DeviceType.

12.2.2 TopologyElementType

The information provided by a DTM with IFunction.FunctionInfo and IData.DataInfo is mapped into the MethodSet and to the ParameterSet. For both types of information (Commands and Parameters) also references in FunctionalGroup nodes are created, so that an OPC Client may represent a joint user interface (see Figure 13).

The BrowseName and DisplayName of the FunctionalGroup-Nodes are based on the grouping in IFunction.FunctionInfo (FunctionGroup) and IData.DataInfo (DataGroup).

Information about IO signals are provided in a folder ProcessDataSet, which contains FdtIoSignalInfoType nodes. FdtIoSignalInfoType nodes are referenced by the corresponding FdtParameter nodes.

12.2.3 FunctionalGroupType

The FunctionalGroupType is used to organize Parameters and Methods (which are defined in ParameterSet and MethodSet) in a user-friendly way (see Table 63). FunctionalGroups may be organized hierarchically by organizing FunctionalGroups as child nodes of FunctionalGroups.

12.2.4 Identification FunctionalGroup

The Identification FunctionalGroup organizes references to parameters, which may be used to identify the device and its device type. The list of parameters that shall be provided in the Identification FunctionalGroup is defined in Table 64.

The values of the referenced Variables may vary for online and offline device. See section 12.2.1 for the mapping of these Variables.

Protocol specific properties shall be organised in a FunctionalGroup called “ProtocolSpecificIdentification” contained in the Identification FunctionalGroup.

Device specific properties shall be organised in a FunctionalGroup called “DeviceSpecificIdentification” contained in the Identification FunctionalGroup.

12.2.5 Device Data and Device Methods

While device data and methods related to the device are defined in separate areas of the OPC UA Information model (i.e. ParameterSet and MethodSet), they are organized by functional groups into a concise representation, which may be structured to present different aspects of the device. A DTM provides different interfaces (e.g. IDeviceData and IFunction), where data and methods are presented independently, while each interface may provide an own structure.

In the mapping from DTM interfaces to OPC UA information model, the representation hierarchies of IData interfaces and IFunction interface are combined into FunctionalGroups to provide a concise representation of the device data and methods within one hierarchy.

This means, that the data of the IData interfaces are mapped to the ParameterSet node in the OPC UA Information model and the command functions from IFunction interface are mapped to the MethodSet of the device. The hierarchical structures in the IData and IFunction interfaces are mapped to the hierarchical structure provided by the FdtFunctionalGroup elements, which organize the representation of data and methods (see Figure 14).

12.2.6 Methods

12.2.6.1 General

A DTM instance can offer command functions. These functions do not have a user interface, they can have arguments and optional default values.

Each command function shall be mapped to a method in the MethodSet of the device instance (see Figure 15). The arguments are mapped to the InputArguments and OutputArguments for the methods. Optional arguments shall be included.

The DTMInfoBuilder can offer information about static functions that are independent of a DTM instance. Such FDT Static Functions may be mapped to methods on the device type created for the DTM. The execution of the method on a device object will need to be mapped to the execution of a static function with a StaticFunctionProvider. The Frame/Server will need to hold the reference to the provider internally and use it for execution of the method (see Figure 16).

12.2.6.2 TransferServices

For a DTM instance it is mandatory to provide the interface IOnlineOperation if the device provides online data. This interface is mapped to an object of type FdtTransferServiceType (see 7.8). Since the DTM interface is not mandatory for all devices, the availability of the TransferServices depends on the availability of the DTM interface. The member SupportedTransfer indicates, which TransferServices are supported for the device.

The TransferServices Type object (with browse name “Transfer”) is provided as child node of an offline device node (not for an online device node).

For the method FetchTransferResultData the server is allowed to limit the TransferResultData in regard to the list of transferred parameters (parameterDefs) to zero data. The results of the transfer will be represented in the parameter values of the device node.

12.2.7 Variable

12.2.7.1 General

The parameter set of a device (offline and online) is described by means of the DataInfo data type (available with the <GetDataInfo> method from IInstanceData (offline) and IDeviceData (online)).

DataInfo provides a description of the available data without the values. The actual values are accessible with <Read> and <Write> methods from IInstanceData (offline) and IDeviceData (online).

DataInfo provides a list of data items (member DeviceDataItems), which may represent a range of types. Some of these data items are mapped to DataVariables (see Table 68).

12.2.7.2 FdtParameter

12.2.7.2.1 General

Table 69 shows the mapping for the FdtParameter.

12.2.7.2.2 Datatype mapping

The datatype mapping for parameter data is described in Table 70.

In OPC UA array datatypes are represented by a combination of the properties datatype, value-rank and array-dimensions (see OPC OPC UA 10000-5, section 5.6.2).

In FDT array datatypes are represented with a dedicated ArrayDatatypeInfo datatype. This datatype has a member ArrayDatatypeInfo.ArrayDimensions, which specifies the length of each dimension of the array.

The mapping for array data types is defined as follows.

• OPC datatype value is mapped according to Table 70.

• OPC value rank is:

• -1 for a simple datatype, or

• Number of fields in FDT ArrayDatatypeInfo.ArrayDimensions (always > 0)

• OPC array-dimensions property is:

• NULL for a simple datatype, or

• has the same value as ArrayDatatypeInfo.ArrayDimensions.

• value of 0 means that the array has a variable length,

• values > 0 indicate a defined length.

12.2.8 Device Support Information

12.2.8.1 Device Type Image

All Bitmaps provided by a DTM shall be represented in the DeviceTypeImage folder according OPC UA 10000-100 (see Table 58). An image shall be represented by an FdtParameter with DataType set to one of the defined image data types. The actual image is provided by the value attribute as ByteString.

The mapping for a device type image is defined in Table 71.

Selection of the image format according to FDT2 is specific for a Frame Application. All image types are allowed that are defined in OPC UA 10000-3.

12.2.8.2 Protocol Support Files

Protocol support files provided for a device are exposed as Variables organised in the ProtocolSupport folder. They may represent various types of information as defined by a protocol. Examples are a GSD or a CFF file. The ProtocolSupport folder is formally defined in OPC UA for Devices 5.7.3.. The mapping is protocol independent. All the documents listed in NetworkData.DeviceInformationDocuments are mapped. The value of the <PlaceHolder> is defined by the label of the respective document (Document.Label).

The label of the DeviceInformationDocument shall be used as BrowseName for the OPC Node.

12.2.9 FdtIoSignalInfoType

All IOSignalInfo provided by the DTM in the IProcessData interface are mapped to respective FdtIoSignalInfo objects.

12.2.10 FdtProtocolType

The FdtProtocolType and its sub-types are used to specify a communication protocol that is supported by a Device or Network. The BrowseName of each instance of a ProtocolType shall define the Communication Profile (see OPC UA for Devices 6.3).

OPC UA for FDT uses a sub-type FdtProtocolType (see 7.7) for mapping the needed information.

13 Profiles and Conformance Units

13.1 Conformance Units

Table 75 defines the corresponding ConformanceUnits for the OPC UA Information Model for FDT.

13.2 Profiles

13.2.1 Profile list

Table 76 lists all Profiles defined in this document and defines their URIs.

13.2.2 Server Facets

13.2.2.1 Overview

The following sections specify the Facets available for Servers that implement the FDT companion specification. Each section defines and describes a Facet or Profile.

13.2.2.2 FDT Base Server Profile

Table 77 defines a Profile that describes the basic requirements for an OPC UA server supporting the FDT information model.

13.2.2.3 FDT General Server Facet

Table 78 defines a Facet that describes the general requirements for a server.

13.2.3 Client Facets

13.2.3.1 Overview

The following tables specify the Facets available for Clients that implement the FDT companion specification.

13.2.3.2 FDT General Client Facet

Table 79 defines a Facet that describes the base characteristics for all OPC UA Clients that make use of this companion specification. Additional Profiles will define support for various information models that are part of this document.

14 Namespaces

14.1 Namespace Metadata

Table 80 defines the namespace metadata for this document. The Object is used to provide version information for the namespace and an indication about static Nodes. Static Nodes are identical for all Attributes in all Servers, including the Value Attribute. See OPC 10000-5 for more details.

The information is provided as Object of type NamespaceMetadataType. This Object is a component of the Namespaces Object that is part of the Server Object. The NamespaceMetadataType ObjectType and its Properties are defined in OPC 10000-5.

The version information is also provided as part of the ModelTableEntry in the UANodeSet XML file. The UANodeSet XML schema is defined in OPC 10000-6.

14.2 Handling of OPC UA Namespaces

Namespaces are used by OPC UA to create unique identifiers across different naming authorities. The Attributes NodeId and BrowseName are identifiers. A Node in the UA AddressSpace is unambiguously identified using a NodeId. Unlike NodeIds, the BrowseName cannot be used to unambiguously identify a Node. Different Nodes may have the same BrowseName. They are used to build a browse path between two Nodes or to define a standard Property.

Servers may often choose to use the same namespace for the NodeId and the BrowseName. However, if they want to provide a standard Property, its BrowseName shall have the namespace of the standards body although the namespace of the NodeId reflects something else, for example the EngineeringUnits Property. All NodeIds of Nodes not defined in this document shall not use the standard namespaces.

Table 81 provides a list of mandatory and optional namespaces used in an FDT OPC UA Server.

Table 82 provides a list of namespaces and their indices used for BrowseNames in this document. The default namespace of this document is not listed since all BrowseNames without prefix use this default namespace.

Annex A FDT Namespace and mappings (Normative)

A.1 Namespace and identifiers for FDT Information Model

This appendix defines the numeric identifiers for all of the numeric NodeIds defined in this document. The identifiers are specified in a CSV file with the following syntax:

<SymbolName>, <Identifier>, <NodeClass>

Where the SymbolName is either the BrowseName of a Type Node or the BrowsePath for an Instance Node that appears in the specification and the Identifier is the numeric value for the NodeId.

The BrowsePath for an Instance Node is constructed by appending the BrowseName of the instance Node to the BrowseName for the containing instance or type. An underscore character is used to separate each BrowseName in the path. Let’s take for example, the FdtParameter ObjectType Node which has the DisplayFormat Property. The SymbolName for the DisplayFormat InstanceDeclaration within the FdtParameter declaration is: FdtParameter_DisplayFormat.

The NamespaceUri for all NodeIds defined here is http://opcfoundation.org/UA/FDT/1.01/

The CSV released with this version of the specification can be found here:

http:/opcfoundation.org/UA/schemas/FDT/1.01/Opc.Ua.FDT.NodeSet.csv

https://opcfoundation.org/UA/schemas/FDT/Opc.Ua.FDT.NodeSet.csv

A computer processible version of the complete Information Model defined in this document is also provided. It follows the XML Information Model schema syntax defined in OPC 10000-6.

The Information Model Schema for this version of the document (including any revisions, amendments or errata) can be found here:

http://www.opcfoundation.org/UA/schemas/FDT/1.01/Opc.Ua.FDT.NodeSet.xml

http://www.opcfoundation.org/UA/schemas/FDT/Opc.Ua.FDT.NodeSet.xml

Annex B Use cases (Informative)

B.1 General

The following use cases describe how base features are supported by the FDT OPC UA system architecture.

B.2 Use case: List topology

B.3 Use case: Identify device

B.4 Get list of available device parameters

B.4.1 Use case: Browse device parameters

B.4.2 Use case: Get attributes of a device parameter

B.5 Use case: Get Device Status

B.6 Use case: Get Device Diagnostics

B.7 Read parameters

B.7.1 Use case: Read offline data

B.7.2 Use case: Read online data

B.8 Use case: Write device parameters

B.9 Use case: Audit trail

_____________

Agreement of Use

COPYRIGHT RESTRICTIONS

This document is provided "as is" by the OPC Foundation and the FDT Group.

Right of use for this specification is restricted to this specification and does not grant rights of use for referred documents.

Right of use for this specification will be granted without cost.

This document may be distributed through computer systems, printed or copied as long as the content remains unchanged and the document is not modified.

OPC Foundation and FDT Group do not guarantee usability for any purpose and shall not be made liable for any case using the content of this document.

The user of the document agrees to indemnify OPC Foundation and FDT Group and their officers, directors and agents harmless from all demands, claims, actions, losses, damages (including damages from personal injuries), costs and expenses (including attorneys' fees) which are in any way related to activities associated with its use of content from this specification.

The document shall not be used in conjunction with company advertising, shall not be sold or licensed to any party.

The intellectual property and copyright is solely owned by the OPC Foundation and FDT Group.

Copyright © 2021, OPC Foundation, Inc. and FDT Group.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OPC or FDT Group specifications may require use of an invention covered by patent rights. OPC Foundation or FDT Group shall not be responsible for identifying patents for which a license may be required by any OPC or FDT Group specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OPC or FDT Group specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

WARRANTY AND LIABILITY DISCLAIMERS

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OPC FOUDATION NOR FDT GROUP MAKES NO WARRANTY OF ANY KIND, EXPRESSED OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OPC FOUNDATION NOR FDT GROUP BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you.

RESTRICTED RIGHTS LEGEND

This Specification is provided with Restricted Rights. Use, duplication or disclosure by the U.S. government is subject to restrictions as set forth in (a) this Agreement pursuant to DFARs 227.7202-3(a); (b) subparagraph (c)(1)(i) of the Rights in Technical Data and Computer Software clause at DFARs 252.227-7013; or (c) the Commercial Computer Software Restricted Rights clause at FAR 52.227-19 subdivision (c)(1) and (2), as applicable. Contractor / manufacturer are the OPC Foundation, 16101 N. 82nd Street, Suite 3B, Scottsdale, AZ, 85260-1830

COMPLIANCE

The combination of FDT Group and OPC Foundation shall at all times be the sole entities that may authorize developers, suppliers and sellers of hardware and software to use certification marks, trademarks or other special designations to indicate compliance with these materials as specified within this document. Products developed using this specification may claim compliance or conformance with this specification if and only if the software satisfactorily meets the certification requirements set by FDT Group or the OPC Foundation. Products that do not meet these requirements may claim only that the product was based on this specification and must not claim compliance or conformance with this specification.

Trademarks

Most computer and software brand names have trademarks or registered trademarks. The individual trademarks have not been listed here.

GENERAL PROVISIONS

Should any provision of this Agreement be held to be void, invalid, unenforceable or illegal by a court, the validity and enforceability of the other provisions shall not be affected thereby.

This Agreement shall be governed by and construed under the laws of Germany.

This Agreement embodies the entire understanding between the parties with respect to, and supersedes any prior understanding or agreement (oral or written) relating to, this specification.