DCS abbreviates Total Distributed Control System: distributed control danger, centralised management and display. In the late 1960s the Programmable Logic Controller (PLC) was developed for logic operations, applied first in car manufacturing. In the mid-1970s DCS handling analogue control reached the market, replacing analogue instrument control based mainly on PID computation; the idea came first from instrument makers (then serving the chemical industry), later the computer industry joined DCS development.
In the 1970s microcomputer technology was immature; DCS vendors developed their own operator stations, controllers, I/O boards and network interfaces — everything proprietary.
In the early 1970s some replaced centrally mounted analogue instruments with minicomputers such as the PDP-11/24, with multitudes of cables to the control room. Using the minicomputer as controller and its CRT as display, one machine received thousands of transmitter signals and computed hundreds of loops — danger was rather concentrated: as many cables as analogue instruments ever needed, and if the machine failed both control and display died. Digital control disappointed.
Then came the idea of separating control from display: one computer computes, another displays. A process may need many displayed and controlled points, some with closed-loop or logic operation; process parts are relatively independent, divisible into stages whose I/O points are distributed across several or dozens of computers (controllers) — one machine failing no longer affects the whole: the "wolves replacing the tiger" tactic, i.e. distributing the danger. Display, operation and printing management were centralised, and a network joined the control and display halves into one system — the "distributed system".
How far should danger be distributed? That depended on the computer technology of the day. In the mid-1970s full distribution meant one controller per loop. Unfamiliar with digital technology and used to analogue instruments, the industry favoured loop controllers in the late 1970s and 1980s: digital controllers made to look exactly like analogue instruments — same operating habits, PID digitalised inside — one instrument per loop. Expensive, but the danger was distributed; a communication network then joined the controllers and CRT-based interfaces, usually in a star topology. Loop controllers cost too much to make — poor price/performance; two-loop and four-loop controllers followed with slightly better ratios. For medium and large systems DCS beat loop-controller systems on price/performance, though some special spots still used loop controllers.
With too many loops — thousands of points, hundreds of loops in one controller — danger concentrated again and had to be distributed. As computing advanced in power, memory and reliability, one computer could take on more, concentrating tasks somewhat; and controller/network redundancy matured, allowing more concentration too.
In today's DCS one controller runs dozens of loops plus hundreds of acquisitions and some logic — proven good in the field. That raises controller upgrade questions. When controllers sit far from sensors, fieldbus advanced: CAN, LONWORKS, FF buses and HART protocol input boards all entered DCS.
DCS has three parts: controllers with I/O boards, the communication network, and the human-machine interface (HMI). I/O boards connect through terminal boards to the process, reading sensor signals. I/O board types, each with its terminal board:
Every I/O board sits on the I/O bus. For signal safety and integrity, signals are conditioned before entering — limit checks, temperature compensation, filtering — on the terminal board or separately; such boards are now called signal-conditioning boards.
The I/O bus connects to the controller. In the 1980s controller power was weak, so to raise I/O counts the controller's tasks were split into three types: closed-loop controllers, analogue acquisition units and logic processors, each with its own I/O bus — varying among DCS. For speed prefer parallel buses; serial buses are commoner, especially RS-485. Acquisition units and logic processors can carry more I/O.
Closed-loop controllers, acquisition units and logic processors may connect directly to the network with the HMI, each controller an independent node with its own functions and network interface. Some DCS save network ports by pre-connecting all process-control equipment on a control bus — the process station — raising its I/O capacity and saving ports, then linking to the network and HMI through one interface. As computers improved, PC-based controllers grew powerful, handling analogue and logic alike — one controller, one network node, connected to the HMI over the network.
The controller is the DCS core — essentially a PC (some DCS controllers literally are PCs). It holds CPU, RAM, E²PROM and ROM chips plus two interfaces: one downward to the I/O bus, one upward to the network and HMI. ROM stores the control algorithms (some DCS call it the function-block library): PID, PID with dead band, integral-separation PID; arithmetic add/subtract/multiply/divide/square/root; functions — first-order filter, sine, cosine, X-Y generator, lead-lag; advanced — Smith predictor, C interface, matrix add/multiply; logic AND/OR/NOT/NAND. Station function blocks bind analogues, digitals and the human together. More function blocks mean easier user configuration: per process requirements the user links blocks into a control scheme stored in E²PROM — erasable, since schemes change with the process. Different users, different schemes. In configuration the user picks blocks, fills parameters, links them and stores the scheme; then the controller runs. Controllers carry an operating system, configuration software and communication software.
For safe operation closed-loop controllers are always redundant — one in use, one hot standby. For successful redundancy: identical hardware and software versions; check the send-receive chips; check the redundancy chips; identical module settings; check for hand-operating stations.
The communication network joins process stations and HMIs. Topologies: bus, ring and star — the bus is logically a ring; star suits only small systems. Ring or bus, broadcast is usual; other protocols are rare. Network speeds run around 10–100 M.
The HMI has four node types: operator stations, engineer workstations, history/trend stations and dynamic data servers.
Their design principles differ greatly. The PLC grew out of imitating relay control: 1970s PLCs had only digital logic control, first applied in car manufacturing. They store instructions for logic, sequencing, timing, counting and arithmetic, operating machinery and processes through digital I/O. The user's program expresses the process requirements, pre-stored in user memory; at run time instructions execute step by step. The CPU's program counter increments each step, running from step zero to the final step (usually END), then looping back. One full cycle is a scan period — 1 to a few dozen microseconds depending on model. Such program-counter looping is absent from DCS — one reason PLC redundancy lags DCS.
DCS grew from operational amplifiers, making every function and every relation between process variables a function block (some call them puffed blocks). Mid-1970s DCS had only analogue control — e.g. TDC-2000: one controller computed 8 PID loops per second, first applied in chemicals.
The chief visible difference lies in logic solving versus analogue computation; even after mutual borrowing they differ. Since the 1980s PLCs gained some loop algorithms beyond logic, but complex computation remains hard: ladder programming makes analogue logic unintuitive and cumbersome, while logic solving is fast — microsecond class, 1K of logic in under 1 ms. PLCs treat all inputs as digital, 16 (or 32) bits per analogue; DCS treats all inputs as analogue, 1 bit being digital; a logic solve takes hundreds of microseconds to a few milliseconds. PLCs need a few dozen milliseconds per PID — comparable to DCS; large PLCs use another CPU for analogue computation, passing results to the PLC controller. DCS PID times vary by model but sit in the same few-dozen-millisecond class (early TDC-2000: 8 loops per second). Chip advances keep shortening algorithm times, which also depend on block arrangement and configuration.
Earth resistance: maybe undemanding for a PLC, but DCS needs single-digit ohms (usually below 4). Analogue isolation matters too — fit intrinsic-safety barriers in explosive areas.
For the same I/O count PLC costs less than DCS (about 40% saving). PLCs have no dedicated operator station; their software and hardware are commodity, so maintenance costs far less. One PLC controller accepts thousands of I/O (over 8,000 at most); a DCS controller only hundreds (≤500). If the controlled object is mainly interlocking with few loops, PLC fits; if mainly analogue with much function computation, DCS is better. DCS beats PLC in controller/I-O/network redundancy, advanced computation and industry-specific requirements. PLCs, using commodity monitoring software, make enterprise MIS design easier.
Notably, the DCS dedicated operator station is not heaven-ordained — it is historical. Unless DCS vendors open their stations to plant MIS networking, individual DCS risk vanishing from the market. New technology brings negative sides too: opened stations invite viruses and hackers — design in passwords, isolation and firewalls to minimise the harm.
