Emerson Process Experts

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.

Tags: EDDL | FDT | DTM | HART communications | Foundation fieldbus | FF | Profibus | device description |

May 14, 2008 in Asset Optimization, in Enterprise Integration, in Foundation Fieldbus, in Interoperability, in Profibus, in Technologies | Comments (0)

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.

Tags: nuclear power | control valve | safety valve | digital valve controller | valve regulator | Foundation fieldbus | NRC | ASME | EPRI |

April 16, 2008 in Foundation Fieldbus, in Plant Equipment, in Power, in Regulatory Compliance, in Safety | Comments (0)

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.

Tags: EDDL | electronic device description language | Foundation fieldbus | Profibus | HART communications |

April 2, 2008 in Asset Optimization, in Foundation Fieldbus, in Interoperability, in Profibus | Comments (0)

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.

Tags: collaborative measurement | project management professional | PMP | Foundation fieldbus | distillation column | measurement strategy | control strategy |

March 12, 2008 in Control Strategies, in Distillation Column, in Foundation Fieldbus, in Measurement, in Project Services, in Wireless | Comments (0)

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.

Tags: Foundation fieldbus | DCS |

March 4, 2008 in Foundation Fieldbus | Comments (0)

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.

Tags: Foundation fieldbus | Profibus PA | Profibus DP | abnormal situation prevention | predictive maintenance |

February 21, 2008 in Foundation Fieldbus, in Interoperability, in Profibus | Comments (6)

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.

Tags: EDDL | electronic device description language | FDT | DTM | IEC61804 | IEC 61804 | SP104 |

February 12, 2008 in Asset Optimization, in Foundation Fieldbus, in Interoperability, in Profibus | Comments (0)

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.

Tags: EDDL | EDD | Foundation fieldbus | HART Communications | Profibus |

December 12, 2007 in Foundation Fieldbus, in Interoperability, in Profibus | Comments (0)

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.

Tags: Fieldbus Foundation | Foundation fieldbus | fieldbus segment | segment calculator | H1 segment | segment design | segment engineering |

November 20, 2007 in Foundation Fieldbus, in Interoperability, in Support Services | Comments (1)

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.

Tags: Foundation fieldbus | SIS | safety instrumented system | function blocks | Fieldbus Foundation | sensor | logic solver | final control element |

October 11, 2007 in Foundation Fieldbus, in Safety | Comments (0)

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.

Tags: Foundation fieldbus | capital projects | preventive maintenance | proactive maintenance |

October 4, 2007 in Foundation Fieldbus, in Oil & Gas, in Refining | Comments (0)

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.

Tags: EDDL | electronic device description language | EDD | ISA Expo | ISA104 | 61804-3 | Foundation fieldbus | Profibus | HART communications |

October 1, 2007 in Foundation Fieldbus, in Interoperability, in Profibus, in Technologies | Comments (0)

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.

Tags: Profibus | DeviceNet | Foundation fieldbus | HART communications | smart field devices | PEpC | Construction Industry Institute | CII |

September 7, 2007 in DeviceNet, in Foundation Fieldbus, in Profibus | Comments (2)

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.

Tags: EDDL | electronic device description language | ISA | SP104 | foundation fieldbus | profibus | HART communications |

August 7, 2007 in Foundation Fieldbus, in Interoperability | Comments (0)

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.

Tags: flow meter | flow measurement | foundation fieldbus | Coriolis | magnetic flow | vortex | thermal mass flow | variable area meter |

August 3, 2007 in Education, in Foundation Fieldbus, in Measurement, in Support Services | Comments (2)

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.

Tags: refinery | centrifugal pump | bearing lubrication | machinery health | foundation fieldbus |

July 30, 2007 in Asset Optimization, in Foundation Fieldbus, in Plant Equipment, in Refining | Comments (2)

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.

Tags: foundation fieldbus | process control | interlock | PID |

July 12, 2007 in Foundation Fieldbus, in Screencast | Comments (2)

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.

Tags: ISA | EDDL | Electronic Device Description Language | ANSI/ISA-61804-3 | IEC 61804 | Foundation fieldbus | RSS |

June 15, 2007 in Asset Optimization, in Digital Busses, in Foundation Fieldbus, in Interoperability | Comments (0)

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.

Tags: Foundation fieldbus | digital busses | communications protocol |

June 1, 2007 in Foundation Fieldbus, in Interoperability | Comments (0)

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.

Tags: Foundation fieldbus | temperature transmitter | model predictive control | MPC | advanced process control | APC | screencast | diagnostics |

May 18, 2007 in Abnormal Situation Prevention, in Control Strategies, in Foundation Fieldbus, in Screencast | Comments (0)

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.

Tags: Foundation fieldbus | digital busses | abnormal situation prevention | pump-motor | predictive diagnostics |

May 7, 2007 in Abnormal Situation Prevention, in Asset Optimization, in Foundation Fieldbus, in Screencast | Comments (0)

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.

Tags: Foundation fieldbus | HART | diagnostics | communications protocols |

April 30, 2007 in Foundation Fieldbus, in Measurement | Comments (2)

I had