Monday, May 28, 2018

IAM Search

Device Management

Modern field devices provide a wide range of information and also execute functions that were previously executed in PLCs and control systems. To execute these tasks, the tools for commissioning, maintenance, engineering and parameterization of these devices require an exact and complete description of device data and functions, such as the type of application function, configuration parameters, range of values, units of measurement, default values, limit values, identification, etc. The same applies to the controller/control system, whose device-specific parameters and data formats must also be made known (integrated) to ensure error-free data exchange with the field devices.

PROFIBUS has developed a number of methods and tools ("integration technologies") for this type of device description which enable standardization of device management. The performance range of these tools is optimized to specific tasks, which has given rise to the term scaleable device integration. Therefore the tools are put together in one specification with three volumes.

In factory automation, for historical reasons, the GSD is used preferably, but the use of FDT increases as well. In process automation, depending on the requirements, EDD and FDT are used (see Fig. 30).

Integration technologies at PROFIBUS

Fig. 30: Integration technologies at PROFIBUS

Methods of device description:

The communication features of a PROFIBUS device are described in a communication feature list (GSD) in a defined data format; the GSD is very much suited for simple applications. It is created by the device manufacturer and is included in the delivery of the device.

The application features of a PROFIBUS device (device characteristics) are described by means of a universal Electronic Device Description Language (EDDL). The file (EDD) created in this manner is also provided by the device manufacturer. The interpreter based EDD is very much proven for applications with medium complexity.

For complex applications there is also the solution of mapping all device-specific functions, including the user interface for parameterization, diagnosis, etc., as software component in a Device Type Manager (DTM). The DTM acts as the "driver" of the device opposite the standardized FDT interface, which is implemented in the engineering tool or in the control system.


7.1 GSD

A GSD is a readable ASCII text file and contains both general and device-specific specifications for communication. Each of the entries describes a feature that is supported by a device. By means of keywords, a configuration tool reads the device identification, the adjustable parameters, the corresponding data type and the permitted limit values for the configuration of the device from the GSD. Some of the keywords are mandatory, for example Vendor_Name. Others are optional, for example Sync_Mode_supported. A GSD replaces the previously conventional manuals and supports automatic checks for input errors and data consistency, even during the configuration phase.


Structure of a GSD

A GSD is divided into three sections:

General Specifications

This section contains information on vendor and device names, hardware and software release versions, as well as the supported transmission rates, possible time intervals for monitoring times and signal assignment on the bus connector.

Master Specifications

This section contains all the master-related parameters, such as the maximum number of connectable slaves or upload and download options. This section is not available in slave devices.

Slave Specifications

This section contains all slave-specific information, such as the number and type of I/O channels, specification of diagnosis text and information on the available modules in the case of modular devices. It is also possible to integrate bitmap files with the symbols of the devices. The format of the GSD is designed for maximum flexibility. It contains lists, such as the transmission rates supported by the device, as well as the option to describe the modules available in a modular device. Plain text can also be assigned to the diagnosis messages.

There are two ways to use the GSD:

  • GSD for compact devices whose block configuration is already known on delivery. This GSD can be created completely by the device manufacturer.
  • GSD for modular devices whose block configuration is not yet conclusively specified on delivery. In this case, the user must use the configuration tool to configure the GSD in accordance with the actual module configuration.

By reading the GSD into the configuration tool (into a PROFIBUS configurator), the user is able to make optimum use of the special communication features of the device.


Certification with GSD

The device manufacturers are responsible for the scope and quality of the GSD of their devices. Submission

of a GSD profile (contains the information from the profile of a device family) or an individual device GSD (device-specific) is essential for certification of a device.


PNO Support

To support device manufacturers, the PROFIBUS Web site has a special GSD editor/checker available to download, which facilitates the creation and checking of GSD files.

The specification of the GSD file formats is described in the following PROFIBUS guideline GSD, order No. 2.122.

New Development Stages of the communication functions of PROFIBUS are continually integrated in the GSD by the PNO. Thus, the keywords for DP-V1 can be found in the GSD Revision 3 and those for DP-V2 in the GSD Revision 4.


Manufacturer ID

Every PROFIBUS slave and every master class 1 must have an ID number. This is required so that a master can identify the types of connected devices without the need for extensive protocol overheads. The master compares the ID number of the connected devices with the ID numbers specified in the configuration data by the configuration tool. Transfer of the user data is not started until the correct device types with the correct station addresses are connected to the bus. This ensures optimum protection against configuration errors.

For an ID number for each device type, device manufacturers must apply to the PROFIBUS User Organization who also handle administration of the ID numbers. Application forms can be obtained from any regional agency or from the PROFIBUS Web site on the Internet.

Profile ID

A special range of ID numbers (generic ID numbers) have been reserved for field devices for process automation and drives respectively: 9700h - 977Fh or 3A00h - 3AFFh. All field devices corresponding exactly to the specifications of the PROFIBUS PA Devices profile version 3.0 or higher, or PROFIdrive version 3, may use ID numbers from this special range. The specification of these profile ID numbers has further increased the interchangeability of these devices. The ID number to be selected for the respective device depends on various factors for example in the case of PA Devices on the type and number of existing function blocks. The ID number 9760H is reserved for PA field devices that provide several different function blocks (multivariable devices). Special conventions also apply to the designation of the GSD files of these PA field devices. These are described in detail in the PA Devices profile.

The first profile ID number reserved for PROFIdrive (3A00h) is used during the DP-V1 connection buildup to check that the master and slave are using the same profile. Slaves that positively acknowledge this identifier support the DPV1 parameter channel described in the PROFIdrive profile. All further profile ID numbers serve to identify vendor-independent GSD files. This enables the interchangeability of devices of different manufacturer without the need for new bus configurations. For example, the VIKNAMUR mode with vendor-independent PROFIdrive GSD is defined as a component of the PROFIdrive profile for the chemical industry.


7.2 EDD

The GSD is inadequate for describing application-related parameters and functions of a field device (for example configuration parameters, ranges of values, units of measurement, default values, etc.). This requires a more powerful description language, which has been developed in the form of the universally applicable Electronic Device Description Language (EDDL). Above all, the EDDL provides the language means for the description of the functionality of field devices. This also contains support mechanisms to

  • integrate existing profile descriptions in the device description,
  • allow references to existing objects so that only supplements require description,
  • allow access to standard dictionaries and
  • allow assignment of the device description to a device.

Using the EDDL device manufacturers can create the relevant EDD file for their devices which, like the GSD file, supplies the device information to the engineering tool and then subsequently to the control system.

EDD application

An EDD is a very versatile source of information, for example

  • Engineering
  • Commissioning
  • Runtime
  • Asset Management
  • Documentation and e-Commerce


EDD advantages

An EDD provides significant advantages to both device users and device manufacturers.

The uniform user and operation interface supports the user by

  • Reducing training expenses
  • Reliable operation
  • Only one tool for all applications
  • Validation of the input data

The device manufacturer is supported by the fact, that developing an EDD is very easy and cost effective

  • Without specific knowledge, by the device developer
  • By using existing EDDs and text libraries
  • By universal suitability for simple to complex devices

An EDD also provides investment protection to both users and manufactures because an EDD is independent of operating systems and easy to extent.


New Development Stages

As with the GSD, the EDDL will also be subject to upgrade that keep it in step with the continuous development of advancing device technology. Work is currently underway on a unique specification for dynamic semantics and for the description of hardware modular slaves.

The specification of the EDDL is an integral component of the international standard IEC 61804. It is included in the PROFIBUS guideline 2.152.


7.3 FDT/DTM Concept

The existing description languages for configuration and parameterization have their limits. This becomes clear when, for example

  • complex, non-standardized characteristics of intelligent field devices including the diagnosis capabilities are to be made useable for the plant operator or
  • in the "Optimization of assets" field, functions for preventative maintenance or for maintenance procedures are to be supported.
  • the operation of devices needs to be "encapsulated" in software (safety technology, calibration, etc).

These complex task areas, require an "auxiliary tool" that allows device manufacturers to provide users with expanded and also very specific characteristics of their field devices in standardized form and which at the same time allows the manufacturers of automation systems to integrate these field device characteristics in the control system over standardized interfaces.

The solution to this is the fieldbus-independent interface concept FDT/DTM (see Fig. 31), which was developed in a working group of the PNO and the ZVEI (Central Association for the Electrical Industry) and made generally available.

FDT DTM concept

Fig. 31: FDT/DTM concept

The FDT Interface

The definition of a universal interface provides the ability to implement suitable created software components on all engineering or other integration platforms of automation systems fitted with this interface. Such an interface has been specified and designated


FDT (Field Device Tool).

The FDT specification is currently available as version 1.2. The specification of FDT is contained in the PROFIBUS guideline 2.162.


Device Description as Software Component

The specific functions and dialog of a field device for parameterization, configuration, diagnosis and maintenance, complete with user interface, are mapped in a software component. This component is called the DTM (Device Type Manager) and is integrated in the engineering tool or control system over the FDT interface.

A DTM uses the routing function of an engineering system for communicating across the hierarchical levels. Furthermore it uses its project data management with versioning. It works as a "driver", similar to a printer driver, which the printer supplier includes in delivery and must be installed on the PC by the user. The DTM is generated by the device manufacturer and is included in delivery of the device.

DTM generation

There are various options for generating the DTM:

  • Specific programming in a higher programming language.
  • Reuse of existing component or tools through their encapsulation as DTM.
  • Generation from an existing device description using a compiler or interpreter.
  • Use of the DTM toolkit of MS Visual Basic.

With DTMs it is possible to obtain direct access to all field devices for planning, diagnosis and maintenance purposes from a central workstation. A DTM is not a standalone tool, but an ActiveX component with defined interfaces.


User Benefits of FDT/DTM

The FDT/DTM concept is protocol-independent and, with its mapping of device functions in software components, opens up interesting new user options.

The concept incorporates integration options where they are most useful, in the areas of engineering, diagnosis, service and asset management - liberated from the specific communication technologies of the various fieldbuses and the specific engineering environment of automation systems.

The FDT standard provides a basis for integrated solutions from the field to the tools and methods of corporate management.

Go back to the header article PROFIBUS Technology and Application

Comments (0)Add Comment

Write comment

security code
Write the displayed characters



  • ...more


Important: All images are copyrighted to their respective owners. All content cited is derived from their respective sources.

Contact us for information and your inquiries. IAMechatronics is open to link exchanges.

IAMechatronics Login