1.6 Introduction: Migration to DTM

Reflecting the current situation, there are a lot of different field devices ranging from simple I/O sensors to complex, modular Remote-I/Os or drives. According to their complexity, the devices can be divided into four categories:

A: Simple devices that communicate only cyclically, for example a light barrier B: Adjustable devices with fixed hardware and software, for example a pressure transducer C: Adjustable devices with modular hardware but fixed software blocks, for example remote I/O D: Adjustable devices with modular hardware and programmable software blocks, for example a complex servo-drive

These different devices come with different kinds of descriptions of their capabilities or even their own configuration tools depending on the functionality the devices provide. With FDT all these devices can be integrated into Frame Applications via DTMs in a unified way even if the device manufacturer doesn’t see his primary task in developing a DTM.

For instance, simple devices of categories A and B may be sufficiently described by already existing device descriptions or files containing information about the communication capabilities. It is possible to develop ‘generic DTMs’ that can interpret these device descriptions and make the contained information and functions available for the system and its user. Once a generic DTM for a specific device description is developed, all devices supporting this description can be integrated using the same DTM.

On the other hand, for devices of categories C and D there may be already existing standalone tools. FDT provides the openness to equip these tools with the FDT-interfaces and to build DTMs out of existing standalone tools. That way, the device manufacturer’s investments can be protected. DTMs that are equipped with external tools are seen as a way to migrate towards FDT. The final goal of such a migration should be a DTM, which provides a well integrated ActiveX-based GUI.

In the long run, each device manufacturer has the freedom to choose from the following options for existing or new devices: - Stay with the generic solutions based on device descriptions, - Offer a DTM that is maintained as a standalone tool in parallel, - Build a new DTM from scratch in order to introduce new features for handling the device.

Figure 3: DTM - Implementations