Roots of PLCs and DCSs

Many of us have been around process automation for decades. We also have new folks joining our ranks every day. It’s for the new members of the global process automation community that I share a presentation given by Emerson’s Gordon Lawther at the ChemInnovations conference last fall. The presentation, The Evolution of PLCs and DCSs, provides the historical roots, historical strengths and applications, and advancements over time.

The genesis of the PLC [programmable logic controller] goes back into the 1960s. General Motors had to put great effort into changing their factory automation over before the introduction of the new model year. Automation was done with relays, cam timers, and drum sequencers. Electricians had to spend significant time rewiring.

For those that have not had the pleasure of meeting the world-famous PLC inventor, Dick Morley, you may find the opportunity to meet him at industry events such as ISA Automation Week, ISA Marketing & Sales Summit, etc. As described in his Wikipedia entry:

Richard (Dick) Morley is known as the “father” of the programmable logic controller (PLC) since he was involved with the production of the first PLC for General Motors, the Modicon, at Bedford and Associates in 1968.

By moving the logic from discrete devices to software, it significantly reduced the time to rewire discrete manufacturing processes at General Motors and other manufacturers.

Click to enlarge

Click to enlarge

Gordon summarized some generalizations of early PLCs: inexpensive, easy to use, small and modular, mostly programmed/maintained by in-house staff, minimal operator interfaces, and predominantly used in unattended operations. The architecture was composed of a card rack with central processor and I/O cards connected to plant floor devices. A programming terminal was connected to the PLC to download the control software, written in ladder logic.

Over time, this architecture grew to include peer-to-peer communications among PLCs, operator workstations, remote I/O, etc. Even later came redundancy, additional software such as historians, batch processing, and support for bus networks.

As it was designed for discrete applications, the PLC had execution rates to less than 10msec to support applications such as turbomachinery, pulse counters, and safety shutdown applications. Sequencing was another class of applications for materials movement, packaging lines, and robotics to name a few. PLCs were also well suited for skid-mounted systems such as air compressors, chemical additives, and mixers.

Click to enlarge

Click to enlarge

DCSs [distributed control systems] grew out of the process industries [where fluids flow through pipes]. These include continuous processes found in oil and gas production and refining, chemical plants, and metals and mining processes. Also, they were designed for batch processes typically found in industries such as pharmaceuticals, biotech, and specialty chemicals. Process variables such as flow, temperature, pressure, and level needed to be closely controlled, especially in complex processes such as distillation, fermentation, reactors and heat transfer applications.

Instead of relays, DCSs replaced pneumatic controllers where the control loop relied upon compressed air. Instead of the headache of wiring, the DCS solved the headache of manifolds and air tubing to all the controllers.

The DCS had integral I/O cards with closed loop control performed in a controller’s central processor. Programming languages were based on assembly language, FORTRAN, and other early logic languages. Process variables, setpoints, valve outputs, and other parameters were displayed in tabular displays and faceplates that were somewhat like the panel board pneumatic controllers they superseded. Controllers and operator workstations were connected together through a communications bus.

Gordon noted some of the early generalizations surrounding DCSs: expensive, very large systems, complex application requirements due to complex process control challenges, proprietary technologies for operator interfaces, communications, programming tools, redundancy for high availability applications, services/training provided by DCS manufacturer or 3rd party. Also, it was designed for attended operations where operators supervise the process to keep production and product quality on target.

The inherent strengths of DCS architectures are that that they scale large enough to manage entire plants with tens to hundreds of thousands of I/O. They provide tight integration between the operators and the process. They have built in functions and standard libraries to manage complex continuous and batch control and provide a common database to streamline the management of engineering functions. Redundancy extends across the architecture—power, networks, controllers, I/O modules, etc.

Many industries such as food & beverage and the Life Sciences industries have requirements for regulatory control and high-speed discrete automation. DCSs and PLCs were connected together via serial interfaces such as RS232 / 422 and OPC. Over time, the PLCs and DCSs have acquired strengths from each other. Technologies and open standards have evolved to help these increased capabilities—high-speed networks, open protocols, industry standard programming languages (IEC 1131), PC-based operator stations, Microsoft operating systems, standard I/O busses, redundancy, and comprehensive services.

Now most systems, regardless of their roots, have fully redundant hardware architectures, digital I/O busses, integrated safety systems, asset management and optimization, advanced process control (APC), high-performance human machine interfaces (HMI), advanced batch management, and connectivity with operations management/manufacturing execution and enterprise resource planning (ERP) systems. Innovations such as electronic marshalling continue to occur to advance the capabilities of these systems.

The focus for process manufacturers when evaluating alternatives is on architecture robustness, ease of use (operations, engineering, maintenance, and plant management), security, services and local support, and industry & application project experience and track record.

MP3 | iTunes

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

Update: Udemy has a great PLC infographic. Check it out:

3 comments

  1. Hey PJ – I agree with the points you make. In addioitn, I believe the Stuxnet worm should make us rethink plant safety designs. In my books, digital safety systems should be air-gapped from operations systems, and mechanical safeties should be designed to make catastrophic malfunction impossible. Safety systems are currently evaluated on a probabilistic basis – what is the likelihood that enough components will fail simultaneously in a way that could cause catastrophe? Safety systems need to start being evaluated from an adversary’s perspective: is there a set of components, which if destroyed or caused to malfunction simultaneously, can cause a catastrophe?In your example of a reaction tank with feeds from two different and incompatible chemicals for example – is there a mechanical safety system that can ensure that both valves are not open simultaneously, and that the tank is empty of all inputs before the source of inputs is switched?I fear, though, that mechanical design changes like this are prohibitively expensive as a retrofit, and will be considered only for new plants. But to me, this kind of design is part of the future of security at chemical facilities. The worst consequence that a worm, or even an insider with access to the control system, should be able to produce is denial-of-service: triggering a safety shutdown. The air-gapped digital safeties and the mechanical safeties should be designed to prevent any more serious consequences.

  2. Aya, I’m sorry I somehow missed your thoughtful and insightful comments. And Don, thank you for sharing that infographic.

Leave a Reply