Two new technologies are behind the significant changes afoot as fieldbus advances.
Fieldbus system users have been frustrated for many years by the difficulty of working with these systems. As devices have become more complex, operators, engineers, and technicians have struggled to get all of the value from the devices. One obvious way to help relieve much of the frustration is to introduce expert applications written by the device vendor that can be integrated with the fieldbus system.
The expert applications we are talking about are user interfaces that appear within the context of a control system's engineering or maintenance environment. Instead of clicking on a device in the system's hardware tree and being presented with a list of the device's parameters, a rich application, designed by those who understand that instrument type best, becomes visible. If you want to understand if a valve is properly sized, look at a graph of its range of setpoints over the past month. If you want to calibrate a pressure transmitter, the application walks you through the process, does all the maths, stores all of the data, and indicates the results and their quality.
The integration of these applications with the system is important. This allows diagnostics to be performed from the control room. There is no need to disturb the network to plug in a handheld. The device does not need to be taken out of service or connected to a standalone application.
The introduction of these applications has been slow due to the disparate or non-existent interfaces to control systems and configuration tools. The fieldbus industry has responded to this situation with the introduction of two new complementary technologies - FDT and Enhanced EDDL.
EDDL
The Electronic Device Description Language was created at the dawn of fieldbus for the purpose its name implies - it is used to describe devices. Systems that interact with fieldbus devices need to know the rules of the conversation before communication can start. What function blocks are present in a device type? What parameters are available? What are the data types of those parameters? What are the default values and permitted ranges of those parameters? This information is used by the system to understand a device even before the device is present in the system.
System problems not solved by DD
Fieldbus technologies, from the communications specifications through the various device description languages, have all been created by looking at the problem from the device's perspective. That is, the technologies give us the means to create devices with a lot of parameters, but they do not really help the system, or system user, understand how www.fdt-group.org interpret, combine, categorise, and interact with the parameters. Using DD files, the system can present lists of parameters. It is up to the user to understand their use.
DD files are unable to communicate with devices. Several layers of software must exist between the DD file and actual communication with a device.
DD files are not all the same
The various fieldbus technologies that make use of the EDDL language have used the language in different ways. This continues to this day with the new DD enhancements (we will talk about them later). DD files are written in a language, but the files are then 'tokenised' into a binary format. The tokenisation formats are different for each fieldbus technology (ex FF DDs are different to HART DDs) and the specifications of how to interpret the files are kept secret. System vendors are required to purchase software from each of the fieldbus organisations to interpret DD files. These software packages were designed separately, forcing system vendors to create and maintain multiple products to support the multiple fieldbus DD file types.
DD files limit the scope of interaction with devices. When using FF DD files for example, only one function block at a time is accessible, even though multiple function blocks' behaviours might be related.
Enhanced EDDL
Enhanced EDDL is the beginning of the various fieldbus organisations' response to the first issue listed above - that a simple list of parameters is not a good enough interface to fieldbus devices. While these 'enhancements' are being added to the original EDDL language, they are fulfilling a completely distinct set of requirements and need to be discussed separately.
Enhanced EDDL is a rudimentary programming language that is designed to support a windowed interface to devices. In addition to listing parameters, programs written in the Enhanced DD language can support the creation of tabs to isolate parts of the interface, create two-dimensional graphs and plots of data, can perform basic mathematics, store files, and display pictures.
Enhanced EDDL is a 'C-like' language that is, like the original EDDL, tokenised and distributed in a unique format designed by the each of the various fieldbus organisations.
The code in the file can be interpreted at run-time by software that is available from the fieldbus organisations (different software for each type of fieldbus).
The authors of the systems that use EDDL are responsible for writing a significant amount of code to interpret the file. For example, the enhanced DD file will say to create a graph at a relative position on the screen. The system software, which is written on the operating system and programming language platform of the system vendor's choosing, must create the presentation for the graph based on the graphing capabilities of the www.fdt-group.org chosen programming language. They are also responsible for writing software drivers to interface with the physical network and for the configuration environment in which the EDDL and the required wrapper software will operate.
Work is continuing on improving the EDDL language with improvements to the basic device description characteristics as well as additional enhancements.
Limitations of Enhanced EDDL
As mentioned above, the enhanced DD language is fairly simple. Device vendors are faced with making increasingly complex devices and software to support them. One of the decisions the vendors need to make is the choice of language on which to base their supporting software. Since all contemporary engineering tools are based on the Windows operating system, the list of language options is quite long. Supporting software can be written using C, C++, C#, Visual Basic, Visio, MatLab, EDDL, or any of many others.
As in all engineering decisions, the toolset must be chosen based on the product requirements. If the application is simple and can be accomplished with EDDL, this is a reasonable choice and has some benefits, including a degree of platform independence.
If more advanced features like the ability to interact with a database, advanced or multidimensional graphics, output to Excel spreadsheets, or advanced mathematics are needed, a language supporting those features must be selected. Other requirements like the need to interface to multiple function blocks or multiple devices at the same time, or to offer an embedded help system would also impact the decision.
FDT
Regardless of the language chosen to write a software application to support a fieldbus device, that application must be interfaced to the control system or configuration tool. A general approach to this interface can be described as two software components. The first component is a driver that presents an interface to the physical communication channel between the system or tool and the actual fieldbus devices. The second component is an interface to the platform. This interface allows for things like a tree of the devices in the system and access to data storage on the platform.
Assuming that all vendors of control systems need to support fieldbus device applications, these two components must be created for each system on the market. If the interfaces are designed by each system vendor, the result would be several proprietary interfaces.
The device vendors would then be in the situation of having to support all of the different systems with unique versions of their software. If a device vendor also happened to be a competing system vendor, it is less likely that the interface description would be shared.
The result could be that device vendors would not make applications (or would make the much less desirable standalone applications), and that the users of some systems could not benefit from the applications from some device vendors.
FDT technology was developed to help automation users avoid this fate. FDT defines the interfaces between device applications and the control system platform and the physical fieldbus devices. FDT allows device vendors to create applications that have a common interface to the system. Any system that supports these interfaces can integrate the applications. The applications have precisely the same behaviour, look and feel in every system.
FDT has little impact on the system and no impact on the devices or their DD files. As discussed above, every system must have interfaces of these types. FDT simply defines the interfaces in an open, standardised way. DD files are still necessary to describe the devices to the system for system configuration and the devices themselves are unchanged.
Device applications that conform to the FDT specification (they are called DTMs) can be written in many languages. DTMs that support enhanced EDDL files have also been written so enhanced EDDL applications can be integrated with the system in the same way in which DTMs written in other languages are integrated.
Limitations of FDT
FDT is a Microsoft Windows-based technology. As such, it is subject to the inevitable upgrades and operation system version changes with which we have all become familiar. As with all software tools on all operating systems, FDT platforms and device applications will need to be updated occasionally.
FDT only defines interfaces between system components. As such, FDT components cannot replace DD files, which continue to be an integral part of all fieldbus systems. Discussion Enhanced EDDL is an extension of the DD technology that is supported by all fieldbus systems. It is a programming language that can be used to create portable applications that can be executed in any system that supports the technology.
FDT is an interface specification that allows system and engineering tool vendors to implement a common component interface. Device applications that implement the FDT interface can be easily integrated with any system that supports FDT. These applications can be written in many languages, including EDDL. There are also FDT applications on the market that interpret EDDL applications on the fly, so EDDL files can be added to the system at any time.
FDT's dependence on the Microsoft Windows operating system has been the subject of much debate. There is no doubt that the 'moving target' nature of Windows presents a significant challenge to users that have system lifetimes of 20 or more years. It appears, however, that the industry has voted with its chequebook. The benefits offered by www.fdt-group.org Windows seem to outweigh the negatives. Essentially 100% of system engineering tools sold today by all vendors are based on Windows. Even the vendor that claims FDT's dependency on Windows is a significant weakness sells very popular Windows-based device applications.
The FDT technology has been gaining significant momentum with the majority of major system and device vendors as well as some notable end users becoming members of the FDT Group and developing FDT-based products. Many of the supporters of FDT are also supporting the development of the EDDL enhancements. Systems are already available that support both technologies.
There has been a significant amount of discussion in the press that, somehow, pits FDT against EDD. It is hoped that this discussion has made it clear that there is no overlap at all in the two technologies. FDT-based systems support DD files and always will.
Device vendors do not need to abandon DD in favour of FDT DTMs. No device modifications are necessary to support FDT. Both technologies, individually and together, are adding huge value to fieldbus systems.
This white paper was kindly provided by Yokogawa.
For more information contact Yokogawa, 011 831 6367, www.fdt-group.org
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version