00000e

Want to Go Back?

Sept. 24, 2003

Smart devices and fieldbuses can let you return to the 1940s with single-loop integrity in a truly distributed system

In 1975, when Honeywell introduced the TDC 2000 distributed control system, it was anything but distributed. In those days, process control engineers had a choice of using minicomputer-based, centralized SCADA systems; racks of electronic or pneumatic single-loop controllers with PID technology that originated in the 1940s and 1950s; and combinations thereof.

Although the ads and brochures of the day proclaimed "distributed," DCSs that came out of Honeywell, Fisher Controls, Taylor Instruments, Fischer & Porter, Beckman, Foxboro, and all the other giant instrument companies were actually centralized systems. They brought all the field data into a central control room, ground it up in microcomputers, displayed the results on three-CRT consoles, and sent the appropriate control signals back out to the field actuators and control elements.

Single-loop controllers were replaced by multi-loop controllers, minicomputers were replaced by microcomputers, and field wiring was replaced by redundant data highways. Gone forever, it seemed, was the concept of single-loop integrity; that is, where a failure in a loop's I/O, valve, sensor, controller, or wiring affected only that loop, not an entire process unit.

Today, modern technology has made it possible to return to those thrilling days of yesteryear and the traditional concept of single-loop control. In a way, we've returned to the 1940s, and a new era of truly distributed control (TrDC).

If you want to return, that is.

We're Learning How

If you want single-loop control, the technology is readily available. You need only two basic elements, points out Ed Bullerdiek, control group leader at Marathon Ashland Petroleum, Detroit. "All you need is reasonably fast and robust networking technology and devices that support control at the local level," he says. That hardware and software is readily available from a variety of sources.

Fieldbus is one such technology (Figure 1). "Fieldbus and its capability to have embedded control algorithms physically on the field devices provides the ability to truly localize islands of process control without having to depend on a central controller," says Arturo Medina, systems engineer and automation specialist at R.S. Stover, Marshalltown, Iowa.

Figure 1: Control on the Wire

Fieldbuses and smart devices allow control to shift from the host CPU (top) to the rack or into the field devices themselves (bottom). (Source: ICE-Pros)

Some vendors agree with using fieldbus for TrDC. "There are two key enabling technologies," says Terry Krouth, vice president of PlantWeb Technology at Emerson Process Management (www.emersonprocess.com). "One is Foundation fieldbus, which is designed from the ground up to enable control in the field with function blocks, scheduling, peer-to-peer communications, security, etc. The other technology includes microprocessors and electronics that run with extremely low power consumption and software that can deliver high performance in an environment where power is gold."

Krouth notes that Foundation fieldbus technology is owned by an independent foundation that supports conformance testing and interoperability. "This gives users freedom to choose suppliers based on product performance and functionality."

"The key to highly distributed control is interoperability," adds Dave Appleby, process solutions product manager at Rockwell Automation (www.rockwell.com). "Foundation fieldbus devices are required to be interoperable, providing a user with tools to implement a control system with products from multiple vendors."

Others are not so sure about fieldbus yet. "I am not a big fan of fieldbus," says Michael LaRocca, senior process control engineering specialist at Solutia's W. G. Krummrich Plant, Sauget, Ill. "Until fieldbus has the ability to implement a high-integrity interlock equal to that offered by hardwiring, I don't think there is sufficient wiring cost savings to justify the additional cost and complexities fieldbus introduces."

"With fieldbus, I'm not sure you are at truly distributed control," cautions Bullerdiek. "If you hang several devices on a segment, they are all at risk if you lose power to the segment."

Richard McCormick, process control engineer at the Raffinerie Jean Gaulin refinery in Levis, Quebec, agrees. "One major restriction is the number of devices per wire loop, especially in intrinsically safe areas," he says. "Also, the current level of redundancy for these controls on the wire' is not fully addressed yet. Losing a loop can mean losing many controls."

Other engineers say fieldbus is not necessary, because Ethernet does the same things. "Embedded computing with TCP/IP Ethernet links will work," says Mike Luffey, vice president of engineering at DeSoto County Electric, Horn Lake, Miss.

A reflow furnace control system developed by Yamatake (Figure 2) illustrates how a standalone system can be developed to control a fast, critical process with off-the-shelf components. According to Russell Kirkman, product development manager at Yamatake (www.yamatakeusa.com), the system can be installed directly in a piece of equipment or in a nearby rack on DIN rails.

"The Internet and Ethernet make it possible to do control with small, very fast processors that can be placed with the I/O right where it's required in an application," says Steve Arnold, product marketing specialist at Schneider Electric (www.schneiderautomation.com). "With Foundation fieldbus, the controller is talking over the bus, so it's not truly distributed control."

Figure 2: Fast Field-Based Furnace Control

The O2 sensor signals the modular controller, which signals the mass flow controller to adjust the nitrogen valve. The controller also controls the heaters. (Source: Yamatake)

If you have a DCS now, you can add TrDC to it. "We are using a wide variety of controllers now, connected via OPC drivers to our HMI system," explains Eric Kettunen, process control supervisor at Bowater Newsprint, Calhoun, Tenn. "We use an appropriate device for each system. For example, we use Siemens PLCs for some safety systems and Modicon Quantums for inexpensive remote controls. We only add I/O to existing legacy DCS systems. We don't purchase new legacy DCS controllers. PLCs and PLC I/O and the ease of networking various manufacturers together has made process control quite simple."

Arnold agrees. "Based on the number of systems we sell that use Modicon Quantums, we think TrDC is growing. In one application, for example, a systems integrator working with a utility was able to exchange expensive turbine governors for a Quantum system. This saved them hundreds of dollars on each installation."

Kettunen is also happy with Ethernet. "Ethernet communication is robust and cost-effective. We stopped relying on one or two suppliers a few years ago. This is not exactly TrDC, but we are no longer bound to proprietary process control networks or specific controllers."

Kettunen is, of course, talking about the joys of working with open systems that actually work together. Ian Verhappen, director of ICE-Pros, a systems integrator in Fort McMurray, Alberta, says it's not always that way. "Open standards and adherence to same without adding enhancements are the keys to success," he notes. "Manufacturers adding enhancements to a standard means it is no longer a standard, and once again they are able to keep everyone else out. This is why independent testing is needed to ensure interoperability and adherence to the standard."

Nevertheless, in spite of a few shortcomings, TrDC is here. You can buy it in fieldbus systems or assemble it yourself with components using Ethernet, Internet, embedded computers, PLCs, wireless networks, and/or cell phones.

But Do You Really Want It?

As we noted, TrDC is somewhat of a return to the 1940s, when process control loops consisted of a control valve, flow or level meter, and a pneumatic single-loop controller, all located in the field. In some cases, the pneumatic controllers were installed in a nearby control room, mostly for protection from the elements. When single-loop electronic controllers entered the picture in the 1950s, the controllers were moved to centralized control rooms, and wires linked them to the field devices. It was the same principle as the pneumatics, but the wires let the controllers be a bit farther away.

Control rooms consisted of racks of single-loop controllers with faceplate analog readouts. Operators could glance down the rack and make sure all the faceplate indicators were centered, which meant the plant was "lined out" and operating perfectly.

With today's devices, we can return to the 1940s and put everything back in the field, including the controllers.

Since 1975, we've heard control engineers repeatedly longing for a return to those days when control was truly distributed. Now, some engineers aren't so sure.

"The operator interface is no longer an inherent part of a field control device," says Bullerdiek. "I'm not sure that having loops still operating buys you much if you can't see what is going on because the network is down. Loss of view is a serious problem, and most facilities will shut down if view cannot be restored in a short period of time."

"I used to be an ardent fan of true distributed control 15-20 years ago," says LaRocca. "I've changed my colors, though. I now believe the low cost, flexibility, and ease of doing advanced control in multi-loop devices far outweighs the integrity and reliability offered by TrDC. This has become even more relevant with the high mean time between failure values available with today's controllers and the availability of fault-tolerant devices for critical loops."

Bullerdiek agrees. "We are seeing much more complicated and interactive control strategies these days. Fragmenting the control hardware may be counterproductive relative to the desire to use more coordinated or multivariable control schemes."

Some process plants may not want single-loop control. Rob Burgman, senior automation engineer at Sun Chemical's pigment division, Muskegon, Mich., works in a batch plant, and he says single-loop controls aren't best there. "Our batch processes are better suited to centralized control, where one has access to all control functionality," he explains. "We operate loops differently, depending on what phase of the S88 batch is executing. Interlocks change depending on what phase is running and what steps are being executed. Our loops only execute during specific parts of the batch process. TrDC would complicate, rather than simplify, our operation."

On the other hand, we haven't had the capability to do TrDC for nearly 30 years, so maybe some engineers don't realize what's possible. Back in the 1940s and 1950s, feedforward, cascade, and multivariable control schemes using single-loop pneumatic and electronic controllers could be incredibly complex. That's all changed.

"One limitation of the original single-loop controllers was they had no capability to network and upload their information to a central data collector," says Jim Loar, engineering group leader at Ciba Specialty Chemicals, Newport, Del. "Data collection was a strip-chart recorder. With field-based controls this network is provided, so I don't see any problem in where the control takes place, as long as it provides the control you need."

"By having control at the site, you're not relying on one centralized processor to control all aspects of an application," Arnold reminds us. "Distributed control means you have quicker response to individual parts of the application, which can be crucial. When an input changes, the output needs to respond accordingly. Distributed control gives you finer control over a system. It doesn't get as far off track as you would with centralized control."

Networks are much faster, too. "Problems with single-loop control came about because of slow communications speed and response time," recalls Arnold. "Analog PID controllers had serial communications that were about 19.2 Kbps, too slow for a central control system to respond. Today's Ethernet systems transmit information at 100 Mbps, and we are on the verge of gigabit Ethernet."

McCormick agrees that modern networking makes it much easier to link loops. "TrDC will link loops together so they will be able to communicate. This is absolutely required for higher-level applications as well as advanced regulatory controls, such as cascade, constraint, override, and so on. This communication was not possible back in the old days, so everything needed to be hardwired."

Luffey says we can move to a new level of control. "We can do local single-loop but also acknowledge the effects of other variables in complex equations and logic to optimize complete unit operations," he suggests. Luffey also says the danger of such a scenario is runaway loops. "We do municipal SCADA and always implement a local control at the plant level if remote signals are lost. This works well in preventing problems, even though it occasionally causes premature halts. There has to be remote intelligence to limit actions or implement failsafe strategies if remote signals are lost."

He adds, "I am developing expertise in areas such as Ethernet networking and browser software, as I see problems developing there rapidly."

Then There Are the Problems

There are always problems when dealing with new technology, even if it's really old technology that's been reborn.

Loar points out that we went to DCS because of a problem. "With TrDC, we're getting back to the concept of pneumatic single-loop controllers," he says. "We lived for a long time with controllers operating independently of each other, separate from central control. But isn't this the problem we were trying to solve by going to centralized control? For example, a level controller is not an independent entity: It is part of a whole unit operation, and its information is important to the entire process."

LaRocca says it's difficult to do TrDC with fieldbus. "I see the same drawback of doing TrDC with fieldbus that exists with single-loop controllers: the need for rewiring. With fieldbus, I suppose it might be called re-segmenting. My understanding is that two devices on different fieldbus segments cannot talk to each other on short scan times. So, if you come up with a new control scheme that requires devices on different segments to talk to each other quickly, then you have to rearrange segments, and perhaps install new fieldbus cable. With multi-loop controllers, communication between devices is just a matter of programming. I personally have no desire to return to the single-loop controller days. I like being able to make control strategy changes without rewiring or rearranging fieldbus segments."

Medina says that coordination is vital. "The main problem I see is the requirement to have very consistent configuration and maintenance practices, so there is no mystery on where the control blocks are assigned, how certain algorithms are run, and so on," he suggests. "Everything can be backed up in a safe place and remembered, in case the master controller gets hit by a meteorite or something."

Then there is the problem of nonstandard standard devices. "Remove Rosemount's smart transmitter and replace it with Yokogawa's," says Burgman. "Are the PID algorithms the same? Will the old tuning parameters work? I have worked with each of these manufacturers' DCSs, and their PID controllers don't work the same."

Burgman offers a laundry list of similar process tuning problems: Will a supervisory control system that can alter tuning parameters on the fly have to be reprogrammed for different PID controllers? How do you implement split-range control with two different valves? How does a TrDC system handle variable frequency drives with PID? None of them talks fieldbus.

Then, Burgman asks the killer question: "Is this just another way to lock me into sole-sourcing, since it will be easier to do all this with a single vendor?"

What about failures? Jorge Cano, process control engineer at Grupo Pe‚±oles in Torreon, Coahuila, Mexico, says he doesn't see many failures in control systems these days, so he doesn't expect any more with TrDC. "I work in a complex facilities group where we have wastewater plants, chemical plants, refinery metals plants, electric kilns, and other processes," says Cano. "We have, like many other plants, our own problems, but never have I seen a distributed control system fail in its parts. Problems are always other things, such as a bad wire, bad electrical feed, and PLC failures."

As Cano and several other respondents point out, hardware and network failures seem to the least of the problems associated with TrDC. It appears TrDC networks and components are as reliable as anything else available on the market. Maybe more so. "If a processor in a TrDC system fails, you could lose an activity," notes Arnold. "A processor problem with centralized control risks an even greater level of failure."

"One of the great appeals of TrDC is that it actually reduces risk and improves reliability," adds Krouth. "If there is a loss of control for any reason, backup local systems can pick up control and keep the loop running."

Instead of hardware, it would seem any problems that exist with TrDC concepts are more procedural, architectural, and philosophical than anything else.

Lane Desborough, marketing manager at Honeywell, Phoenix, Ariz., says everything is integrated today. Dividing it up could cause problems. "Let's say you have control algorithms in the valve tops, and the brains and alarm notifications are distributed out into a thousand places around the plant," he posits. "Where is the guarantee that these controllers are working toward a common purpose, such as making money? What happens if the business objective suddenly changes from maximize throughput' to minimize energy consumption'? How are they coordinated in such a way as to notify the operator, maintenance planner, technician, and engineer when their performance degrades and is no longer consistent with business objectives?"

Desborough continues with a litany of problems: "What happens if one loop is tuned too tightly, causing it to oscillate, and this oscillation process propagates to another loop? Is the first loop smart enough to detect the fact that it's influencing the behavior of the other? Is the second smart enough to not cry wolf' and send an alert to the operator that it needs attention? Is either loop smart enough to realize it is not critical to the process and should not be alerting the operator as to its performance?"

He goes on, listing several problems that are easily solved with networks, centralized control, and advanced supervisory software.

Blending in Single-Loop Control

No one is saying we should revert completely to the good ol' days of single-loop controllers operating completely alone. Putting control in the field is a good idea for several reasons, but no one has ever advocated getting rid of the centralized supervisory control systems, HMIs, expert tuning systems, and all the other support software such as asset management, ERP, MES, scheduling, and so on.

"A modern digital architecture combines the reliability of single-loop controllers with the flexibility to do advanced control in the field or in a controller," says Krouth. "You can combine regulatory and a great deal of advanced control in the field devices, and use the advanced strategy and optimization in the central control system to generate setpoints, constraint limits, change gains, and so on."

Some of those who have been working with fieldbus understand TrDC reasonably well. For example, Luis Trejo, a product manager at Emerson Process Management in Mexico, likes TrDC. "In my local office, we have integrated more than 50 systems with fieldbuses, control in the field, and communications to corporate networks," says Trejo. Applications include paper mills, industrial and power boilers, chemical plants, food and beverage, and oil production. "We are getting pretty close to TrDC, and I have always wanted to get there."

"Integrating single-loop entities through a centralized database for optimization gets benefits from both worlds," says Verhappen, who installs fieldbus systems. "TrDC and its single-loop integrity lets you minimize the impact on the control system of a single point of failure, while providing the capability for optimizing across multiple loops in a centralized environment.

"I think we have to be clear on the difference between distributed control and distributed I/O," continues Verhappen. "Many of the TrDC solutions are really only distributing I/O by putting the PLC or smarts in a hardened box in the field. My take is that vendors are doing this to circumvent the wire savings attributed to fieldbus systems by shortening the field wire run to keep market share. Mind you, all of them are doing it, so it must be working."

"There will always be a tension between distribution vs. centralization," says Bullerdiek. "The correct answer will depend on the process or system to be controlled and what the user wants to achieve with the system. There is not, and never was, one correct answer. It is nice to see that the technology is finally getting to the point where we can pick solutions to fit our needs instead of having to force fit our needs into the available solutions. It makes the up-front designer job more difficult, but the improved performance/cost ratio will pay off."