FDT Technical Description

Transcription

1 FDT Technical Description Open access to device intelligence

2 Contents FDT at a glance...3 Strengths of FDT...6 Organization...8 Technical description...9 Technical orientation...9 Device Type Manager...9 FDT Frame Application...9 Channels...10 Architecture...10 DTM interfaces Channel interfaces...12 FDT Frame Application interfaces...12 Nested communication...13 Scenarios...14 Scalability...15 Scanning example...15 DTM implementation...16 DTM style guide...17 Certification process...18 Contact...21 Abbreviations...22 Figures...23 Imprint...24

3 FDT at a glance FDT is an interface specifi cation that standardizes the data exchange between field devices and control systems or engineering and asset management tools. FDT enables easy device access and confi guration through any host system that provides the interface. FDT is not a new fieldbus protocol. It can be used with any communication protocol. FDT is vendor independent and established as an open publicly available specification. Field Information from processes is required during the entire life cycle of a plant or application. FDT supports all phases of a plant life cycle: engineering, installation, commissioning, production, and maintenance. In this documentation, a DTM is represented by the adjoining symbol. A FDT Frame Application is represented by the adjoining symbol. End users need an open technology that preserves the investments made in installed field devices. Replacement or costly upgrades of the installed base have to be avoided. Seamless data exchange from devices to asset management applications is also required by end users. Vendors do not want to adapt their software to different engineering environments. There shall be a single component supporting the capabilities of the device which interoperates with many host systems. and how they are achieved with FDT Broadly speaking, the FDT system can be compared to the printer driver system known from office applications. The printer is delivered with the corresponding driver. That driver implements standardized interfaces so that any office application can make use of it. In FDT, the hardware (the field device in this case) is delivered with a driver called Device Type Manager (DTM), which has the standardized FDT interface (Figure 1). This enables any FDT-enabled application (FDT Frame Application) e. g. engineering system or asset management tool to use it. Both DTM and FDT Frame Application are described in this chapter. Demands End users are demanding a single engineering environment to manage, commission, and confi gure any field device, from any device manufacturer, and connected to any fieldbus communication protocol. They want the flexibility to select any supplier s product and not be restricted to a specific vendor. End users need an open technology that preserves the investments made in installed field devices. Replacement of the installed base has to be avoided. Users want a technology that enables them to make use of any field device without restrictions. They want to be able to select the best device fit for their application and access all the powerful native features of modern devices, without restriction imposed by the integration to a specific system. Figure 1 Printer driver compared to FDT 3

4 Figure 2 Any DTM can run in any FDT Frame Application FDT specifi es these standardized software interfaces. They were defined in a general way, so that it is possible to design engineering environments that could manage any device from any manufacturer using an arbitrary protocol as required by end users (Figure 2). The device vendor provides the interfaces for the DTM, including communication capabilities to the device itself but also to other DTMs. The Device Type Manager of a device from one vendor is thus able to interact with the Device Type Manager of a device from another vendor. This allows connecting products of different vendors, to have greater flexibility. It is possible to select the device best fitting the demands of the application, independent from vendor or communication protocol. A change of the current installed base is not required. The existing network of buses, communication devices and fi eld devices can be mapped to the FDT engineering system. The only thing needed is the Device Type Manager component representing the devices in the DTMs. FDT is not limited to a predefined set of description semantics or graphic elements. Anything that can be done with software is possible inside the DTMs. This allows device vendors to implement any functionality they fi nd useful for their customers and makes it easier for automation suppliers to evolve their software with the state of the art in communication and information technology. Investments in automation are protected well into the future. Automation suppliers no longer have to worry about integration problems. Development costs due to diverse environments in host systems and field devices, which used to require customized interfaces for every combination, cease to exist. Resources can be invested in specialized, differentiated features that bring benefi ts to the end users. FDT provides standard interfaces, which means that the DTM can be used either in automation systems or stand-alone asset management tools. The Device Type Manager is unique for each device type and needs to be built only once, thereby protecting vendors investments. Its content is inaccessible to third parties and the vendor s knowhow is protected. Technology The DTM encapsulates all device-specifi c data, functions, and business rules. Depending on its implementation, a DTM can range from a simple graphical user interface for setting device parameters to a highly sophisticated application that can perform extensive calculations for diagnostic or maintenance purposes or evaluate elaborate business logics for device calibration. One can distinguish between three kinds of DTMs. Device Type Managers for a device class with direct access to a communication component are named Communication DTM. DTMs which are used for routing between different protocols (i. e. from PRO- FIBUS to HART) are named Gateway DTM. A DTM that represents a fi eld device is called Device DTM. A Device DTM interacts with a Communication DTM or Gateway DTM to access its field device. 4

5 These DTMs run in a FDT Frame Application, for example device confi guration tools, control system engineering tools, operator consoles or asset management tools. The FDT Frame Application initiates the Device Type Managers and connects them for proper communication. Depending on the task of the FDT Frame Application, it uses varying functions of the DTM to perform this task. FDT Group Organization The FDT specification is specified and maintained by the FDT Group, AISBL 1. The FDT Group is a non-profit association of international companies that support the proliferation of the FDT Technology. The group is open to all automation suppliers and users that wish to participate. The mission of the FDT Group is to promote the acceptance and usage of the FDT Technology in the factory automation industry, process automation industry, and hybrid application industry. History In 1998, the specifi cation phase started in the context of the ZVEI (Zentralverband Elektrotechnik- und Elektronikindustrie e. V.). In 1999, completion of the technology was accelerated when the specification was adopted by Profi bus Nutzerorganisation e. V. (PNO), that later transferred the rights to the FDT Group. A fi rst style guide defi nition was released in 2000, defi ning guidelines for a uniform user interface for DTMs. In May 2001, the specification became publicly available in version 1.2. The new version has been available since There have been many activities concerning different protocols for FDT. PROFIBUS and HART were integrated from the start; Foundation Fieldbus (FF) and Interbus were added in a second step. Project Groups are working on further extensions for AS-interface and DeviceNet (a protocol of the Control and Information Protocol (CIP) family) as well as PROFINET IO. Other protocols will follow. At the beginning of August 2004, the test and certification tool dtminspector became available. In 2005 the fi rst independent test sites were accredited and the certification process was launched. Availability & Market Today 2, over 57 companies are supporting FDT technology. DTMs are available for hundreds of different devices. These can be used in several FDT-enabled host applications. In the summer of 2006, an extensive interoperability test was performed at the test lab of Reinhold und Mahla, an independent test service provider located in Industriepark, Höchst, DE. The test setup consisted of 26 devices and 6 frame applications from 13 suppliers. The results were communicated at the NAMUR general meeting (Nov 2006) and published in the technical literature 3. The conclusions are very clear: The FDT technology is mature. Products are stable and available in industrial grade. The technology is suitable for industrial automation applications in the chemical, petrochemical and pharmaceutical industries. Consistent plant-wide data access FDT Technology is communication independent it supports all commonly used communication protocols and fieldbus standards over all network levels. 1 Association Internationale Sans But Lucratif International not-for-profit Association 2 February atp international; 4(2006)N 3, p8 5

6 Strengths of FDT Motivation In process and manufacturing automation, a control system often compromises thousands of digital and analog input/output signals. When a fi eldbus is used, these signals are transmitted over the bus. Field devices are connected directly to the bus or via remote IO devices. Typically, many different field device types from various manufacturers are used. The devices are configured and parameterized for each task performed in the process. The devices must be made known to the control system. All signals must be created and integrated into the function planning of the control system (Figure 3). The number of different device types within a project makes the configuration difficult and timeconsuming. Until recently, different tools, one for each supplier, had to be mastered and data had to be exchanged between them and host systems. Data conversions were often necessary, requiring detailed specialist knowledge. Consistency of data, documentation, and confi gurations could only be guaranteed by an intensive system test. The workload and the complexity of the engineering task became quickly unmanageable for the already understaffed project engineering team. Simplifi cation and unifi cation of the engineering confi guration was the fi rst motivation for creating the FDT technology The main goals of the FDT specification are Central workplace for planning, commissioning, diagnostics, and maintenance service with direct access to all field devices. Integrated, consistent confi guration and documentation of the process control system, the fieldbuses, and devices. Organization of common data for the process control system and field devices. Central data management and data security. Simple and fast integration of different device types into the process control system. Native language support. Handling of multi-user scenarios. Instead of providing the device plus a tool for configuration, diagnostics, and service, the device manufacturer develops the DTM running in any tool. Figure 3 Situation without FDT 6

7 End user benefits End users are free to choose their device from the variety of devices available on the market. With FDT it is possible to integrate any device in any automation system. It is now possible to select the device that best fits the demands of the process application. The choice can be based on the features and functionality of the device independently from the integration restriction imposed by the system vendor. This includes independence from fieldbus. All data of modern fi eld devices can be obtained, even for the most sophisticated devices. Special tasks are supported through the complete life cycle of the device. This may already begin with off-line engineering. It continues with the installation and commissioning phase, where parameter download and calibration are done. At runtime of the plant, operation tasks and monitoring duties as well as diagnostics and maintenance functions are assisted. And of course, predictive maintenance functions are enabled for any type of asset management system. There is a single standard graphical interface displaying engineering and confi guration information for a device type. Users of the engineering tool can easily become familiar with it. The effort for personnel training decreases as it is no longer necessary to learn multiple different tools. A FDT system evolves with the state of the art in communication and information technology. Suppliers are free to keep enhancing the features of their devices. As long as the DTM interface is compliant, the interoperability is ensured. Investments in automation are protected well into the future. New communication protocols are constantly being added to the specification. The team working on the specification ensures backward compatibility. Supplier benefits The device vendor needs to develop just one software component. Because of the standardized interfaces FDT provides, the same DTM can be reused in any FDT Frame Applications. The DTM is unique for each device and needs to be built only once. Development costs due to diverse environments in host systems cease to exist. Integration problems no longer have to be minded. Device vendors investments are protected because the component does not need to be changed when the surrounding system changes. Device suppliers can concentrate on investing resources in specialized, differentiating features native to their products and focus on features that bring benefits to their end users. The Device Type Manager can be sophisticated, supporting high-end user interfaces or sophisticated algorithms. There is no limitation to the features that can be supported by the DTM. Everything that is possible with a modern programming language can be implemented. The vendors know-how is protected. The DTM exists in a binary form. The content of the software component is invisible to third parties. Migration to future development platforms fl ows smoothly, because the technology itself allows such an evolution. Microsoft COM technology has been chosen, being known as industry standard for developing software components. It is taken care of the continued support and the possibility to migrate to succeeding technologies. Control system provider benefit Manufacturer or device-specifi c adaptations are a concern of the past. The control system does not need extensions for new protocols or new device functions. The control system provider supplies the FDT frame application and that will give a standard interface to all DTMs. System suppliers can focus on new features in the control system. This also reduces the test effort. Beyond device configuration FDT supports more than just devices configuration or parameterization. The following examples show some highly sophisticated use cases for FDT application. Network scanning: FDT supports discovering devices connected to the bus, detecting installed communication hardware, identifying devices, and setting the fieldbus addresses. This can be used for automatic generation or verifi cation of the system topology. It is possible to detect devices which have changed. Topology import/export: FDT defi nes a way to interchange topology information. This enables data exchange between different FDT applications. The DTMs persistent data can also be exported. Audit trail: User interaction can be traced. Event related information like Device reset executed by user Operator at pm can be recorded. This can be used to set the documentation of historical data automatically. FDT supports audit trails by an extra interface. 7

8 Organization The FDT Group AISBL is a not-for-profi t association of international automation companies that support the proliferation of the FDT Technology. The FDT Group is open to all companies that wish to participate. The long-term mission of the FDT Group is to promote the acceptance and usage of FDT in the automation industry. Organizational structure The FDT Group consists of a Board of Directors (BoD), an Executive Committee (ExCom) as well as different Committees. (Figure 4) The Board of Directors is elected by the FDT Group members, the Executive Committee is then appointed by the Board of Directors. Working Groups and Project Groups are part of a Committee. A Working Group is a long-term instance. Each Working Group has a defined mission and scope. The international team is managed by a Working Group leader. Working Group members join in meetings or telephone conferences. The Executive Committee can appoint Project Groups on specifi c technical items (e. g. specifi c protocols). The Project Group is subordinate to the Working Group and only exists until the defined end of the project is reached. Activities The Committees focus on Marketing Technology, including - Specification - Test and Certification Associations and Standards End User Forum A Working Group is a long-term activity with a defi ned mission and scope. The Working Group are complemented with interoperability workshops. Suppliers meet to test DTMs and FDT Frame Applications in various combinations proving the independence of FDT concerning vendors and protocols. FDT Group AISBL Marketing Technology Business Office User Forum Associations & Standards Core Marketing Technical Working Group Chairman Administration User Forum English Standards & Associations Technical Liaison Marketing Communications Test & Certification Working Group Chairman Membership User Forum German Associations & Consortia Marketing Liaison Working Group Chairman Americas Certification Registration Working Group Chairman Europe Technical support Working Group Chairman Asia Training & Education Administration Working Group Chairman Factory Automation Finance Subcontract Documentation Figure 4 FDT Group organization structure Certification Office Lab contracting Admin 8

9 Technical description Technological orientation The combination of a software component with a hardware component introduces the Plug & Play principle for device integration into asset management tools and process control systems. As Microsoft Windows has established itself as the de facto industry standard, it has also been chosen for FDT. COM (Component Object Model) is a Microsoft platform for software components. It has a proven clientserver architecture and manages the integration of software components into the FDT Frame Application. COM is a binary standard, it is language independent and object oriented. It enables inter-process communication and dynamic object creation. A COM component exposes its functionality through interfaces. FDT defines COM interfaces for DTMs and FDT Frame Applications. Graphical user interfaces are represented by ActiveX technology. ActiveX is an extension to the COM technology, defi ning how to integrate graphical user interfaces into an application. In FDT, the ActiveX control is displayed by the FDT Frame Application and it is connected to the DTM for data exchange. Thus it seamlessly integrates into the user interface of the FDT Frame Application; nevertheless it can display the full potential of the DTM s abilities. XML (Extensible Markup Language) is a standard for the creation of data documents in a hierarchical structure. It is designed to be machine readable as well as understandable for humans. XML defi nes general rules on how to build such a document. FDT uses XML documents to exchange data between objects, i. e. between the FDT Frame Application and the DTM. FDT defi nes the structure of that XML by specifying so-called XML Schemata. The content however is provided by the DTM. In the following parts of this description it is assumed that the reader is familiar with the above named technologies. Device Type Manager The Device Type Manager (DTM) is a software component developed by the device manufacturer containing device-specifi c application software. The device manufacturer is responsible for the functionality and the quality of a DTM. The DTM is typically supplied with the device. It is not a stand-alone tool. The DTM always needs a FDT Frame Application to run. A DTM contains user dialogs and user interfaces, including a help system necessary for the application it represents. The user interface may be multilingual. The DTM is also able to generate documentation for the device. It also knows the rules of the device specific application and it performs a parameter validity check. In contrary, the DTM has no knowledge about the FDT Frame Application. A Device Type Manager may contain both parameterization and configuration e. g. processing sequences for sophisticated calibration, advanced diagnostic and maintenance functions for high-quality fi eld devices. Diagnostic functions, customized for the device, are also held by the DTM. DTMs which mainly provide communication possibilities are called Communication DTM. DTMs which support transformation between protocols (e. g. PROFI- BUS to HART) are called Gateway DTM. DTMs offering operation on a device are called Device DTM. A Device DTM suits at least one device, but it can however cover device families, for example a suite of pressure transmitters. FDT Frame Application The DTM is integrated into engineering tools or other FDT Frame Applications like stand-alone commissioning tools or asset management tools that are providing FDT interfaces. The FDT Frame Application is typically independent of any fieldbus. The approach to integration is open for all kind of fieldbuses (different protocols) and thus meets the requirements for integrating different kinds of devices into heterogeneous control systems. FDT Frame Applications manage all device instances and store the instances data but have no devicespecific knowledge. They also take care of data versioning. FDT Frame Applications guarantee system-wide consistent confi guration and make multi-user operation possible as well as client/server operation. DTMs can integrate into any FDT Frame Applications and vice versa, a FDT Frame Application can integrate any DTMs of different vendors. 9

10 Channels Communication channels To access the device, a DTM needs to be able to put data onto the bus. Therefore, FDT defined communication channels. Once a DTM needs to connect to its device, the FDT Frame Application passes the communication channel to the DTM. The communication channels can be provided by either the FDT Frame Application itself, or it can make use of communication channels which are part of a Communication DTM or a Gateway DTM. If the FDT Frame Application provides built-in communication channels, it has full control over communication and can perform low-level actions such as monitoring or fi ltering. An advantage of communication channels of a DTM is that they can easily be integrated into the system and are thus extending the number of protocols the system is able to access. Of course, both ways of providing communication channels can coexist. Process channels In addition, input and output signals provided by devices must be created and integrated into the function planning of the control system. The Device DTM offers information about IO signals of its device, such as the temperature, the current fl ow rate, or other process values. These signals are represented by process channels of the DTM. A process channel exposes for example addressing and data type information. The addressing information might be the bit position within the cyclic data transfer of PROFIBUS DPV0 or (via) Interbus, or the command number of HART. The information a channel provides is fieldbus specific information. In this brochure a FDT channel object is represented by the adjoining symbol. Architecture FDT is a specification of COM interfaces to facilitate the interaction between a device-specific application and a FDT Frame Application. Figure 5 shows the scope of FDT interfaces. Typically, the FDT Frame Application comprises client applications that use DTMs and some kind of database for persistent storage. Client applications are seen to be applications focusing on aspects like configuration, observation, or channel assignment etc. and using the functionality provided by the DTM that is the server. Figure 5 Scope of FDT interfaces 10

11 Note that the FDT specification just specifies COM interfaces, not the implementation behind those interfaces. It defines the behavior that the interfaces are expected to provide to client applications that use them. It neither specifies the implementation of DTMs nor the implementation of FDT Frame Applications. DTM Interfaces Mandatory interfaces The IDtm 2 interface is the main interface. Via this interface the DTM gets its initialization after the DTM object has been instantiated. The FDT Frame Application also uses this interface to set the DTM into on-line mode, select the language used in the user interfaces, and reset the DTM for release. The DTM s general information like vendor, version number, and the capabilities of the DTM can be accessed via the IDtmInformation interface. This allows integration of the DTM into the libraries of a FDT Frame Application and supports the planning engineer by associating the device. Instance related data of the DTM is stored via the default COM IPersistStreamInit or IPersistPropertyBag interface. It is not determined how the DTM performs storage or which kind of data of the DTM is stored, but the DTM must be able to re-establish its complete state when this is requested by the FDT Frame Application. The DTM exposes its parameters through the IDtmParameter interface. The returned information is an inmemory representation of its instance data. It depends on the device type and fi eldbus type, which parameters are available. Via IDtmDocumentation, the DTM provides device instance specific information. The returned data will be transformed into HTML, which can contain images and hyperlinks and can be printed. The base diagnosis functions required by a FDT Frame Application for DTMs with configuration parameters are defined by the IDtmDiagnosis interface. By that interface, the FDT Frame Application can find out whether the data sets of two DTMs are equal or not. In contrast, IDtmOnlineDiagnosis defines a method to compare the DTM s data set with the parameters of its device. Also, the status of a device can be determined via this interface. The DTM sometimes needs to be informed about changes in the environment. IFdtEvents provides the means to inform the DTM about locking of its data set by another DTM in a multi-user environment or about changes of parameters the DTM provides. Process channels are made available to the FDT Frame Application by the IDtmChannel interface. Via the IFdtCommunicationEvents interface, the DTM is informed about responses for its communication requests. IDtmOnlineParameter allows a FDT Frame Application to trigger uploading or downloading parameters of the device. On-line access to single device parameters is supported by IDtmSingleDeviceData Access. The DTM reveals device-specific parameters and their addressing including data type, value, status information, unit and limits. Even semantic information is included here. Similarly, but for off-line purposes, IDtmSingleInstance- DataAccess has been defined. Instead of reading and writing to the device, the DTMs off-line parameters are the addressed subject. Figure 6 Device DTM interfaces 2 Words in italic letters are names of FDT COM interfaces or methods or names of XML Schema definitions 11

12 Channel interfaces In order to represent the device s IO connections or process signals, the DTM implements FDT channel objects. Process channel interfaces This channel object implements the IFdtChannel interface which gives access to the channelspecific parameters. The channel s parameters are fieldbus-specific. Figure 7 shows a process channel and its interface. In addition, a communication channel might want to bring its own confi guration interface in form of an ActiveX control for setting up the communication itself, e. g. the baud rate or the start and stop bits. The IFdtChannelActiveXInformation interface can be used by the FDT Frame Application to get the provided ActiveX controls. Figure 8 shows the interfaces of a communication channel. Figure 7 Process channel interface Communication channel interfaces Besides the general channel interface IFdtChannel, a communication channel implements the IFdtCommunication and IFdtChannelSubTopology interfaces. IFdtChannelSubTopology is the interface the FDT Frame Application uses to add subordinate DTMs. It provides a means to verify whether or not a DTM can be added as a child as well as the ability to remove the child. It is also used for building the topology by scanning the sub-topology. IFdtCommunication defi nes methods where the FDT Frame Application can find out which protocols are supported by the channel and it has methods where a subordinate DTM can request transactions or define communication sequences. The channel supports scanning the bus for connected devices. IFdtChannel Scan is the interface for triggering the scan process. Figure 8 Communication channel interfaces FDT Frame Application interfaces Mandatory interfaces The main interface of a FDT Frame Application is IFdtContainer. The DTM can lock its data set inside a multi-user system. The IDtmEvents of a FDT Frame Application is used by the DTMs to give information about the change of their on-line state, their available functions or parameters, and the completion of executed functions. Via IFdtDialog, the DTM may open a dialog to show messages like errors, warnings, or information. With IFdtTopology, the FDT Frame Application provides access to the system topology. Thus the DTM can get information about the child DTMs connected to its channels as well as add or remove child DTMs from its channels. 12

13 For DTMs providing audit trail information, the FDT Frame Application implements IDtmAuditTrailEvents. The FDT Frame Application can then record the data and display it on the user interface. Task related interfaces For temporary storage of large amount of data such as logs of measured data or historical values of configuration changes, the FDT Frame Application can provide a temporary storage path for the DTM via the IFdtBulk- Data interface. If the FDT Frame Application supports scanning of the topology, it also provides a IDtmScanEvents interface so that the DTM can respond with the results of the scanning process. A DTM can use the events of the IDtmRedundancy- Events interface to reflect its redundancy capabilities. If the FDT Frame Application provides capabilities to set single device parameters it must support the event interfaces IDtmSingleDeviceDataAccessEvents and/or IDtmSingle Instance Data Access Events. Figure 9 shows the interfaces of a FDT Frame Application. Nested Communication In the following, an arrangement of devices is regarded (Figure 10). The devices are arranged hierarchically and are interconnected through different fieldbuses. It is up to the planning engineer using the FDT Frame Application to connect the DTMs accordingly. The FDT Frame Application starts one DTM for each field device. DTM A is a Communication DTM providing a communication channel. DTMs B and C in the fi gure support gateway functionality. Thus, they also provide communication channels. In case a parameter download is initiated for Device DTM D, the DTM does not directly access its field device. Instead, it passes the parameters to the communication channel of its superior DTM, which is DTM B. DTM B then transforms the request from PROFIBUS to Ethernet. It passes the result to the channel object of the Communication DTM. The communication channel is now able to pass the data to the PC s Ethernet plug-in card. Data is then transmitted via Ethernet to the controller. It transforms the Ethernet packets into PROFIBUS telegrams and sends them to the appropriate field device. As seen in the example, FDT provides a way to support different fieldbuses and to access devices from a central engineering system. The DTM does not need to have a direct connection to the fi eld device, as it used to have for traditional stand alone tools (as seen in Figure 3). The example also indicates that the DTM does not need to have knowledge about the network topology. It just has to support its own communication protocol. Superior connected Gateway DTMs will take care of protocol transformation. Of course Ethernet and PROFIBUS were just examples. The described mechanism also works for more hierarchical levels as shown in Figure 10 for an additional PROFIBUS-HART coupler (C) and an additional HART device (D). For other protocols, the example would have been similar. Figure 9 FDT Frame Application interfaces 13

14 Figure 10 Nested Communication Scenarios Service tool FDT can be used to build a service tool, which is used for configuration and parameterization in the field. This could be seen as a replacement for standalone tools described in Figure 3. The service tool typically uses a point-to-point connection and the devices are detected by scanning the network. The current configuration is uploaded into the DTM and then changed directly in the device. The configuration changes can be printed for archiving. FDT supports this scenario: Building the topology by scanning the network using IFdtChannelScan and IDtm Scan Events. Uploading confi guration and parameters from the device by IDtmOnlineParameter. Confi guration and parameterization by opening ActiveX user interfaces of the DTM via IDtmActiveXInformation. Printing the configuration by IDtm-Documentation. Engineering tool An engineering tool can also profi t from FDT. The topology is typically planned in off-line mode and later verified by scanning the network. Sometimes data is planned outside and imported. The DTMs are pre-confi gured in off-line mode; the data is downloaded to the device when it is available. The engineering tool keeps track of configuration changes and archives historical data. In addition, audit trail information is recorded. FDT is involved in: Verifying the planned topology by IFdtChannelScan and IDtm Scan Events. Pre-configuration by opening ActiveX user interfaces via IDtm ActiveX Information. Detection of configuration changes by IDtm Diagnosis. Recording audit trail information by IDtm Audit TrailEvents. Bus master configuration The communication master can be configured using a FDT enabled tool. FDT provides the means for: Getting master configuration data (GSD in case of PROFIBUS) via IDtm Parameter. Control system The devices connected to the fieldbus can be made known to the control system using FDT. The input and output signals can be created and integrated into functional system planning. 14

15 For this case, FDT defines: Process channels which offer addressing and data type information of IO signals (IFdtChannel). Asset management Gathering asset data for analysis by an asset management tool is also supported by FDT. Asset management relevant information can be collected from the devices. Operation counters can be queried. The DTM can perform a diagnosis and calculate the date for the next service interval. See the following FDT definitions: IDtmSingleDeviceDataAccess for access of asset management relevant values and query of operation counters. IDtmOnlineDiagnosis for detection of conditionbased and predictive maintenance. Scalability Few devices FDT can already be introduced in simple cases, such as device configuration. This might be done in workshops or small installations. Operations are mainly performed via the user interfaces of the DTM and often, an on-line connection to the device is established directly to the field device. FDT provides full access to the entire DTM functionality, which corresponds to the entire device functionality. Switching between operation modes can, for example, be done by tabs or menus. The current configuration settings and the parameters values are read from the device and displayed to the user in a way they can easily be modified. Of course, the changed values can be written back to the device. The device can be diagnosed and calibrated. If the device provides maintenance information, its status can be viewed. Large installations Even in huge plants, FDT can be used effectively with several hundreds of devices. An asset management program surveys necessary liquid levels being able to order resources which are short on supply. The asset management program also lists maintenance information of all devices and performs diagnostic checks. Additionally a HMI system is installed, which allows in-time-operation. Process values are shown beneath a graphic of the vessel, for example. Alarm messages are shown in case a process value is out of the defined range. With an engineering tool, extensions of the plant are planned in parallel. Devices can be inserted and preconfigured in off-line mode, including setting of the addresses. At commissioning, the device is made available to the asset management and the HMI. One or more operation terminals provide access to field devices to engineers in the field. So the engineer can check the measured values. All these programs are FDT enabled. They all access the same DTMs but (re)present different parts of their information in a different way. The asset management might use a fl at list of the devices which need maintenance accomplishment, the engineering tool uses a hierarchical network topology to be able to correctly determine addresses, and the HMI may separate the devices by rooms and floors or the position in the process diagram. Because all stations need access to most of the actual information, the DTMs data sets are stored on a database server. Like that, different FDT Frame Applications may be employed in different contexts. The availability of the DTMs functions is controlled according to the applications context. For example, planning engineers log in at the engineering tool with the operation phase engineering. They then have access to off-line confi guration but they won t be able to perform an on-line connection to the device. The operator who wants to check process values against the defined values might log in with the special user role observer defined in FDT. So he s not able to accidentally modify a parameter s value. In difference to the simple use case, this scenario often uses functions which do not require interaction via a user interface. Information is handled in the background at pre-defined time intervals and is filtered etc. Scanning Example Scanning of the network topology is an example which makes use of some FDT interfaces. On a PC where lots of DTMs are installed but the network topology is not set up until now, the user wants to scan the whole network, independent from protocols. First of all, the FDT Frame Application performs a socalled catalogue update to find out which DTMs are installed. As a result of this, it also finds out which DTMs are Communication DTMs and which DTMs are Device DTMs. 15

16 Figure 11 Distinguishing Communication DTMs from Device DTMs This is done via the defined interface IDtmInformation and the method GetInformation. The DTM responds with an XML document which corresponds to DTMInformationSchema. This document contains static information about the protocols provided by the DTM or required by the DTM. Figure 11 shows a simplified example of two documents. The DTM providing (supporting) the protocol is the Communication DTM, the other one is the Device DTM. After that, the FDT Frame Application starts all Communication DTMs, one at a time and performs a request asking the DTM if it can find the according hardware. This is done by using the method Scan- HardwareRequest of the interface IDtmHardware- Identification. Scanning for hardware may take some time so this method returns immediately and the recognizing process takes place in the background. The result of scanning for hardware is provided asynchronously via the interface IDtm Scan Events and the method OnScanHardwareResponse. The result is again a XML document, this time according to the DTM Scan Ident Schema. Figure 12 shows a simplified example for a response. Figure 12 Scan result for hardware identification With the received information, the FDT Frame Application checks the table of installed DTMs if there is a Communication DTM fitting the hardware. If yes, it is started and added to the topology. If no, there might be a message to the user that hardware was found but cannot be used without installing other DTMs. Once the Communication DTMs are known, the same mechanism applies for finding field devices. The FDT Frame Application asks for the channels of the Communication DTM (interface IDtmChannel, method GetChannels) and performs a ScanRequest on the interface IFdtChannelScan of each channel. The information returned is now protocol specifi c and corresponds to the FDTxxxScanIdentSchema, where xxx is the name of the protocol. Then there is a XSL transformation which can produce a result according to the DTM Scan Ident Schema. This is one of the mechanisms FDT uses to ensure protocol independence. When the transformation succeeded, the FDT Frame Application again looks up the table of available DTMs and if there is a DTM matching the given information, it is placed into the network topology. This time, only field Device DTMs are considered. DTM implementation There are different ways of implementing a DTM. Figure 13 shows three different approaches. If a device description (DD) already exists, it is probably the easiest way to have a DTM generated from the device description. If a stand-alone application is already present, the code from that application may be reused. The application just has to provide its information at the defined DTM interfaces. Of course, the DTM can be developed from scratch. Existing libraries which already cover the FDT interface implementation can be used. Therefore, only the business logic and data model has to be developed. 16

17 Figure 13 DTM implementation approaches DTM style guide With FDT, the variety of applications and tools a user had to deal with has decreased. The user only has to be familiar with few FDT Frame Applications. In contrast, graphical user interfaces are developed by the DTM vendors and their usage differs as well as their look and feel. Therefore, a Project Group of the FDT Group has defi ned rules and guidelines how a DTM is supposed to behave on its graphical user interface. This covers layout instructions, representation of parameters and menu structures. Figure 14 shows the general layout of a graphical user interface provided by the DTM corresponding to the style guide. The identification area shall give an overview of which user interface of which DTM is currently open. It displays a field device photograph and a vendor logo. The device type and the device name are also shown. The menu bar and tool bar are positioned directly underneath the identification area. The navigation area is optional. It organizes elaborate parameter models in functional groups and thereby simplifies information in the action area. In the action area, parameters can be set. The name of the parameter shall be shown fi rst, followed by a status indicator, an editable element and the unit of the parameter. The action area shall also contain default buttons like OK, Cancel, and Apply. The status bar indicates whether data is changed online (on the device) or off-line (in the DTM s data set). The current user role (e. g. administrator) can also be displayed there. Figure 14 DTM style guide user interface 17

18 Certification process Test definition & execution To ensure the quality of DTMs, the FDT Group has defined a certification process. Within the certification process, the DTM will undergo a compliance test, which results in a test report (Figure 16). The FDT Group has defined a number of test cases in textual form. These test cases define sequences to be performed with the DTM and they contain the expected results. The textual representation of all test cases has been transformed into scripts. These scripts are interpreted by a special tool called dtminspector. The tool will execute the defi ned steps and compare the DTMs behavior to the expected results. In the end, the dtminspector emits a report, which either states that the DTM has successfully passed all tests (Figure 16) or that the DTM does not behave correctly corresponding to the FDT specification. In case of a failure, the report contains detailed information about the test run (Figure 15). The DTM developer can reproduce the error and correct it. There are more than 60 test case documents defi ned, each containing several tests to be performed, so that the DTM has to pass more than 300 single tests. Figure 15 Report showing an error Figure 16 Certification report example 18

19 Test Sites In order to ensure independent, uninfluenced, and high quality testing of DTMs, the FDT Group audits and accredits test sites. The test sites are required to have technical competence, be able to handle the test tool, have adequate facilities at their premises, be impartial and independent, as well as cooperate with clients and the FDT Group. An auditor visits the company applying for a test site and checks if all requirements are met. Once the company fulfi lls all requirements, the auditor recommends the company as a test site. The FDT Group then decides whether or not to accredit the company as an official test site. These test sites are available on the FDT Group website. A certified DTM will behave correctly according to the specification. DTM vendors profit from the certification tool dtminspector during DTM development. The developer can regularly check if his implementation is conforming to the standard (Figure 17). This also covers features like data set access in multi-user environments, as well as bad cases, such as communication loss, which is often difficult to test. Some of these can hardly be imitated by unplugging the connectors manually at the correct time. Certification process Once the DTM is to be released, its setup and a device are sent to a test site. The test site performs the official tests on a clean system, together with other certified DTMs (e. g. for communication). The test site then generates a report which is handed out to the DTM vendor. The vendor applies for a formal certificate and sends the report to the Certification Office of the FDT Group. The Certification Office checks the report s validity and if the report contains a positive result. The DTM is then added to the list of certifi ed DTMs (which can also be found on the FDT Group web site and the formal certifi cate is issued. Figure 18 shows the certification process. The certificate will be valid for three years. After that period, the device manufacturer can declare that the software was not changed. After receiving this declaration, the Certification Office will issue a prolongation of the certification for another three-year term. A test report covers exactly one device type and one operating system. If the DTM suits multiple devices, the vendor may provide a statement that the other device types supported by the DTM will behave the same way concerning the FDT interfaces. Figure 17 Development support Benefits Figure 18 Certification process 19

20 Test objectives The offi cial test tool checks the DTM for conformance to the FDT specification. This includes the DTM state machine and return values of the defined interfaces. The tests begin with the test of the correct installation and end in a deinstallation test. The tests also cover features such as multiuser environments. FDT defines mandatory and optional interfaces. Of course, mandatory interfaces are always tested. In case the DTM does not implement an optional interface (e. g. IDtm Online Diagnosis), the tests for that particular interface are skipped. But if the DTM implements an optional interface, it has to behave correctly and an error will lead to a negative report. Additionally, test cases have been defined that test the robustness of a DTM. As long as robustness is not defined in the specification, it will just result in a warning but not affect the reports success. The tests defined by the FDT Group do not cover functional tests, such as the DTMs internal parameter model. The DTM vendor has to perform functional tests on his own as he would have done before. Arbitration Theoretically, in case of a negative report, a DTM vendor might insist on his opinion that his DTM behaves correctly and the tests contain an error. He then has the possibility to directly contact the FDT Group, which will inspect the tests and discuss the problem. Members of the FDT Group will then provide an arbitration, which either invalidates the vendor s objection or the specific test case. If the test case or the test script contains an error, then the DTM might get a certificate anyway. 20

21 Contact Homepage Contact section General information Marketing information FDT Specifications information The specification itself can be downloaded for free in the Download section. Test and certification information Press contact Business office 21

22 A. Abbreviations AISBL CIP COM DCS DTM FDT FF HART HMI PLC PNO XML ZVEI Association internationale sans but lucratif Non-profit organisation according to Belgian law. Common Industrial Protocol A family of protocols, including DeviceNet, ControlNet, and EtherNet/IP. Component Object Model The Component Object Model is the Microsoft approach to develop reusable software components. It is a binary standard that describes calling conventions in a language neutral fashion. Distributed Control System A distributed control system is part of a manufacturing system. It is used to monitor and control distributed equipment with remote human intervention. Device Type Manager A Device Type Manager is a software component representing a device. It encapsulates device-specific data, functions, and business rules. Field Device Tool Field Device Tool is the name of the standard itself. FDT standardizes the communication between field devices and systems. It is independent of the communication protocol and vendor and is established as an open standard. FOUNDATION Fieldbus The Foundation Fieldbus is a two-wire fieldbus which supplies devices with energy. Highway Addressable Remote Transducer HART is a communication protocol, overlaying the analog 4 to 20 ma process value to transport additional digital information. Human machine interface The human machine interface is a layer that separates the human operating a machine from the machine itself. Programmable Logic Controller Device turning on or off outputs depending on the state of input signals. It replaces sequential relay circuits. Profibus Nutzerorganisation e.v. The PNO is a German organization that is a part of Profibus International. Translated, it would be Profibus User Organization. Extensible Markup Language The extensible markup language is a simple but flexible text format used to interchange data between computer applications. Zentralverband Elektrotechnik- und Elektronikindustrie e.v. The ZVEI is a German organization. Translated, it would be Electrical and Electronic Manufacturers Association. 22

23 B. Figures Figure 1 Printer driver compared to FDT...3 Figure 2 Any DTM can run in any FDT Frame Application...4 Figure 3 Situation without FDT...6 Figure 4 FDT Group organization structure...8 Figure 5 Scope of FDT interfaces...10 Figure 6 DTM interfaces Figure 7 Process channel interface Figure 8 Communication channel interfaces Figure 9 FDT Frame Application interfaces...13 Figure 10 Nested Communication Figure 11 Distinguishing Communication DTMs from Device DTMs...16 Figure 12 Scan result for hardware identification...16 Figure 13 DTM implementation approaches Figure 14 DTM style guide user interface Figure 15 Report showing an error...18 Figure 16 Certification report example...18 Figure 17 Development support...19 Figure 18 Certification process...19 Liability Exclusion FDT Group, AISBL has carefully elaborated the contents of this brochure. Nonetheless, the possibility of errors cannot be eliminated. Liability of the FDT Group, AISBL is excluded, regardless of its reasons. However, data in this brochure is checked periodically. Necessary corrections will be contained in subsequent versions. The FDT Group, AISBL gratefully accepts suggestions for improvement. Terms used in this brochure may be trade marks. Their use by third parties for any purposes may violate the rights of the owner. This brochure is not a substitute for the FDT specifi cation (Profibus Guideline Order No ). In case of doubt, the FDT Specification takes precedence. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher. 23

24 More than 55 of the leading, most influential automation companies support FDT. Join Today For more information please visit or to 2007 FDT Group All product brands or product names may be trademarks of their respective owners. Order No. TO3 Status October 2007