< PreviousField Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 9 of 67 1 Scope This part of FCG TS62769 defines the FDI Information Model. One of the main tasks of the Information Model is to reflect the topology of the automation system. Therefore it represents the devices of the automation system as well as the connecting communication networks including their properties, relationships, and the operations that can be performed on them. The types in the AddressSpace of the FDI Server constitute some kind of catalogue, which is built from FDI Packages. The fundamental types for the FDI Information Model are well defined in OPC UA for Devices (IEC 62541-100). The FDI Information Model specifies extensions for a few special cases and otherwise explains how these types are used and how the contents are built from elements of DevicePackages. The overall FDI architecture is illustrated in Figure 1. The architectural components that are within the scope of this document have been highlighted in this illustration. FDI Server Information Model Management OPC UA FDI Package Device Definition Business Logic User Interface User Interface Plug-in Information Model FDI Client Device Access Services User Interface Services Platform UI Services (Drawing, Input Devices) Hosting Services User Interface Plug-in FDI Package Device Definition Business Logic User Interface Description Business Logic Processor OPC UA Services Device Object Device Object Device Object User Interface Plug-in UID Interpreter Business Logic Interface Business Logic User Interface Description Communication Server UID Data Store System Services System Communication Hardware OPC UA Client OPC UA OPC UA Services OPC UA Services UIP Services Specified by this part of this International Standard Specified by other parts of this International Standard Not specified by this International Standard Figure 1 – FDI architecture diagram 2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. IEC 61784-1, Industrial communication networks – Profiles – Part 1: Fieldbus profiles Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 10 of 67 FCG TS61804-3 1 , Function blocks (FB) for process control and Electronic Device Description Language (EDDL) – Part 3: EDDL syntax and semantics IEC 62541-3, OPC unified architecture – Part 3: Address Space Model IEC 62541-4, OPC unified architecture – Part 4: Services IEC 62541-5, OPC unified architecture – Part 5: Information Model IEC 62541-6, OPC unified architecture – Part 6: Mappings IEC 62541-8, OPC unified architecture – Part 8: Data Access IEC 62541-100, OPC unified architecture – Part 100: OPC UA for Devices FCG TS62769-1, Field Device Integration (FDI) – Part 1: Overview FCG TS62769-2, Field Device Integration (FDI) – Part 2: FDI Client FCG TS62769-4, Field Device Integration (FDI) – Part 4: FDI Packages FCG TS62769-7, Field Device Integration (FDI) – Part 7: FDI Communication Devices 3 Terms, definitions, abbreviated terms, acronyms and conventions 3.1 Terms and definitions For the purposes of this document, the terms and definitions given in FCG TS62769-1 apply. 3.2 Abbreviated terms and acronyms For the purposes of this document, the abbreviated terms and acronyms given in FCG TS62769-1 as well as the following apply. HMI Human Machine Interface SCADA Supervisory Control and Data Acquisition TCP Transmission Control Protocol 3.3 Conventions for graphical notation OPC UA defines a graphical notation for an OPC UA AddressSpace. It defines graphical symbols for all NodeClasses and how different types of References between Nodes can be visualized. Figure 2 shows the symbols for the NodeClasses used in this standard. NodeClasses representing types always have a shadow. 1 To be published. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 11 of 67 Object Variable Method ObjectType DataType ReferenceType VariableType Figure 2 – OPC UA Graphical Notation for NodeClasses Figure 3 shows the symbols for the ReferenceTypes used in this standard. The Reference symbol is normally pointing from the source Node to the target Node. The only exception is the HasSubType Reference. The most important References such as HasComponent, HasProperty, HasTypeDefinition and HasSubType have special symbols avoiding the name of the Reference. For other ReferenceTypes or derived ReferenceTypes the name of the ReferenceType is used together with the symbol. Hierarchical Reference NonHierarchical Reference HasComponent HasProperty HasTypeDefinition HasSubType HasInputVars Figure 3 – OPC UA Graphical Notation for References Figure 4 shows a typical example for the use of the graphical notation. Object_A and Object_B are instances of the ObjectType_Y indicated by the HasTypeDefinition References. The ObjectType_Y is derived from ObjectType_X indicated by the HasSubType Reference. The Object_A has the components Variable_1, Variable_2 and Method_1. To describe the components of an Object on the ObjectType the same NodeClasses and References are used on the Object and on the ObjectType such as for ObjectType_Y in the example. The Nodes used to describe an ObjectType are instance declaration Nodes. To provide more detailed information for a Node, a subset or all Attributes and their values can be added to a graphical symbol (see for example Variable_1, the component of Object_A in Figure 4). Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 12 of 67 Types Object_B Variable_1 Variable_2 Method_1 ObjectType_Y ObjectType_X Object_A Variable_1 Variable_2 Method_1 Variable_1 Variable_2 Method_1 DataType = Int32 Value = -22 AccessLevel = Read Figure 4 – OPC UA Graphical Notation Example To improve readability, this document frequently includes the type name inside the instance box rather than displaying both boxes and a reference between them. This optimization is shown in Figure 5. ObjectType_Y: Object_B BaseVariableType: Variable_1 AnalogItemType: Variable_2 Method_1 Figure 5 – Optimized Type Reference 4 Overview of OPC Unified Architecture 4.1 General The main use case for OPC standards is the online data exchange between devices and HMI or SCADA systems. In this use case the device data is provided by an OPC server and is consumed by an OPC client integrated into the HMI or SCADA system. OPC provides functionality to browse through a hierarchical namespace containing data items and to read, write and monitor these items for data changes. OPC UA incorporates features like Data Access, Alarms and Historical Data via platform independent communication mechanisms and generic, extensible and object-oriented modelling capabilities for the information a system wants to expose. The current version of OPC UA defines an optimized binary TCP protocol for high performance intranet communication as well as a mapping to Web Services. The abstract service model does not depend on a specific protocol mapping and allows adding new protocols in the future. Features like security, access control and Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 13 of 67 reliability are directly built into the transport mechanisms. Based on the platform independence of the protocols, OPC UA servers and clients can be directly integrated into devices and controllers. The OPC UA information model provides a standard way for Servers to expose Objects to Clients. Objects in OPC UA terms are composed of other Objects, Variables and Methods. OPC UA also allows relationships to other Objects to be expressed. The set of Objects and related information that an OPC UA Server makes available to Clients is referred to as its AddressSpace. The elements of the OPC UA Object Model are represented in the AddressSpace as a set of Nodes described by Attributes and interconnected by References. OPC UA defines various classes of Nodes to represent AddressSpace components most importantly Objects, Variables, Methods, ObjectTypes, DataTypes and ReferenceTypes. Each NodeClass has a defined set of Attributes. Objects are used to represent components like folders, Devices or Networks. An Object is associated to a corresponding ObjectType that provides definitions for that Object. Variables are used to represent values. Two categories of Variables are defined, Properties and DataVariables. Properties are Server-defined characteristics of Objects, DataVariables and other Nodes. Properties are not allowed to have Properties defined for them. An example for Properties of Objects is the Manufacturer Property of a Device. DataVariables represent the contents of an Object. DataVariables may have component DataVariables. This is typically used by Servers to expose individual elements of arrays and structures. This standard uses DataVariables mainly to represent the Parameters of Devices. 4.2 Overview of OPC UA Devices The OPC Unified Architecture for Devices (DI) (IEC 62541-100) standard is an extension of the overall OPC Unified Architecture standard series and defines information models associated with Devices. IEC 62541-100 describes three models which build upon each other as follows: • The (base) Device Model is intended to provide a unified view of devices irrespective of the underlying device protocols. • The Device Communication Model adds Network and Connection information elements so that communication topologies can be created. • The Device Integration Host Model finally adds additional elements and rules required for host systems to manage integration for a complete system. It allows reflecting the topology of the automation system with the devices as well as the connecting communication networks. The Devices information model specifies different ObjectTypes and other AddressSpace elements used to represent Devices and related components such as the communication infrastructure in an OPC UA AddressSpace. The main use cases are Device configuration and diagnostic but it allows a general and standardized way for any kind of application to access Device related information. Figure 6 shows an example for a temperature controller represented as Device Object. It is a DeviceType Object that is a subtype of TopologyElementType and inherits all components of this type. The component ParameterSet contains all Variables describing the Device. The component MethodSet contains all Methods provided by the Device. Components of the FunctionalGroupType are used to collect the Parameters and Methods of the Device into logical groups. The FunctionalGroupType and the grouping concept are defined in IEC 62541-100 but the groups are DeviceType specific, i.e., the groups ProcessData and Configuration are defined by the TemperatureControllerType in this example. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 14 of 67 FunctionalGroupType: ProcessData TemperatureControllerType: Device1 BaseObjectType: ParameterSet Organizes BaseObjectType: MethodSet Start Stop FunctionalGroupType: Configuration Organizes Organizes Temperature TemperatureSetpoint Organizes ChangeSetpoint Organizes RunState Organizes Figure 6 – OPC UA Devices Example: Functional Groups Another IEC 62541-100 concept is illustrated in Figure 7. The ConfigurableObjectType is used to provide a way to group sub components of a Device and to indicate which types of sub components can be instantiated. The allowed types are referenced from the SupportedTypes folder. This information can be used by configuration clients to allow a user to select the type to instantiate as sub component of the Device. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 15 of 67 Block-oriented Device DeviceType TopologyElement Type Some Block Device BlockType: <BlockIdentifier> FolderType: SupportedTypes Organizes 0..n ConfigurableObjectType: Blocks BlockType 1..1 1..1 FFProfi Figure 7 – OPC UA Devices example: Configurable components The SupportedTypes folder can contain different subsets of ObjectTypes for different instances of the Block- oriented Device depending on their current configuration since the list contains only types that can be instantiated for the current configuration. 5 Concepts 5.1 General The FDI Server provides FDI Clients access to information about Device instances and Device types regardless of where the information is stored, for example, in the Device itself or in a data store. This information is provided via OPC UA Services and is called the FDI Information Model. The FDI Information Model specifies the entities that may be accessed in the FDI Server, including their properties, relationships, and the operations that can be performed on them. Which types of Devices or other topological elements are available in a given FDI Server is driven largely by the information in the FDI Packages. 5.2 Device topology One of the main tasks of the Information Model is to reflect the topology of the automation system. Therefore, the Information Model represents the devices of the automation system as well as the connecting communication networks. The entry point Device Topology is the starting point within the Information Model for the topology of the automation system. The entry point Communication Devices contains the communication devices that are used by the FDI Server to access the elements of the topology. Figure 8 and Figure 9 illustrate an example configuration and the configured topology as it will appear in the FDI Server AddressSpace (details left out). Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 16 of 67 Figure 8 – Example of an automation system The PC in Figure 8 represents the FDI Server box. The FDI Server communicates with devices connected to Network “A” via a Native Communication, and it communicates with devices connected to Network “B” via a Nested Communication. “A” CP Device 2 PC1 Network ”A” Network ”B” CPU CPU Station 1 Station 2 Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5 , Ed. 1.2.0, 22 Jul 2019 Page 17 of 67 Device Topology Network “B” Network “B” Device B_CP 2 Station 1 CPU CP Network “A” A_CP 1 Network “A” Card FolderType: Objects Station 2 CPU B_CP 1 DeviceSet Organizes ConnectsTo ConnectsTo ConnectsTo B_ CP 0 ConnectsToParent A_CP 0 ConnectsToParent NetworkSet Entry Points Device Network ConnectionPoint Figure 9 – Example of a Device topology Coloured boxes are used to easily recognize the various types of information. Brown boxes represent the networks. Light blue boxes represent the Devices and light yellow is used for Connection Points. Light pink boxes represent the entry points that assure common behaviour across different implementations: • DeviceTopology: Starting node for the topology configuration. • DeviceSet: All instantiated Devices are components of this Object, i.e., they exist in the AddressSpace independently of the Device Topology. • NetworkSet: All Networks are components of this Object. 5.3 Online/offline Management of the Device Topology is a configuration task, i.e., the elements in the topology (Devices, Networks, and Connection Points) are usually configured “offline” and – at a later time – will be validated against their physical representative in a real network. Field Device Integration (FDI) – Part 5: Information Model RELEASED FCG TS62769-5, Ed. 1.2.0, 22 Jul 2019 Page 18 of 67 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 the online and offline representation and allows navigating between them. 5.4 Catalogue (Type Definitions) The supported (sub-types of) TopologyElements are organised as Type definitions in the OPC UA AddressSpace forming some kind of a catalogue. These definitions typically are generated based on descriptive information from FDI Packages. The Type definitions contain the Parameters, and default values for Parameters, Methods, Actions and Functional Groups including user interface elements. The FDI Server can include folders in the type model to organise the types according to manufacturer or other criteria. Type definitions can then be used to create instances of Devices in the OPC UA AddressSpace. Instances can be created either offline or based on data determined by Scanning. Figure 10 illustrates an example of some Type definitions (details left out) as they may exist in the AddressSpace. Catalogue Basic Types defined in OPC UA Companion Standard for Devices ProtocolType MfgADevB0101 Type MfgMDevN0101 Type MfgPDevQ0101 Type FFBusType HARTBusTypePROFIBusType DeviceType Blocks Blocks Figure 10 – Example Device Types representing a catalogue 5.5 Communication In order to integrate Devices, the FDI Server needs to be able to communicate to them. This can be done using Native Communication or Nested Communication. The example in Figure 9 above for instance specifies that the FDI Server has direct access to the PROFINET Network using its PROFINET network card. In order to access “Station 2”, the FDI Server has to go through Station 1, which provides the communication services for the PROFIBUS DP Network (see IEC 61784-1, CPF 3). This can be achieved through Nested Communication, which is specified in FCG TS62769-4. Communication Devices and Communication Servers are specified in FCG TS62769-7. 5.6 Semantic Information The Type System of OPC UA already provides means to express the semantic of an Object. As an example, The Devices Companion Specification defines the DeviceType ObjectType expressing that instances of this ObjectType represent devices. However, the detailed semantic of the device is not specified further. Semantic information provides a means to represent that an Object has the semantic differential pressure transmitter for instance. This allows clients to automatically retrieve and identify such devices. Next >