Foundation Fieldbus

Emerson's DeltaV team connected with ARC Advisory Group's Larry O'Brien to share details on the DeltaV I/O on Demand capability in the upcoming DeltaV version 11 release. Larry's ARC View, How Emerson's "I/O on Demand" Is Changing the Automation Infrastructure, summarizes the I/O on Demand concept as it applies to Electronic Marshalling, Foundation fieldbus, WirelessHART I/O, and safety instrumented system I/O.

In the whitepaper, the issue for process manufacturers is framed:

A lot of wiring in place today in process plants probably doesn't need to be. The potential for reducing this wiring, I/O, and other hardware components and the labor costs associated with it is tremendous.

For those not familiar with the phrase, the last mile (or last kilometer), it's the final hop of the communications path to end customers. Many think of it in terms of the phone/cable TV/internet service to residential dwellings. The sheer number of connections of "the last mile/kilometer" slows upgrading communications bandwidth.

The whitepaper ties this concept to process manufacturing plants:

I/O represents the "last mile" from the automation system to the field device, and users look for any opportunity to reduce the cost of this last mile and provide better diagnostics to avoid failure.

Electronic Marshalling takes the practice of marshalling and its connections with multi-channel I/O to a single channel:

...users add I/O as they need it, one point at a time. This is done with CHARacterization Modules, or CHARMs. CHARMs turn the idea of conventional I/O on its head.

Instead of conventional wiring landing at a terminal block, wired to I/O modules, which are then wired to controllers - the wiring is connected directly to a DeltaV electronic marshaling rack. CHARM modules are attached onto this continuous rail. CHARMs can then be characterized however you want them to be and plugged into the rack. CHARMs also have self-diagnostic capabilities.

This approach eliminates the need for separate marshalling cabinets, which can reduce the number of control room cabinets by 50% and reduce intra-cabinet wiring by 90%. Most project engineers know the pain associated with late project changes, which often leads to rewiring, re-terminations, control strategy I/O binding changes, etc. These thoughts are summarized:

In ARC's view, the significant cost associated with traditional marshalling methods can limit the changes possible in the engineering and design of the system. The new I/O on Demand capability of Emerson's DeltaV S-series allows users to add or change I/O types whenever they make project design changes, no matter where the I/O is located. This reduces project costs and, even more importantly, reduces time to startup.

The whitepaper highlights the integrated power supply in the DeltaV Foundation fieldbus card, which eliminates bulk power supplies and fieldbus power conditioning modules. This again, eliminates cabinets and it also adds diagnostic coverage of these power elements from the DeltaV system.

With wireless control applications emerging, redundancy options have been added:

Redundant items include DeltaV network communication, 24VDC power, I/O cards, remote links, and the multiple communication paths of the adaptive mesh network itself. The redundant architecture eliminates any single point of failure and provides immediate switchover in case of a fault.

From a safety instrumented system I/O perspective, the DeltaV SIS has:

...a modular logic solver that has integrated I/O processing, memory and logic solver processing... added every time I/O is added to the system.

This 7-page whitepaper provides a great overview of the elements of I/O on Demand and how it can change the economics of a project. As mentioned in an earlier post, additional whitepapers delve into Electronic Marshalling and an economic cost analysis in more detail.

MP3 | iTunes

Update: I've updated the link to the whitepaper which is now additionally hosted on the EmersonProcess.com web site.

The DeltaV team has been hard at work creating two new whitepapers detailing an I/O on Demand cost analysis and Electronic Marshalling. These technologies are available in the latest DeltaV release.

Emerson's Oil and Gas sales and marketing director, David Newman developed the I/O on Demand Cost Study whitepaper. He presents a study:

...from an existing offshore manned platform was analyzed to compare the different combinations of capital cost of the as built wired / Foundation fieldbus versus Electronic Marshalling technology. The results show cost savings of between 7% and 26% which equates to $0.3M to $1.25M, depending on the options chosen, with additional value of saving of up to 30 tonnes in weight and up to 43 m2 of deck space in cabling, cable tray, junction boxes and cabinets.

The scope of the study includes materials and labor for a manned, offshore platform and its process automation system and associated cabling, cable tray, marshalling cabinets, system cabinets, controller I/O cards, and control room space requirements. David describes the layout:

The Control Room is situated at one end of the Platform, such that the average cable length on the cable tray is about 90 metres. In that room are System Cabinets containing controllers and I/O cards. From there, the cabling continues to Marshalling Cabinets, then onto cable tray which runs out onto the platform. At various positions on the platform, cabling exits the cable tray to local Junction Boxes. From the Junction Boxes, there is an average of 10 metres of cable to each field device, and in the case of a Fieldbus loop an average of 5 metres between the junction box and megablock and the megablock and the field device.

The cost analysis first considers the number of I/O that could be wireless I/O, based on the speed of the control loop or monitoring application. Based on the platform topology 30 wireless I/O can be connected per wireless network.

The whitepaper compares these scenarios:

• Conventional wired with Fieldbus (separate power) - as built
• Conventional wired, Control Room Electronic Marshalling with Fieldbus (separate power)
• Conventional wired, Field Electronic Marshalling with Fieldbus (separate power)
• Conventional wired, Field Electronic Marshalling with Fieldbus (integrated power)
• Conventional wired, Field Electronic Marshalling, Fieldbus (integrated power) and wireless devices

Pages 8-10 of the whitepaper show the I/O mixes used in the calculations. The savings, presented on page 12, range from 6.8% to 25.6% for the 1874 total number of points considered.

David has developed a calculator that an Emerson local business partner or sales office can apply to your application to how these I/O on Demand technologies can impact the financial costs of your project.

MP3 | iTunes

John Rezabek closes his ControlGlobal.com Surprise! Field-Based Control Beats DCS article with the thought:

The SP50 committee set out years ago to define and specify a robust, vendor-independent controls suite exploiting the intelligence of microprocessor-based field devices that would equal or exceed the "bulletproof" DCSs of the 90s. They succeeded.

The source of this conclusion is two recent studies, one conducted by Emerson fieldbus consultants Dan Daugherty, Mark Coughran, and Ferrill Ford. The other is by Kenexis Consulting's Ed Marszal, who applied a similar reliability model used with safety instrumented functions to Foundation fieldbus (FF) control loops running PID in the FF device. The common vernacular for this type of control is control-in-the-field (CIF). I described and embedded Dan, Mark, and Ferrill's Emerson Exchange presentation in a post, Dispelling a Rules of Thumb in Foundation Fieldbus Segment Sampling Rate. In John's article, he summarizes this study:

One of the things revealed was that control in DCS did not benefit substantially from over-sampling, which involves running the macrocycle two or more times faster than the DCS PID block. The other notable result was that control-in-DCS could not approach CIF in performance, especially when macrocycles (the deterministic cycle time of all the function blocks on a fieldbus segment) were cranked down to as little as 150 milliseconds. CIF was distinctly better and had no problem matching the performance of fast, pure analog (4-20 mA) control.

Control in the field has the advantage of single loop integrity, diagnostics, and signal status across the fieldbus segment. For the reliability study comparing control in a DCS controller versus CIF for a simple PID loop, John quotes Ed's findings:

Fieldbus is significantly better--mean time to fail (MTTF) of 48.2 [years] versus MTTF of 15.9 [years].

The numbers were rerun using field devices with the same reliability numbers and the CIF case again had greater MTTF. I sent Dan a link to the article and asked what thoughts he might have to share. He wrote:

It is good to see confirmation of our conclusions from independent researchers using different methods of analysis. In the tests ran in the Marshalltown flow lab, Mark Coughran, Ferrill Ford and I not only demonstrated the superior performance of FOUNDATION fieldbus deployed as Control-in-Field (CIF), but were able to show the relative contributions of the control algorithm update rate and the I/O sampling rate of the macrocycle. This is useful information for economical control system design to the necessary performance requirements. We were able to dispel the myths that inhibited the choice of FOUNDATION fieldbus due to unnecessary overdesign, which in turn leads to low density and higher cost segment design.

I fully concur with the conclusions that use of FOUNDATION fieldbus can lead to higher availability than one can get with point-to-point I/O. Without going into all the complicated algebra, the common sense view is that one H1 card for 16 loops (8 loops per segment x 2 segments per card) will have a lower failure rate than 4 I/O cards for the same number of loops. Then once one chooses to use redundant H1 cards and fieldbus power supplies, the availability is much, much higher. Clearly, FOUNDATION fieldbus is by far the most reliable way to deploy control. (I assume that by now, everyone understands individual devices and short circuits are isolated from the segment through the field connection hardware.)

Given these performance and reliability results, the case favoring this highly distributed control-in-the-field approach continues to build.

MP3 | iTunes

On the Fieldbus Foundation Forums is a recent post, Macrocycle for control in the controller. The post begins:

I have seen many posts about scheduling and macrocycle calculation for control-in-the-field (CIF). I have some doubts about control-in-the-controller (CIC) application. Unfortunately, there is no other option in the project I am working for.

The question asks about acyclic vs. cyclic communications, macrocycle communications, and loop response time.

ISP Lima Process Control Specialist and Control magazine contributing editor, John Rezabek, contributed to the conversation. He referenced a post I had done previewing one of the Emerson Exchange presentations, Control Response Period for Foundation Fieldbus Control-in-the-Field Loops. This presentation was given by Emerson fieldbus consultants Dan Daugherty, Ferrill Ford, and control performance consultant, Mark Coughran.

Here's their presentation, which tested and compared control performance for CIC and CIF:

Dan shared a few thoughts with me that I wanted to pass along specific to control in the controller and control in the field considerations. He said most process control engineers don't know how slow the modes they need to control are. The performance for control loops where control is performed within a Foundation fieldbus (FF) device will always be better, but if the engineer imposes reasonable rules on the use of CIC, it will work well.

Some want to do CIC to avoid the fieldbus segment design calculations and others encounter problems once they do the calculations and commission the segment. In some automation systems like the DeltaV system, the Foundation fieldbus H1 card can run the control loop. Since it's directly connected to the fieldbus segment, the latency of passing information up to the controller is avoided. This significantly reduces the number of applications requiring CIC.

Dan takes issue with rule of thumb developed over the years where the segment-sampling rate is 2X the controller update rate. He believes this is a misapplication of Shannon's sampling theorem. The problem is not that it doesn't work; it's that it increases the cost of project due to fewer devices per fieldbus segment.

Deciding that none of their theoretical arguments, diagrams, and Laplace transforms was having an impact with the 2X sampling belief, Dan, Mark, and Ferrill performed tests in the Fisher Marshalltown flow lab. Dan summarized the most important thing he learned from the test:

Once the loop control mode frequencies are identified, then you choose your control settings so the closed loop transfer function attenuates that frequency. And you need your control update rate to be somewhat faster than that. When we were looking at update rates in the ¼ and ½-second range, we essentially had an update rate that was 25 to 50 times the frequency of the mode we wanted to control, and 2.5 to 5 times 10x the frequency we were trying to control.

He concluded:

It's true that CIF, with super precise determinism, gave the very best control. But CIC gave pretty good control. So, it wasn't really a question of whether or not to use CIC or CIF (because CIF is clearly better), but if circumstances made it necessary to use CIC whether or not it was better to oversample at a slow update rate or to get one-to-one sampling at a faster control update rate. It turns out the faster control update rate gives you more for the money than oversampling at a slower control update rate does. However, note that this line of reasoning applies mainly to continuously changing disturbances.

So, first you need to understand what you are really trying to control, and how good is good enough. That determines your control update rate. Second, once you have a control update rate, then see how much you are willing to load the segment (devices per segment, for economic reasons). If you are forced to use CIC, and if that maximum loading doesn't allow oversampling, then don't oversample. If you are forced to use CIC, and if that if the maximum loading allows oversampling, then by all means oversample.

If you are using CIC, then what you gain by oversampling is a slightly better attenuation of the disturbance frequency, AND a significant improvement in end-to-end response time. So, if you have a process that is mostly flat lined, but every once in a while some rather sudden change occurs, an oversampled segment will have an initial response that is a little quicker than one that isn't oversampled, and if you are using any discrete logic, then you will have a little quicker end-to-end response to the field input.

As for estimating "required" macrocycle times, that varies by method used (number of compel data communications required), speed of devices, and number of devices. CIC requires more compel data per macrocycle, so it will tend to make the macrocycle about 2x longer than if CIF were used.

Our interest in the experiment wasn't to see if CIF or CIC was better, but to determine if oversampling was worth it. Given the already longer macrocycle with CIC, in my opinion, it is a needless self-imposed penalty to oversample, which (for same number of devices) now takes your control update rate out to 4x what you could get with CIF. So, you get worse control because it is CIC, and worse again on top of that because you slowed down even more to oversample.

MP3 | iTunes

A great question came in the Process Automation Usability Project forum asking why there is not more control in the field being done. If you're unfamiliar with the term, it's where a Foundation fieldbus (FF) transmitter, digital valve controller, or other instrument runs the control logic for the loop, instead of this being done in the automation system controller.

When I saw the question, I bounced it over to Emerson fieldbus consultant Dan Daugherty, whom you may recall from earlier fieldbus-related posts. Dan made a couple of great points, the first on segment design:

If you do control-in-controller, and you don't care a whole lot about process segregation (only do it on a coarse, controller level), then you can skip all the concerns regarding segment design except for voltage drop and number of devices. Many engineering companies didn't want to learn segment design, so they stuck with control-in-controller.

His second point dealt with the complexity of the control strategy used:

...some control strategies are complex enough they can't be done on a single segment (prior to 2007) because not all the control functions they wanted to use were available in devices. That is no longer true with Emerson because we have ability to pick up functions in the H1 card, effectively filling out any gaps that used to exist in the control-in-field palette of functions.

His third point is that there are economic and performance advantages to using control in the field. In his response, he references a presentation that he and some colleagues are giving at the upcoming Sep 28-Oct 2 Emerson Exchange conference, Effects of Macrocycle Time and Sampling Rates on Control Loop Performance.

The team set up controlled tests in Emerson's Marshalltown Flow Lab to compare performance between Foundation fieldbus and conventional 4-20mA analog loops for control response period, load frequency response, and setpoint step response.

Their tests showed that with FF control in the field, the control response period equaled the macrocycle and they could get 0.18 seconds, which is adequate for almost all loops. The exceptional loops that require faster response times, such as surge control and compressor lube oil, typically have dedicated controllers. Dan does however reference a 2008 Emerson Exchange presentation where field-based control was successfully performed in a compressor anti-surge application.

Another important finding is that there is even more reason to use control in the field as the number of loops on a fieldbus segment increases. The control response period is much greater when control is performed in the automation system controller than when control is executing in an FF device when they looked at 8 loops on a fieldbus segment.

If you'll be joining us in Orlando at the Emerson Exchange, you may want to check out Dan and team's presentation. One session will be Sep 29 at 11am and the second on Oct 1 at 10am. Visit the Personal Scheduler to plan the all sessions you want to see.

MP3 | iTunes

Three automation suppliers' host systems have just passed the Fieldbus Foundation's Host Profile Registration Process, including Emerson's DeltaV system and AMS Device Manager software. The DeltaV and AMS Device Manager software achieved Class 61 - Integrated Host registration by successfully completing the test procedures outlined in the FF-525 Host Profile Registration Process checklist.

The Fieldbus Foundation describes the benefit of this host testing process:

Both automation suppliers and end users will benefit from host registration. Like the current device registration process, host registration will strengthen fieldbus interoperability and system integration. The updated host profile specification is easier to understand than current specifications, and eliminates inconsistent features in favor of defined host profiles.

I caught up with DeltaV product manager, Randy Balentine on what this means for process manufacturers. His first point is that this host interoperability testing enforces a new level of consistency, interoperability, and integration between Foundation fieldbus (FF) host systems and FF field devices. It also highlights the significance of the Electronic Device Description Language (EDDL), because two pieces, DD v5 Visualizations, Methods and DD v5 Persistent Data, are mandatory in this testing. I've discussed in numerous posts, the importance of EDDL in providing a consistent view of information from intelligent field devices.

This host profile registration testing was performed this month in the DeltaV Interoperability test labs in Austin, Texas. Two representatives from the Fieldbus Foundation administered and witnessed the testing process. The tests confirm support for the features contained in the FF-569 (Host Interoperability Support Test Procedures Revision 2.1).

Randy highlights two important tests that only the DeltaV and AMS Device Manager software have passed so far. The first is DD v5.1 Device-Level Access, which provides the ability for the software to present the user with information from FF function, resource, and transducer blocks in a single view rather than multiple views--one for each block. This common view makes operations and troubleshooting easier since tasks can be organized into logical groupings of related information. The artificial barriers based on where the data resides in FF devices are removed.

A second unique test passed is support for Enhanced Parameter Download Support Services, which means that the DeltaV and AMS Device Manager host is able to read a list of parameters in an FF device and prevent a host download from overwriting the values in the device that the suppliers never want to be overwritten. This allows the DeltaV and AMS Device Manager software to perform automatic FF device commissioning and replacement operations without the need for personnel interaction with a software screen.

Randy noted that the following versions of software were part of the successful test:

• DeltaV software, v10.3
• DeltaV v10.3 ProfessionalPLUS Workstation
• DeltaV MD Controller, software revision 10.3.0
• DeltaV Fieldbus H1 Interface Card, Series 2, software revision 4.86
• AMS Suite: Intelligent Device Manager version 10.5

Congratulations to the whole Emerson team who developed the test plans and worked with the Fieldbus Foundation to successfully pass this host registration profile process. Tests like these help improve interoperability amongst products from many automation suppliers.

MP3 | iTunes

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

I'm lucky enough to receive a copy of Andrew Bond's Industrial Automation Insider newsletter each month through an Emerson subscription agreement. Andrew covers the happenings among the automation suppliers and standards bodies. You can also find some of Andrew's writings on the ControlGlobal.com site.

In the November 2008 newsletter, one item that caught some attention around here was this nugget:

...first TÜV-approved SIL3 Foundation fieldbus safety valve controller to appear on the market. The device delivers status changes automatically via Foundation fieldbus and incorporates real time alarm management eliminating the need for external wiring or I/O cards.

I have the privilege of working in the vicinity of two very knowledgeable people with respect to process safety, Riyaz Ali and Mike Boudreaux.

Riyaz notes that the Foundation SIF specifications are still under development. In a recent Fieldbus Foundation release, it quotes ARC's Larry O'Brien:

It is very clear that end users want this technology and are striving to include FF-SIF systems in their project specifications. Many major end users will probably be specifying FF-SIF systems for their new projects starting in 2011.

A September 2008 ARC whitepaper, Foundation Fieldbus Safety Instrumented Functions Forge the Future of Process Safety, provides background on the Foundation SIF standard advancement and its current draft status. Mike and Riyaz were present at the successful May 2008 Foundation SIF end user demonstration project in Amsterdam, and Mike shared his experiences with me. Riyaz also shared that one of the function blocks, the SIF_DO block, will not be available from the Fieldbus Foundation until the first half of 2009.

Many automation suppliers are developing products based on the current Foundation SIF draft, including Emerson. I asked Riyaz about the current solution Emerson provides until the standard is ratified. Riyaz responded:

The current solution for use in a Foundation fieldbus SIS application is to use the DVC6000f PD instrument. Several hundred units have been supplied worldwide to process manufacturers where partial stroke test scripts are run from host systems, such as the DeltaV system and AMS Device Manager.

In this application, process manufacturers use a solenoid valve operated by a hardwired digital output from the SIS logic solver.

Riyaz expects that until process manufacturers have sufficient experience, they will continue to use an independent solenoid valve to take the SIS valve to the fail state, while at the same time using a DVC6000f PD for partial stroke diagnostics using Foundation fieldbus through the basic process control system (BPCS).

Mike notes that both the DeltaV and DeltaV SIS systems are capable of performing these safety instrumented function predictive diagnostics. The DeltaV system is being used to perform partial stroke testing with the DVC6000f PD using Foundation fieldbus communications. The DeltaV SIS system is being used to automate partial stroke testing with the DVC6000 SIS safety valve controller using HART communications. This additional diagnostic coverage assists process manufacturers with their IEC 61511 safety lifecycle efforts.

Using diagnostics enabled by Foundation fieldbus and HART communications, the DeltaV and DeltaV SIS systems with DVC6000 digital valve controllers can provide many of the benefits today that are promised by Foundation SIF in the future.

MP3 | iTunes

Update: Next week is the Thanksgiving holidays in the U.S. and I'll not be posting. We'll be upgrading our version of Movable Type software. Wish us luck!

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.

You may have seen some of the coverage of last week's Foundation for Safety Instrumented Functions (SIF) End User Demonstration (DeltaV News, Sound OFF! blog, and ARC's Larry O'Brien's blog to name a few.) This event highlighted demonstrations of Foundation Fieldbus Safety Instrumented Systems (FF-SIS) which were held at Shell Global Solutions in Amsterdam, Saudi Aramco in Dhahran, BP in Gelsenkirchen, Germany and Chevron in Houston.

A demonstration version of the Fisher DVC6000f SIS was included at each of the demonstration sites. Also, Emerson participated in the demonstrations of Foundation SIF technology by providing special demo versions of Rosemount, DeltaV, Fisher, and AMS Suite products.

Emerson's Mike Boudreaux was at this event held in Amsterdam. Mike presented the results of Emerson's participation the Chevron demonstration held earlier this month. For this demonstration, Emerson provided a logic solver that communicated with field devices using the FF-SIS protocol. Demo versions of devices from various suppliers were specially developed to demonstrate the capabilities of the FF-SIS protocol. The demonstration tested the capabilities of the FF-SIS protocol and interoperability of devices.

These components were included in the demonstration project:

• Rosemount pressure transmitter
• ABB pressure transmitter
• Magnetrol level transmitter
• Siemens level transmitter
• Emerson logic solver
• Fisher DVC6000f SIS control valve
• Westlock positioner
• Pepperl+Fuchs power conditioners with diagnostics
• Fieldbus Diagnostics FF-SIS packet analyzer
• DeltaV HMI and engineering tools
• AMS Suite: Intelligent Device Manager
• Fisher ValveLink SNAP-ON

I hope Mike doesn't mind, but I've lifted the account of the demonstration from his Emerson-internal blog:

The demo system was originally assembled at Emerson in Austin, TX where we did some preliminary testing to make sure that everything worked. When the demo unit was delivered to Chevron, it was set up and running in less than an hour. It was simply a matter of plugging in cables and powering the system up. There were a couple of devices that required software resets, but for the most part the system started up with ease. We used AMS Suite: Intelligent Device Manager for configuring devices and clearing fault states. The functionality of AMS Suite easily transferred to FF-SIS.

We implemented two SIF's with 1oo2 voting. The first was a high pressure shutdown, acting on the DVC6000f SIS. The second SIF is for a high level shutdown, acting on the Westlock positioner. We tested various trip scenarios. In one case, we demonstrated degraded mode operation, where the voter block was configured to ignore a value if the PV status was bad based on device diagnostics. The function blocks operated as expected, with the same functionality that is available in the DeltaV SIS system today using HART I/O.

In addition to using AMS Suite for configuring devices, we also demonstrated the partial stroke test using ValveLink SNAP-ON. The partial stroke test was executed flawlessly with all of the features of ValveLink available for the FF-SIS device as is already available today through HART or FF. In addition to a standard partial stroke test, we also demonstrated a scenario where a trip occurs during the PST cycle. The valve behaved as it should, aborting the PST and closing the valve.

In his presentation, Mike described how the use of Foundation SIF technology could help process manufacturers to run safer and more reliable processes. His first point was that more advanced diagnostics are available to detect random and systemic failures while reducing spurious trips. Another was that test intervals for final control elements could be increased through the initiation of partial stroke testing from the operator stations. Also, the maintenance of devices involved in the SIFs is simplified with the integration of their diagnostics with the operator stations. This integration also facilitates easier commissioning and testing of these devices.

This end user FF-SIS demonstration testing is another milestone in the path of this technology becoming available for your future process safety applications. End users who participated at the event in Amsterdam indicated that they will continue to internally test the Foundation SIF technology. Most people expect that it will be 2-3 years before an actual implementation will occur in a process manufacturing facility. Key milestones for the future will be the finalization of the FF-SIS specifications, development and testing of commercial devices, and device certification for IEC 61508 compliance.

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.

My spy utility, WatchThatPage, alerted me to another good article, this time on the Fisher control valves and regulators area of the Emerson website. The article, Getting ready for the nuclear renaissance, from the April issue of Valve World magazine, features Bill Fitzgerald, director of the Fisher Valves nuclear business unit.

As more and more people around the world climb the economic ladder, the global demand for energy continues to grow. A nuclear power renaissance is underway, according to Bill driven by:

...issues like global warming and a desire for energy independence... It can never be the only solution, but it is a logical part of the solution.

Bill describes his team tracking forty U.S. projects. He estimates two-thirds of these will actually be built. The first ones may come on-line as soon as 2015. Bill describes the large engineering firms as well as the U.S. Nuclear Regulatory Commission (NRC) staffing up anticipating the work required to completely design, build and commission the first wave of these plants over the next seven years. This expected growth is by no means limited to the U.S.

As part of this process, the engineering firms' procurement people need to identify and begin to purchase the long-lead items like reactor vessels, which may take three years from order to delivery. Control valves also fall into this long-lead item category. As Bill explains:

...control valves have long lead times because the ASME has just issued new qualification requirements. So to use a valve in a given safety related application will probably require 18 months of qualification testing. We also have to factor in ever-tighter seismic requirements. Then materials procurement, machining, assembly and testing will probably take an additional 9-18 months, depending on valve type. So, we believe that if we get an order today for a nuclear grade valve it could take as long as three years to actually deliver it to the end user.

And Bill notes that these valves are used in safety critical areas. Not having them will delay the startup of the plant. Based upon this expected global increase in nuclear power plants, Emerson and other automation suppliers are increasing their capabilities to meet this demand.

Technology has changed greatly since these types of plants were built in the U.S. a generation ago. Bill describes digital technologies like Foundation fieldbus, which can be used in the balance of plant applications to provide better control and diagnostic information. Devices like digital valve controllers have completed Electric Power Research Institute (EPRI)-certification for use in this demanding application.

As energy producers seek ways to meet the increasing global energy demand, these preparatory activities are critical to meet challenging project schedules.

Update: I was just pointed to a great Béla Lipták article, The Third Industrial Revolution by a member of our DeltaV Twitter community. Béla describes the post fossil fuel world based on solar power and the role of process automation. It's well worth your read and I look forward to his book due out in August.

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.

I received an email from Anand Iyer. He's a certified project management professional (PMP) and a project manager in Emerson's engineering center in Pune, India. His project experience covers the gamut from pharmaceuticals, bulk drugs and intermediates to oil, gas and petrochemicals.

He's sent me a paper he's written entitled, Collaborative Measurement Control System Engineering. It describes how measurements close to one another in the process can collaborate with one another to verify their operation. He describes an example around a distillation column:

Now let us take two temperatures (bottom temperatures) in a distillation column and a level measurement. When the level is normal, the two temperatures are same or have a fixed relationship between them. TI1 is placed at a lower level in the column (near bottom) and TC2 is at a higher level (and used for Temp. control). Now TC2 is generally used for control. We can safely say that if Level is normal, and TC2 is under maintenance, TI1 can be used for control (with a minor adjustment to Setpoint if required). Thus Level and Thermocouple TI1 put together can "collaborate" the measurement of Temperature-measurement TC2.

Anand contrasts the traditional approach to a failure with how collaborative measurement strategies can be used in control strategies to avoid outages or process disturbances. In the traditional approach:

...the first thing done if an element were to fail was to swap the elements (either during the shutdown caused by the failure) or by a planned outage or having the loop in manual and doing the swap. At times, we have also used our ingenuity and just swapped the wires at the analog inputs and tuned control setpoints to have the plant up and running in a very short time. And hopefully, in all that chaos, someone had the presence of mind to record the swap on the wiring diagrams.

Using a collaborative measurement strategy:

...says that if level is not low and TC2 is not available then TI1 can be a valid measurement. We alarm the operator that TC2 is not available, fine tune the setpoint if required... All this occurs automatically and there is no outage or disturbance that could result in quality issues.

He extends the thought to Foundation fieldbus devices where the final control elements themselves can perform the logical evaluations and select the available primary or collaborated measurement, increasing the overall robustness of the control strategy. Anand also extends his thinking to wireless devices and how they could be used in a collaborative measurement environment--not as a primary measurement, but as a collaborative measurement to check on other devices nearby.

I hope you'll give Anand's paper a read and add your thoughts.

A question came into Control.com's Automation List the other day, about strategies to convince management of the benefits of going with Foundation fieldbus (FF) or a DCS. The question:

We have two options at our hands, either to go for in vogue DCS, an easier option to adopt, or implement the Fieldbus, a novel concept. The problem lies in convincing the management which is more inclined to DCS because it is in use in contemporary industries.

Responses came back, which correctly pointed out that most current DCSs offer Foundation fieldbus digital communications as one of the ways to connect digital field devices into the system.

Emerson's Jonas Berge had a great response, first noting that Foundation fieldbus is not novel, with the process manufacturing installations starting in 1997. In his posted response, Jonas writes:

FF has come along way over the past ten years. The specifications have been clarified, corrected, and complemented. Product implementations of the technology have been corrected and completed. Better tools have come to market. Procedures for project execution and practices for operations and maintenance have been established. It is far easier to be successful now than only a few years ago. Most major EPCs now have FF experience. Your management should not worry about "immaturity".

You may wish to justify to your management on the following basis:

• Project savings
• Operations improvement

Here is a summary of why FF works so well for plants:

Project Savings

• Less wires, conduits, trays, terminations
  • Multiple devices per bus
  • Multiple signals per device
• MOV, MV, feedback etc.
• Reduced control room footprint
  • Fewer I/O cards and barriers
• Fewer engineering drawings
  • Multiple loops per drawing
• Faster loop check and commissioning
  • Automatic 'ring-out'
• Enables innovation...
  • New classes of digital devices

Operation & Maintenance Improvement

• Better accuracy
  • No precision lost in D/A & A/D
• High signal integrity
  • Distortions can be detected
• More powerful diagnostics
  • More current for devices
• Engineering unit
  • Measure to sensor limits
  • No range mismatch
• Stave off obsolescence
  • Firmware download
• Easier device troubleshooting
  • Remote Diagnostics
• Validity display and loop shut-down
  • Signal status
• Predictive maintenance
  • Diagnostics Alerts
• Easier replacement and servicing
  • Fewer Connections

Contact me directly at jonas.berge (at) emerson.com

For an FF project to be a success it has to be planned, engineered, and designed correctly. If you follow old DCS practices for design, loop check, commissioning etc. all you will get is a more expensive DCS without new fieldbus benefits. However, if done correctly FF will deliver on the great promise of digital control and architecture. These practices have been worked out and fine tuned by leading automation vendors over thousands of projects the past ten years.

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.

When engineering a project with Foundation fieldbus, one element to consider is the electrical loading on each segment. I received an email the other day asking:

...to find required formulas to calculate FOUNDATION FIELD BUS loading... I am using [brand X] product and I have come across a web site that you can provide information. If you have those formulas... it would be nice if you could share them.

I also did some Googling around, and saw a few things, but did not see our Emerson Segment Design Tool listed in the search results, at least not in the first few pages. The segment design tool development team released version 5 of this tool in September, just before the Emerson Exchange meeting.

Here's a bit about what this calculator tool does:
The Segment Design Tool is a Windows 98/NT/W2K/XP compatible program designed to provide a general guide for reducing the time required to engineer a Foundation fieldbus H1 segment for the DeltaV system, Ovation system and the Rosemount 3420 Fieldbus Interface. The Segment Design Tool checks the segment layout utilizing the Fieldbus Foundation's guidelines governing cable lengths, power consumption and proper segment termination. This tool now supports a variety of hazardous area protection techniques, including FISCO, FNICO and Entity Concept for Intrinsic Safety.

One of Emerson's Fieldbus consultants, Dan Daugherty, whom you may recall from earlier posts, helped me find the URL for this tool. He also added this bit of wisdom that I passed back to the person who originally emailed me:

My advice for people who can't find an exact match in the Segment Design Tool's component library for their cable or other components is to find something close and then use enough design margin that it won't matter if it isn't exact.

I'll also pass along that the segment design tool team invites comments and questions. Feel free to take them up on their offer, or leave a comment on this post, and I'll pass it along to the team.

Emerson's Marshall Meier was a very busy person at this year's Emerson Exchange. In addition to his Web 2.0 in the Plant presentation that I wrote about in an earlier post, he presented on the subject of Foundation fieldbus (FF) technologies emerging in safety instrumented systems (SIS). Key points made in the presentation were that the Foundation fieldbus specification has been enhanced to support SIS, that the Fieldbus Foundation is currently running a demonstration project to validate the FF-SIS specification, and that this specification will begin to emerge in future SIS sensors, final control elements and logic solvers.

The purpose of Marshall's presentation was to give a look into the technology and process for how this standards effort is unfolding. It was not to say that this technology is ready to apply in your operations.

He first posed the question, "Why use Foundation fieldbus in SIS?" The answer is that Foundation fieldbus provides more computational horsepower and each value has a status associated with it. Conventional 4-20mA analog signals do not provide this goodness indication of data. More advanced diagnostics are also available to be used as part of the safety instrumented function. An example is Rosemount sensors that detect plugged impulse line conditions. Another benefit is with FF-SIS devices, users wouldn't need to have 4-20mA SIS devices in an otherwise FF installation.

The additional safety-related function blocks specified in phase one of the preliminary specification include analog input and discrete output. Discrete input and analog output blocks are not yet defined in this early specification. Function blocks that can only run in a logic solver include analog comparators and logic blocks. Note that the same device description standard as the process-level FF function blocks will be applicable to FF-SIS blocks.

The Fieldbus Foundation last year announced a demonstration project working with process manufacturers and identified four sites with various suppliers' safety logic solvers, sensors, and final control elements. These tests are meant to validate the specifications for FF-SIS. These participating companies include Chevron, Shell, BP, and Saudi Aramco.

The FF-SIS specifications will advance in phases. Beyond the function blocks mentioned earlier, phase two will include additional blocks and the potential to have SIS and non-SIS devices on the same segment.

I'm catching the session, Realized Benefits from Foundation Fieldbus at the ISA Expo 2007. ARC Advisory Group's Larry O'Brien moderated the session.

The first part of the session looked at BP's use of Foundation Fieldbus (FF) in an onshore oil & gas production SCADA application in the U.S. state of Wyoming. They tested various suppliers systems and field devices in the harsh Canadian winter environment to compare the robustness of the various FF offerings. At each well site of eight wells, control was run in the FF devices, which in turn were connected, into their remote terminal units (RTUs). They saw immediate project savings in the wiring/installation labor/physical footprint savings. A key benefit they saw was remote diagnostics into these devices from a central location.

Next Suncor Firebag shared their Foundation fieldbus experiences. Suncor has standardized on Foundation fieldbus for all capital projects. Firebag has 9-10 billion barrels of reserves using today's extraction technologies. The extraction efficiency is expected to increase over time and these known reserves will increase. Suncor documented commissioning savings of Foundation fieldbus versus conventional devices of one sixth of the time. The benefits cited included faster time to first oil, and instrumentation maintenance practices moved from preventive to predictive. This helps eliminate unnecessary maintenance and avoid unplanned shutdowns.

They are currently looking at applying the statistical processing from the high-speed history in the FF devices to detect flame flutter on furnace and boiler flames. Another application they are investigating again with this high-speed sampled data is early detection of water hammer conditions in piping. This condition can cause millions of dollars in damage to the pipes if it is unchecked.

Emerson's Marcos Peluso gave a quick overview of the case for control in the field and robustness as measured by mean-time-between-failure. The key is the communications path is shorter when the control loop executes between a sensor and final control element than when it is between a sensor, automation system controller, and final control element. The loop can also execute with more certainty with the execution times of the fieldbus segment. Marcos indicated that the application should determine whether control is run in the automation system controller or in the FF device. There are strengths to each approach.

EnCana next presented how they could get gas compressor stations up and running more quickly with Foundation fieldbus devices than with conventional field devices. For their installations, all control was run in the field devices. This designed proved helpful in avoiding lost production when batteries did not hold their charge from solar panels. The remote terminal units and wireless network transmitters dropped out when the battery voltage dropped, but the FF devices kept running. Operators drove to site after they lost communications but found the compressors continuing to run with the loops fully in control. Overall, they we able to reduce operating expenses by linking together their remote compressor stations by centralizing the operators window into their decentralized control. Troubleshooting could be done remotely which reduced downtime.

Finally, Shell briefly shared their Foundation fieldbus experiences. While they agreed with the project savings others had experienced, they saw the biggest value in moving from preventive to proactive maintenance. They recommended this is where process manufacturers should spend the bulk of their planning efforts. This process often involves a cultural change so it takes time and quite a bit of planning and execution. Their approach is to have focused resources continually reviewing the diagnostics from intelligent field devices and performing maintenance based on this information. They cited savings in the millions of dollars from shifting to this approach.

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.

I caught up with Emerson's Terry Blevins who has been leading the standards efforts around Electronic Device Description Language (EDDL) with his work as chair of the ISA SP104 committee. From the EDDL.ORG website:

The Electronic Device Description Language (EDDL) standard advances interoperability of devices in control systems. Integration of simple sensors through complex drives is facilitated. Device diagnostics, asset management, and user interface displays enhance reliability and performance.

Terry will be presenting a paper at this year's ISA Expo (Oct 2-4 in Houston, Texas USA) along with Emerson's Jonas Berge and other committee members from Siemens and the Institut für Automation und Kommunikation Magdeburg (ifak). This two-hour tutorial is scheduled for Tuesday afternoon.

In the exhibition area of the ISA Expo, they will be demonstrating the benefits process manufacturers derive from sensors, actuators, control systems, and handheld communicators that support the EDDL standard. These benefits come from the ability to configure, calibrate, diagnose, and provide data and alarms back to operators. Terry extends an invitation to those of you going to the Expo to stop by the ISA Booth to visit with him and some of the SP104 members. Terry also mentioned that he'd be doing a talk on EDDL at the ISA booth on Thursday afternoon.

As the paper notes, EDDL is required for Foundation fieldbus, HART, and some Profibus devices, which means that virtually every automation system supplier supports it. Some of the key advantages cited by this paper include:

• A well-defined structure for supporting simple to very complex field devices
• EDD files are text-based (not code-based) and thus independent of operating systems and control platforms
• EDD files being text based also makes switching versions, revisions, and supplier brands simpler

If you want to follow the progress of this standards effort, you can visit the EDDL.ORG website, or subscribe to their mailing list.

I also encourage you to take Terry up on his offer to visit with him and see the presentation of this paper.

An RSS search feed pointed to a Process and Control Today news item about the opening on a new Emerson European flow center. This center provides comparison, selection, final assembly, configuration, calibration, testing, support and training for quite a range of Emerson Process management flow brands including Micro Motion, Rosemount, and Brooks Instrument. The flow technologies include Coriolis, magnetic flow, vortex, thermal mass flow, and variable area meters.

The center was built to help process manufacturers primarily in Europe, the Middle East and Africa. With so many technologies, each have their advantages in different applications, it was important to have a common area where manufacturers could work with product and application experts to properly select and configure the best solution for the application.

I caught up with Emerson's Henk Verweerd who shared some highlights with me. The center, located between Arnhem and Utrecht in the Netherlands, supports seven languages, employs 275 people, and covers over 9000 square meters of floor space. In addition to the technical and application support, the team performs project and order management, repair management, and creation of documentation for projects and required regulatory agencies.

With the trend toward project modularization to decrease project schedules, the team helps instrument integrated systems for railcar, ship and truck loading/unloading, pipeline/LPG/LNG/gas metering, and proving Coriolis meters. The flow center includes four mini-plants fully instrumented with Foundation fieldbus devices to provide hand-on training for flow meters and applications, including the diagnostics these devices can provide to the automation systems.

Henk mentioned that the whole reason for the facility was to bring together experts from the various product lines to be able to work with manufacturers and quickly arrive at the best solution. It also helps provide better service, support, and input for future product improvements.

A colleague pointed me to an article, Timeline of a refinery pump failure and how it could have been prevented, on the Belgium-based EngineeringNet.be website. The story was about a South American refinery that had a high-speed centrifugal pump fail catastrophically resulting in production losses and large repair costs. Todd Reeves is in Emerson's Machinery Health Management team, part of the Asset Optimization organization.

What happened was an inboard bearing lost lubrication, overheated and finally seized up. The unfortunate part of the story is an automated motor-pump train monitor and advanced vibration analysis system had been installed four months earlier and was working properly.

This monitoring equipment included the CSI 9210 Machinery Health Transmitter connected to the automation system via Foundation fieldbus. This equipment did its job communicating advisory alarms it began to detect problems in the lubrication system.

These alerts went unheeded until they became maintenance alerts and ultimately failure alerts. Todd wrote that the health curve of the pump deteriorated rapidly in the final ten minutes before failure.

Why? The equipment did its job and dutifully reported the problem. The issue turned out to be more of overall unit tuning and alarm management issues. These alerts had been lost among other alarms coming in.

Working as a team, the refinery and local asset optimization experts reviewed the overall alarm strategy and identified opportunities to reduce the alarms and alerts coming in to the operators.

Specifically for the pumps, a best practice was established to add additional temperature measurements on the pump. Training was established to clarify how these alerts would be transitioned between the operators and maintenance staff. Clarifying this process is important when working with predictive diagnostics. At the time, it is not yet an actual problem--but like this centrifugal pump example--will fail if not addressed.

Here is another installment in our continuing series of screencasts showing the intersection of Foundation fieldbus (FF) digital communications with automation systems. The intent of these screencasts is to demonstrate visually how the information in these smart field devices interacts with the automation system to help improve the process.

Emerson's Rune Reppenhagen shows a control loop with a Coriolis flowmeter, a digital valve controller, and a connection to a redundant pair of Foundation fieldbus H1 cards. Rune describes the control strategy where the analog input runs in the Micro Motion transmitter, the PID control block and analog output block run in the Fieldvue DVC6000 digital valve controller and fieldbus segments connects to the pair of DeltaV H1 cards.

In this 3:21 screencast, Rune shows how control around the loop is maintained by running even in the event of loss of both H1 cards. As you might expect, the information is no longer transmitter to the operator, but the loop will continue to operate. Operators can monitor the loop locally at the devices with their local indicators until the communications are reestablished.

Different applications and operating philosophies may prompt where you might want to locate your control strategies--in the automation system controller or in Foundation fieldbus devices. John Rezabek, a contributing editor for Control magazine, implemented this approach seven years ago as he describes in his article, Not jazzed about fieldbus? Try it. He describes the additional benefit of mode-shedding to manual when the process variable (PV) of the PID is bad or uncertain in the devices. John writes:

While it's a diligent piece of work, this user-coded mode shedding is utterly unnecessary in fieldbus--it's already hard-coded into the blockware and happens automatically. In the same way, the "actual" mode of a PID block sheds to manual when its PV status is bad or uncertain, holding the last output computed before the input's signal status changed.

For bad or uncertain transmitter information, John writes:

Bad or uncertain PV status will cause appropriate mode-shedding in the same scan (macro cycle) in which the condition is detected, so no "new" valve output is passed to the AO block; it dutifully holds last value.

All this happens by interconnecting the FF signals via your programming interface. No additional code or external interlocks are necessary. It's built-in, out-of-the-box and standard in certified FF devices that have implemented PID.

The bottom line from the screencast and what John writes is that Foundation fieldbus provides a lot of robustness in control in addition to the digital diagnostics it delivers.

As reported in the Sound OFF! Editors' Blog, the ISA issued a press release announced that the ISA-SP104 committee has completed adoption of EDDL as an ANSI standard specified by IEC 61804. It is now: ANSI/ISA-61804-3 (1004.00.01)-2007, Function Blocks (FB) for Process Control - Part 3: Electronic Device Description Language (EDDL).

So if you are an automation engineer you might ask... so what? I have attempted to address this "so what?" question in prior posts, but it is something I will try again in my quest to simplify in my mind--if not yours.

The best way I can think of it is a text-based file that is associated with your smart Foundation fieldbus, HART, or some of your PROFIBUS devices in your plant. This text-based file presents its operation, diagnostic, performance analysis, operating statistics, calibration and other information in a standard, globally agreed upon way. Applications like your control system, asset management software and handheld devices that support this standard can present the information to you in a standard, intuitive way.

The analogy I have used in the past is the Really Simple Syndication (RSS) standard for publishing and consuming information across the web. Like the smart field devices, web news feeds, blogs, and other RSS-enabled content provide their information in this agreed upon global data standard. You can use RSS readers like my favorite, Google Reader, to read the information to which you choose to subscribe.

Continuing the analogy, your RSS reader presents this information to you in a common way--the look, the fonts, the shortcut keys, etc. The content can come from different suppliers' web servers, be on different operating systems, and even run with different software applications that create these standards-based RSS files.

Likewise, your application that understands the global EDDL standard (like Emerson's AMS Device Manager and 375 Field Communicator) can present the information from various smart field devices, from different suppliers, and even running different digital communications protocols. As ISA-SP104 Committee Chair (and fellow blogger), Terry Blevins said in the release:

Using tools based on EDDL can mean faster device commissioning and loop checkout, as well as reduced field trips and the elimination of unnecessary maintenance.

In an earlier post, I had mentioned the ISA-SP104 committee had established an EDDL.ORG site as an educational site. The committee has been hard at work creating educational information including basic information, participating organizations in this standard, and other news, events, and technical resources.

And, as reported this past April, the EDDL team and another smart device-based standard, FDT Group, agreed to combine efforts and work toward a unified solution for device integration that is compatible with both technologies. ARC Advisory Group sums up this collaborative effort well:

ARC applauds the collaboration efforts of the parties involved. The actions of this group will be remembered as the tipping point where practical common standards for field device integration were founded. Working toward the singular goal of easy equipment configuration and management will provide more value than anyone could have imagined.

A few weeks back, there was a conversation going in the automation-related blogs comparing HART and Foundation fieldbus. I joined the conversation in this post which included a whitepaper written by Emerson's Tom Wallace.

The post caused a few comments and a several email exchanges internally within Emerson among the digital communications protocol research and development teams, and with some of the respective foundations.

Tom has synthesized this feedback and updated the whitepaper. The changes are primarily in the order of the compared Foundation fieldbus and HART capabilities as well as the overall tone of the piece.

For process manufacturers making decisions about the automation technologies they will use to run their plants, I hope that this whitepaper along with other sources help to clarify some of aspects and differences of these important digital communications protocols.

Both Tom and I welcome your comments to further the conversation.

In our continuing series of screencasts, I'm trying to give examples of how advanced diagnostics in Foundation fieldbus devices can be used in control strategies to avoid abnormal situations and potential losses in production.

Emerson's Rune Reppenhagen shows in this quick 2 minute, 47 second screencast, how an advanced model predictive control strategy in a DeltaV controller automatically recognizes a failure diagnostic in a temperature transmitter and switches the mode of control over to a manual state.

At the same time, this diagnostic alerts the operator of the situation, and the AMS Device Manager software shows the condition of the transmitter so it can be quickly repaired.

By using the advanced diagnostics from these intelligent field devices in the control and advanced control strategies, conditions which impact the availability and quality of the process can be avoided.

Here is another in my series of screencasts, this time showing how an automation system uses predictive maintenance diagnostics to switchover a pump before it fails.

Emerson's DeltaV product manager, Randy Balentine, shows in this 2 minute, 43 second screencast a redundant pair of pump-motor trains. These pump-motor trains are being monitored with CSI 9210 Machinery Health Transmitters.

Randy shows a situation where one of the transmitters communicates excessive vibration via Foundation fieldbus digital communications to a DeltaV system. One of the DeltaV control modules receives the diagnostic alert, performs the logic to switchover to the backup pump-motor train, and notifies the operator of the problem so that it can be addressed.

By incorporating these predictive diagnostics into the control strategy, the switchover can happen before a failure causes a loss of production. Based on the severity of the diagnostic information reported by the smart Foundation fieldbus transmitter, the actions can range from notification of the operators to control actions performed by the control strategy.

There has been quite a bit of lively discussion around comparisons with HART and Foundation fieldbus. The first item someone pointed out to me was a paper done by Jim Russell, the Chair of Australia's Foundation Fieldbus End User Council, entitled HART v FOUNDATION FIELDBUS - THE FACTS and THE REAL DIFFERENCE. It compares from a strong Foundation fieldbus perspective as indicated by:

Don't believe all the "hype" given out by manufacturers, especially those that tell you that you can get everything provided by Foundation Fieldbus with HART.

Then John Rezabek wrote a piece for ControlGlobal.com entitled, Users driving the bus. He created a stir with these words:

Newer HART I/O promises support for FF-like diagnostics, but some end users feel they're getting a smokescreen when they ask suppliers to clarify the real capabilities and limitations. DCS vendors, eager to win upgrade jobs in brownfield sites, should be telling their customers how much of the installed base of HART devices will need upgrades to support the watered-down, fieldbus-like diagnostics.

Walt Boyes in his Sound Off blog wrote a post A Word from Ron Helson at HART. Ron responds:

The statement about "watered-down, fieldbus-like diagnostics" is also very ironic and misleading. Contrary to the implication, the fact is that all HART-enabled devices - dating back to the early 90's - contain device status and diagnostic information that is easily used by today's HART-enabled automation and I/O systems without any upgrade to the device. Users evaluating their automation system and field communication protocol options must consider many issues including; device replacement, training, project risk, infrastructure upgrades, automation and I/O system upgrades and others. In many cases, total cost vs. benefits have shown HART to be the most cost-effective option.

The discussion continued with a response posted by John Rezabek.

I thought I'd take a different approach and look at what the protocols were designed to do, and how those original design goals influence protocol functionality. Emerson's Tom Wallace recently wrote a white paper entitled, Functional Comparison of HART and FOUNDATION fieldbus. It comes right out by describing the different design objectives of the two technologies.

Prior to digital communications protocols, 4-20mA analog transmitters required multimeters and screwdrivers to adjust potentiometers to range transmitters. Other potentiometers adjusted calibration, zero settings, and damping factors. Signals drifted and required constant maintenance. Electrical interference causing offset were other issues which required maintenance attention.

In the whitepaper, Tom summed up the HART design objectives this way:

When devices became smart, better ways to configure, calibrate, maintain devices, and communicate the process variable became possible. The HART protocol was developed to address this problem set. It had one huge market adoption advantage over other protocols of the day, in that it was not intended to solve all the problems of analog. Process control was still expected to be done from the 4-20 mA signal. Although this solution was technically inferior to a fully digital protocol, it maintained compatibility with the entire control system infrastructure installed in the field. HART was extended to provide the process variable digitally, but this capability is largely unused.

And the Foundation fieldbus design objectives:

FOUNDATION fieldbus was designed to support all the configuration and maintenance capabilities of HART and more. It was designed to be a completely digital process control network capable of being the control system. It does all the things that a regulatory control system does. It is deterministic and real time, handles alarms and alerts, has trending capability, provides the function blocks used for basic and advanced regulatory control, and the sequencing and logic associated with it. To accomplish this larger set of goals, it needs to support more robust messaging and processing power.

In addition, FOUNDATION fieldbus was designed to support all the configuration, calibration, diagnostics, setup, and maintenance activities associated with both devices and the control strategy.

The whitepaper goes on to compare various attributes including:

• Compatible with 4-20 mA control host
• Compatibility with existing control wires
• Communications robustness
• Multivariable capability
• Control via digital signal
• Control/calculation capability
• Accuracy, Stability, and reliability of the process variable
• Availability of process control
• Alarms and alerts
• Ability to access and deliver diagnostic information
• Compatibility with existing knowledge base and work practices

The bottom line is that both HART and Foundation fieldbus continue to provide value for process manufacturers and continue to improve, taking advantage of advancements in technology. As such, Emerson continues to invest in both these communications protocols and take advantage of the rapid advancements in technologies brought to us courtesy of Moore's Law. The different initial design objectives shape what capabilities each protocol can deliver now and in the future.

I had mentioned in an earlier post that short screencasts are a great way to quickly convery ideas in lieu of hundreds of words. One of Emerson's product application specialists, Rune Reppenhagen, graciously agreed to demonstrate how advanced diagnostics can be used in automation system control strategies.

Today's example shows how air in a fluid can impact Coriolis flow measurement and cause the automation system control strategy to falsely assume it needs to increase the speed of a pump to try to raise compensate for the low flow measurement. This situation called entrained air or slug flow causes the measurement on the coriolis meter to go to zero. The actual flow is OK but the problem is with the measurement.

Rune demonstates in this screencast (runtime: 4:51) how advanced diagnostics like those found in Micro Motion Elite mass flow and density meters can be configured in systems like the DeltaV system to read these diagnostics and take action in the control strategy to turn the loop to manual control for the operator and notify him of the cause of the situation.

This immediate recognition of a process problem and operator notification of the situation is one example of how advanced diagnostics and digital communications protocols like Foundation Fieldbus provide ways for process manufacturers to avoid losses in production, quality excursions, and abnormal situations which can impact the efficiency of the production process.

In an earlier post, I mentioned seeing a draft article by Emerson's Terry Blevins and James Beall on performance monitoring and the Process Analytical Technologies (PAT) initiative.

The article, Monitoring and Control Tools for Implementing PAT, has now been published in Pharmaceutical Technology magazine.

Terry and James do a great job in summarizing the common problems process monitoring can detect. These include problems where the control is limited, information from the field transmitters is bad or uncertain, loop modes are incorrect, or there is high variability associate with the loop.

You can do process monitoring with an application that runs either on top of the existing automation system or embedded within it as I discussed in an earlier post on DeltaV InSight.

Here's a few tips gleaned from the article which I'll paraphrase:

• Make sure the performance monitoring application understands the operating states of the batch process avoid false indications or failed measurements
• Where you are using smart field devices like Foundation fieldbus, HART, or others include the status which accompanies the measurement so that performance calculations are based on valid information
• Check the operating modes of the loops versus their design as a basic measurement of control performance.
• Having a model to compare the actual running process against can help spot the largest areas of variability to focus improvement efforts.

Terry and James wrap up their article nicely pointing out that the Food and Drug Administration's PAT initiative has opened up the opportunity to use these performance monitoring tools to improve the operations of their processes. The timing is great with newer technologies coming along to simplify the performance monitoring process.

The ARC Advisory Group just released a Foundation fieldbus study which indicates that fieldbus solutions are expected to grow globally by more than 22% annually over the next five years. Specifically, the announcement of the Fieldbus Solutions study cites:

The worldwide market for Fieldbus Solutions in the Process Industries is expected to grow at a compounded annual growth rate (CAGR) of 22.3% over the next five years. The market was greater than $831 million in 2006 and is forecasted to be over $2,279 million in 2011...

When the Foundation fieldbus technology was introduced in the mid 1990s, the compelling benefits were in capital expenditure savings, primarily in wiring and commissioning savings. I got to see this personally when I went to Alaska's North Slope to see an Oil & Gas producer be one of the first to adopt this digital communications technology. It made perfect sense given the tremendous labor costs, and cost of building structures to shield the equipment from the harsh, arctic environment. You can see some photos on slides 75-76 of a Foundation fieldbus Installation tutorial in the Fieldbus Tutorial section of EasyDeltaV.com.

The ARC study announcement indicates that more and more process manufacturers are seeing operating expenditure benefits, especially through predictive maintenance. The study indicates:

Manufacturers are recognizing that the real value of fieldbus is Operating Expenditure (OpEx) related rather than Capital Expenditure (CapEx) related. End users have reported that predictive maintenance is the single largest savings resulting from the use of fieldbus.

I caught up with Emerson fieldbus consultant Dan Daugherty to get examples of predictive maintenance benefits. He cited a study by Dow in a Hydrocarbon Processing magazine article from a few years back. The article cited remote diagnostics in smart instruments helping to eliminate 63% of "problem not found" maintenance tickets through remote diagnostics. These diagnostics also helped reduce problems associated with drift, plugged impulse lines, and zero shifts in the field devices. Use of the ValveLink Snap-On in AMS Device Manager makes it possible to diagnose valves without having to pull them offline and look inside them. In another study by DuPont, they found that only 14% of the valves scheduled for preventative maintenance actually required being pulled and rebuilt. Dan summed it up well:

The savings on valves more than justifies implementing predictive maintenance methodology, so it is as if all the other benefits (fewer trips to the field, etc.) are for free.

The ARC announcement concludes that new installations benefit most. The greatest growth areas for these installations are in Brazil, Russia, India and China.

Depending on the conditions of an existing facility in terms of maintenance costs, the benefits from predictive maintenance may provide the economic justification to retrofit existing non-digital instrumentation and communications.