EDDL and FDT Strategy for Merging EDDL and FDT
Without doubt, central access to automation device data and functions is a great help to users. There are two technologies which offer this functionality: Field Device Tool (FDT) and Electronic Device Description Language (EDDL). Each of these technologies has advantages and disadvantages. An integrated approach based on OPC UA merges the two technologies.
EDDL and FDT have been competing for the attention of control system and device manufacturers for several years now. The two technologies focus on different issues, but there is a good deal of overlap. It is precisely this overlap which has led to a situation where the technologies compete with rather than complement each other. So why not both? The “Lehrstuhl für Informationstechnik im Maschinenwesen” (itm) at the Technical University in Munich looked at the problem and came up with a strategy which combines the advantages of EDL and FDT in a single all-inclusive solution. The strategy is based on the new OPC Unified Architecture (UA), which was released by the OPC Foundation in July 2006.
Which one does what?
Open FDT technology defines the interfaces between the device-specific operator functions, the so-called Device Type Manager (DTM), and the device-independent engineering system, the FDT Frame. Since a DTM only has to comply with this interface specification, device manufacturers have maximum freedom when they define interactive functionality, implementation of the DTM software components and selection of the programming language. This can make operation of very complex devices very manageable.
One big disadvantage of FDT technology is the close relationship between the DTM components which are supplied by the device manufacturer and the Microsoft Windows platform. EDDL, which is also open and standardized, takes a different approach. It has its own language that the device manufacturers use to create text-based descriptions (Electronic Device Description, EDD), which are essentially digital data sheets, for their devices. The scope of the language is limited compared to standard programming languages, and it is designed specifically for device description. Manufacturers can quickly and efficiently create EDD device descriptions which are processed by an EDD-specific interpreter in an open engineering system which has no device dependencies. The EDD is not dependant on any operating system or computer platform. It uses a standardized HMI strategy, which is defined by EDDL, and the interpreter technology makes it very robust. The limited functionality of the language can cause annoying limitations on very complex devices.
What happens next?
- The Institute for IT in Mechanical Engineering (itm) in Munich has developed an integration strategy which combines the best of both technologies in an all-inclusive client-server architecture. A four-layer device integration model was developed to define the client-server architecture:
- Data and State model: contains the data that the device will publish for engineering purposes including metadata such as units, range or limits and contains dependencies between elements of the data model and the device state to ensure consistency.
- Basic Device Methods provide functionality like e.g. calibration.
- These two layers are combined in the Device Information Model (DIM) and essentially define the structure and behavior of the device data interface. The other layers are:
- Advanced Business Logic, which contains the higher-level user support functions such as automation calculation of linearization tables from 3D tank geometry data, and the Graphical User Interface (GUI).
These two layers also form a unit called the Device Operation Model (DOM). Compared to device firmware, the DIM is a 1-to-1 model of the device data with is published for device integration purposes. The DOM accesses data elements in the DIM for HMI functions. The new concept is based on the new OPC Unified Architecture. The description of the DIM is based on EDDL, as the language contains all of the necessary elements. Platform independence and interpreter-based execution offer a high level of technology independence and resilience. On the client side, the Device Engineering Framework, which is comparable with the FDT Frame application, together with the DOM provides the basis for device HMI functionality. The focus is on the work flow which takes place when the user is working with the device. The device manufacturer uses the FDT concept to program a wide range of functions and GUIs. The flexibility and programming power of FDT are included in the new concept.
Prof. Klaus Bender is the Chairman of the “Lehrstuhl für Informationstechnik im Maschinenwesen” (itm) at the Technical University, Munic, and member of the executive board at the Profibus Users Group. D. Großmann is a teaching and research assistant at itm.
This article is protected by copyright. You want to use it for your own purpose? Contact us at support.vogel.de (ID: 195016)