Want to Go Back?

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."

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?"