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)

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)

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

Tags: fieldbus | digital bus | segment design | HAZOP | FEED | front end engineering design | CII | Constuction Industry Institute | PepC |

October 23, 2007 in Metals, Mining, Minerals, in Profibus, in Project Services | 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)