< PreviousField Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1 , Ed. 1.2.0, 21 Jun 2019 Page 9 of 29 Offline Data device information maintained by an FDI Server that is stored in an FDI Server specific database Online Data device information maintained by an FDI Server that is retrieved from a physical device User Interface Services UI Services set of services through which a User Interface Plug-in accesses the operating system platform User Interface Services platform UI Services user interface services provided natively by the operating system User Interface Description UID descriptive element of an FDI Package that is used by an FDI Client to render user interface User Interface Description interpreter UID interpreter software component in an FDI Client that renders User Interface Descriptions and invokes Actions User Interface Plug-in UIP executable element of an FDI Package that is executed by an FDI Client User Interface Plug-in Services UIP Services set of services through which an FDI Client interacts with a User Interface Plug-in 3.2 IEC TR 62541-1 terms (OPC UA) For the purposes of this document, the terms and definitions given in IEC TR 62541-1 apply. AddressSpace Attribute Client Method Node NodeClass Notification Object ObjectType Reference Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1, Ed. 1.2.0, 21 Jun 2019 Page 10 of 29 ReferenceType Server Service Set Session Subscription Variable 3.3 IEC 62541-3 (OPC UA) terms For the purposes of this document, the terms and definitions given in IEC 62541-3 (OPC UA) and the following apply. Aggregates ArrayDimensions AuditEvent AuditUpdateMethodEvent BrowseName ByteString DataType DataVariable Folder HasComponent HasProperty HasSubType HasTypeDefinition ModellingRule NodeId Property UserAccessLevel UserExecutable Value ValueRank 3.4 IEC 62541-4 (OPC UA) terms For the purposes of this document, the terms and definitions given in IEC 62541-4 (OPC UA) apply. AddReferences Browse BrowseNext Call CreateSession NodeManagement Read Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1 , Ed. 1.2.0, 21 Jun 2019 Page 11 of 29 Request Header Response Header StatusCode TranslateBrowsePathsToNodeIds UserIdentityToken Write 3.5 IEC 62541-5 (OPC UA) terms For the purposes of this document, the terms and definitions given in IEC 62541-5 apply. BaseObjectType PropertyType 3.6 IEC 62541-100 (OPC UA for Devices) terms For the purposes of this document, the terms and definitions given in IEC 62541-100 apply. Block Device DeviceType Parameter 3.7 Abbreviated terms and acronyms DTM Device Type Manager EDD Electronic Device Description EDDL Electronic Device Description Language FB Function blocks FDI Field Device Integration FDT ® 1 Field Device Tool (see IEC 62453) GUI Graphical User Interface n/a Not applicable OPC Open packaging conventions OPC UA OPC Unified Architecture (see IEC 62541) PC Personal computer PNO PROFIBUS Nutzerorganisation e. V. (is a regional organization of the PROFIBUS and PROFINET International consortium) RPC Remote Procedure Call UI User Interface UID User Interface Description UIP User Interface Plug-in 1 FDT logo is a trade name of the non-profit organization FDT Group AISBL. This information is given for the convenience of users of this part of FCG TS62769 and does not constitute an endorsement by IEC of the trade names holder or any of its products. Compliance does not require use of the registered trade name. Use of the trade names requires permission of the trade name holder. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1, Ed. 1.2.0, 21 Jun 2019 Page 12 of 29 UUID Universally unique identifier XML Extensible markup language ZVEI Zentralverband Elektrotechnik- und Elektronikindustrie e. V. 3.8 Conventions Capitalization of the first letter of words beyond those defined in ISO/IEC Directives Part 2 is used in the FCG TS62769 series to emphasize an FDI specific meaning. It is used for the following cases: • Defined terms • Names of Services defined in FCG TS62769-2 • Names of FDI Package elements defined in FCG TS62769-4 • Names of Information Model elements defined in FCG TS62769-5 EDD language elements are written with all letters in uppercase. 4 Background 4.1 Motivation In today’s automation systems field devices from many different suppliers have to be integrated into the system, which results in additional effort for installation, version management and operation of these devices. This challenge is best met with an open and standardized device integration solution. Two different device integration technologies exist: the Electronic Device Description Language (EDDL) according to IEC 61804 and the Field Device Tool (FDT ® ) according to IEC 62453. While these technologies take different approaches to solve the problem, there is a lot of overlap between them. This has led to a situation where the technologies compete with each other instead of complementing each other. As a result, system suppliers have taken their positions, device suppliers have had to double their efforts in order to support EDDL and FDT ® , and the end users have become frustrated because they want the best of both technologies. For all parties involved the ideal solution looks different. System suppliers want to achieve robustness while assuring a high level of technology and platform independence. Device suppliers want to support only one technology instead of two in order to reduce cost and effort, and they want to provide the optimal means for operating their devices. End users want to avoid false investments and therefore demand only one future-proof solution that offers all the advantages of the competing technologies. 4.2 Electronic Device Description Language (EDDL) The Electronic Device Description Language (EDDL) is a language for describing the behavior of field devices. It enables systems to configure, calibrate, troubleshoot, and operate a field device without any prior knowledge of the device. Device descriptions written in EDDL describe the capabilities of the field device; it is up to the system to determine how to utilize these capabilities. These device descriptions enable systems to access all the data and properties of all devices, which simplifies the maintenance, support, and operation of the devices. It works well for small handheld applications and large integrated automation systems. It works well for embedded systems and systems running on commercial operating systems. With EDDL, the device supplier can organize the device's data, properties, and procedures for access by the end user. This provides the system guidance in dynamically creating a user interface for the device. The capabilities of this user interface can vary significantly for different classes of devices, and it can be as simple or complex as the device being described. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1 , Ed. 1.2.0, 21 Jun 2019 Page 13 of 29 In the early 1990s, the first version of EDDL was created and was used to describe HART field devices. In 1996, the EDDL was used to describe F OUNDATION Fieldbus devices. Then in 2000 it was used to describe PROFIBUS devices. All three versions of EDDL can trace their lineage back to the original HART version. Therefore, all three versions are largely the same, with some differences due to differences in the underlying communication protocols. EDDL was standardized first as part of IEC 61804-3 and IEC 61804-4 in March 2004. 4.3 Field Device Tool (FDT ® ) FDT ® is an interface specification that standardizes the interface between the device software and the systems. It provides independence from the communication protocol and establishes a clear boundary between the software provided by the device supplier and the software provided by the system supplier. In FDT ® , field devices are delivered with a device-specific software component called a Device Type Manager (DTM), which is only functional when used in conjunction with an FDT ® -specific environment called a "frame application". A frame application interacts with a DTM through a set of standard FDT ® interfaces. A device supplier can develop a DTM for each of its devices, or it can develop a DTM for a group of devices. A DTM can be used to access Device Parameters, configure and operate the device, and diagnose problems. A DTM can range from a simple Graphical User Interface (GUI) for setting Device Parameters to a highly sophisticated application for performing complex calculations for diagnosis. DTMs can be nested in order to support Modular Devices. The nesting of DTMs also allows multi-level communication hierarchies to be supported. Devices routed through different bus protocols can be connected through standard interfaces. A device DTM just has to support its own communication protocol. Gateway DTMs that connect to the device DTM handle protocol transformation. The FDT ® specification supports a variety of bus protocols, for example: PROFIBUS, HART, F OUNDATION Fieldbus, Interbus, AS-interface, IO-Link, DeviceNet, and PROFINET IO. In 1998, the specification phase started in the context of the Zentralverband Elektrotechnik und Elektronikindustrie e. V. (ZVEI). In 1999, completion of the technology was accelerated when the specification was adopted by PROFIBUS Nutzerorganisation e. V. (PNO), which later transferred the rights to the FDT Group AISBL. FDT ® was standardardized as IEC 62453-1 in May 2009. 4.4 OPC Unified Architecture (OPC UA) OPC Unified Architecture (OPC UA) is a platform-independent standard through which various kinds of systems and devices can communicate by sending messages between clients and servers over various types of networks. It supports robust, secure communication that assures the identity of clients and servers and resists attacks. OPC UA defines standard sets of services that servers can provide, and individual servers specify to clients what service sets they support. The services act on an object model which is managed by the server and discoverable by a client. Information is conveyed using standard and vendor-defined data types, and servers define object models that clients can dynamically discover. Servers can provide access to both current and historical data, as well as alarms and events to notify clients of important changes. OPC UA can be mapped onto a variety of communication protocols and data can be encoded in various ways to trade off portability and efficiency. Transports and encodings for XML based Web Services as well as a high performance binary are defined for OPC UA. The abstraction of the OPC UA standard from any particular technology provides future-proofing allowing OPC UA to be mapped onto future technologies. The integration of system components includes a “how” factor and a “what” factor. The comprehensive set of services provided by OPC UA enables the “how” of system integration. OPC UA also provides the basic building blocks of the “what” of system integration by defining an extensible object model. Other standards bodies, vendors, and end users can extend this object model to achieve a tight integration between system components. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1, Ed. 1.2.0, 21 Jun 2019 Page 14 of 29 OPC UA is standardized in IEC 62541. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1 , Ed. 1.2.0, 21 Jun 2019 Page 15 of 29 5 Architecture 5.1 Overview The FDI architecture consists of FDI Packages, FDI Clients, and FDI Servers as shown in Figure 1. 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 International Standard Not specified by this International Standard Figure 1 – FDI architecture diagram 5.2 FDI Packages FDI Packages are the means by which device vendors provide information about their devices to system vendors. FDI Packages collect all of the device information required by a system vendor in one place. FDI Packages are system independent, i.e., device vendors provide the same FDI Package to all system vendors. An FDI Package includes the following: • Device Definition – Core definition of the device that is used by an FDI Server to create the Information Model. • Business Logic – Ensures the integrity of the Information Model. • User Interface Description – Declarative user interface that is rendered by an FDI Client via a UID Interpreter. • User Interface Plug-in – Optional programmed user interface that is hosted by an FDI Client. The Device Definition and Business Logic are used exclusively by an FDI Server. The User Interface Description is processed by the FDI Server and transferred to the FDI Client. User Interface Plug-ins are not processed by the FDI Server, beyond what is necessary to deliver them to the FDI Client. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1, Ed. 1.2.0, 21 Jun 2019 Page 16 of 29 The Device Definition, Business Logic, and User Interface Description are completely platform independent. User Interface Plug-ins shall be targeted at a specific run-time environment. Distinct User Interface Plug-ins can be developed for different run-time environments, but a specific User Interface Plug-in will only run on a single run- time environment. The content of an FDI Package is specified in FCG TS62769-4. 5.3 FDI Client FDI Clients interpret and render descriptive user interface contents (UID, Device Parameter values and so on) that are delivered to an FDI Client via the Information Model of an FDI Server in a specified format and through defined services. Interpretation of the EDD portion of an FDI Package however is only done in the FDI Server. In addition FDI Clients also host User Interface Plug-ins. The environment for hosting User Interface Plug-ins consists of four sets of services: the Hosting Services, the UIP Services, the User Interface Services, and the Device Access Services. • The Hosting Services provide the means by which a User Interface Plug-in interacts with the FDI Client. • The UIP Services provide the means by which an FDI Client can activate, control, and shutdown the User Interface Plug-in. • The User Interface Services provide the means by which a User Interface Plug-in accesses the operating system specific Platform UI Services, which provide access to the screen, keyboard, mouse, and so on. • The Device Access Services provide the means by which a User Interface Plug-in accesses the Information Model in an FDI Server. The behavior of an FDI Client is specified in FCG TS62769-2. 5.4 FDI Server FDI Servers provide 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 can be provided via OPC UA services. The Information Model specifies the entities that can be accessed in an FDI Server, including their properties, their relationships, and the operations that can be performed on them. The Information Model is driven largely by the Device Definitions in FDI Packages. The Information Model is based on the Information Model specified in the OPC UA Devices Specification. The FDI Server invokes the Business Logic in FDI Packages as entities in the Information Model are accessed. One of the main purposes of the Business Logic is to keep the Information Model consistent. The Business Logic Interface is the means by which Business Logic is integrated with the Information Model. This interface consists of a set of well-defined Business Logic entry points, which can be used by the Information Model to invoke Business Logic, and a set of well-defined Information Model entry points, which can be used by the Business Logic to access the Information Model. An FDI Server shall support all elements of an FDI Package. Some of the information managed by an FDI Server shall be stored persistently. The means by which this data is stored is server specific. The behavior of an FDI Server is specified in FCG TS62769-3, and the Information Model is specified in FCG TS62769-5. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1 , Ed. 1.2.0, 21 Jun 2019 Page 17 of 29 5.5 FDI Communication Server An FDI Server inherently knows how to communicate with devices via the communication hardware it natively supports. In addition, an FDI Communication Server can be used to extend the devices that the FDI Server can communicate with. An FDI Server communicates with an FDI Communication Server via standard communication services that are specified in FCG TS62769-7. 5.6 User Interface tiering There are three tiers of user interfaces that can be developed using FDI. The lowest tier is a User Interface Description based user interface. This kind of user interface is completely defined by a User Interface Description. It is the easiest user interface to create, but it also has the most limitations. This kind of user interface is sufficient for relatively simple devices. The second tier is a User Interface Plug-in based user interface. This kind of user interface is defined via the combination of a User Interface Description and one or more User Interface Plug-ins. This is a more complicated user interface to build since it involves some software development, but it also can produce a more sophisticated user interface. This kind of user interface is required for some complex devices. The third tier is an FDI Client. An FDI Client may access multiple devices, while User Interface Descriptions and User Interface Plug-ins may only access a single device. This kind of user interface is required when access to multiple devices is required. 5.7 FDI security considerations FDI is used between components in the operation of an industrial facility at multiple levels: from high-level enterprise management applications accessing device data to low-level direct process control of a device. Such a system may be an attractive target for industrial espionage or sabotage, and may also be exposed to threats through untargeted malware such as worms circulating on public networks. Corrupted device configurations could result in financial losses, affect employee and public safety, or cause environmental damage. FDI relies on many other systems within the industrial facility. The FDI Clients and Servers are installed on IT systems. Standard communication protocols such as OPC UA and field bus protocols are used for communication between the FDI Clients and the FDI Server as well as between the FDI Server and the devices. Therefore, FDI security should work within the overall Cyber Security Management System (CSMS) of a site. A CSMS typically addresses threats, analyses the security risks and determines what security controls the site needs. Resulting security controls commonly implement a “defence-in-depth” strategy that provides multiple layers of protection and recognizes that no single layer can protect against all attacks. Boundary protections may include firewalls, intrusion detection and prevention systems, controls on dial-in connections, and controls on media and computers that are brought into the system. Protections in components of the system may include hardened configuration of the operating systems, security patch management, anti-virus programs, and not allowing email in the control network. Standards that may be followed by a site include the IEC 62443 series [2] and IEC TR 62351- 10 [1]. The system owner that installs FDI Clients or Servers should analyse its security risks and provide appropriate mechanisms to mitigate those risks to achieve an acceptable level of security. Developers of FDI Clients and Servers should analyse security threats to the system and implement appropriate countermeasures. The threats and appropriate countermeasures depend on the technologies used for implementation and fall outside the scope of the FDI specification. Field Device Integration (FDI) – Part 1: Overview RELEASED FCG TS62769-1, Ed. 1.2.0, 21 Jun 2019 Page 18 of 29 5.8 Redundancy Redundancy is system specific and managed by the automation system. FDI Packages are specified without regard to redundancy. User Interface Descriptions and User Interface Plug-ins have no knowledge about the redundancy of the devices they are associated with. 6 Deployment 6.1 Overview The FDI specification does not mandate a specific deployment strategy. However, a typical deployment scenario is shown in Figure 2. The shaded boxes correspond to the components described in 5.2, 5.3, 5.4, and 5.5. Server I/O Subsystem Devices I/O Subsystem Devices L2 FDI Server L3 L4 ERPCMMS Firewall Firewall MES Device Tool / Handheld Tool FDI Server FDI Client Operator Station FDI Client Engineering Station FDI Client Maintenance Station FDI Client Third-party Tool FDI Client Generic OPC Client OPC Client FDI Package FDI Package Handheld Tool FDI Client Controller I/O Subsystem Devices Communication Server Comm. Services Communication Device Devices Connects directly to devices. Figure 2 – Typical deployment scenario 6.2 Engineering, operator and maintenance stations The engineering, operator and maintenance stations are part of an automation system through which users engineer, operate and maintain their plant. One or more FDI Clients can be running on these stations. These FDI Clients are full-featured clients that can interpret User Interface Descriptions and execute User Interface Plug-ins. Next >