PLC vs. DCS - Competing Process Control Philosophy
By Bill Lydon, Editor
The idea of using a PLC-based system rather than a Distributed Control Systems (DCS) has become a philosophical and technical debate in the industry. Distributed Control Systems (DCS) have been the primary solution for process automation but now many PLC vendors are pursuing these applications arguing that a single integrated architecture based on PLCs and/or PACs (Programmable Automation Controllers) is the best approach to total plant automation. In turn, there are DCS vendors that have introduced PLC and PAC products as offerings. The primary logic offered for using a single PLC-based system rather than a DCS for process functions along with PLCs for discrete functions is to have one control architecture for the entire plant. The premise is this offers the best of both worlds. In this article the term PLC will include PAC.
Process Plant Control
The majority of process plants today have both DCSs and PLCs installed for controls. The DCSs generally control and manage the core processes (food, pharmaceutical, refining, etc.). PLCs are used to control non-core process functions including material handling, water treatment, motor controls, balance of plant operations, air compressor controls, packaging, and other functions. There are plants where PLCs or DCSs control all of the plant functions but at this point these are the exceptions.
DCS systems have for many years provided multi-disciplined controllers for logic, sequential and process control, HMIs, custom applications, and business integration on one platform.
Although PLCs have become more powerful, they are still based on “loose” component architectures allowing functions to be easily added with hardware and software. For example, a historian may be added to many PLC products by plugging a module into the backplane that acquires data from the controllers, but history communications is done over a separate Ethernet connection.
Configuration vs. Programming
The DCS from its inception has been designed for configuration as opposed to PLCs which started with a general programming model. DCS configuration uses standard control objects that are automatically linked to the appropriate faceplate, simplifying configuration and leading to standardization. When configuring a tag, everything required is there to connect it to a field point and apply alarm logic, history, version control and other functions, saving time and improving quality. For example, if you have a two input, one output valve, there is a function block library so you don’t have to create the logic from scratch. PLC suppliers have been developing new configuration software to provide this level of integration.
Technology Levels the Playing Field
Today with open technologies, DCS systems are competitively priced with PLCs. Ten years ago there was a marked difference in the cost of technologies used in DCS controllers and PLCs but with processors, memory, embedded software, and communications commoditization, this has become insignificant for new offerings from all vendors. The everyday use of our smart phones, iPads, and electronic games decreases the cost of increased computing power. This is driven by increased unit volume production of processors and related components. Consider that mobile phone shipments in 2010 were 1.39 billion, up 18.5% from the 1.17 billion units shipped in 2009.
Integration with the enterprise is becoming very important to improve operations and maximize asset management. DCS systems have tied into the enterprise for years, conforming to the Purdue Model and more recently the ISA95 standard. This level of sophistication came later for discrete PLC applications. Virtually all DCS and PLC manufacturers’ software is based on Microsoft technologies with standard software interfaces to business enterprise systems for information interchange and synchronized operations.
Asset management is becoming more important and PLCs are playing catch up with DCSs to provide integrated software for a full range of devices and asset management standards.
APC Advanced Process Control
Process optimization is another area where traditional PLCs may be lacking when compared to a DCS, which will typically offer a number of tools for optimizing control loops and more advanced alternatives to improve performance of PID control. PLCs are adding these functions with their push into process control.
Total Production Optimization
Real-time software modeling and control optimization is an emerging function being provided to achieve higher efficiencies by DCS suppliers. This level of optimization is high level, multivariable control based on real-time business management goals, actual feedstock information, production demand, and energy costs - all in an effort to optimize plant profits. Accomplishing this with PLC-based systems at this time can be approximated with loosely coupled software add-ons.
Skid & Packaged Systems
PLCs on skid mounted and packaged systems for process plants are creating control and automation problems. Skid mounted and packaged systems are factory built units that provide a specific function needed in a plant. The controls and automation on a skid become part of the plant just as much as site installed controls and automation. The dilemma is that many skid vendors have typically standardized on one brand and model of PLC controller and the plant is using another vendor. Ideally the plant process control system has efficient and cost effective multiprotocol interfaces for all PLC protocols. These interfaced subsystems generally require more field engineering to configure and maintain than the other plant controls.
Sensor/Control Network Communications
The need to connect to multiple industrial networks is a necessity and virtually all process plants utilize multiple discrete and process industrial networks including DeviceNet, Profibus, PROFINET, EtherNet/IP, Modbus TCP, HART, and Foundation Fieldbus. DCSs have highly refined and integrated interfaces to Foundation Fieldbus and HART and adequate interfaces to other industrial automation networks. PLC systems tend to have less refined interfaces to Foundation Fieldbus and HART. In many cases they rely on third party hardware and software with configuration being more labor intensive. Oddly the discrete network interfaces can be an issue with PLC systems since there are many standards and larger vendors optimize the interface and software configuration to their flagship protocols and have weak interfaces to competitive protocols. These other protocol interfaces are typically accomplished with third party interfaces where the software configuration is more cumbersome.
DCS Backbone Network
DCS backbone networks are typically standard Ethernet hardware but use their own closed,high-performance protocols and natively support redundancy. In DCS systems, the process networks (Foundation Fieldbus, HART) and PLC-oriented networks (DeviceNet, Profibus, Modbus, etc.) are connected to controllers, which are connected to the process DCS backbone. PLC systems use open published protocols that are designed to cover a wide range of applications including simple discrete, synchronized motion control, motor control, and process.
Many process control systems require redundancy for I/O, controllers, networks, and HMI servers at various levels. The level of controller redundancy for higher level process applications is new to PLC suppliers and they continue to add options for redundancy. DCS systems generally have easier to apply redundancy solutions but the open networking standard groups such as ODVA and PI International have defined solutions for their protocols particularly with the initiatives for networked machine safety.
An advantage often cited by PLC vendors is that all control functions can connect to one Ethernet backbone (process control, discrete, motion control, safety; etc.) In my opinion, this is not a rational engineering approach when configuring plant systems for performance and reliability.
Thoughts & Observations
It sure looks like the PLC vendors who advocate a single control architecture for process plants are essentially creating a DCS system built around their hardware and software components. These PLC vendors are continually demonstrating how their software is like a DCS. In an interview early in 2011 with a business manager at a major PLC company who is pursuing the process business, I asked what distinguishes their offering from a DCS. He responded by rephrasing the question, noting the real question should be what distinguishes their PLC-based DCS from other DCS systems. Following this logic, the decision is between the new PLC-based DCS and traditional DCS offerings.
As this unfolds, both DCS and PLC suppliers will evolve and we may eventually see a new architecture but in the meantime plants need to continue to operate and improve.
Should the goal be a single unified architecture?
I suggest, rather than accepting a suppliers definition of a single unified architecture, that you create a definition for your operations. As part of this process you might think about how open architectures have changed the game, providing you with more options and requiring vendors to be more competitive. These are some questions to consider:
- Does the system reduce engineering time for my applications?
- Does the system reduce process control configuration time?
- Does the system support the industrial network interfaces I need now and in the future?
- Does the system support the enterprise software interfaces I need now? (SAP, Oracle, etc.)
- Does the system support interfaces to my legacy systems?
Most systems can answer yes to these questions, so you need to quantify these characteristics to make solid decisions.
Don’t buy an impression….kick the tires.
I have never understood how engineers that would never buy a new automobile without looking under the hood and taking test drives will buy an automation system based on vendor demonstrations and PowerPoint presentations. Selecting the right system for your operations requires complex analysis, with a number of considerations, based on production processes, in-house capabilities, and other factors. The time and cost of integration is significant over the life of a system and should be examined as part of the analysis. I suggest having your own control engineer(s) configure some control loops, sensors, I/O configuration, HMI screens, and communications – specific to your applications - for each system under consideration. This can be accomplished with a demonstration system provided by vendors, including controller hardware. This investment upfront can save a large amount of money and lost production time over the life of a system. If the vendor tells you this can only be done by taking a training course on their product, don’t walk…run away from this supplier.
One thing is clear, process users are getting more options to consider.
Many agree that the beginning of the DCS started with the introduction of the Honeywell TDC 2000 in 1975. It was the first system to use microprocessors to perform direct digital control of processes as an integrated part of the system. This distributed architecture was revolutionary with digital communication between distributed controllers, workstations and other computing elements. Computer-based process control systems before the TDC 2000 were mainly data collection and alarm systems with controlled done by pneumatic loop controllers and standalone electronic PID controllers.
The PLC was invented in response to the needs of the American automotive manufacturing industry primarily to replace thousands of relays, cam timers, and drum sequencers. The big advantage was that programmable logic controllers could be reconfigured with software programming rather than rewiring control panels. The automotive industry is still one of the largest users of PLCs.
PACThe term Programmable Automation Controller (PAC) has been used for over eight years with a few companies claiming to have invented the term. The term refers to more powerful controllers, but the term PAC continues to be imprecise with vendors and analysts each having a different spin on the term. Wikipedia provides this definition: A programmable automation controller (PAC) is a compact controller that combines the features and capabilities of a PC-based control system with that of a typical programmable logic controller (PLC). PACs are most often used in industrial settings for process control, data acquisition, remote equipment monitoring, machine vision, and motion control. Additionally, because they function and communicate over popular network interface protocols like TCP/IP, OLE for process control (OPC) and SMTP, PACs are able to transfer data from the machines they control to other machines and components in a networked control system or to application software and databases.
Back to top
- Industrial Internet Consortium: Another Industrial Internet of Things (IoT) Organization
- EtherNet/IP & DeviceNet Network Updates
- Security Cycle of Awareness
- Cyber Security - Protecting Automation Controllers
- Industry 4.0 - Only One-Tenth of Germany's High-Tech Strategy
- Roxtec Releases Free Transit Designer 2.0 software
- Expansion of Oil, Gas and Energy drives Automation and Control Market
- Life Cycle Engineering used OSIsoft for Real-time Asset Management
- ISA releases conference program for Cybersecurity Conference
- Feed manufacturer reaps rewards of totally integrated automation