← Course Home Moraine Valley Community College · Dept. of Engineering & Technology · Dr. John L. Sands
OT-101 · Day 1 · Lesson 3 · 4 Contact Hours

OT Technologies & Field Devices

A device-by-device tour of what actually sits on a plant floor — what each device does, how it fails, and what it exposes on the network.

📊 Intermediate ⏱ 4 hours 🎯 5 objectives

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.

Anchoring analogy

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.
Part A · Foundations Lecture

The controllers: PLC, RTU, and IED

≈ 45 min

A 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.

PLC, RTU, and IED compared
CharacteristicPLCRTUIED
Typical settingSingle machine or process areaGeographically remote field siteSubstation or electrical equipment
Control styleContinuous scan-cycle logicPeriodic polling and supervisory commandsLocal protection logic, acts independently and fast
Typical protocolModbus TCP, EtherNet/IP, PROFINETDNP3, Modbus (often over WAN links)IEC 61850, DNP3
Example deviceController on a bottling lineController at a remote pump stationProtective relay on a feeder breaker
Anchoring analogy

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.

Worked example

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.

Teaching note

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 min

A 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.

Anchoring analogy

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.

Worked example

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.

Teaching note

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 min

A 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.

HMI, engineering workstation, and historian compared
CharacteristicHMIEngineering workstationHistorian
Primary purposeReal-time monitoring and manual operator controlProgramming and configuring controllersLong-term logging of process data
Typical platformWindows, running vendor SCADA/HMI softwareWindows, running vendor programming softwareWindows or Linux server, often SQL-based
Risk if compromisedOperator loses accurate visibility and controlAttacker gains the ability to rewrite control logicData integrity loss, or a pivot point toward business systems
Anchoring analogy

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.

Worked example

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 min

A 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.

Anchoring analogy

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.

Worked example

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.

The control loop and the independent safety path A sensor feeds a controller (PLC, RTU, or IED), which drives an actuator — the basic control loop. The HMI, engineering workstation, and historian sit above the controller for supervision, programming, and logging. A separate safety instrumented system runs its own sensor and final element in a fully independent path, bypassing the controller entirely. HMI Engineering workstation Historian PLC / RTU / IED Sensor Actuator Basic process control loop SIS sensor (independent) SIS final element (e.g., shutdown valve) Independent safety path — bypasses the controller entirely

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.

Part B · Applied Practice

Activity: Match the Device to What It Exposes

Individual, then pair-share ≈ 25 min

Individual (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.

DeviceWhat it typically exposes on the network
PLC
RTU
IED
HMI
Engineering workstation
Historian
Safety instrumented system

Simulation: Device Explorer — PLC, RTU, IED, HMI

≈ 20 min
⚠ Simulation only — no live equipment or network

Select 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.

Select a device above to see its role and network exposure, then try simulating a failure.

Review & Knowledge Check

≈ 20 min

Five questions covering the lesson's key distinctions. Answer each, then select Grade My Quiz to see your score and an explanation for every item.

Q1.Which device is built to protect a specific piece of electrical equipment and can act within a few cycles without waiting for a remote command?
Q2.An RTU at a remote pump station goes offline. What is the most likely immediate consequence?
Q3.What is the main security concern with an HMI compared to a PLC?
Q4.Why is a safety instrumented system (SIS) typically kept functionally independent from the basic process control system?
Q5.A tank level sensor sends a signal to a PLC, and the PLC opens a drain valve when the level is too high. Which device is functioning as the actuator in this scenario?
0 / 5
Suggested assessment artifact

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