Industrial Control Systems

Sensors and actuators

Every industrial control system starts at the physical process: a tank, a pipe, a furnace, a power line. Two kinds of field devices connect that process to the computers.

A sensor measures a physical quantity and turns it into a signal a controller can read. Examples:

• A temperature transmitter on a boiler that sends the water temperature as an electrical signal.
• A pressure sensor on a pipeline or a pump discharge.
• A level sensor in a tank, or a flow meter in a pipe.
• Current and voltage transformers in a substation, which scale the grid's high currents and voltages down to values a relay can measure safely.
• A limit switch that reports whether a valve is fully open or fully closed.

An actuator does the opposite: it receives a signal and changes the process. Examples:

• A control valve that opens from 0% to 100% to regulate a flow.
• A circuit breaker that connects or disconnects a line or a transformer.
• A motor drive (a variable-frequency drive) that sets the speed of a pump or a fan.
• A heater, a solenoid or a relay that switches something on or off.

Many field signals are still analog. A common standard is the 4–20 mA current loop: 4 mA means the bottom of the measuring range and 20 mA the top. Starting at 4 instead of 0 has a safety reason: 0 mA can only mean a broken wire or a dead instrument, so the controller can tell a fault from a real zero. Digital signals are on/off (a contact is open or closed). Increasingly, field devices also speak digital fieldbus or Ethernet protocols (see Industrial Protocols).

Programmable logic controllers

A programmable logic controller (PLC) is a rugged industrial computer that reads sensors, runs a control program and drives actuators. NIST describes it as "a solid-state control system that has a user-programmable memory for storing instructions" for functions such as input/output control, logic, timing, counting and "three mode (PID) control". PLCs were introduced to replace cabinets full of electromechanical relays, and they still look like it: a rack or a DIN-rail unit with input and output modules, built to survive heat, vibration and electrical noise for decades.

The scan cycle

A PLC does not wait for events the way a web server does. It repeats the same cycle forever:

1. Read inputs: copy the state of every input (sensors, switches) into memory.
2. Execute logic: run the program once from top to bottom, using that snapshot.
3. Write outputs: copy the results to the physical outputs (valves, motors, lamps).
4. Handle communication and diagnostics, then start again.

One cycle typically takes from about a millisecond to some tens of milliseconds, depending on the program and the hardware. Because the program works on one consistent snapshot of the inputs, its behavior is predictable, and engineers can calculate the worst-case reaction time. A watchdog timer stops the PLC and puts its outputs in a defined state if a cycle takes too long. That predictability is why plants trust PLCs, and why anything that slows a PLC down, such as a flood of network traffic, is a real risk.

Ladder logic

PLC programs are written in the languages of the international standard IEC 61131-3: ladder diagram, function block diagram, structured text (similar to Pascal) and sequential function charts for structuring sequences; instruction list, an assembler-like language, was deprecated in edition 3 (2013) and removed in edition 4 (2025), but older projects still use it. Ladder logic (ladder diagram) is the oldest and still the most widely recognized. It looks like an electrical drawing of relay circuits: two vertical "rails" with horizontal "rungs" between them. If a path of closed contacts connects the left rail to a coil on the right, the coil is energized.

The rung below starts and stops a pump motor. It is the textbook "start/stop with seal-in" circuit.

       START       STOP_OK    OVERLOAD_OK        PUMP_RUN
 |-----] [-----+-----] [---------] [-----------------( )-----|
 |             |                                             |
 |   PUMP_RUN  |                                             |
 |-----] [-----+                                             |

 ] [  contact: closed when the input or bit is on
 ( )  coil:    output or bit is on while the rung conducts, off when it does not

Pressing START energizes PUMP_RUN. The PUMP_RUN contact in parallel with START then keeps the rung closed after the button is released (the "seal-in"). The pump stops when STOP_OK or OVERLOAD_OK drops out. Both are wired fail-safe: the stop button is a normally closed contact, so the input is on while everything is fine, and a pressed button and a broken wire both stop the pump. The same logic in structured text is one line:

PUMP_RUN := (START OR PUMP_RUN) AND STOP_OK AND OVERLOAD_OK;

RTUs and IEDs

A remote terminal unit (RTU) is a field controller at a remote site, such as a pumping station, a gas compressor or an electrical substation. It collects measurements and status from the equipment around it, sends them to a central control center, and carries out commands it receives back ("open breaker 3"). RTUs are built for long-distance, sometimes slow or unreliable links (radio, leased lines, mobile networks), buffer data when the link is down, and often have wide temperature ranges and battery backup. The line between RTU and PLC has blurred: modern RTUs run control logic, and PLCs can act as RTUs.

An intelligent electronic device (IED) is a microprocessor-based device in electrical equipment that measures, protects, controls or communicates, usually inside a substation. The classic IED is the protection relay: it measures current and voltage on a line or a transformer and, when it detects a fault such as a short circuit, trips the circuit breaker within a fraction of a second, before the fault current destroys equipment or endangers people. Other IEDs are bay controllers, power-quality meters and transformer monitors. In modern substations IEDs talk to each other and to the station computer with IEC 61850 (see Industrial Protocols).

Distributed control systems and SCADA

Controllers rarely work alone. Two architectures tie many of them together.

A distributed control system (DCS) runs a single plant, such as a refinery, a chemical plant or a power station. In NIST's words, control is achieved by "intelligence that is distributed about the process to be controlled, rather than by a centrally located single unit": many controllers each run part of the process, connected by a fast, redundant plant network to operator stations and engineering tools. A DCS is usually one vendor's integrated system, and its controllers run continuous closed-loop control.

SCADA (supervisory control and data acquisition) is, according to NIST, "a generic name for a computerized system that is capable of gathering and processing data and applying operational controls over long distances". Typical users are electricity transmission and distribution, pipelines, water distribution and railways. A central SCADA server polls RTUs and IEDs at many remote sites, shows the state to operators and sends their commands back. The fast control (protection, local loops) stays in the field; SCADA supervises.

In practice the categories overlap: a water utility may run a DCS-like system in its treatment plant and SCADA for its pumping stations, and large SCADA systems include advanced applications. A transmission system operator runs SCADA with an energy management system on top; The Power Grid explains that combination.

HMIs, historians and engineering workstations

Human-machine interfaces

A human-machine interface (HMI) is the screen through which operators watch and control the process: process diagrams with live values, alarm lists, trend charts and buttons to start a pump or open a breaker. An HMI can be a touch panel on a machine or a row of workstations in a control room. Its job is situational awareness: showing the operator what matters and alarming on what needs action. An HMI that freezes or shows false values leaves the operator blind, which is why attacks on HMIs and the "loss of view" they cause are taken so seriously.

Historians

A historian is a database built for storing process values over time: every temperature, pressure and breaker position, with a timestamp, often every second for years. Engineers use it for trends and troubleshooting, managers for production reports, and regulators for compliance evidence. Because so many people outside the control room want this data, the historian is the system most often connected toward the business network, usually through a copy in the industrial DMZ (see The Purdue Model and OT Architecture).

Engineering workstations

Engineers configure and program controllers from an engineering workstation that runs the vendor's tools and holds the project files. It can change what the plant does, so it is one of the most valuable targets on an OT network; The Purdue Model and OT Architecture explains where it belongs and how it is protected.

Control loops

A control loop is the chain that keeps a physical quantity at its desired value: measure, decide, act, and measure again. It has four parts: a sensor, a controller, an actuator and the process itself.

Open and closed loops

In an open loop the controller acts without measuring the result: a timer that runs a pump for ten minutes, whether the tank is full or not. It is simple, but it cannot correct for disturbances. In a closed loop the controller continuously compares the measurement with the target and corrects the difference, the error. If someone opens a tap and cold water flows in, a closed loop notices the temperature dropping and heats harder. Nearly all continuous industrial control uses closed loops.

Setpoints

The setpoint is the target value of a controlled quantity: 40 °C for a water heater, 2.0 m for a tank level, 380 kV for a busbar voltage. Operators change setpoints from the HMI within limits the engineers have configured. The setpoint is also a security-relevant value: a setpoint outside safe limits, or a change nobody authorized, is one of the most direct ways to misuse a control system, so changes are logged and, ideally, checked against those limits in the controller itself.

PID control

Most continuous loops are run by a PID controller, which calculates its output from three terms of the error (setpoint minus measured value):

• P, proportional: acts on the current error. A big error gives a big correction. On its own it usually leaves a permanent offset, because a heater that must stay on to cover heat losses needs a remaining error to keep it on.
• I, integral: acts on the error accumulated over time. As long as any error remains, the integral keeps growing and pushes the output further, which removes the offset. Too much integral action causes overshoot and oscillation.
• D, derivative: acts on the rate of change. When the value is rising fast toward the setpoint, D brakes early, which damps overshoot. It also amplifies measurement noise, so it is used with care; many industrial loops run with P and I only.

Choosing the three gains is called tuning. The simulation below models a heated water tank with a slow heater, heat loss to the surroundings and a sensor that lags behind the real temperature. It runs the same process with P, PI and PID control and prints the measured temperature at a few moments. Two details are common in real controllers too: the output is limited to 0–100%, and the integral stops growing while the output is at a limit (anti-windup), otherwise it would build up a large overshoot.

# A heated water tank. The controller sets the heater power (0-100%) to hold
# the water at the setpoint. One loop iteration = one second.
SETPOINT = 40.0   # °C
AMBIENT = 15.0    # °C; the tank loses heat to its surroundings


def simulate(kp, ki, kd, seconds=900):
    water = AMBIENT        # true water temperature
    measured = AMBIENT     # what the temperature sensor reports (it lags)
    heater = 0.0           # actual heater power; it warms up slowly
    integral = 0.0
    previous = measured
    highest = measured
    log = {}
    for t in range(seconds + 1):
        error = SETPOINT - measured
        slope = measured - previous                  # D acts on the measurement
        output = kp * error + ki * (integral + error) - kd * slope
        command = min(max(output, 0.0), 100.0)       # a heater cannot go beyond 0-100%
        if command == output:                        # anti-windup: stop integrating at a limit
            integral += error
        previous = measured
        if t in (0, 60, 90, 120, 240, 900):
            log[t] = (measured, command)
        # The physics: heater lag, heating minus losses, sensor lag
        heater += (command - heater) / 30
        water += 0.01 * heater - 0.02 * (water - AMBIENT)
        measured += (water - measured) / 10
        highest = max(highest, measured)
    return log, highest


for name, gains in [("P", (8, 0, 0)), ("PI", (8, 0.1, 0)), ("PID", (8, 0.1, 80))]:
    log, highest = simulate(*gains)
    print(f"{name}  (kp={gains[0]}, ki={gains[1]}, kd={gains[2]})")
    for t, (temp, command) in log.items():
        print(f"  t={t:3} s  {temp:5.2f} °C  heater {command:5.1f}%")
    print(f"  highest {highest:.2f} °C, settles at {log[900][0]:.2f} °C")

P  (kp=8, ki=0, kd=0)
  t=  0 s  15.00 °C  heater 100.0%
  t= 60 s  33.91 °C  heater  48.7%
  t= 90 s  39.73 °C  heater   2.2%
  t=120 s  35.77 °C  heater  33.8%
  t=240 s  35.25 °C  heater  38.0%
  t=900 s  35.00 °C  heater  40.0%
  highest 39.74 °C, settles at 35.00 °C
PI  (kp=8, ki=0.1, kd=0)
  t=  0 s  15.00 °C  heater 100.0%
  t= 60 s  33.97 °C  heater  61.9%
  t= 90 s  41.02 °C  heater   9.7%
  t=120 s  38.14 °C  heater  32.7%
  t=240 s  40.21 °C  heater  40.7%
  t=900 s  40.00 °C  heater  50.0%
  highest 41.07 °C, settles at 40.00 °C
PID  (kp=8, ki=0.1, kd=80)
  t=  0 s  15.00 °C  heater 100.0%
  t= 60 s  33.47 °C  heater  50.4%
  t= 90 s  39.47 °C  heater  34.3%
  t=120 s  39.15 °C  heater  46.2%
  t=240 s  39.73 °C  heater  49.5%
  t=900 s  40.00 °C  heater  50.0%
  highest 40.00 °C, settles at 40.00 °C

Reading the output:

• P only settles at 35 °C, 5 °C below the setpoint. To make up for the heat loss at that temperature the heater needs 40%, and a gain of 8 only gives 40% for an error of 5 °C. A higher gain would shrink the offset but make the loop swing more.
• PI removes the offset: the integral keeps raising the output until the error is gone, and the heater ends at the 50% that 40 °C needs. The price is an overshoot to 41.07 °C after about a minute and a half.
• PID sees the temperature rising quickly and reduces the heater early (50.4% at 60 seconds against 61.9% for PI), so at 90 seconds it still needs 34.3% instead of dropping to 9.7% after an overshoot. It approaches 40 °C without overshooting, at the cost of a slower final approach.

Real loops are tuned by control engineers on the real process, often with the vendor's auto-tuning tools and always under the plant's change procedures: a badly tuned loop can oscillate, wear out valves or trip a safety system.