01 May 2004

Demystifying a protocol, Part 2

Fieldbus device descriptions provide interoperability.

By Stephen Mitschke

Process automation users want and need solutions that offer the greatest number of choices and avoid future obsolescence. The IEC 61804-2 "Electronic Device Description Language" (EDDL) standard, approved two months ago, includes the device description language (DDL) used as an underlying technology in Foundation fieldbus.

DDL is a text-based language describing the digital communication characteristics of field device parameters. It can convey information such as device status, diagnostic data, and configuration details between the host and the field device.

Device description (DD) files developed using the International Electrotechnical Commission (IEC) 61804-2 standard provide users an operating system–independent method to integrate, configure, set up, operate, diagnose, and maintain field devices through host applications running on handheld- and desktop-PCs as well as process automation systems (PASs).

DD basics

Developers of DD files for Foundation fieldbus devices start with a library of blocks and block parameters. Using the constructs of DDL, developers describe the attributes of network accessible devices, such as primary and secondary variables, device health, and performance.

Built in to the DDL structure is the flexibility necessary for device manufacturers to enhance standard Foundation fieldbus blocks by using DDL to describe and add parameters needed to include device solutions.

DDL also permits developers to incorporate methods—a series of actions such as stepping a user through sensor configuration—that a host application can execute.

DD methods use a limited subset of the ANSI C scripting language and reside only in the host system. Because the limited subset does not access the host application or the operating system software, a secure means of communicating between host systems and remote devices is built-in.

DD technology was designed to avoid the need for special, proprietary, and operating system–specific host application files.

For users, this means the same DD file works with a full-blown PAS and with a simple handheld configurator. For device developers, this means there is far less of a burden to develop, test, and maintain different files to support different host applications. For both it means the economic barriers for small device manufacturers to develop and market niche solutions reduces, which gives users more choices.

Managing hundreds, sometimes thousands, of installed and spared instruments requires tight and robust revision control. Sometimes, spared instruments require a different version than the instruments they will replace.

DD revision control uses a file naming convention consisting of a unique manufacturer identifier, device type, device revision, and DD revision.

The manufacturer identifier is assigned and managed by the appropriate fieldbus organization with the device manufacturer managing the remaining file naming information.

In the case of Foundation fieldbus, each of the four identifications embed in the device description and then help define a unique directory structure for distributing DD files.

When a device connects to the Foundation fieldbus network, the host application reads the identification information, compares the information against the library of installed DDs, and loads the correct file for the correct device.

Registration

Once you create a DD source file, the developer uses a tokenizer tool to validate the syntax, dependencies, and other protocol and language rules.

After verification and validation, the tokenizer generates a DD binary file that organizes the information into a format accessible by host applications. Besides providing a compressed, easier-to-transfer file, the binary format also provides protection against accidental changes using a simple text editor.

Within the host application DD services, software unpacks the DD binary and displays the defined information to the user.

Before Fieldbus Foundation (FF) registers a DD file, the file undergoes a series of tests using FF's Interoperability Test Kit. The first test loads the DD binary into a test system to validate correct identification information. Next the file undergoes multiple test cases to ensure the DD matches the device and follows protocol rules for maintaining interoperability between host and device.

Finally, FF logs the DD file information, including name, date, size, and the 32-bit cyclic redundancy checksum value. These files are available to download from the Fieldbus Foundation Web site at www.fieldbus.org.

HART Communication Foundation (HCF) (www.hartcomm.org) and Profibus Nutzerorganisation e.V (PNO) (www.profibus.com) apply similar DD testing and registration procedures.

OS independence

Because DD technology is operating system (OS) independent, manufacturers can develop a single DD and be confident they can safely and consistently implement it on a variety of host application platforms.

For example, when a user upgrades the host workstation from Unix to Linux or from Windows NT to Windows XP, there is no requirement to upgrade any of the existing DD files.

The way DD maintains platform independence is simple. Each DD file has a unique number and contains only the descriptions needed by the host application. The host application interprets any methods in the DD file using a method interpreter, thus providing a safe area or “sandbox” where methods can execute.

Security and reliability become enhanced because the installation of a DD file does not initiate installation of DLL files or other executable software.

DD is useable by all device manufacturers due to protocol independence. The IEC 61804-2 EDDL standard implements vendor-independent electronic device description (EDD) source files that describe a device's configuration, maintenance, and functionality.

The standard provides a specification for defining the architecture of the EDD application, syntax (form), semantics (meaning), and user interface structure.

The IEC standard, approved this March, currently defines how DD technology applies to Foundation, HART, and Profibus protocols. Wisely, the design of the standard is to be communication protocol– independent and expandable to include other fieldbus protocols that would benefit from the use of DD technology.

Worldwide use

DD technology includes support for multiple languages as defined by the International Organization for Standardization (ISO). Under the DDL structure, DD developers can write a single DD that incorporates multiple language text strings, each conforming to ISO 639 for language codes and ISO 3166 for country codes. The DD host application selects the appropriate language from the DD file to display user information.

To avoid conflicts with the host application and to maintain a consistent and uniform look and feel, the DD file does not specify fonts, window sizes, color, or other aspects of the host interface.

Because of the wide number of host application types—from a PAS with a rich graphic to a simple handheld with a limited capability display—the host application generates the screens based on “hints” provided by the DD file content. This permits each host application developer to seamlessly integrate DD information with a specific host application's capabilities.

The architecture of DD technology makes it easy to use multiple protocols within the same host application, requires no custom tools for configuration and calibration, and still maintains a common look and feel between the system software and device configuration. This is an advantage when it comes to operator and maintenance personnel training and use.

During a time when software technologies quickly become obsolete, quarterly operating system security patches are the norm, and a new operating system appears every couple of years, pre-1990 DD technology continues to flourish.

Adopted for instrumentation and automation applications in 1992 by HART Communications Foundation, DD technology is now in more than 15 million Foundation HART and Profibus devices worldwide.

In 2002, Infraserv Hochst established a multivendor laboratory, incorporating six Foundation fieldbus host systems and 42 field devices from 11 instrument suppliers. Infraserv Hochst developed and applied a variety of tests to evaluate the interoperability of the Foundation fieldbus technology.

In a final report delivered to the NAMUR general assembly in Lahnstein, Germany, 100% of the DD files worked correctly between each host system and the respective devices, further validating an important aspect of DD technology—systemwide interoperability occurs through a well-defined specification and rigorous testing procedures.

Representatives of Fieldbus Foundation, HART, and Profibus met in February 2003 to begin a collaborative project to extend the capabilities of IEC 61804-2.

The scope of the cooperative project was to add robust organization and graphical visualization of device data as well as support for persistent data storage features to IEC 61804-2.

When completed, the project's resultant work will integrate within the three current participating fieldbus network technologies and add to the IEC standard during the standard's next scheduled maintenance period.

Sophisticated devices, such as control valves and radar level gauges, with hundreds of configuration, calibration, and diagnostic parameters, will benefit from the new user interface enhancements. Familiar dialog boxes, text, dynamic variables, pictures, charts, and archival data go to users in a consistent, familiar format. Graphs, such as control valve signatures, may incorporate pan/zoom functionality for inspecting specific detail. Additionally, DD extensions support user interaction with device content, such as permitting adjusting filter values.

By providing a standard, platform-independent means for displaying graphical information, device suppliers using DD technology can focus their resources on increasing product features to better meet user requirements, knowing that the solutions consistently deliver across a variety of platforms and operating systems.

Another DD extension useful to end users is support for persistent data storage. This new feature permits device suppliers to instruct the host application to store device or local data. This implementation relieves the device supplier of the burden of the underlying file system of the host application. The host application can manage data storage. The persistent data store enables a variety of new applications using DD technology. For example, valve diagnostic software, developed using DD technology, can archive valve signatures for later review by support personnel. P

DD lifeline