Profibus

I saw ARC Advisory Group's Larry O'Brien's post this week, Emerson Profibus Membership is One More Step toward Common Ground. In it, he writes:

In fact, Emerson has supported Profibus for some time. The PNO membership officially seals the deal and gives Emerson a hand in future PNO development activities, most importantly the implementation of EDDL or Electronic Device Description Language in future iterations of Profibus. EDDL is a common technology that is shared across the Profibus, Foundation Fieldbus, and HART protocols, and serves essentially as a markup language that describes the characteristics of devices and how data should be stored and displayed. EDDL files are similar to XML files, and are used to describe equipment parameters, such as device status, diagnostic data, and configuration details. EDDL is operating system independent and host system independent.

Readers of this blog know that we do discuss EDDL and its cross-protocol applicability and importance to process manufacturers--a consistent view into devices from multiple suppliers, multiple digital communications protocols, and multiple operating systems. In one post, I summed it up:

Following the EDDL standard, device suppliers create Electronic Device Description (EDD) files for their smart field devices. These files provide a standardized form and structure for automation systems and handheld communicators to access and display device diagnostic and setup information, independent of communication protocol or operating system.

Emerson's Terry Blevins gave a nice, quick demonstration of this interoperability including WirelessHART devices at last year's ISA Expo.

The EDDL.org team also has quite a number of demonstration videos on their wwwEDDLorg YouTube channel. Emerson's Jonas Berge provides a lot of the energy behind the new content on EDDL.org. He had a conversation last fall with Automation World's Gary Mintchell, recorded in Gary's Feed Forward blog podcast.

As Larry notes, Profibus has been supported around Emerson for a long time. One example is Profibus DP support in the DeltaV system introduced back in the v5.1 release.

Common ground is a good thing when it comes to access to the information in the smart devices which touch your process and have the ability to warn you of abnormal situation which might impact your plant's performance. The advancement of the EDDL standard is one example of this common ground.

MP3 | iTunes

Update: Thanks to the person who spotted and alerted me to the broken link to Larry's post. I've fixed it above and added it here.

I received an email recently from Emerson's Jonas Berge. As a member of the ISA104 Electronic Device Description Language (EDDL) committee, Jonas works to educate process manufacturers on how this standard fosters interoperability between intelligent field devices, asset management software, and process automation systems from various automation suppliers.

Jonas is a large contributor to the EDDL.ORG website. This site provides a basic overview of the standard, news updates, demonstration videos, and other educational materials.

I'll highlight a few recent videos that Jonas and his team have added to the EDDL YouTube page. This first video shows how trend chart data and a level radar echo curve can be exported to Excel for analysis. It includes a Rosemount 3144P temperature transmitter and Rosemount 5400 radar level transmitter in Honeywell SDC-625 software.

The second video shows how the device manufacturer's expert provides their know-how in the form of context sensitive help text for parameter settings and diagnostics. It also shows how device management software provides easy access to device manuals as well as drawings and procedures, and ability store notes. It includes a Rosemount 3051S and Siemens TH300 transmitter, AMS Device Manager and Siemens PDM software, and a 375 field communicator.

The third video shows how the configuration of a device can be printed. It includes a Rosemount 3144P shown in Siemens PDM software and a Rosemount 3051S shown in AMS Device Manager.

There are plenty of other videos on the EDDL YouTube page, which show how EDDL is applicable to different communication protocols and is independent of the underlying communication hierarchy. Applications built on this standard can interoperate with data from HART, WirelessHART, Foundation fieldbus, and Profibus devices--all in the same application.

MP3 | iTunes

Earlier this week, I listened to Gary Mintchell's personal podcast, Automation Minutes Episode 59 (iTunes | RSS feed). Gary interviews Emerson's Jonas Berge, a member of the ISA104, Electronic Device Description Language (EDDL) standards committee. EDDL is also recognized globally by international standard IEC 61804-3. A few weeks earlier, Gary had interviewed a member of the FDT (a competing standard) marketing committee.

Jonas provides a detailed summary of what EDDL means to process manufacturers. It's a standard to display information in intelligent field devices communicating via HART, WirelessHART, Foundation fieldbus and Profibus back to the device management software and automation system. EDDL files are standards-based compressed text files that reside in the device management software to provide a consistent view to devices from different manufacturers for setup, calibration, diagnostics, etc. Through the EDDL file, the device manufacturer tells the system what command to send to get information from the device, how to decode it, and how this manufacturer would like to present the data.

Jonas offers a great analogy of how EDDL is like HTML. Both are text-based files. Client software (device management software and web browser) renders both, both are platform independent since they are text files and not installed programs, and both are version independent again since they are not installable programs. And similar to how devices like PCs, MACs and smart phones render HTML pages, PCs and handheld devices with device management software render smart device information.

Also, in how HTML supports sophisticated displays, EDDL supports sophisticated ways to render valve signatures, vibration spectrums, radar level "echo curves", dial gauges, historical trends, and step-by-step "wizard" procedures. Jonas points out that these graphical enhancements were added to the EDDL standard in 2006 to address the NAMUR NE 105 requirement to support access to full functionality in complex devices in the way the device manufacturers want this functionality to be displayed. These complex devices include valve positioners, variable speed drives, machinery health transmitters, wireless gateways, and bus diagnostic modules to name a few.

The design basis behind the EDDL standard is that the device manufacturer knows best what information their devices contain and how it should be displayed. The device manufacturers can make the full functionality of their devices visible and available on any system. The device management software suppliers know best how to provide a consistent view of trends, gauges, step-by-step procedures, etc.

For plant staff members who manage the device management software, the EDDL files do not become obsolete as the operating system is revised or security patches are added. Since these are text-based files, multiple versions can exist together within the device management software to address the plant realities of different devices, from different vendors, communicating with different digital protocols.

The information presented from these various devices have a common look and feel for the instrument technician and others who access the information. And the integrated diagnostics provided by the EDDL standard meet the NAMUR NE 91 requirements.

I captured a quick video at the recent ISA Expo 2008 in Houston, Texas. I just received some photos and ISA104 / EDDL Booth Report that show systems from ABB, Emerson, Invensys, and Siemens interoperating with advanced valve positioners and transmitters from Emerson, Endress+Hauser, Invensys, Masoneilan, MTL, Metso, Samson, and Siemens. These pictures demonstrate this interoperability in action:

MP3 | iTunes

The ISA recently issued a press release around demonstrations of Electronic Device Description Language, EDDL (international standard IEC61804 and ANSI/ISA-61804-3) and FDT (ISA103) technologies at the ISA Expo 2008 in October in Houston, Texas.

For those not familiar with EDDL, I described it in an earlier post as a text-based language that is used to describe the characteristics of field devices. Following the EDDL standard, device suppliers create Electronic Device Description (EDD) files for their smart field devices. These files provide a standardized form and structure for automation systems and handheld communicators to access and display device diagnostic and setup information, independent of communication protocol or operating system.

Emerson's Terry Blevins has been working closely with other automation suppliers on the EDDL demonstration. He also is the ISA104 committee chairman. This committee has adopted the EDDL standard, IEC61804, as an ANSI/ISA standard. The release describes what will be shown in the ISA104 booth at ISA EXPO 2008:

The ISA104 EDDL booth at ISA EXPO 2008 is a demonstration by major DCS manufacturers such as Invensys, ABB, Siemens and Emerson that illustrates the technical strengths of the EDDL standard, IEC61804, to support advanced user interfaces for diagnostics and device setup independent of the communication technology support by the device. Devices such as valve position[er]s based on HART, Foundation Fieldbus, and Profibus from Metso, Samson, Invensys, Fisher Controls, and Siemens are used to illustrate how manufacturers are using EDDL to document their device capabilities in a single, open and consistent format. A live demonstration of diagnostic information being accessed using a WirelessHART adapter connected to a wired HART device and through wireless access to a self-powered WirelessHART device illustrates how EDDL supports the latest wireless devices.

The demonstration provides the exhibit attendees the opportunity to see the advanced interfaces for device diagnostics and device setup that are available from the major DCS manufacturers that use device EDD's. This demonstration will also show how the EDDL technology is by DCS supplier to provide interfaces to support wireless devices based on the WirelessHART standard.

In the release, Terry and the ISA104 committee also describe recent activities to continue to advance the IEC61804 standard:

International Electrotechnical Commission's Technical Committee 65 (IEC TC65) met in Tokyo, Japan, the week of 18 May. The working group responsible for the EDDL international standard, IEC SC65E WG7, met on 20 May and discussed future EDDL enhancements that will be incorporated into the existing standard, IEC61804. A number of guests from Japan and China that attended the WG7 meeting expressed an interest in learning more about EDDL. Thus, following the WG7 meeting, Christian Diedrich and Terry Blevins put on a workshop that provided more detail on EDDL and showed examples of how EDDL is used to write device descriptions.

If your plans include Houston the 14-16^th of October, make sure to stop by and visit with Terry and the other automation suppliers to see how this standard provides a common, interoperable way to present smart device information to you.

Recently, one of my RSS feeds alerted me to a new Micro Motion 2400S transmitter packaged in stainless steel for the ELITE Coriolis flow and density meter line. This 316L stainless steel packaging is:

Rated to IP66 and IP67, the corrosion resistant stainless steel housing is ideal for applications where instruments are subjected to regular caustic wash-downs, which are typically found in the food, beverage and life science industries. The 316L construction is also ideally suited for marine and offshore environments.

I caught up with Emerson's John Martin, a Food & Beverage industry manager for the Micro Motion family of products. I wanted to get the story behind the design of this product.

For those that have never been inside a food & beverage or pharmaceutical manufacturing process, John shared how you'll be struck by the bright, shiny silver look you see around the process. Hygienic standards are paramount in these industries and a mild caustic (e.g. sodium hydroxide) is often used to wash down the processing equipment. Standard painted-aluminum transmitter housings do not do well in this caustic environment. This new 316L stainless steel housing allows the transmitter to be integrally mounted with the Coriolis meter and provides a local display at the measurement point for the operations personnel.

John noted that normally, transmitters with aluminum and painted-aluminum housings had to be mounted remotely, in stainless steel enclosures or control rooms, to avoid the corrosive environment. This installation method meant more engineering and installation costs.

This 2400S transmitter supports DeviceNet and Profibus DP communications. These are common digital bus communication protocols used by PLCs and other automation systems like Emerson's DeltaV system. Across two wires, these transmitters communicate process and diagnostic information back to the controllers. From the press release:

The result is that one instrument can provide flow, density and temperature measurements, eliminating the need for multiple sensors and the wiring/configuration costs associated with them. In addition, digital communications unlock instrument diagnostic information, such as drive gain, meter verification and other alarms.

John also shared with me that other industries like offshore oil and gas and other marine environments have corrosive environments caused by saltwater and salt in the air, making them good candidates for this stainless steel transmitter housing.

I do know from my days back as an engineer working on offshore Gulf of Mexico oil and gas platforms, that we put the instruments with painted aluminum housing inside 316 stainless steel junction boxes to protect them from the corrosive, salt-air environment. This packaging option might have reduced the size/number of junction boxes required.

Update: I just saw a Twitter "tweet" from @timalosi who reminds me:

there is more to hygenic than stainless. draining is much more important. the Housing is just for looks

Tim, point taken and all in 140 characters or less!

I had the opportunity to visit with Emerson's Tom Wallace who was here in Austin recently. I like to joke with Tom that a post I had done with him comparing and contrasting HART and Foundation fieldbus caused such a stir, that it produced one of this blog's highest monthly visitor totals to date.

So let's see what we can do this month! Tom takes a comparative look at some of the swirl that surrounds EDDL and FDT/DTM in a new paper, FDT/DTM, and Enhanced EDDL, what's best for the user. These are both technology enablers for field devices, automation systems and asset management applications.

If this is all acronym soup to you, here's Tom's brief description of these technology enablers:

Device functionality is invoked using Electronic Device Description Language, EDDL or DTM's [Device Type Manager]. The DD or DTM tells the host what functionality the device has, and how the functionality is invoked. It also tells the host how to do common maintenance functions such as calibration, trims, tests, and other device activities.

I'll start with Tom's conclusion and then highlight some of his supporting points. He concludes:

In my opinion, there is a better technical implementation based primarily on ease of implementation and support. That solution is to use EDDL for all devices where EDDL is technically capable of delivering complete device functionality, and to use a DTM or a snap-on application to handle only the exceptions. I make this recommendation because it is simpler to implement a single solution than a combined solution. EDDL is a single solution that will work for the vast majority (95%) of HART, Foundation fieldbus, and Profibus PA devices.

Tom's point for commissioning Foundation fieldbus devices contrasts installable programs versus data files:

Commissioning Foundation fieldbus devices on most control hosts require DD's [device descriptions]. Most control hosts have a set list of applications that are considered safe to install on the host engineering or operator station. Each DTM is an application, and the testing required to ensure hundreds, or potentially thousands of DTM's are compatible with a control host user interface is not practical. EDD's are files, not application programs. Therefore there is no program installation risk loading EDD's on a control host.

On data availability, Tom writes:

...EDDL is the path for data availability that originates from a device, or is going to a device. The OPC Foundation support for the enhanced EDDL will broaden the use of EDDL for applications such as ERP, maintenance management, and other applications.

For the display of data in field devices, Tom notes:

EDDL is supported in the host by DD services. DTM is supported in the host by a frame or FDT. For many applications and hosts either EDDL or DTM can be used for data display. For hosts that are not based on a windows operating system, EDDL will be used as DTM requires a windows operating system. EDDL has defined display objects such as charts, graphs, etc. DTM is more of a free form environment using a variety of programming languages.

The choice for the enabler technology to use is EDDL or a combination of EDDL and DTM. Tom lists some considerations for your discussion based on operating systems, operating system version management, functionality and complexity of the device and if a custom display needs to be created.

Tom sums all this up with the following recommendation:

The final recommendation is to use EDDL as the required standard since each device must have a DD. Allow the use of DTM's on an exception basis where the functionality is required, and EDDL cannot provide it. Make sure that all the functionality to replace a failed device, or place a new device in service is available in EDDL. This will simplify implementation and maintenance, mitigate operating system migration issues, and provide a lower risk more error free working environment.

Update: Welcome readers of Gary Mintchell's Feed Forward blog! Join the conversation and add your comments below or on Gary's post.

I recently joined the Electronic Device Description Language (EDDL) mailing list to follow the work of this important standard. For those not familiar with this standard, EDDL.org describes it:

Electronic Device Description Language (EDDL) technology is used by major manufacturers to describe the information that is accessible in digital devices. Electronic device descriptions are available for over 15 million devices that are currently installed in the process industry. The technology is used by the major process control systems and maintenance tool suppliers to support device diagnostics and calibration.

In prior posts, I've discussed how this text-based standard makes the exchange of information from smart field devices and maintenance software and/or automation systems easy so that information from different suppliers field devices can be presented to you in a common way. These smart field devices are based on the popular digital communications protocols HART, Foundation fieldbus and Profibus. EDDL can theoretically be used with any protocol. The standard declares device parameters and their dependencies, visual representations, user interactions, and how systems access information.

Emerson's Jonas Berge is an active participant in EDDL and the ISA104 Committee and recently posted a summary of activities that I thought I'd share:

BIS test find EDDL meets NAMUR NE 105

EDDL Workshop, Frankfurt Germany, 8 April 2008

ISA Electronic Device Description Interoperability Guideline Gains ANSI Approval

ISA Electronic Device Description Gains ANSI Approval

Recent Articles
EDDL makes Foundation fieldbus easier

EDDL: Unlocking Device Information

EDDL allows interoperability for devices to constantly gather information

News/Events Archive
EDDL demo and presentation at CIA2007 in Singapore 27-30 November

ISA104 explains EDDL at ISA EXPO 2007

EDDL demo and presentation in Japan in November 2007

EDDL demo and presentation in Singapore in November 2007

Forum
Make sure your colleagues involved with bus technology and intelligent device management also join this EDDL forum. There will be more important announcements shortly.

Jonas noted to me that the first link to the BIS test (BIS Prozesstechnik--subsidiary of Bilfinger Berger Industrial Services) used devices and control systems from different suppliers to see if the EDDL meets the requirements in NAMUR recommendation 105 for field device integration in engineering tools. This tested the IEC 61804-3 standard and how it is used by device and control system manufacturers, and the advantages the new EDDL standard has for plants in the commissioning, operation, and maintenance phases of the lifecycle.

The test is described:

A wide range of device types were tested including everything from the simple temperature and pressure transmitters to sophisticated radar level transmitters, valve positioners, and frequency converters (variable speed drive) connected via HART, FOUNDATION fieldbus, PROFIBUS DP and PROFIBUS PA bus systems.

Findings include:

The study found that EDDL meet the requirements also for complex devices, further software tools are not required. EDDL wizards, images, and trend charts enable good usability and intuitive operation also for complex use cases (e.g. Partial Stroke Tests).

Jonas and those involved in the EDDL standards effort have been quite busy in communicating their activities. I hope this post helps bring some additional visibility to these efforts.

In the early days of Foundation fieldbus back in 1996 and 1997, we used to do capital expenditure (CAPEX) comparisons of installations installing Foundation fieldbus versus what they would have cost installing conventional I/O. The savings were pretty eye opening in terms of material and labor savings, commissioning time, and control room space savings.

The big part we missed, because there hadn't been enough run-time, was the much larger operational benefits available through abnormal situation prevention, predictive maintenance, and improved control.

I bring all this up because I found in RSS feeds recently the article, Reviewed resource: Profibus PA and Foundation Fieldbus--a cost comparison, on the Control Engineering website. The whitepaper was developed by the Profibus Trade Organization.

The focus of this study was a CAPEX look at the differences between Foundation fieldbus (FF) and Profibus PA installation. The report concluded that: Profibus PA devices are less expensive, one can fit far more PA devices on a segment than comparable FF devices, the links are less expensive, and PA is easier.

My initial reaction was not suitable for family reading, so I ran it by some folks, including Emerson fieldbus consultant Dan Daugherty, who is both a Foundation fieldbus expert and a Certified Profibus Network Engineer. His initial response to me was also not suitable for family reading, so I put the post I'd worked up aside for several days of calm reflection. So now, here we go...

One argument made was that PA devices cost less than FF devices due to extra memory and processing power needed in Ff. While not conceding that this is true, and not wishing to discuss pricing on this blog, I'll simply say from classic economics 101, that price is determined by the market, based on the value received and not the cost to make.

I'm not sure what automation system was considered in the analysis, but the study claimed costs associated with a "linking device" in Foundation fieldbus. In systems like the DeltaV system, the FF segment connects directly to an FF input card in the I/O subsystem, as do other buses like Profibus DP, DeviceNet, and AS-i bus. A PA device cannot be directly connected to a host system, but rather must come through a linking device. In the DeltaV system, a PA device is connected through a linking device to a Profibus DP segment.

As Dan points out, this introduces increased engineering, increased maintenance, and a higher probability of failure on demand with these additional components. This impacts both capital expenditures and ongoing operational expenditures.

Another claim in the whitepaper is that more PA devices can be put on a segment than FF devices. Dan notes that since communications on a PA segment are not deterministic, to deliver the same control update period as FF, say the 400msec mentioned in the whitepaper, it must oversample and reduce the number of devices. In this 400msec case, an FF segment can run 6 control loops (12 devices.) A PA segment would need to drop from 24 to 12 devices and sample at 200msec to achieve this 400msec control update period.

Voltage drop on a bus-powered bus is also a constraint. It's a function of the length of the segment (trunk plus spurs) and the current draw of the devices on the segment. In order to get the bus lengths typically seen in process manufacturing applications, there's little chance of ever finding 24 devices on a segment. FF can allow 16 bus-powered devices, but the typical practical loading, constrained by voltage drop (same rules for PA) usually makes 12 devices a more typical real-world implementation. Also, typical plant practices partition segments by geographic region, process criticality, and future growth capacity, which also limit segment device counts.

The easier/less-complex claim is the biggest head scratcher. PA and FF have the same physical layer so grounding and other physical installation considerations are similar. From a device-commissioning standpoint, I'm not sure what's easier than connecting a Foundation fieldbus device to a segment, having it automatically recognized by the system, and quickly commissioned into operation. When you have to introduce a linking device into the mix, it gets harder, not easier. Especially when there is RS-485 running on DP and bus-powered Manchester Biphase on PA, each requiring separate tools and linking devices.

This post could go on and on to discuss the operational benefits associated with Foundation Fieldbus in abnormal situation prevention, robustness, ongoing calibration savings and even autotuning within the device, but I think this is a good stopping point.

Automation World magazine's editor in chief, Gary Mintchell, wrote a post yesterday on his Feed Forward blog. The post, The Saga Continues - FDT v EDDL describes some of his discussions with people involved in both groups about the relative merits of their respective approaches to smart device communications. Lest I be accused of tossing around acronyms too casually, EDDL stands for Electronic Device Description Language and FDT stands for Field Device Tool.

Because I subscribe to Gary's RSS feed with Outlook 2007, I was able to forward his post much like an email message to Emerson's Terry Blevins and Tom Wallace for their views. Here is the text of their comments posted on the Feed Forward site.

From Terry:

Gary, It is good to see your interest in EDDL. As you may be aware, EDDL is the international electronic device description language standard for the process industry (IEC 61804).

Through the work of the ISA SP104 committee the IEC61804 standard was officially adopted last year as an ISA/ANSI standard. The SP104 committee worked with ISA to establish the www.eddl.org web site. At this web site you will find information on the benefits of EDDL and the advantages that EDDL has over other technologies.

In particular, you may find the paper and the tutorial that the SP104 committee presented at ISA2007 EXPO to be of help in examining this topic in more detail - please see www.eddl.org/files/ISA2007_EDDLTutorial_Presentation.pdf and www.eddl.org/files/ISA2007_EDDLTutorial_Paper.pdf.

Best regards,

Terry Blevins
Chair, SP104

From Tom:

Gary,

First, some good comments from you, thanks. I have a few thoughts to add to yours. First is a technical clarification. EDDL is the language used to write DD's. The DD is not in the device, it's in the host. Next, FDT/DTM is not used by any control host to my knowledge. It's used for asset management, therefore it's not in the DCS, the DCS usually is the path for information from the field to the FDT application. Regarding differences, because EDDL is operating system agnostic, DD's written using EDDL can reside in a handheld. FDT/DTM requires a PC level Windows operating system. As such, it won't work on devices that use an embedded operating systems such as linex, or Windows CE. Also, control hosts frequently use DD's. For example, Yokogawa CENTUM CS3000 uses EDD's to understand and use the capability of FF field devices. To my knowledge, DTM's are not used in this way. The net result is that the user will need DD's for intrinsically safe handhelds, and will in many cases also need DD's for the control host to correctly function with FF devices.

DD's will provide the functionality to perform maintenance functions on just about any HART, FF, or Profibus PA device in existence. Adding FDT/DTM where it's not needed adds to end user maintenance cost and time. Both EDD's and DTM's must be installed and maintained. Why add maintenance work if it's not needed? In addition, EDD's have been forward compatible for many years. What this means is that if a user installs a newer version of device to their plant, an older DD will work with the newer device. It may not know about enhanced functionality in the newer device, but it will perform the basics of configuration and maintenance. When it's 2AM and you're trying to avoid a shutdown, or get the plant back up, the last thing you want is to find you don't have the latest configuration file you need to configure your device. Although DTM's could be written to be forward compatible, to date most are not. I recommend users of FDT/DTM have a complete set of DD's available and on tools they use regularly so they can avoid this potential problem. There are some cases where EDDL is not sufficient, and a supplementary technology is needed. Some devices require calculation capability beyond that provided by EDDL for initial device setup. These devices usually have a separate Windows based configuration program already available to provide the added capability. DTM's have potential use here, but alternate solutions already exist. At this point I think that DD's will always be in the plant, and DD's will continue to be needed to perform functions and in environments that FDT/DTM cannot serve. One other issue I'm seeing with FDT/DTM is that it is not being used as a complementary technology to EDDL, it's being used as a replacement for EDDL to perform functions that have been and will continue to be completely supported with EDDL. These functions include device configuration and maintenance for devices that have been completely supported by DD's in the past, and continue to be completely supportable by EDDL or enhanced EDDL today. Since EDDL is an IEC standard, I am concerned about FDT/DTM, or any technology that is being used to move users away from standards, especially since the standard, EDDL will provide all the functionality needed for the vast majority of devices in all plants worldwide today. Another concern is that FDT/DTM may be slowing the implementation of the full functionality of EDDL in host systems. As such, it's not a complementary technology, but a competing one. Finally, I'd like to make a recommendation for the end user community. It strongly aligns with your recommendations, but has some additional points. The first is that the end user community encourage their host vendors to fully implement all the features supported by EDDL in their hosts. The second is that the end user community encourage their host vendors to move with speed and dedication toward the solution being worked by the EDDL / FDT/DTM working group. When this solution is available it should provide the best of both EDDL and FDT/DTM. The third is that I recommend the end user community use EDDL as their standard solution and add FDT/DTM on an exception basis. Since FDT/DTM is being positioned as a complementary technology to EDDL, I encourage the end user community to use it that way. Use FDT/DTM only if and where it provides needed functionality that is not available through EDDL.

Although I am strongly pro-EDDL, and cautious about FDT/DTM, I hope these comments have some merit, and you will consider posting them.

Thanks and regards,

Tom Wallace

If you have thoughts to share, join the conversation on the Feed Forward site or here.

Advancing industry standards remains a vibrant activity in the process automation business. These standards foster faster market acceptance of new technologies by providing interoperability among many suppliers' devices compliant to the particular standard.

InTech magazine has a nice update on one of these standards efforts, Electronic Device Description Language (EDDL) which is an extension of the International Standard IEC 61804-2. The article, EDDL allows interoperability for devices to constantly gather information, was written by ISA104 committee members, Christian Diedrich, Ludwig Winkel, and Emerson's Jonas Berge and Terry Blevins.

The authors succinctly summarize the benefit of the EDDL standard for process manufacturers:

Using this technology, it is possible to provide an interoperable environment where distributed process control systems or handheld communicator can gather information available in modern automation sensors and actuators to configure, calibrate a device, diagnose problems, and provide data and alarms for user-interface displays.

They also note that the technology is pervasive in smart field devices:

For a user to garner Foundation Fieldbus (FF) certification, EDDL is a requirement, and it is the only device description language supported by the HART Communication Foundation. Because of that, virtually every Process Control Systems vendor worldwide supports EDDL. On top of that, Electronic Device Descriptions' (EDD) are available for any FOUNDATION, HART, and some Profibus based field devices.

EDDL's text-based data structure allows it to be platform independent:

EDDL provides a well-defined structure for supporting the most simple to the very complex field device. Since EDD's are text-based interpreted by the host system, these files are independent of operating systems and control platforms. This structure allows the same EDD to have a common look and feel across applications, which reduces the learning curve and supports multiple host applications. Also, this enables field device additions to come into play without affecting the runtime stability of the control system.

The biggest benefit for users is that a consistent graphical user interface can be used to display the EDD information in smart devices, even when these devices come from different automation suppliers. The article states:

Graphical visualization supported by EDDL such as graphs and charts take full advantage of the capabilities of the host automation system. These capabilities can benefit engineers and maintenance personnel by providing a consistent look and feel during device configuration and maintenance.

Applications like Emerson's AMS Device Manager and 375 Field Communicator provide graphical views of graphs, charts and calculations into devices supporting EDDL. These views also include complex instruments such as digital valve controllers, radar level gauges and multivariable meters.

Jack Murray, a member of Emerson's Metals, Mining, and Minerals industry team, shared a paper he had co-written with an Alcan Gove bauxite mine and alumina refinery staff member and Emerson fieldbus consultant, Sudhir Jain. Alcan was recently purchased by Rio Tinto.

Their paper, Fieldbus Technology on a Large Scale Mineral Project, describes Alcan's path from the 4-20mA analog world to a digital bus communications world. Alcan's investigation of the benefits of moving from analog to digital began in 1999. They had seen possible ways to reduce their project costs and improve operations by using digital busses.

Their first step, like most when undertaking something new, was a small step. They chose to implement Foundation fieldbus in a non-critical area of an existing facility. Their initial installation consisted of 20 I/O. They chose fieldbus devices from a number of automation suppliers to obtain a greater breadth of experience. They also chose Profibus DP for their motor control centers and variable speed drives.

This experience proved beneficial when the decision was made in 2004 to nearly double refinery capacity to meet growing demand. The project consisted of 5,000 field devices and 15,000 total I/O including motors and drives. They used a DeltaV system and the two digital busses, Foundation fieldbus and Profibus DP, for which they gained experience to connect the majority of this I/O. A key part of their decision was to work with Sudhir during the front end engineering design (FEED) process to assist in the segment design, training of key personnel, and to establish wiring best practices and standards.

Sudhir related to me how they developed new hazard analysis procedures (CHAZOP, short for control HAZOP) to ensure that failure of any bus segment would not leave a critical part of the plant unmonitored or uncontrolled. Segment segregation practices were developed to address the findings from this analysis. They also had a 3D model of the plant site, so that questions of distance and pathways could be quickly addressed to help rapidly advance the engineering effort.

They chose a modular construction approach using pre-assembled modules (PAMs). These modules were assembled and fitted off-site and fully pre-commissioned before they were delivered to the plant site. These PAMs were self-contained units and included process vessels, piping, pumps, instrumentation and valves, all fully wired and tested.

The digital busses fit into this modular approach with test procedures developed and a portable DeltaV system used to test field devices and fieldbus segments within the PAMs. Once delivered to the plant site, it was much faster to hook up fully tested segments than to individually terminate and retest devices as had to be done on their analog-based projects.

The project team followed elements of the Construction Industry Institute (CII) PepC model. The paper describes this model:

In the new model procurement transactions for the most critical elements of the project (indicated by capital P) happen first and to a large extent define the next step, the main body of the engineering effort for the rest of the project (Capital E). This is followed by procurement of the materials for the rest of the project (small p), followed by the actual construction (capital C).

This model helped Alcan take advantage of the expertise of the suppliers involved in the project and aligned with their globally distributed engineering and procurement practices. It also supported their modular approach and the use of PAMs.

As with most every bus-based project, they documented savings in cabinet space, installation and commissioning. The real value was in the accelerated project timeline. In five fiscal quarters, 95% of the engineering, 76% of the PAM fabrication, and 54% of the on-site construction was completed. Alcan was able to meet their aggressive project schedules and get production on-line sooner.

Update: Welcome readers of Carl Henning's PTO PROFIblog. I'm not sure about the "voice of reason" part, but like Carl, I certainly agree that the benefits from the digital bus technologies outweigh the change in status quo from the analog world.

Read the Crossing the Chasm article to which Carl refers and judge for yourself. Feel free to let me know what you think.

For those attending the ISA Expo 2007 this week in Houston, Texas, there is quite a number of Emerson experts presenting papers. Topics being presented include: safety, analyzer integration, statistical analysis, EDDL, wireless, applied Foundation fieldbus, project justification, building automation, mesh networks, and predictive maintenance.

I'll be coming in to listen in on some of these and meet with some members from our automation blogging community.

I had a chance to catch up with ModelingAndControl.com's Terry Blevins who will be co-presenting, Keeping Systems and Communicators Up-to-date using EDDL. Here's a quick preview if this standard is something you want to learn more about. Terry also chairs the ISA104 committee that is working to advance this standard.

This tutorial explores the history of the Electronic Device Description Language (EDDL) developments, how the technology works, the benefits of the approach taken, recent advancements, how systems and communicators are changing because of these advancements, and demonstrations. EDDL, or IEC 61804-3, is an international standard and is endorsed by four major interoperability foundations: Fieldbus Foundation, HART Communications Foundation, Profibus Nutzerorganisation e.V (PNO), and the OPC Foundation.

EDDL is a text-based language that is used to describe the characteristics of field devices. Following the EDDL standard, device suppliers create Electronic Device Description (EDD) files for their smart field devices. These files provide a standardized form and structure for automation systems and handheld communicators to access and display information, independent of communication protocol or operating system.

The goal of this technology is to provide an interoperable environment where automation systems and handheld communicators for the purpose of configuration, calibration, diagnostics, and operating data and alarms for display can access information available in smart field sensors and actuators. There are more than twenty million smart devices installed in the world that have EDDs. These first began to appear in the early 1990s in HART devices, and was adopted into the Foundation fieldbus and Profibus standards in 1994. The EDDL.org site provides much more on the history and activities in the advancement of this standard.

Recent enhancements to the standard include better parameter organization, support for charts, graphs help better visualize the information in the smart field devices, and persistent data storage to convey historical information. These enhancements were approved in 2006 as a part of the IEC 61804-3 maintenance cycle.

The next phase of enhancements includes additional support for devices connect to the process including the ability to pass procedures like device setup and maintenance. Other enhancements include increase data access to databases and lookup tables, extended product information access, OPC UA information model, and support for modular devices.

The common threads through the demonstration of EDDL in action is the versatility in support from simple to very complex field devices, the independences of operating systems and control platforms, the common look and feel from an information visualization standpoint, and the ability to add devices on the fly without affecting the running automation system.

The ISA104 committee is meeting at the ISA Expo, so stop by to speak with Terry and the committee members at booth 1356 to find out more first hand.

I caught up the other day with Emerson's Dan Daugherty, whom you may recall from an earlier post on Foundation fieldbus operational benefits. Dan is a fieldbus consultant and has a lot of experience working with process manufacturers on their digital bus implementation planning.

Dan also shares that geek gene that afflicts me and many other engineers. For those old enough to remember the late sixties movie, The Graduate, the one word of advice offered to Dustin Hoffman by his father's friend for his future was "plastics". For Dan and I who came on the engineering scene in the 1980s, the advice given to us would have been "microprocessors".

These pervasive, smart little pieces of processed sand are what make this ever-growing digital revolution possible. In our world of process automation, it means a host of digital communications protocols has come along including HART, Foundation fieldbus, Profibus (for Carl's benefit!), DeviceNet, and AS-i bus to name a few. Note that I say digital communications instead of digital busses to avoid the argument that HART communications are not bus-based. As Dan points out, this is technically true with a bus being defined as parallel wiring used to connect multiple devices. It's also true that digital communications occur over the HART 4-20mA analog signals.

This digital communications revolution has been fostered by ever-increasingly powerful, lower cost, and lower power-consuming microprocessors. Communications went from one-way process variable (PV) communications to bi-directional communications where PV, signal status, diagnostics, and configuration information could also be communicated between smart devices and automation systems.

Dan shared an example of a variable speed drive connected via Profibus DP or DeviceNet to a DeltaV system. These digital busses are typically used for motor control center (MCC) line-ups including drives, switchgear, and motor starters as well as non-MCC devices like on/off valves, discrete I/O blocks, and valve islands.

In the pre-digital bus era, it would take five pairs of wires to handle the basic functions of: start/stop, feedback, speed setpoint, speed feedback, and status. With Profibus DP or DeviceNet, you need two pairs of wires. Even with all these wires, the fundamental missing element of the old way was the lack of diagnostics.

Even more, because it's a bus, you can get perhaps 30 or more devices on DeviceNet or Profibus DP segment, and that changes your ratio from 5:2 to 150:2. In some cases (e.g. drives), the power wire can come from another source, so it's potentially 150:1. So, now you can get diagnostics you didn't have before, some of which come in every cyclic data exchange (and are easily available to operators if you want them to have them, and deeper dive drill-down diagnostics your maintenance staff can access on demand.

Using these diagnostics to avoid a single abnormal situation likely will provide you a greater return on investment than the entire wiring, installation and commissioning savings provide.

Now, Dan will be the first to point out that nothing comes for free. When designing a project to incorporate Profibus DP or DeviceNet, you need to consider the topology of your segment, segment length limitations, devices per segment and power for the devices. Also, there are differences in the two busses even down to the physical layer. DeviceNet provides power and communications in one cable which has its advantages and disadvantages.

A key point is that all busses (or buses as Dan argues with me) have different purposes in life and it's unlikely that a plant would or should standardize on just one. With systems like the DeltaV system which support multiple busses natively, you can choose your expensive equipment (ala the Construction Industry Institute's PEpC process) and then the DeltaV system will be able to connect to which ever bus that equipment uses.

The good news is that once you have developed standards around these digital busses by working with Dan and the other fieldbus consultants, future projects become easier. These standards can extend from the wiring and installation considerations into how the diagnostics are used in defined, modular control strategies to help avoid abnormal situations and improve operational performance.

It's amazing what these microprocessors have made possible.