< PreviousField Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 19 of 67 Objects in OPC UA typically have Variables holding variable values. While the BrowseName or DisplayName provide a “hint” regarding the semantic of the Variable this cannot be used to automatically identify the semantic of a Variable. As an example, the ParameterSet of a DeviceType Object contains a flat list of the parameters of the device. Semantic information provides means to represent that a Variable (e.g. in the ParameterSet) has a specific semantic associated with it. This allows clients to automatically retrieve and identify such Variables. The DictionaryEntryType Object, defined in IEC 62541-5, is used to add semantic information to objects in the FDI Information Model. Subtypes of DictionaryEntryType shall define their own namespace (e.g. http://iec.ch/cdd/iec61987). The NodeId of Objects shall consist of the corresponding namespace index and the value of the ID Property as the identifier part. This allows direct access to the Semantic Object without further indirection. The OPC UA Server shall create a concrete object type derived from the abstract DictionaryEntryType for each dictionary referenced. Objects such as DeviceType, FunctionalGroupType, or VariableType can reference one or more DictionaryEntryType objects using the HasDictionaryEntry reference to indicate the semantic meaning for the object. The DictionaryId property of the DictionaryEntryType object contains the identifier value of an external dictionary entry. A client can use these references to access device data with only needing to know semantically what information is desired (i.e. specific object BrowseNames are not required). The following example provides an overview of this design principle (Figure 11). This example uses the IEC Common Data Dictionary (CDD) however it should be noted that any qualifying dictionary may be used. The IEC Common Data Dictionary (CDD) describes classes and properties with the purpose to characterize equipment. The IEC 61987 series for instance describes process automation equipment. Every class and property provide a set of attributes such as Version, Revision, Preferred name, Definition etc. Most importantly, it describes a unique identifier for every class of property. In the case of IEC CDD this is an International Registration Data Identifier (IRDI). In this example, IEC61987DictionalEntryType is defined as a subtype of DictionaryEntryType. The Object DifferentialPressureTransmitter of this ObjectType contains the IEC CDD attribute values as its property values. The IRDI is set as the value of the ID property. DictionaryEntryType IEC61987 DictionaryEntryType 112/2/// 61987#ABA833#003 NodeId: ns=4,i=0112/ 2///61987#ABA833#003 Server Namespace Array: ... [4]: http://iec.ch/cdd/iec61987 ... Figure 11 - Example of concrete DictionaryEntryType and Object Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 20 of 67 Variables may be enumerations. In such cases, the Variable may have a specific semantic as well as each enumeration item of the Variable. As an example, a Variable may contain the units of the measurement value that can be configured. So, the semantic of the Variable itself is “measurement unit”. The enumeration items of that Variable then stand for a specific unit of measure. In case of temperature the first enumeration item may represent degrees Celsius, the second item represents degrees Fahrenheit, the third item represents degrees Kelvin and so on. Associating enumeration items with a specific semantic allows clients to automatically retrieve information such as the currently configured measurement unit without requiring interment knowledge of the particular unit code being used by the device. Enumerated Variables contain an additional property DictionaryEntries, defined in section 15.12.1, which is an array of DataType NodeId where each array item contains the NodeId of the corresponding DictionaryEntry Object. Figure 12 shows an example: The Variable Parameter2 has the Property DictionaryEntries. The array items of the DictionaryEntries Property contain the NodeIds of the corresponding DictionaryEntry Objects. In the example Parameter2[0] is related to the Semantic1 Object, Parameter2[1] is not related to any Semantic Object and Parameter2[2] is related to the Semantic2 Object. SemanticType MySemanticType NodeId: ns=4,i=Semantic1 Identifier Server Namespace Array: ... [7]: http://MySemanticOrg ... MyDictionaryEntryType Semantic1 MyDictionaryEntryType Semantic2 NodeId: ns=4,i=Semantic2 Identifier MultiStateSemanticDiscreteType: Parameter2 EnumValues [0] NodeId: ns=4,i=Semantic1Identifier [1] Empty [2] NodeId: ns=4,i=Semantic2Identifier ValueAsText DictionaryEntries [0] 12, „EnumItem No 1“, „Help for EnumItem No 1“ [1] 15, „EnumItem No 2“, „Help for EnumItem No 2“ [2] 23, „EnumItem No 3“, „Help for EnumItem No 3“ [0] „Localized Text for EnumItem No 1“ [1] „Localized Text for EnumItem No 2“ [2] „Localized Text for EnumItem No 3“ Figure 12 - Example of DictionaryEntries The custom query method GetNodeIdByDictionaryEntryId, defined in section 15.12.2, can be used by a client to search for the nodes that are referencing a specified dictionary entry id. This provides an efficient means for finding data using semantic information. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 21 of 67 6 AddressSpace organization To promote interoperability of FDI Clients and FDI Servers, a set of Objects and relationships are defined in the following subclauses. FDI Servers can implement a subset of these standard Nodes, depending on their capabilities. Based on OPC UA rules, an OPC UA Server separates the AddressSpace in two parts: • The Types-part contains information about all components that have been generated based on descriptive information from FDI Packages (see 5.4). • The Objects-part contains the Device Topology with all instantiated components. All instances of the AddressSpace are related to a type of the Types folder – The entry points DeviceSet, NetworkSet, and DeviceTopology are formally defined in IEC 62541-100. • DeviceTopology is used to aggregate the top level Networks that provide access to all instances that constitute the Device Topology ((sub-)networks, devices and communication elements). Some example elements are shown here and highlighted using the green colour. • All instantiated Devices are components of the DeviceSet Object, i.e., they exist in the AddressSpace independent of the Device Topology. All Networks are components of the NetworkSet Object. FDI Servers can either automatically create Device Objects or they may only show the available types (SupportedTypes folder) and leave it to the user to create proper instances. When using native communication the system will typically provide the Device Topology without having to have it configured by the FDI Client. 7 Device Model for FDI 7.1 General As mentioned above, IEC 62541-100 specifies the fundamental types needed for FDI like the TopologyElementType, the DeviceType and the ProtocolType (the fieldbus protocol). Clause 7 briefly repeats important design elements specified in IEC 62541-100 and specifies additional types that are not in IEC 62541- 100. 7.2 Online/offline All elements that appear in the Device Topology (Devices, Networks, and Connection Points) including their relationship correspond to information stored in the FDI Server’s configuration database. Management of these elements most commonly requires access to the physical component/device (called online data in this standard) and also the storage and administration of related data in a configuration database (called offline data). To support explicit access to either the online or the offline information, each element is represented by two instances that are schematically identical, i.e., there exists a ParameterSet, FunctionalGroups, and so on. A Reference connects online and offline representation and allows to navigate between them. This is illustrated in Figure 13. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 22 of 67 SomeType_A: Station 1 Module: CPU Module: CP NetworkType: PN Network PN CP 1 DeviceSet ConnectsTo NetworkSet SomeType_A: Online Online Parameters Offline Parameters IsOnline ConnectionPoint Figure 13 – Online component for access to device data Support of online/offline is mandatory for FDI Servers. Detailed information of the model and the formal definitions are specified in IEC 62541-100. 7.3 Device health DeviceHealth Mapping The DeviceHealth Property indicates the status of a device as defined by NAMUR NE107. FDI Clients can read or monitor this Property to determine the device condition. Servers determine the health status using the EDD METHOD GetHealthStatus defined in FCG TS62769-4. The frequency at which Servers actually examine the health status may vary from several seconds up to minutes. The mapping of the GetHealthStatus return values to OPC UA is specified in Table 1. Table 1 – DeviceHealth Mapping GetHealthStatus OPC UA 0 – Indeterminate Indeterminate is not defined in the the DeviceHealth data type in IEC 62541-100. Servers that cannot determine the health status of the device shall return the OPC UA Read operation for this Property with an appropriate OPC UA status code, for example: Bad_NotConnected Bad_OutOfService Bad_NoCommunication Bad_NotSupported The following values can be mapped to corresponding values defined for the DeviceHealth data type in IEC 62541-100. GetHealthStatus DeviceHealth data type values 1 - Failure FAILURE_1 2 – Function Check CHECK_FUNCTION_2 3 – Out of Specifications OFF_SPEC_3 4 – Maintenance Required MAINTENANCE_REQUIRED_4 5 - Good GOOD_0 Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 23 of 67 Different to OPC UA for Devices (IEC 62541-100), support of the DeviceHealth Property is mandatory for Device Objects in FDI. This is illustrated in Table 2. The complete DeviceType model and its formal definition are in IEC 62541-100. Table 2 – DeviceType definition (excerpt applicable for this clause) Attribute Value BrowseName DeviceType IsAbstract True References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the TopologyElementType defined in IEC 62541-100 ……… HasComponent Variable DeviceHealth DeviceHealth BaseDataVariableType Optional Mandatory ……… DeviceHealth Diagnostics In certain cases a Device may have additional information associated with the health status, e.g. the possible cause of an abnormal DeviceHealth status and suggested actions to return to normal. This additional information is available with the DeviceHealthDiagnostics Variable. It is formally defined in Table 3. Table 3 – DeviceType definition with DeviceHealth and DeviceHealthDiagnostics Attribute Value BrowseName DeviceType IsAbstract True References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the TopologyElementType defined in IEC 62541-100 ……… HasComponent Variable DeviceHealth DeviceHealth BaseDataVariableType Mandatory HasComponent Variable DeviceHealthDiagnostics[] LocalizedText BaseDataVariableType Mandatory ……… DeviceHealthDiagnostics is an array of LocalizedText. Each array element contains related diagnostic information. The language shall match the requested locale specified in the OPC UA Session. See clause 15.2.1 on how to select the proper language for the current OPC UA Session. When DeviceHealth is requested, the Server shall always also fetch the matching DeviceHealthDiagnostics. The Server shall assure that the values are synchronized by executing GetHealthStatus first and then reading the DeviceHealthDiagnostics. The Server will cache the DeviceHealthDiagnostics as part of the OPC UA Session until DeviceHealth is requested again. If DeviceHealthDiagnostics is read with a separate service request, the Server shall return the diagnostic information associated with the most recently read DeviceHealth status. If the DeviceHealth status has not been read in the current OPC UA Session the Server shall return Bad_NotReadable. If no diagnostic information is available, the returned Value is Null. See FCG TS62769-4 on how DeviceHealthDiagnostics maps to the corresponding EDD information. Example of a DeviceHealthInformation value with two array elements: Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 24 of 67 • [0]: “Critical Power Failure\n Possible cause: Critical Power failure has occurred\n Suggested action: Please check device/surroundings/process.\n” • [1]: “ Device Malfunction\n Possible Cause: The device has detected a serious hardware error or failure.\n Suggested action: Check detailed device diagnosis if possible and/or replace device hardware if necessary.\n ” 7.4 User interface elements General IEC 62541-100 defines in an abstract way, how Servers can expose user interface elements for Clients to display a user interface specific to a FunctionalGroup of a TopologyElement. Subclause 7.4 specifies two concrete user element types: descriptive user interface elements (UIDs) and programmed (executable) user interface elements (UIPs). UIPs are never referenced directly from a FunctionalGroup. They are always indirectly referenced from a UID by means of their UipId. Figure 14 illustrates the type hierarchy of the user interface elements defined in IEC 62541-100 and in this standard. UIElementType UIDescriptionType (UID) BaseVariableType Defined in OPC UA for Devices UIPlugInType (UIP) Figure 14 – Hierarchy of user interface Types UI Description Type FDI Servers may provide a descriptive user interface element (a UID) for each FunctionalGroup. Such an element will be rendered by the FDI Client. The UIDescriptionType is formally specified in Table 4. Table 4 – UIDescriptionType Definition Attribute Value BrowseName UIDescriptionType DataType String IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule Inherits the Properties of the UIElementType defined in IEC 62541-100. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 25 of 67 The Value Attribute provides the UID as a String containing an XML Element. See FCG TS62769-2 for the syntax of UID elements. The XML Schema for the UID Value of all exposed devices adheres to the same FDI Technology Version as indicated by the FDIServerVersion Property (see Clause 14). UI Plug-in Type A User Interface Plug-in (UIP) is a software module that is hosted and run by an FDI Client. In contrast to a User Interface Description (UID) it is an executable UI element. Details on hosting and running Plug-ins are specified in FCG TS62769-2. The UIPlugInType is formally specified in Table 5. Table 5 – UIPlugInType Definition Attribute Value BrowseName UIPlugInType DataType Byte ValueRank 1 – one dimensional array ArrayDimensions Uint32[1] – the length (number of bytes) of the array IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule Inherits the Properties of the UIElementType defined in IEC 62541-100. HasProperty Variable UIPVariantVersion String PropertyType Mandatory HasProperty Variable FDITechnologyVersio n String PropertyType Mandatory HasProperty Variable RuntimeId String PropertyType Mandatory HasProperty Variable CpuInformation String PropertyType Mandatory HasProperty Variable PlatformId String PropertyType Mandatory HasProperty Variable Style String PropertyType Mandatory HasProperty Variable StartElementName String PropertyType Mandatory HasComponent Object Documentation FolderType Optional UIPs may exist in multiple variants for different platforms or supporting different versions. The UipId (a unique identifier defined in the FDI package) identifies the UIP, not a specific variant. UIPs do not have to be exposed in the AddressSpace. With the UipId the FDI Client can retrieve the NodeIds of UIP Variants and their Properties by calling the OPC UA TranslateBrowsePathToNodeIds Service with the Device NodeId as the startingNode and the following list of relative names: • "UIPSet/ < UipId > " • "UIPSet/ < UipId > /RuntimeId" • "UIPSet/ < UipId > /CpuInformation" • "UIPSet/ < UipId > /PlatformId" • "UIPSet/ < UipId > /FDITechnologyVersion" • "UIPSet/<UipId >/Style" • "UIPSet/ < UipId > /StartElementName" • "UIPSet/ < UipId > /UIPVariantVersion" NOTE ”UIPSet” is an identifier for the Server and does not have to be a Node in the AddressSpace. The FDI Server returns arrays of NodeIds for each relative name. The number of entries in each array matches the number of UIP Variants for the UipId. The FDI Client can read the property values using the received NodeIds and choose the appropriate UIP Variant based on FDITechnologyVersion, RuntimeId, CpuInformation, and PlatformId. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 26 of 67 The Value Attribute provides the UIP executable. The exact representation is technology dependent (see FCG TS62769-6). The ArrayDimensions Attribute shall specify the size (number of bytes) of the UIP. FDI Clients need to be able to handle large UIPs. Reading large UIPs with a single Read operation may not be possible due to configured limits in either the FDI Client or the FDI Server stack. The default maximum size for an array of bytes is 1 MegaByte. FDI Clients can use the IndexRange in the OPC UA Read Service (see IEC 62541-4) to read a UIP in – for instance – one megabyte chunks. It is up to the FDI Client whether it starts without index and repeats with an indexRange only after an error or whether it always uses an indexRange. The following Properties help the FDI Client to identify which UIP fits best to its environment: • UIPVariantVersion: The version of this UIP Variant. • FDITechnologyVersion: FDI Technology Version according to which the UIP is developed. A UIP shall always be capable of running in a client/server system with the same major version and different minor/maintenance version. • RuntimeId: Runtime environment of the UIP as specified in FCG TS62769-6. • CpuInformation: Provides additional information about the execution environment associated with the RuntimeId. The allowed values are specified in FCG TS62769-6. • PlatformId defines the type of platform on which this UIP Variant is supported. An FDI Client can choose a particular UIP Variant if it matches the FDI Client's platform (see FCG TS62769-4 for the concrete definitions). – “Workstation”– with regular screen resolution capabilities, memory capabilities, input devices available (like mouse and keyboard) – “Mobile”– limited screen resolution, memory and input devices possible • Style: Defines whether the UIP shall be run “modal” or “modeless” as defined in IEC 62541-4. Currently, the values “Dialog” and “Window” are defined. While “Dialog” requires a modal window, a UIP with style “Window” will be invoked either in a modal or a non-modal window as defined in FCG TS62769-2. • StartElementName: Element needed to start this UIP Variant. FCG TS62769-6 specifies how this information is used when activating the UIP. Documents provided for a UIP Variant are exposed as Variables organized in the Documentation folder. In most cases they will represent a product manual, which can exist as a set of individual documents. The information can be retrieved by reading the Variable value which is represented as a ByteString. The complete ByteString shall be interpreted as a PDF file. FDI Clients need to be aware that the contents that these variables represent may be large. Reading large values with a single Read operation may not be possible due to configured limits in either the FDI Client or the FDI Server stack. The default maximum size for an array of bytes is 1 MegaByte. It is recommended that FDI Clients use the IndexRange in the OPC UA Read Service (see IEC 62541-4) to read these Variables in chunks, for example, one megabyte chunks. 7.5 Type-specific support information Each DeviceType may have a set of additional data. These are mainly images, documents, or protocol-specific data. The various types of information are organized into different folders. See IEC 62541-100 for the formal definition of support information. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 27 of 67 7.6 Actions Overview Actions are operations that are executed in the FDI Server on behalf of a topology element. Once invoked with the InvokeAction Method, Actions can make various state transitions until completed. The actual state is accessible via a transient, non-browsable Variable the NodeId of which is returned by the InvokeAction Method. FDI Clients can subscribe to this Variable to receive updates concerning the Action execution (Action data). Action data may report a state transition or a request to the FDI Client that input is necessary for continuation. The FDI Client can resume the execution with the RespondAction Method and submit the requested data. Figure 15 illustrates how Actions are integrated into a TopologyElement. <specificType> (Device or Block) ActionType: <ActionIdentifier> ActionSet ActionType <GroupIdentifier> ParameterSet <ParameterIdentifier> Organizes <UI Element> Organizes ActionServiceType RespondAction AbortAction InvokeAction BaseObjectType 0..n TopologyElementType Device or Block Instance Figure 15 – Integration of Actions within a TopologyElement ActionSet is used to aggregate the Actions for a specific TopologyElement. This Object is not available on the Type and is only available in an instance if Actions exist for this TopologyElement. Actions can also be referenced from FunctionalGroup Objects. Action Type This ObjectType defines the structure of an Action. It is formally defined in Table 6. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 28 of 67 Table 6 – ActionType Definition Attribute Value BrowseName ActionType IsAbstract True References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the BaseObjectType is defined in IEC 62541-5. The FDI Client determines the required invocation arguments for an Action from the UID. ActionService Type The ActionServiceType defines the Methods to invoke and control Actions. Instances of this type aggregate the Actions for a specific topology element. The ActionServiceType is formally defined in Table 7. Its use is illustrated in Figure 15. Table 7 – ActionServiceType Definition Attribute Value BrowseName ActionServiceType IsAbstract False References NodeClass BrowseName DataType TypeDefinition ModellingRule Subtype of the BaseObjectType defined in IEC 62541-5. HasComponent Method InvokeAction Mandatory HasComponent Method RespondAction Mandatory HasComponent Method AbortAction Mandatory HasComponent Object < ActionIdentifier > ActionType Optional The ActionServiceType and each instance of this Type share the same Methods. The NodeId of these Methods will be fixed and defined in this standard. FDI Clients therefore do not have to browse for these Methods. They can use the fixed NodeId as the MethodId of the Call Service. The OPC UA StatusCode Bad_MethodInvalid shall be returned from the Call Service for elements where the ActionService Methods are not supported. < ActionIdentifier > stands for one or several Actions. Actions (Objects of ActionType) exist only in instances of the ActionServiceType, i.e., when an instance of this ObjectType is added to a TopologyElement. No Actions (Objects of ActionType) exist in the ActionServiceType itself. ActionService Object The support of the ActionService for an Object is declared by aggregating an instance of the ActionService Type as illustrated in Figure 16. Next >