FDT® offers proven architecture for data exchange between software and automation components, regardless of the network layers or protocols used in communication. Point-to-point connections and manufacturer-specific protocols are also supported. This article describes the FDT communication principles and provides examples that illustrate how they can be used in practice.
In factory automation, different fieldbuses and protocols have been established over time for various reasons. Experts estimate that network structures will be flatter and more Ethernet-based in the future. However, not all current communication structures will completely disappear. Manufacturers of automation components must therefore continue to support different communication methods for various applications now and for several years, for example the connection of a commissioning tool via a services interface or the connection of an engineering tool via an Ethernet network.
Basic principle of FDT communication
Communication components such as PC plug-in cards, modems or gateways are mapped in FDT by communication DTMs (Device Type Managers) and gateway DTMs. Similar to device DTMs for sensors and actuators, these DTMs also include specific configuration logic and user interfaces, for example for configuring communication parameters such as baud rates, timeouts, etc. In addition, such DTMs include so-called communication channels. They provide the protocol-specific services via corresponding FDT software interfaces.
Just like device DTMs, communication and gateway DTMs can be used in a software tool and therefore integrate the network or fieldbus support into the tool via "Plug & Play.” Figure 2 illustrates this principle, showing the connection of a drive via CANopen.
For the drive itself, the device DTM supplied by the manufacturer is started in the tool along with the corresponding communication DTM for the CANopen modem. The device DTM uses the software interfaces made available by the communication DTM in order to communicate with the drive. In this example, CANopen SDO read and write commands are used. The so-called annex to the FDT specification determines how the specific services of a protocol in FDT are mapped.
Figure 3 shows the use of the CANopen Communication DTM in the commissioning tool SoMove by Schneider Electric.
The communication DTM user interface is shown in a separate dialogue box when the user selects "Edit Connection" on the main display. In this dialogue box, the user can then configure the CANopen communication parameters. Beyond this, the communication DTM does not appear again in this tool.
Nested communication
Through the use of gateway DTMs, the FDT communication principle also works across several layers. Figure 4 shows an example of communication with an IO-Link sensor via Profibus.
The device DTM uses the software interfaces made available by the communication DTM in order to communicate with the sensor. In this example, IO-Link index/sub-index read and write commands are used. The gateway DTM generates the corresponding Profibus read and write commands and sends them to the corresponding fieldbus coupler via the superimposed communication DTM. The coupler converts the commands back into IO-Link and sends them to the sensor.
The gateway DTM is supplied by the coupler manufacturer so it knows the translation logic. This can be infinitely complex and is programmed in the exact opposite direction in the gateway DTM to in the coupler. For example, a series of Profibus commands can also be generated from an IO-Link command in the gateway DTM. These are then reassembled to constitute a single command in the coupler and then sent.
Manufacturer-specific protocols
If software tools and automation components are provided by the same manufacturer, then proprietary communication protocols are often used. A programmable logic controller (PLC) is not normally programmed via a fieldbus. However, this form of communication is possible with FDT, as shown in Figure 5.
In this case, the communication DTM and the DTM for the PLC are provided by the same manufacturer. The commands between the two DTMs are manufacturer-specific. No annex to the specification is provided by the FDT Group and as a result this communication cannot be used by DTMs from other manufacturers.
Why does it make sense to use FDT here, specifically to map a PLC? Here's the answer: The DTMs can not only be used in their own software tool, but also in other tools. For a PLC, this means the corresponding DTM can be used both in its own programming tool as well as in simple commissioning or diagnostic tools, for example. These tools use only the diagnostic user interfaces provided by the DTM or the gateway communication to the connected sensors/actuators. The actual PLC programming function is normally not included in such a DTM.
Conclusion
FDT defines a communication architecture that has proven reliable in numerous practical applications. FDT supports communication across all layers and protocols. It can also support manufacturer-specific protocols.
The software tools supported by FDT can be enhanced to include more communication methods by integrating corresponding communication and gateway DTMs. DTMs are available for numerous PC plug-in cards, modems, and couplers available on the market. They are easy to use, saving developmental costs.
Authors
