Lesson Overview
Lesson 2 gave you the vocabulary for how OT thinks about priorities and risk. This lesson gives you the cast of characters that vocabulary actually applies to. Every OT environment, whether it's a water treatment plant, a substation, or a bottling line, is built from a fairly small set of recurring device roles — something that senses the physical world, something that decides what to do about it, something that acts on that decision, something a person watches and steers from, and something that remembers what happened. Once faculty can name these roles on sight and reason about what each one exposes on the network, the rest of the course's security content has somewhere concrete to attach.
We'll move through the controllers first — PLC, RTU, and IED — then the field devices that feed them and act on their decisions, then the systems people actually look at and log from — HMI, engineering workstation, and historian — and finish with drives and the safety instrumented system, which behaves differently from everything else on purpose.
Think of a process as a body. Sensors are nerve endings — they feel temperature, pressure, and position and report it inward. Controllers (PLCs, RTUs, IEDs) are the spinal cord and brainstem — they take that sensory input and decide, often reflexively, what to do. Actuators are muscles — they carry out the decision by moving a valve, spinning a motor, or opening a breaker. HMIs and engineering workstations are the eyes and hands a person uses to watch and occasionally intervene. The historian is memory — a record of what the body has been doing. And the safety instrumented system is the withdrawal reflex: a separate, faster, more primitive pathway that pulls your hand off a hot stove without waiting for your brain to finish thinking about it.
Learning objectives
By the end of this lesson, you will be able to:
- Explain the primary function of each core OT device type: PLC, RTU, IED, HMI, historian, and safety instrumented system.
- Compare PLCs, RTUs, and IEDs in terms of typical deployment context and protocols.
- Identify how sensors and actuators convert between the physical process and digital control signals.
- Describe what each device type exposes on the network and the risk that exposure creates.
- Evaluate the consequence of a single device's failure on process visibility, control, and safety.
The controllers: PLC, RTU, and IED
≈ 45 minA PLC (programmable logic controller) is a solid-state, reprogrammable device that executes control logic against local inputs and outputs, typically within a single machine or process area, on a fixed scan cycle — read inputs, execute logic, write outputs, repeat, as covered in Lesson 2. PLCs are the workhorse of discrete manufacturing and are increasingly common in process industries too, usually speaking Modbus TCP, EtherNet/IP, or PROFINET to whatever else shares their network segment.
A RTU (remote terminal unit) is built for a different problem: monitoring and controlling equipment at a site that's geographically remote from the control center — a pipeline valve station, a water tower, a pump station forty miles from the nearest office. RTUs typically run on DNP3 or Modbus, often over cellular, licensed radio, or leased telephone circuits, and report back to a SCADA master at intervals rather than continuously, exactly as Lesson 1 described.
An IED (intelligent electronic device) is most often found in electrical power systems — a protective relay or smart meter monitoring one specific piece of equipment, such as a feeder breaker or a transformer. What sets an IED apart is speed and independence: when it detects a fault condition (an overcurrent, a short), it can trip a breaker within a few electrical cycles — well under a second — without waiting for a command from anywhere else. IEDs typically speak IEC 61850 or DNP3 on a substation LAN.
| Characteristic | PLC | RTU | IED |
|---|---|---|---|
| Typical setting | Single machine or process area | Geographically remote field site | Substation or electrical equipment |
| Control style | Continuous scan-cycle logic | Periodic polling and supervisory commands | Local protection logic, acts independently and fast |
| Typical protocol | Modbus TCP, EtherNet/IP, PROFINET | DNP3, Modbus (often over WAN links) | IEC 61850, DNP3 |
| Example device | Controller on a bottling line | Controller at a remote pump station | Protective relay on a feeder breaker |
Picture three kinds of specialists on a large campus. The PLC is the building supervisor who's physically present, running the elevators and lighting for one building, all day, without needing to check in. The RTU is the regional inspector who drives out to a distant satellite office once every few minutes, checks the gauges, and phones the numbers back to headquarters. The IED is the on-site safety officer at the chemical storage building, who pulls the fire alarm the instant sensors cross a threshold — without waiting for headquarters to approve it, because a few seconds of delay could be the difference that matters.
At a distribution substation, an IED serving as a protective relay continuously monitors current on a feeder breaker. When a fault causes current to spike well beyond normal load, the IED's protection logic trips the breaker within a few cycles — a fraction of a second — isolating the fault before it can damage equipment further upstream. Meanwhile, an RTU at the same substation reports the breaker's status, voltage, and current readings back to the utility's control center every few seconds over a DNP3 link, so an operator sees that the trip happened — but by the time that report arrives, the IED has already done its job.
Students often want to collapse RTU and IED into "just another PLC." Push back gently: the distinguishing feature isn't the hardware, which can look similar — it's the job. An RTU's job is reporting and supervisory control across distance; an IED's job is fast, local protection of one specific asset. A PLC's job is continuous control of a local process. Same general category of device, three different missions.
Sensors and actuators: where the network meets the physical world
≈ 35 minA sensor measures some property of the physical world — temperature, pressure, level, flow, position — and converts it into a signal a controller can read. Many legacy sensors use a 4–20 milliamp analog current loop, where 4 mA represents the low end of the measurement range and 20 mA represents the high end; a controller's analog input card reads that current and converts it back into an engineering value. Newer sensors may report digitally over protocols like HART or directly over an industrial Ethernet protocol, but the underlying job is identical: turn a physical quantity into something a PLC, RTU, or IED can act on.
An actuator is the mirror image: it converts a controller's electrical output signal back into physical action — opening or closing a valve, starting or stopping a motor, moving a damper. Where a sensor is an input device, an actuator is an output device, and the two together form the two ends of every control loop: measure something, decide something, do something.
If the controller is the spinal cord in this lesson's body analogy, sensors are the sensory nerve endings and actuators are the muscles. A sensor doesn't decide anything — it just reports "this is what I'm feeling" the same way a nerve ending doesn't decide to move your hand, it just reports heat. An actuator doesn't decide anything either — it just does what it's told, the way a muscle fiber contracts because a nerve signal told it to, not because the muscle itself judged the situation.
A level sensor mounted on a tank reports a 4–20 mA signal to a PLC's analog input card: 4 mA means the tank is empty, 20 mA means it's full, and everything in between scales linearly. When the PLC's logic determines the level has crossed a high-level setpoint — say, the signal reads 17 mA, corresponding to roughly 81% full — it energizes a discrete output wired to a solenoid-operated drain valve. That valve is the actuator: it has no idea what "81% full" means: it simply opens because 24 volts appeared on its coil, exactly as commanded.
If your institution has any decommissioned 4–20 mA loop hardware, or even a simple analog gauge, bringing it into class makes this abstraction land immediately for IT-background faculty who have never had a reason to think about how a physical measurement becomes a number.
Watching and remembering: HMI, engineering workstation, and historian
≈ 40 minA HMI (human-machine interface) is the screen and software an operator uses to watch a process in real time and issue manual commands — open this valve, acknowledge this alarm, start this pump. Despite running specialized SCADA or HMI software, an HMI is almost always, underneath, a full general-purpose operating system — usually some version of Windows — which means it carries that operating system's entire attack surface in addition to whatever the HMI software itself exposes.
An engineering workstation is a different tool for a different job: a computer, often running vendor-specific programming software, used by engineers and technicians to write, upload, and modify the control logic running on PLCs, RTUs, and IEDs. Where an HMI lets an operator watch and nudge a running process, an engineering workstation can rewrite what the process does — which makes it one of the most sensitive machines in the entire environment, because it typically has direct, trusted write-access to every controller it manages.
A historian is a time-series database that continuously logs process values — temperatures, flows, levels, alarms — for trending, troubleshooting, and regulatory reporting. A historian doesn't control anything; its job is memory, not action. But because historians are useful to people well beyond the control room — engineers building reports, managers reviewing production numbers — they're also one of the more common bridges between the OT network and business-facing systems.
| Characteristic | HMI | Engineering workstation | Historian |
|---|---|---|---|
| Primary purpose | Real-time monitoring and manual operator control | Programming and configuring controllers | Long-term logging of process data |
| Typical platform | Windows, running vendor SCADA/HMI software | Windows, running vendor programming software | Windows or Linux server, often SQL-based |
| Risk if compromised | Operator loses accurate visibility and control | Attacker gains the ability to rewrite control logic | Data integrity loss, or a pivot point toward business systems |
An HMI is a car's dashboard — you watch it and steer with it right now, in real time. An engineering workstation is the mechanic's diagnostic laptop that reprograms the engine control unit — far more powerful, and something you'd never hand to just anyone. A historian is the trip computer's logged history — useful for understanding what happened last week, but it doesn't steer the car and never did.
At a packaging plant, an operator's HMI screen shows a live trend of line speed and a red "Emergency Stop" button. Twice a year, an engineer connects a laptop running the PLC vendor's programming software — the engineering workstation, even though it's just a laptop for this purpose — to update the recipe logic for a new product size. Meanwhile, a historian server has been logging line speed, downtime events, and reject counts every few seconds for the past three years, data the plant's quality team pulls into a monthly report with no involvement from anyone on the plant floor that day.
Moving metal and guarding life: drives and the safety instrumented system
≈ 35 minA variable frequency drive (VFD), often just called a drive, is a device that controls a motor's speed by varying the frequency and voltage of the power supplied to it, rather than running the motor at one fixed speed. Drives are a common type of actuator in their own right — a PLC sends a speed command, and the drive translates that into the electrical waveform an induction motor actually needs to spin at that speed. When a drive fails, the motor it controls typically either stops (a safe default in most designs) or, in rarer and more concerning failure modes, runs at an uncommanded speed.
A safety instrumented system (SIS) is fundamentally different from every device covered so far, and Lesson 2 already told you why: it sits above the CIA triad and outside the basic process control system entirely. A SIS has its own sensors, its own logic solver, and its own final elements (like a dedicated shutdown valve), and it's designed and certified so that its ability to detect a hazardous condition and force the process into a safe state never depends on whether the PLC, HMI, or any network between them is working correctly.
A SIS is a smoke detector wired directly to a sprinkler system and the fire department — not to the thermostat. It doesn't care whether the thermostat's programming is correct, whether its Wi-Fi is working, or whether someone is in the middle of updating its firmware. It has one job, its own sensor, and its own independent path to action, precisely so that whatever else is going wrong with the "normal" control system doesn't stop it from doing that one job.
A boiler's basic PLC control loop manages normal operation — adjusting fuel flow to hold a target pressure using its own pressure sensor and control valve. A separate SIS, with its own independent pressure transmitter and its own dedicated shutdown valve, watches for a pressure excursion far beyond the PLC's normal operating range. If that threshold is crossed — whether because of a process upset, a failed PLC, or a cyberattack that has compromised the basic control system — the SIS trips the shutdown valve and de-energizes the fuel supply on its own, using logic and wiring that never passes through the PLC at all.
Putting the loop together
Every device covered in this lesson fits into one picture: field devices sense and act, controllers decide, and supervisory systems let people watch, program, and remember — with the safety instrumented system running alongside as a deliberately separate, independent path.
Diagram: the HMI, engineering workstation, and historian sit above the controller for supervision, programming, and logging; the controller connects a sensor to an actuator in the basic control loop. The safety instrumented system, shown at right in red, runs its own sensor and final element in a fully independent path that never passes through the controller.
Activity: Match the Device to What It Exposes
Individual, then pair-share ≈ 25 minIndividual (12 min): For each device, select what it most typically exposes on the network. Pair-share (13 min): Compare your answers with a neighbor and discuss why the exposure differs so much from one device to the next.
| Device | What it typically exposes on the network |
|---|---|
| PLC | |
| RTU | |
| IED | |
| HMI | |
| Engineering workstation | |
| Historian | |
| Safety instrumented system |
Simulation: Device Explorer — PLC, RTU, IED, HMI
≈ 20 minSelect a device below to see its role, its typical network exposure, and — using the Simulate a Failure button — what happens if that specific device stops working correctly. Nothing here touches a real device, network, or protocol; it's a model built to compare consequences across device types.
Review & Knowledge Check
≈ 20 minFive questions covering the lesson's key distinctions. Answer each, then select Grade My Quiz to see your score and an explanation for every item.
Have each faculty member sketch the control loop for one real or hypothetical process at their home institution — a building's HVAC system, a lab fume hood, a campus water feature — labeling the sensor, the controller type (PLC, RTU, or IED), the actuator, and whichever supervisory system (HMI, historian) applies. A one-sentence note on what that controller's failure would mean for the process is enough to confirm the device vocabulary transferred before Lesson 4 builds on it.
Further Reading
- Sensors Reference (course site) — a companion reference page with additional detail on common OT sensor types and signal formats.
- Actuators Reference (course site) — a companion reference page covering common OT actuator types, from solenoid valves to variable frequency drives.