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.
By Peter Welander October 14, 2015

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

It begins with I/O hardware

Honeywell’s Universal I/O will work with Experion series C. Courtesy: Honeywell Process SolutionsField wiring and I/O were major contributors to the problem because they had to be configured for the specific site. If field device A had to connect to Controller 3, the cable had to follow whatever path necessary to tie together those points, and if anything had to be changed, the adjustment was time consuming and expensive. Emerson, Foxboro, Honeywell, and Yokogawa all created systems using configurable standardized I/O hardware with field-mountable cabinets.

With more hardware standardization, more elements of the DCS could be designed at the same time. Programming could be written independently of the hardware. Serial development gave way to parallel activity. Rigid design elements gave way to flexibility. 

New list of challenges

The change in approach has changed the way customers and vendors discuss projects. Questions now are not so much whether the system can control the process. That aspect is taken for granted. Discussions now center on many of the newer capabilities along with purchase cost, lifecycle cost, complexity, speed of deployment, stability, adaptability, and longevity. Companies want predictable installation or upgrade projects because so much hinges on maintaining production.

"The pressure on time with a brownfield project is stronger in many ways than it is with a greenfield project," said Claudio Fayad, marketing director, DeltaV platforms for Emerson Process Management. "Refineries are stopping every 6 or 7 years, and they stop for 30 days. The pressure is to make the automation project predictable, regardless if it’s a greenfield, an upgrade, or modernization. It’s part of all those conversations." 

Adding the human element

For many years, DCS design discussions focused on technology. Naturally operators were part of the picture, but often secondarily. With all the aspects of the changing workforce emerging, people are becoming a larger element. Suppliers are changing the way operators interact with the systems based on human factors, and often this extends to how operators interact with each other. There is a far greater emphasis on collaboration human to human, and this can be in the same control room or two people on different continents helping each other out. New technologies support this kind of interaction.

"The new HMI solutions came about through observation of operators and how they work," Gregg explained. "Our new console was designed for the operator who sits there for 12 hours controlling a volatile process and be asked at the 11½ hour to make a critical decision. So we asked, ‘What can we do to help that operator stay alert, be aware, and be responsive?’ Part of the answer was the design of the furniture, but also new ways for the operator to look at the process." 

Flexibility for the future

One truly universal aspect of this discussion is longevity. While most computer-based equipment has a lifespan of a few years, control systems are measured in decades. Any company installing a new system has to be thinking out 20 years or more, with both the vendor and user considering the implications of decisions on that basis. Adaptability and flexibility need to be included because nobody really knows what changes might need to be made years down the road.

"We used to have a very defined mental model about the control system, and there was not a lot of ambiguity," Fayad recalled. "Now you can do so many things and in so many different ways. You can bring I/O on a bus, hard-wired, wireless, or hybrid. The tools were only about control, now they’re about control, operations performance, maintenance, project efficiency, so we have to help people understand those differences and what they mean to work processes. Users want these operational benefits without facing risk."

Marjorie Ochsner, senior marketing manager at Honeywell Process Solutions works with customers during DCS migrations and sees what old systems can look like after many years of constant use.

"Many of our customers have infrequent turnarounds only every several years, so the stability of their control system is core to their business," Ochsner noted. "So when you talk about investing in and implementing new valuable innovations, we are always looking for ways to bring our customers forward without shutting down the process. We call this continuous innovation," she said.

Our friend the DCS is still a solid citizen, and now reaching middle age, is ready to take on ever increasing challenges while delivering systems with greater simplicity and flexibility. Mid-life crisis averted, although there are still occasional thoughts of buying a Corvette.

– Peter Welander is a contributing content specialist for Control Engineering, pwelander@cfemedia.com.

Key concepts:

  • After 40 years, key DCS design elements have not changed significantly.
  • Customers are driving DCS vendors to develop more standardized designs for more predictable project execution.

Consider this

Is your plant still waiting for a modern DCS? Have you quantified the costs of waiting?

ONLINE extra

See links to related articles on this topic below.

Want this article on your website? Click here to see how ContentStream® can make that happen.