Distributed control systems

Why it matters

Refineries, fertiliser plants, power stations, cement and pharma units in India are run from a distributed control system (DCS). Graduate instrumentation engineers are often hired to configure DCS function blocks, build graphics, manage alarms and support commissioning. Understanding the architecture explains why a DCS keeps running when a screen or a network cable fails.

Key ideas

The idea of distribution. Early computer control used one central computer for every loop (direct digital control), so one failure stopped the plant. A DCS spreads control over many controllers, each handling a group of loops near its own I/O, while operation and supervision stay centralised in the control room. "Distributed control, centralised operation."

Architecture (bottom to top).

• Field level — transmitters, valves, motors, analysers; connected by 4–20 mA/HART or fieldbus (FOUNDATION Fieldbus, PROFIBUS PA).
• I/O subsystem — analog, digital, pulse and fieldbus interface cards, often in remote cabinets near the plant with redundant links back.
• Controller level — redundant control processors executing configured function blocks (AI, PID, AO, ratio, lead-lag, logic, sequence) at fixed cycles such as 100 ms, 250 ms or 1 s. Each controller runs its loops independently of the operator stations.
• Control network — redundant, deterministic Ethernet-based networks connecting controllers and stations.
• Supervisory level — operator stations (HMI graphics, faceplates, trends, alarm lists), engineering stations (configuration, downloads), a historian, and alarm management; advanced process control (APC/MPC) and optimisation run here and write set points to the controllers.
• Plant/business level — links to MES/ERP through a firewall and DMZ. These layers correspond to levels 0–4 of the Purdue reference model used in industrial cybersecurity.

Function-block configuration. Loops are built graphically: AI block (scaling, filtering, alarms) → PID block (modes: manual, auto, cascade; anti-windup; bumpless transfer) → AO block (output to positioner). Cascade, ratio, feedforward and split range are made by linking blocks. Each block has a defined execution period, chosen fast enough for the process — a common rule is a period of no more than about one-tenth of the loop's closed-loop time constant.

Redundancy and availability. Controllers run as hot-standby pairs that track each other and switch over without bumping the outputs; networks, power supplies and critical I/O cards are duplicated. Availability A = MTBF/(MTBF + MTTR). For two independent units in parallel with perfect switchover, the system is down only when both are down.

Alarm management. Badly configured DCS alarms flood operators. Good practice (ISA-18.2, EEMUA 191) rationalises each alarm, sets priorities and deadbands, and aims at a manageable average rate — of the order of one alarm per operator per 10 minutes in steady operation.

DCS, PLC and SCADA.

• DCS — continuous and batch process control in one plant, hundreds to thousands of loops, single integrated database and engineering tool, strong redundancy, high licence cost.
• PLC — fast discrete and sequential control of machines and packages; scan times of milliseconds; cheaper; now also does PID. Modern "PAC" and "hybrid" systems blur the line.
• SCADA — supervisory monitoring and control over wide areas (pipelines, grids, water networks), with RTUs or PLCs at remote sites over slow or intermittent links. Safety instrumented systems are kept separate from the DCS (independent logic solver), although they share displays.

Formulas

A = MTBF / (MTBF + MTTR)

• A: availability (fraction); MTBF: mean time between failures (h); MTTR: mean time to repair (h).

A_parallel = 1 − (1 − A₁)·(1 − A₂)

• Two redundant units, independent failures, perfect switchover.

downtime per year = (1 − A) × 8760 h

CPU load = (Σ block execution times + overhead per cycle) / cycle time

• Fraction of a controller's processing capacity used; vendors typically recommend staying well below full load (often around 60–70 %).

modules = ⌈ N·(1 + s) / c ⌉

• N: I/O points of one type; s: spare fraction (e.g. 0.2); c: channels per module; ⌈ ⌉: round up.

Worked examples

Example 1 (standard) — I/O sizing. A plant needs 150 AI, 60 AO, 200 DI and 120 DO points. Allow 20 % spare. Modules have 16 AI, 8 AO, 32 DI and 32 DO channels. How many modules of each type are needed?

1. AI: 150 × 1.2 = 180; 180/16 = 11.25 → 12 modules.
2. AO: 60 × 1.2 = 72; 72/8 = 9 → 9 modules.
3. DI: 200 × 1.2 = 240; 240/32 = 7.5 → 8 modules.
4. DO: 120 × 1.2 = 144; 144/32 = 4.5 → 5 modules.
5. Total 34 I/O modules, before adding redundant cards for critical loops.

Example 2 (GATE level) — availability and loading. (a) A controller has MTBF = 50 000 h and MTTR = 8 h. Find its availability and expected downtime per year, then repeat for a redundant pair (independent failures, perfect switchover). (b) The controller runs 200 PID loops at a 500 ms cycle; each loop's blocks take 0.9 ms and the fixed overhead is 60 ms per cycle. Find the CPU load.

1. (a) A = 50 000/(50 000 + 8) = 0.99984.
2. Downtime = (1 − 0.99984) × 8760 = 1.6 × 10⁻⁴ × 8760 = 1.40 h per year.
3. Redundant pair: 1 − A_pair = (1.6 × 10⁻⁴)² = 2.56 × 10⁻⁸ → A_pair ≈ 0.999 999 97, downtime ≈ 2.56 × 10⁻⁸ × 8760 h ≈ 0.8 s per year (in reality limited by common-cause failures and switchover faults).
4. (b) CPU load = (200 × 0.9 + 60)/500 = 240/500 = 48 % — acceptable, with room for expansion.

Common mistakes

• Thinking the operator station "does the control"; the controllers keep running if every screen fails.
• Assuming redundancy makes failure impossible; common-cause failures (power, software, cabinet heat) defeat simple redundancy calculations.
• Putting safety trips in the DCS instead of an independent SIS.
• Configuring every deviation as an alarm, causing alarm floods.
• Choosing block execution periods that are too slow for fast loops (flow, pressure) or needlessly fast for slow ones (temperature), wasting controller capacity.
• Forgetting spare I/O and spare controller capacity for future changes.

For GATE IN

DCS appears mostly as conceptual questions — architecture levels, the role of controllers versus operator and engineering stations, redundancy, and comparisons with PLC and SCADA — often combined with reliability calculations (availability, MTBF, series/parallel redundancy). Practise availability arithmetic and know which functions sit at which level.

Quick check

1. In a DCS, where do the PID algorithms execute?
2. A unit has MTBF 9990 h and MTTR 10 h. What is its availability?
3. Two units each with availability 0.99 are placed in parallel. What is the system availability?
4. How many 16-channel AI cards are needed for 70 points with 20 % spare?

Answers: 1. In the controllers (control processors), not in the operator stations. 2. 0.999. 3. 0.9999. 4. 6 cards (84/16 = 5.25 → 6).