Communicating Diagnostics via EDDL

It’s often difficult to understand the value a new international standard brings to your process manufacturing operations. Emerson’s Jonas Berge has been hard at work in his capacity on the standards committee ISA104, Electronic Device Description Language (EDDL) to educate process automation professionals. In addition to the standards committee Jonas contributes his energy to the EDDL.org website and the EDDL email list. You can also see some of the other times I’ve featured his work.

His latest article, Temperature Transmitters: Warming Up to EDDL, in Industrial automation asia magazine, describes how enhancements to EDDL (a.k.a. IEC 61804-3) have improved setup and diagnostics of temperature transmitters.

Jonas describes how the technology in temperature transmitters has advanced to provide diagnosis of their health, the sensor wiring and the temperature-sensing element. This diagnostic information is communicated back to the asset management and/or automation system via digital protocols such as HART, WirelessHART and Foundation fieldbus.

An example Jonas offers is a temperature element burnout. The temperature device uses the EDDL standard to

…provide image displays, switched dynamically, that illustrate the problem.

Some of the more sophisticated temperature transmitters have dual sensing elements. Sensor drift can be determined and reported back to an operator or maintenance technician if a maximum difference is exceeded between the two measurements. These dual sensors can also operate in a hot-backup mode if they measure the same point. They are set in a primary/standby mode where failure of the primary sensor causes its value to be ignored and the backup sensor to be used.

Jonas also describes a loop-testing scenario typically performed by maintenance technicians:

Systems and software that fully implement IEC 61804-3 support EDDL wizards that take the technician through required steps to check the temperature transmitter as defined by its manufacturer.

The wizard reminds the technician to inform the operators that a loop test will be performed so the associated control loop can be changed to manual to prevent upsetting the process when temperature is simulated.

The EDDL standard provides a standard way for device manufacturers to embed help into these devices, which reduces learning hurdles for operators and maintenance techs to use these diagnostics.

Thanks to Rohit Kadam for pointing this story to me in his Nice To Meet You..! blog. Rohit is an active member in our DeltaV Twitter Community.

Posted Wednesday, July 2nd, 2008 under Interoperability, Measurement, Technologies.

3 comments

  1. With all due respect, that article by Jonas is severely lacking in actual detail. He clearly does not describe which EDDL enhancements allow for easy diagnostics.
    Also he makes the bold claim: “EDDL is the only technology that can display diagnostic detail directly to operator consoles showing failures that affect process operation.” There is no basis for this claim at all.
    In fact the whole article lacks in details that the reader would expect in order to learn something about EDDL.

  2. Dude, Thanks for your comments. I’ll pass them Jonas’ way for additional comment. Magazines do have various word count constraints that sometimes don’t allow a full airing of the details and is why I try to add hyperlinks to additional sources of information.

  3. Dude, thanks for your frank feedback. The article was written as a tutorial on intelligent device management for end-users, not about writing EDDL for device makers. That is why it has a high-level approach just guiding them to specify enhanced EDDL for their systems and devices in order to get the ability to visually see device diagnostics in the operator console of their DCS.
    Here is an attempt to provide the level of detail you are looking for. Device developers use many of the features of EDDL to achieve precisely the display they want the users to see. For example, MENU renders as navigational aids such as tabbed card, navigation area/tree, frames around related parameters, and pop-up WINDOWS that allows device developers to control how diagnostics is organized so it becomes easier to find.
    Because the display in the case of EDDL is rendered by the device management software, it highlights the failures using the same indication for all kinds, protocols, and brands of devices, for example red for failure. There is no difference from one type, protocol, or brand to the other. This consistency in look and feel is inherent in EDDL technology and doesn’t even require style guide. This unique consistency makes devices easy to use. That is, device developer controls content while look and feel comes from the host.
    Device manufacturers use IMAGE to illustrate concepts or problem areas, for example a picture of the problematic part such as a sensor. Trend CHART may be used to show value over time for user to spot intermittent problems. Gauge, bar graph, and histogram are useful to mimic values visually so they can be seen if technician steps away from the software while working on the device etc.
    Manufacturers impart their know-how to the user through HELP text and images making troubleshooting easy.
    Device developers use “conditionals” in order to show one image when the device is healthy but another image when there is some kind of fault, in order to clearly illustrate what/where that particular fault is. XY-GRAPH/WAVEFORM plot is probably not used in temperature transmitters. I have only seen it for advanced setup and diagnostics such as echo curve, valve signature, and vibration spectrum in more sophisticated “complex” devices such as radar level transmitters (non-contacting and guided wave), valve positioners, and machinery health transmitters. I have not seen table GRID used either, but it could be used to enter custom linearization curves for non-standard temperature sensors or setpoint profile for setpoint generator.
    There are only two device integration technologies out there. One is EDDL, the other is FDT/DTM. A DTM is a Windows device driver software programmed by the device manufacturer that can display diagnostics. No DCS permit installation of third-party software because all software (such as DTMs) write to the Windows registry and install EXE and shared DLL software components that may overwrite files from other DTMs or the DCS itself affecting its robustness (a phenomenon known as DLL-hell). This is why DTMs from different device manufacturers cannot be installed on the DCS consoles, and subsequently diagnostics cannot be seen on the operator consoles using FDT/DTM. EDDL is a compressed text file, not software, so EDDL files can be copied on to DCS consoles without having this problem. This is beyond the scope of the article so I left it out.
    So this is why DTMs must be installed on a separated maintenance station. You may have read about it in the WIB report. Anyway, it is a long technical discussion so I went straight to the point that the problem is that usually nobody watches the maintenance stations (technicians are usually out in the field), so if diagnostics is only displayed in the maintenance console, the device management software will fall into disuse. Diagnostics must go to those that see it. Only the operator consoles are permanently watched so this is where diagnostics must go. Clearly you don’t want to send all diagnostics to the operator console because it would be flooded with alarms and light up as a Christmas tree. Instead what is now being done is that field diagnostics alerts from the devices are prioritized so only critical alerts from critical devices such as genuine failures that will impact the process are brought to the operators, not predictive alerts that have not yet materialized. Operators cannot repair devices, but after a failure occurs they have minutes or hours to take evasive action, such as putting loop in manual, before process is affected. It is a form of early warning of impending process problems. And operators can radio the technicians in the field that can fix the device. So going EDDL enables the user to get information to the right user. Its a good topic for another article on integrated system because as per NAMUR NE 91 there are many other benefits.
    I figured knowing how EDDL actually works may not be so useful for the average reader so I focused on why it is useful. To find out how EDDL works go to http://www.eddl.org/basics.htm
    Device developers can read the detailed EDDL use paper here http://www.eddl.org/developer-corner.htm

Leave a Reply