FDT Technology’s roots in the industrial automation marketplace span the horizon for process, hybrid and factory automation – standardizing device integration and management for all common fieldbuses, regardless of manufacturer. This includes a common environment for accessing the most sophisticated device features. The technology enables configuration, operation and maintenance through a single, standardized user interface – regardless of supplier, device type/function or communication protocol.
So, what components and mechanisms are required to implement the FDT interface in a Programmable Logic Controller (PLC) programming environment such as CODESYS?
Due to the variety of fieldbuses found in factory automation, FDT technology is useful for standardized device management. That is because PLC programming systems common in this environment – such as CODESYS – can ensure significantly better device integration if FDT is employed.
A developer software tool, referred to as the FDT/FRAME™ Common Component, is available for developers looking to implement seamless asset integration in their PLCs for the factory automation marketplace. The FDT/FRAME Common Component software developer tool can be obtained by contacting the FDT Group and is used as the base component to ensure complete asset integration within interface application offerings. Using it ensures that implementation conforms to the FDT specification and improves interoperability with many Device Type Managers™ (DTMs™).
The FDT/FRAME Common Component contains all of the interfaces required by the FDT specification to develop an FDT-enabled application. This kind of application can perform a wide range of functions such as a stand-alone tool for device configuration, a diagnostics tool or an asset management tool.
In Fig. 1, the outer FRAME Application represents the FDT application. This is where all the functions of each application are implemented. The inner part shows the base FRAME Common Component (also known as fdtCONTAINER component). Interfaces connecting the two elements are located between the application and base component. The direction of the arrows shows whether the interface calls up the base component or the application.
The database adapter (DBAdapter) can be seen in the lower part of the application. It forms the adaptation layer for the application-specific database. The functions shown in the database adapter (for example, "Project Record" or "DTMInstance Data") are placeholders for programming database access.
The base component itself contains functions for managing the DTMs (DTMCatalog) and the application project (FRAMEProject). The system topology, the associated DTMs (DTMList) and a proxy form part of the project. This proxy separates abstract online call-ups into individual FDT function call-ups – for example "go offline.” The instantiated DTM itself runs in the DTMContainer component.
The CODESYS plug-in concept
CODESYS is a software suite for automation technology that is based on the IEC-61131-3 programming tool. The software makes it possible to integrate additional functions using custom-designed plug-ins such as new menus, editors, etc. The FDT base component is also embedded into the programming tool with this mechanism.
Fig. 2 provides a detail of the CODESYS architecture, including the FDT components. The project structure, as shown in CODESYS, should be considered in parallel to this (CODESYS device tree) architecture. The FDT Integration Plug-in contains the FDT base component for managing an FDT project with the associated DTMs.
The architecture in Fig. 2 shows integration using CANopen devices as an example. It is possible to use devices with and without DTMs. The CANopen Master is represented by a DTM used to configure the CANopen fieldbus. It is also the communication interface with the CANopen devices. The IFdtCommunication interface, used by a device DTM to exchange data with its slave (DTM for Slave 2), serves this purpose. The CANopen Master DTM converts the data from the device DTM into protocol-specific messages like CANopen and sends them to the device. The response from the device is processed in reverse order.
Device management
Device management makes it possible to mix simple components, which do not require an explicit DTM with devices with increased functionality and whose full scope of functions are enabled by the DTM. CODESYS contains a general XML Device Description (DD) for all devices as well as the associated fieldbus device file (for example, EDS for CANopen). The DD contains all the information related to the device, its parameters and communication options.
If a device with a DTM is used, the DTM is transferred from the DTM catalogue to the project, and the associated XML description is generated automatically. The system receives the required data via the interface DTM. Information related to the manufacturer, device type and version data is made available in this way, as well as other information. Frequency converters are an example of a device with a wide range of functions. In this case, it is advantageous to provide each device range with a DTM that covers the entire range.
Fieldbus configuration
The CANopen Master Configurator enables convenient configuration of the fieldbus. This includes parameters for the fieldbus itself such as baud rate or heartbeat (monitoring time). This DTM assigns the device addresses (Node ID) and maps PDOs (ProcessDataObjects). The latter establishes the connection between the PDOs and the application objects in the object dictionary.
The Master Configurator exchanges data with the device DTMs via the interface DTM (SetParameters). It is notified when the device DTM changes data. The changes can be requested via the interface (GetParameters). After configuration is complete, the Master Configurator checks the consistency of the data in the CANopen system. The CANopen data is downloaded to the Master and the devices and used during runtime for starting up the system, setting the fieldbus parameters and exchanging data.
Generating process data
Process data is the data transferred between the PLC and the slaves during the fieldbus runtime. The description of the process data defined by means of the device DTMs is made available at a corresponding interface (process channels). In this case, the information from the Electronic Device Description (EDD) is not used, as it is insufficient for the intended purpose. This procedure is particularly helpful for modular devices with a variable configuration. The Process Data Objects (PDOs) are automatically generated for the process data. Existing variables can be assigned to the process data or redefined in the device DTM.
The PLC tool receives the variables from the device DTM and makes them available to the PLC program in a final step. This allows the variables to be used directly by the PLC programmer for further processing.
To summarize, using FDT Technology in CODESYS provides programmers with a wide range of options for device management. The functions and flexibility by far exceed what is possible using the usual description files (e.g., EDS, GSD). For instance, devices from different manufacturers can be integrated into one tool. Access to the devices is ensured beyond the scope of fieldbus hierarchies. With their graphical user interface, DTMs make accessing the relevant device simple and also offer device-specific diagnostics functions enabling rapid fault detection in the event of maintenance.
Authors
Nuno Barral is Project Design Leader and Software Architect at Schneider Electric Automation.
Manfred Brill is Innovation & Technology Senior Manager at Schneider Electric Automation.
What is FDT Technology?
FDT standardizes device management for field devices in one tool. Device management is standardized regardless of the device manufacturer and the fieldbus/network used. This means that every device in an FDT/FRAME can be configured, operated and maintained by standardized interfaces – regardless of manufacturer, type or communication protocol. The three key elements of FDT are:
1. The FDT interface – the standard for device management
The FDT interface is the specification describing standardized data exchange between devices and the control system, or the engineering and asset management tools.
2. The FDT Device Type Manager (FDT/DTM™) – device driver for intelligent instruments
The DTM provides a standardized structure for accessing the device parameters as well as configuring and operating devices, and performing fault diagnostics. DTMs range from a simple graphical user interface for parametrization to a sophisticated application, which can handle complex real-time calculations for diagnostics and maintenance. DTMs are divided into three categories:
Device DTM:
• Supplied by the device manufacturer
• Represents the entire logic and parameterization of a device
• Creates a standard interface with the FDT/FRAME
• Used in any FDT Frame Application
• Based on the DTM style guide
Communication DTM: Represents communication components such as PC network cards and couplers
Gateway DTM: Represents components that connect two different networks/fieldbuses
3. The FDT FRAME Application (FDT/FRAME™) - host system
The FDT/FRAME is a software program, which integrates device, communication and gateway DTMs from various manufacturers and for different networks/fieldbuses. It offers:
• Shared, standardized environment
• User management
• DTM management
• Data management
• Network configuration
• Navigation
