This article was printed in CONTROL's October 2009 edition.
By Jim Montague, Executive Editor
Don't get too comfy. Sure, most digital fieldbus protocols are well beyond their awkward childhood and teenage years, and they're maturing into responsible young adults who are able to cooperate and interact with each other. Their many parents must be justifiably relieved and proud.
However, some new and ominous challenges remain, and our grown-up fieldbuses already are beginning to take on some challenging and unusual roles and tasks, such as safety instrumented functions (SIFs) that will allow them to serve in safety instrumented systems (SISs) or anyone of several wireless networking methods.
For instance, Ethernet-based protocols, wireless and even Internet-based networking are continuing their march down from the enterprise and larger consumer realms, and onto the plant floor and out into the field. Several observers say this push will force fieldbuses into sub-networks for production operations and process applications, while Ethernet flavors run above to reach higher-level asset management systems.
Others speculate that the dual progression from point-to-point hardwiring to twisted-pair to wireless and from highly centralized control to powerful distributed intelligence will make traditional control rooms obsolete. If all the smarts are in a super-smart network gateway in the field, why go back to a control room? This evolution may be logical, if not inevitable, but it also raises a question—will some of the useful potential of fieldbuses be wasted if they just serve as segregated commodities?
However, the good news is that most of the fieldbuses have been coordinating their efforts around electronic device description language (EDDL) for several years. The original partners included the Fieldbus Foundation (www.fieldbus.org), Profibus Nutzerorganisation (PNO, www.profibus.com) and HART Communication Foundation (www.hartcomm.org) with assistance from the OPC Foundation (www.opcfoundation.org), and they formed the EDDL Cooperation Team (ECT, www.eddlcoopteam.org). More recently, ECT has been working to welcome in new capabilities provided by the field device tool/device type manager (FDT/DTM) protocol and its FDT Group (www.fdtgroup.org), again with matchmaking from OPC and its OPC-UA technology method. This latest effort is known as the Field Device Integration (FDI) group, and its team members are drafting specifications now.
So, while complete plug-and-play interoperability may not have arrived yet, many persistent and crippling protocol translation problems have gone away or are vanishing, often with added help from improved linking devices. In general, fieldbuses have been getting a lot easier to use.
Steady 'Overnight' Success
Despite their recent gains and cooperation, digital fieldbuses have traveled a long and winding 10 to 15 year path to acceptance and adoption. Their developers and advocates have demonstrated plenty of patience in slowly chipping away at reluctant end users to get them to improve or replace old networking technologies. Fortunately, they've also had help from some enlightened end users hungry to gain the labor and material savings, otherwise-unobtainable signals and data, and operating efficiencies that fieldbuses can deliver. And, after struggling for a decade or two, some fieldbuses are breaking through to some long-awaited "overnight" successes in many major process applications.
"We've been using digital protocols for ‘smart devices' for many years. The earliest installations used vendor proprietary protocols, such as Honeywell's DE and Foxboro's Foxcom, which were installed in the early 1990s," says John Kinsley, of Saudi Aramco's (www.saudiaramco.com) Process and Controls Systems department. "We started piloting Foundation fieldbus (FF) technology in 2000. The initial field trials were limited to monitoring only segments typically in utilities areas or non-critical processes. Our first plant-wide installation was commissioned in 2004. Based on this experience and other pilot plants, we standardized on FF for process control applications and all new facilities in 2005."
Kinsley reports that, while FF's basic architecture hasn't changed much in the past four years, its adoption and use are growing rapidly. "Our installation base and experience level with FF technology has grown considerably. Since 2005, we've installed FF at seven grass-roots facilities with over 35,000 FF devices. The percentage of FF devices versus total I/O continues to increase as more devices are introduced to the market. On some of our earlier projects, the percentage of FF I/O versus conventional was approximately 25%. This number is closer to 40% on more recent projects. We've also increased the number of devices per segment as our confidence in the technology has grown."
Of course, FF isn't Saudi Aramco's only network. Kinsley adds that his company uses proprietary fieldbuses for MOV networks, gas chromatographs and tank gauging. "We're also at the early stages of adopting the IEC 61850 standard for substation automation," he says. "We have pilot installations in operation, but are still evaluating the technology. One of the critical components in the adoption of a new technology is to ensure there are sufficient numbers of suppliers for the end devices. We're in the process now of reviewing supplier capabilities before moving towards a wider adoption of IEC 61850. Also, we typically don't have a mixture of different fieldbuses in one facility. However, where we do, the data are interfaced to a central DCS that provides communication between the busses."
Kinsley adds that the main benefits of using FF and other digital networks at Saudi Aramco's plants are cost and use of advanced features for commissioning and troubleshooting. "We've achieved cost reductions by adopting digital fieldbuses, and these come primarily from reduced requirements for cabling and the footprint of the I/O and marshalling cabinets. We've also seen a reduction in commissioning time for fieldbus-based instruments. This is primarily from the reduced calibration requirements for smart instruments."
Charlie Piper, senior program manager for Invensys Operations Management's (www.invensys.com) DCS and control platforms division, reports that users are adapting and learning how best to use fieldbuses more than ever before. "There's a whole revolution going on in how users are hooking up sensors and actuators into their control systems," says Piper. "We used to have politics and hype, but now fieldbus technology is mature enough that people are running with it, and this is driving a lot of the cooperation going on now. In fact, in the past several months, several big oil and gas users told some vendors, who had been fighting against opening up the fieldbus protocols, that the vendors must open them up or the users would go elsewhere. There's still a lot of turmoil, but now it's going in the right direction because it's being pulled by the end users." For example, Invensys' fieldbus system contributed to a successful startup on Saudi Aramco's Shaybah GOSP4 project that began producing oil this past June.
Most likely, the simplest mathematical formula in digital fieldbus is ECT + FDT + OPC = FDI. Of course, it's a summary of how the EDDL Cooperation Team and the FDT Group partnered with help from the OPC Foundation to form the FDI group.
ECT's steering committee reported in May that its technical team has achieved some important milestones in developing a common solution for FDI. And FDI's project team has worked over the past 18 months to identify use cases encompassing all facets of plant operations from start-up and commissioning to ongoing maintenance activities and plant operations. It also drafted an architecture concept migrating participating technologies to a common device integration standard. ECT reports that results of the FDI project are based on cooperation from suppliers, including ABB, Emerson Process Management, Endress+Hauser, Honeywell, Invensys, Rockwell Automation, Siemens, Smar and Yokogawa, as well as ECT's members.
In addition, the FDI team has performed a complete inventory of use-case analyses and designed a draft for an architecture concept and for functional specifications. The architecture is a client/server structure based on OPC-UA's client/server protocol. This method's field device integration is realized by a "device package" provided by the device supplier containing EDDL components and an optional programmed component for programmed user interfaces. This design will allow complete flexibility to develop customized user interfaces.
"FDI will standardize all EDDL and FDT devices and give them one core for their information model and one core for their data services, and this will mean standard configuration and run-time operations," says Tom Burke, OPC Foundation's executive director. "So any field device will be able to plug in, and any generic application will be able to configure it. A valve is a valve is a valve, independent of its manufacturer. This is bigger than any of us can imagine. It will make our devices just like USB because they now will be instantly recongnized."
The current phase of the FDI project includes development of the detail specifications followed by validation of the specifications by each of the member organizations, which began during the second quarter of 2009. Details of the exact FDI architecture and associated device interface will be unveiled with the release of the final functional specification, currently planned for the summer of 2010.
In addition, Dave Glanzer, Fieldbus Foundation's technology development director, reports that the foundation and ISA have been cooperating since last October on developing a wireless I/O (WIO) backhaul network to help users bring in more remote signals and data from their applications.
Up-Front Engineering is Up and Running
These new levels of cooperation among the fieldbus organizations and their protocols are coming just in time—if not way overdue—for many users and their applications, and gives them some much-needed confidence at a time when nerves are frayed due to recent economic recessions. For instance, now more than ever, ethanol producers must tightly control their plants to produce consistently high yield and minimize energy and raw material consumption. This also means protecting their fieldbus physical layer against short circuits, improper terminations and many other problems.
For example, Abengoa Bioenergy Corp. (www.abengoabioenergy.com) built its 88-million gallons per year (MGY) greenfield ethanol production plant in 2006 in Ravenna, Neb., and commissioned it in February 2007 (Figure 1). To design and install the plant's control system, Abengoa recruited system integrator FeedForward Inc. (www.feedforward.com). As one of the largest dry-mill ethanol plants in the U.S., its dry-mill process hydrolyzes corn starch into sugar and then ferments it into alcohol. The steps include milling, liquefaction, saccharification, fermentation, distillation, dehydration and denaturing.
"Many process plants are embarking on real fieldbus applications for the first time. Fieldbus is a truly enabling technology, but its installation involves some additional considerations over and above traditional 4-20 mA systems. Up-front engineering is key to the success of any fieldbus project, and end users must be mindful of physical layer requirements such as power conditioning and segment termination," says Jeff Marsh, FeedForward's senior project manager. "Without correct connection of wiring and field devices, any anticipated ROI from fieldbus technology can be wiped out because technical complications can delay setting up a plant and take a long time to recoup in operational savings."
To prevent performance and reliability problems caused by bad or over/under terminations, short circuits, interference and inadequate grounding, engineers at Abengoa's Ravenna plant decided to specify new device couplers with automatic segment terminators and short-circuit protection. These couplers simplify fieldbus installation, reduce time required to install and troubleshoot field devices, and assist in segment commissioning by eliminating manual termination. As a result, FeedForward installed MooreHawke's (www.miinet.com) Trunkguard system, which is reportedly the first FF and Profibus physical layer solution with automatic fieldbus segment termination. Abengoa's control system incorporated 72 individual fieldbus segments with more than 650 nodes, which were installed using MooreHawke's field device couplers, redundant fieldbus power supplies and segment power conditioners.
"Trunkguard provided seamless plug-and-play connection with the Yokogawa DCS. The control system's H1 cards connected directly to the power conditioner boards, eliminating the need to manually wire each fieldbus segment" explained Marsh. "Unlike the older current-limiting technique, Trunkguard's short-circuit protection prevents segment failure caused by single device faults. Its "fold-back" technique automatically removes the faulted device from the segment, and doesn't permit any current flow to the device until the fault is corrected. The fold-back technique employs a logic circuit on each spur, which detects a short in an instrument, disconnects that spur from the segment and illuminates an LED visible to maintenance personnel."
Tom Wilson, Abengoa's COO, adds that the Ravenna plant's fieldbus-based DCS will give its ethanol process long-term competitive benefits. "Fieldbus provides us with a leaner automation architecture containing less wiring and hardware than a traditional control system. Loop and wiring diagrams, panel drawings and cable schedules were greatly simplified. Plus, installation was easier than with a traditional system, since several devices could be multi-dropped on one pair of wires," says Wilson. "The flexibility of fieldbus also allows us to reconfigure our process automation scheme to meet product and sales demands without major reinvestments. It reduces I/O subsystem requirements and makes the plant control system very scalable. The system can be expanded or modified loop-by-loop as needed. Thanks to our fieldbus automation solution, our Ravenna plant has achieved optimal operating conditions that increase yields, while also cutting the amount of energy needed per gallon of ethanol produced."
"It was the classic integration problem—it was hard to bridge the gaps between the existing network and the fieldbuses," says Hein Hiestermann, HiProm's CEO. "However, this has become easier over time with better communication devices, such as the EN2PA module we invented that links EtherNet/IP to Profibus PA."
Stephen Proctor, HiProm's technical director, adds that HiProm has been making modules with help from Rockwell Automation (www.rockwellautomtion.com) for years, but adding Profibus meant writing firmware to make a Profbus PA device look like an Allen-Bradley I/O device. This eliminates the need for the array of devices previously needed to connect foreign networks and controllers, he explains. "This method makes configuation and automated operations a lot easier," says Proctor.
Gateways, Subnets and the Future
Ironically, as fieldbuses replace hardwiring and as linking devices and gateways make it easier, there's probably no way to avoid basic changes in how industrial networks are designed and implemented. Few observers think traditional control rooms will disappear, but there's sure going to be a lot more data processing and value-added jobs going on ever further out in the field.
"Also, as the wireless standards mature and more functionality is pushed out to the field, we're likely to see an even greater distributed architecture with all the primary control done at the field-device level with wireless linking devices resident in the field junction boxes that communicate back to a central control room. This would be a significant change from our current design practices. However, the potential cost savings are tremendous due to reduced home-run cables, cable trays, process interface buildings and other equipment."
Ironically, once integrators and users begin to eliminate point-to-point hardwiring, some users also start question how much twisted-pair fieldbus networking they need, especially if more data processing and intelligence is migrating to the field anyway. "We're just saying it's helpful to distribute controllers closer to the I/O points and other devices that they're hosting," says Karie Daudt, senior product manager for Turck Inc.'s (www.turck.com) networks and interface division. "For example, we have a programmable gateway for EtherNet/IP that is like a mini PLC. It has both smart I/O and distributed PLC capabilities, and so it can run control programs locally for distributed I/O points, and then just pass the resulting process data up to the asset management system. In fact, one of these programmable gateways has been doing PID control for a glass manufacturer, and it can keep that process running locally, even if communications are lost with the initial master PLC."
Jim Montague is Control's executive editor.
DeviceNet, ControlNet, EtherNet/IP
- DeviceNet, ControlNet, EtherNet/IP are based on the upper-layer Common Industrial Protocol (CIP), and are supported by ODVA (www.odva.org) and ControlNet International (www.controlnet.org), which co-manage EtherNet/IP.
- DeviceNet uses linear, trunkline/dropline topology; ControlNet has a linear, tree, star or combination; and EtherNet/IP has active star with devices connected to an Ethernet switch
- DeviceNet uses twisted-pair physical media for signal and power; ControlNet uses coaxial or fiberoptic cable; EtherNet/IP typically uses 10/100Base T or 1 Gbps with Cat 5E, twisted-pair cable
- DeviceNet allows 64 nodes maximum; ControlNet allows 99 nodes maximum; EtherNet/IP has no practical device limit
- Maximum distance is 500 m at 125 kbps for DeviceNet, depending on data rate; ControlNet's maximum distance is 1 km via coax with two nodes, 3 km over fiber with 99 nodes, 30 km over fiber or coax with repeaters up to 99 nodes; EtherNet/IP has no distance limit
- DeviceNet and ControlNet's communication method is producer/consumer with peer-to-peer and master/slave options
- Data rate is 500 kbps, 250 kbps or 125 kbps for DeviceNet; 5 Mbps for ControlNet; 10/100 Mbps and 1 Gbps for EtherNet/IP
- Data packet size is 0-8 bytes variable for DeviceNet; 0-510 bytes variable for ControlNet; 0 to 65,511 bytes variable for EtherNet/IP
- Foundation fieldbus H1 and High-Speed Ethernet (HSE) are supported by the Fieldbus Foundation (www.fieldbus.org)
- H1 typically uses twisted-pair wiring in a star or bus topology; HSE uses twisted-pair or fiberoptic media in a star topology
- Maximum devices for H1 is 16 devices per segment, depending on performance needs, and up to 65,000 segments; HSE has no device limit due to IP addressing
- H1's maximum distance is 1.900 km at 31.25 kbps and 100 m at 100 Mbps on twisted-pair; HSE's maximum distance is 2 km at 100 Mbps using full-duplex, fiber-optic cable
- H1 and HSE use client/server, publisher/subscriber, event notification communication methods
- Data packet size for H1 is 128 octets, with 256 maximum overhead, but this dimension varies for HSE because it uses TCP/IP
- H1's cycle time usually is less than 500 msec, depending on individual applications; HSE's cycle time is less than 100 msec
- Modbus Serial (RTU/ASCII), Modbus Plus (proprietary to Schneider Electric), and Modbus TCP/IP were developed by Modicon and Schneider, and are supported by Modbus-IDA (www.modbus.org)
- Uses twisted-pair, RS-232 and RS-485 wiring in linear, line, star and tree topologies with segments
- Modbus Serial can address a maximum of 247 devices; Modbus TCP/IP allows unlimited addressing
- Maximum distance is 100 m between switches for Modbus TCP/IP via Cat5 copper wiring
- Modbus uses a master/slave or client/server communication methods
- Transmission properties include 1 Mbps for Modbus Plus; 300 bps-38.4 kbps for RTU/ASCII; 100 Mbps for TCP/IP
- Data packet size is variable for Modbus Plus; 0-254 bytes for RTU/ASCII; 1,500 bytes for TCP/IP
HART, Wireless HART
- HART (highway-addressable, remote transducer) field communications and Wireless HART protocols are supported by the HART Communication Foundation (www.hartcomm.org)
- Employs 4-20 mA wiring in point-to-point topology for simultaneous analog/digital communication, point-to-point for digital only, multidrop for digital only (up to 32 devices), and intrinsically safe with appropriate barriers
- One device maximum for point-to-point or 16 devices maximum for multi-drop, which is derived by the noise calculation.
- A network can have more than 16 devices if it meets the specification's noise calculations, but those that exceed these limits might have degraded communications.
- Maximum distance for twisted-pair is 10,000 ft for one device and 5,000 ft for multiple devices
- Traditional analog, 4-20 mA communications, as well as simultaneous encoded digital, FSK based on the Bell 202 telecomm standard, PSK, high speed HART-ITU (CCITT) V.27
- 1,200 bps transmission speed, and 9,600 bps for high-speed HART
- Data packets include one start bit, eight data bits, one odd-parity bit, one stop bit, as well as two-dimensional error checking with device status in every reply
- Two or three transactions per second cycle time for diagnostic information and non-primary variables; three or four transactions per second in "burst mode," and instantaneous analog transmission of primary variables
Profibus, Profinet, ProfiSafe
- Profibus-PA, Profibus-DP, Profinet, Profinet for Motion Control, and ProfiSafe were developed by Siemens AG and are supported by the Profibus Nutzerorganisation e.V. and the Profibus Trade Organization (www.profibus.com)
- Uses twisted-pair or fiberoptic cabling in line, star, ring or bus topologies
- Maximum devices are generally 127 nodes in four segments with three repeaters, plus three masters; Profibus-PA is limited by current restrictions to 15 devices per segment; Profinet allows unlimited devices; and Profisafe has application-specific limits
- Maximum distance is typically 100 m between segments at 12 Mbps, or 12 km with fiber
- Master/slave, peer-to-peer communication methods
- Transmission properties include 1.5 or 12, Mbps for Profibus DP; 31.25 kbps for Profibus PA; 100 Mbps for Profinet
- 256-byte data packets, including 244 bytes of content data
- Configuration-dependent cycle times of less than 2 msec, as well as 1 msec and 10 msec for Profinet versions