The changing drivers of DCS development

Now that distributed control system (DCS) technology is moving into middle age, the nature of what users want from it is evolving. Enough maturity may avoid a mid-life crisis.


Solvay’s PVC polymerization plant at Tavaux, France, uses Emerson’s Charms with DeltaV version 11. Courtesy: EmersonThat industrial citizen, the distributed control system (DCS), has reached the age where it needs to take stock of its accomplishments so far and decide what's next. Born around 1975, this technology is certainly mature and has many years to go before retirement. Let's reflect on its life so far.

Forty years ago, more or less, this technology was launched as several automation original equipment manufacturers (OEMs) brought out similar platforms at roughly the same time. Which company released what and when exactly isn't critical to this discussion. Suffice it to say the platforms had a high degree of similarity and covered much of the same space. Early adopters among oil refiners, chemical plants, and other traditional process industries used them to replace panel boards, pneumatic, and electronic analog controllers. Many of those early platforms are now only memories, although some companies continue under the same banner.

The systems were purposely built around proprietary hardware and software, using hard-wired input/output (I/O) field devices. Operators got their information on monochrome cathode ray tube (CRT) displays using keyboards and maybe proprietary tablets. What seems now to be hopelessly outmoded was, at the time, the height of adaptability.

For as crude as the computer software was at the time, the DCS's number crunching capability was pretty sophisticated. Algorithms to control loops were reliable, and most of the time these platforms worked pretty well and could keep even complex processes on an even keel. Many of these early systems operated for decades, and with a little critical maintenance from time to time, some are still working today.

Evolutionary process

Over the years, DCSs evolved in many ways, but some of the basic underlying concepts remained static. Some of those improvements include:

  • Operator interaction with human-machine interfaces (HMIs) grew more sophisticated as graphic capabilities got better and a greater sense of how operators access information grew.
  • Operator interaction spawned studies of how operators work in abnormal situations, further improving operator effectiveness.
  • I/O supporting field devices added digital mechanisms to increase the amount of information available.
  • Asset management platforms helped improve reliability by making the connection with maintenance more direct.
  • Open off-the-shelf hardware replaced proprietary equipment, although to many, this proved to be a mixed blessing.
  • Alarm management became an industry in its own right.
  • Support grew more sophisticated for integration with larger enterprise networks to allow information transfer, but with it came the whole new issue of cyber security.
  • Procedural automation, still a relatively new development, has taken a growing role in helping operators get through startups, shutdowns, and other situations where safety incidents can happen. 

Similar implementation

In spite of all these improvements, the mechanisms for designing and implementing a system didn't really change:

  • Field devices were still hard-wired to the DCS I/O through junction boxes and marshalling cabinets.
  • Each of these had its own terminals, meaning there could easily be 15 points where wires were terminated, introducing points where communication could be lost.
  • Field devices only could communicate with the controller to which they were connected.
  • New capabilities added to controllers and field devices often served only to make them more complex and difficult to configure.
  • Programming was written largely from scratch and could not be implemented until the hardware was installed because it had to reflect the final configuration.

So long as projects remained relatively simple, the traditional approach worked, and users tolerated its shortcomings. Some plants adopted fieldbus networking to mitigate the field wiring problems, but in the greater scheme of things, those numbers were small. 

Lacking standardization

Over the years projects and their resulting DCSs became more complex and more expensive. The costs of large projects grew higher, and companies often saw their new plant waiting to start up, delayed by final adjustments to the automation platform. It did not take long for companies to realize how much money was being lost each day, never to be recovered. Systems were too hand-built, lacked standardized components, and were too engineering intensive.

Automation engineers found themselves in the crosshairs when their systems were the last thing standing in the way of startup and realizing revenue. In spite of all the improvements over the years, to the thinking of many users, the DCS at age 35 was fat and out of shape, but there was no practical alternative. The customers said, "There has to be a better way." The vendor companies had to get this couch potato back into condition.

"For us it started about five years ago with electronic marshalling," said Roger Freeman, vice president of Emerson Process Management's project management office. "That was followed by virtualization of the entire DCS, not just the workstations, but the controllers and I/O controllers, so that the whole engineering side could be done independently of the hardware platform. The whole thing became more flexible at a lower cost."

The key realization, made by Emerson and others, was that the process of designing and implementing a DCS was far too linear. Main steps had to take place in a serial fashion, each waiting for completion of the one previous. Any delays added to the overall timeline, pushed out the ultimate startup of the plant, and resulted in lost value. Late changes required by process engineers made the situation worse since they could not be anticipated.

"The whole idea of LEAP [Honeywell's lean project management program] is to separate functional design from physical design and bind them at the very end," said Jack Gregg, Experion product marketing director for Honeywell Process Solutions. "It's the perfect scenario for new installations, but can also be applied to brownfield projects." 

<< First < Previous 1 2 Next > Last >>

Anonymous , 12/08/15 07:33 AM:

Not only do each hardwired device have its own terminals, each hardwired device has many terminals because each signal of each hardwired device requires a pair of terminals plus an I/O channel in the DCS. On average devices have about 3 I/O signals each i.e. 3 pairs of terminals on a device. Simple pressure and temperature transmitters only have a single signal, but more advanced devices like flow meters, level transmitter, control valves, on-off valves, and electric actuators have many signals each. That is, hardwiring requires on average 3 pairs of wires per device and 3 I/O card channels per device. Multiply the number of signals by the number of connection points from the device to the I/O card. This is what makes hardwiring so costly. Digital networking like fieldbus solves this problem:

I personally believe it is about time to retire 4-20 mA and on-off signals and instead use digital networking for field instruments. Automation has to go digital so that it can enjoy the same transformation as digital phones, digital photography, emails, TV, music, movies, and online news etc. The number of plants with digital networking like FOUNDATION fieldbus is steadily growing.

Digital networking provides more design flexibility than hardwiring precisely because it is not “hard” (rigid). Digital networking uses virtual communication relationships. You can have many virtual I/O signals over a single pair of wires. For instance, a valve may have 3 I/O signals traveling over a single pair of wires. That is, devices can be added to the network, and more signals can be enabled in devices, without laying more cable or adding I/O channels in the DCS. A design for an on-off valve can easily be changed to control valve or electric actuator / motor operated valve (MOV) without redesigning the signal wiring or changing I/O. Therefore, when designing, only a rough estimate of number of devices is required, not the exact I/O count and I/O type for each tag. With digital networking it doesn’t matter how many signals the device has, or if they are inputs or outputs, or if they are analog or discrete.
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
The System Integrator Giants program lists the top 100 system integrators among companies listed in CFE Media's Global System Integrator Database.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
This eGuide illustrates solutions, applications and benefits of machine vision systems.
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Motor specification guidelines; Understanding multivariable control; Improving a safety instrumented system; 2017 Engineers' Choice Award Winners
Selecting the best controller from several viewpoints; System integrator advice for the IIoT; TSN and real-time Ethernet; Questions to ask when selecting a VFD; Action items for an aging PLC/DCS
Robot advances in connectivity, collaboration, and programming; Advanced process control; Industrial wireless developments; Multiplatform system integration
Motion control advances and solutions can help with machine control, automated control on assembly lines, integration of robotics and automation, and machine safety.
This article collection contains several articles on the Industrial Internet of Things (IIoT) and how it is transforming manufacturing.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Future of oil and gas projects; Reservoir models; The importance of SCADA to oil and gas
Big Data and bigger solutions; Tablet technologies; SCADA developments
SCADA at the junction, Managing risk through maintenance, Moving at the speed of data
Automation Engineer; Wood Group
System Integrator; Cross Integrated Systems Group
Jose S. Vasquez, Jr.
Fire & Life Safety Engineer; Technip USA Inc.
click me