This is the last in a three-part series on programmable logic controllers by Armand L. Rogado, Senior Electrical Engineer for KHNP/ KOPEC - Ed.
X. Communications
XI. Distributed Control System (DCS)
A DCS refers to a control system usually of a manufacturing system, process or any kind of dynamic system, in which the controller elements are not centralized in location (like the brain) but are distributed throughout the system with each component sub-system controlled by one or more controllers. The entire system of controllers is connected by networks for communication and monitoring.
XII. Elements
A DCS typically uses custom designed processors as controllers and uses both proprietary interconnections and protocols for communication. Input & output modules form component parts of the DCS. The processor receives information from input modules and sends information to output modules. The input modules receive information from input instruments in the process (a.k.a. field) and output modules transmit instructions to the output instruments in the field. Computer buses or electrical buses connect the processor and modules through multiplexers/de-multiplexers. Buses also connect the distributed controllers with the central controller and finally to the Human-Machine Interface (HMI) control consoles or Process Automation System.
Elements of a distributed control system may directly connect to physical equipment such as switches, pumps and valves or may work through an intermediate system such as a SCADA system.
XIV. Applications
Distributed Control Systems (DCSs) are dedicated systems used to control manufacturing processes that are continuous or batch-oriented, such as oil refining, petrochemicals, central station power generation, pharmaceuticals, food & beverage manufacturing, cement production, steelmaking, and papermaking. DCSs are connected to sensors and actuators and use setpoint control to control the flow of material through the plant. The most common example is a setpoint control loop consisting of a pressure sensor, controller, and control valve. Pressure or flow measurements are transmitted to the controller, usually through the aid of a signal conditioning Input/Output (I/O) device. When the measured variable reaches a certain point, the controller instructs a valve or actuation device to open or close until the fluidic flow process reaches the desired setpoint. Large oil refineries have many thousands of I/O points and employ very large DCSs. Processes are not limited to fluidic flow through pipes, however, and can also include things like paper machines and their associated variable speed drives and motor control centers, cement kilns, mining operations, ore processing facilities, and many others.
A typical DCS consists of functionally and/or geographically distributed digital controllers capable of executing from 1 to 256 or more regulatory control loops in one control box. The input/output devices (I/O) can be integral with the controller or located remotely via a field network. Today's controllers have extensive computational capabilities and, in addition to proportional, integral, and derivative (PID) control, can generally perform logic and sequential control.
DCSs may employ one or several workstations and can be configured at the workstation or by an off-line personal computer. Local communication is handled by a control network with transmission over twisted pair, coaxial, or fiber optic cable. A server and/or applications processor may be included in the system for extra computational, data collection, and reporting capability.
The DCS largely came about due to the increased availability of microcomputers and the proliferation of microprocessors in the world of process control. Computers had already been applied to process automation for some time in the form of both Direct Digital Control (DDC) and Set Point Control. In the early 1970's Taylor Instrument Company, (now part of ABB) developed the 1010 system, Foxboro the FOX1 system and Bailey Controls the 1055 systems. All of these were DDC applications implemented within mini-computers (DEC PDP 11, Varian Data Machines, MODCOMP etc) and connected to proprietary Input/Output hardware. Sophisticated (for the time) continuous as well as batch control was implemented in this way. A more conservative approach was Set Point Control, where process computers supervised clusters of analog process controllers. A CRT-based workstation provided visibility into the process using text and crude character graphics. Availability of a fully functional graphical user interface was a way away.
Central to the DCS model was the inclusion of control function blocks. Function blocks evolved from early, more primitive DDC concepts of "Table Driven" software. One of the first embodiments of object-oriented software, function blocks were self contained "blocks" of code that emulated analog hardware control components and performed tasks that were essential to process control, such as execution of PID algorithms. Function blocks continue to endure as the predominant method of control for DCS suppliers, are supported by key technologies such as Foundation Field bus today.
Digital communication between distributed controllers, workstations and other computing elements (peer to peer access) was one of the primary advantages of the DCS. Attention was duly focused on the networks, which provided the all-important lines of communication that, for process applications, had to incorporate specific functions such as determinism and redundancy. As a result, many suppliers embraced the IEEE 802.4 networking standard. This decision set the stage for the wave of migrations necessary when information technology moved into process automation and IEEE 802.3 rather than IEEE 802.4 prevailed as the control LAN.
Conclusion
The effectiveness of selection between PLC vs. DCS depends on understanding the functionality application that will minimize automation cost investment for the benefit of the customer and owner. The challenge ahead of most manufacturers in automation technology is identification of process definition of the project, its component database, and specific system application.
About the Author
Armand L. Rogado, P.E., is a senior electrical engineer in the Electrical Engineering Department working for KOPEC. He has worked in several nuclear and combined cycle power plants in the US, Iraq, Philippines, Saudi Arabia and So. Korea as Nuclear Safety Engineer, Project Manager, Project Construction Engineer, Startup System Engineer, PLC&DCS Instrument & Control Engineer, and Maintenance Electrical Engineer for the past 35 years. He is a registered professional engineer and INPO Certified System Engineer for PWR and BWR Nuclear Power Plant.
