A tank fills. A heater brings the liquid toward a target temperature. A mixer runs, the process holds, and the tank drains. On a screen, that can look like a simple animation. Underneath it are several different questions: who controls the equipment, where does the displayed value come from, and what evidence tells us that the picture is current?
Those questions are a useful way into OT cybersecurity. Before deciding whether a system is secure, it helps to understand what it is supposed to do and how people know that it is doing it.
This story draws on documented October 2026 tests in my simulated OT lab. It describes dated results, not the lab's current health. The diagram and browser exercise below are newly created teaching examples: they simplify the process and do not reproduce its configuration, timing, or access paths.
Start with the physical meaning
Imagine a small batch-mixing process. A level value describes how full the vessel is; a temperature value describes its contents. The controller uses a sequence and conditions to decide when to request filling, heating, mixing, or draining.
A PLC, or programmable logic controller, executes that control logic. An HMI, or human-machine interface, helps an operator understand the process and issue permitted commands. A historian stores selected measurements so someone can investigate what happened over time.
These are different responsibilities. A historian is not the controller, and an animated tank is not independent proof that a pump is moving liquid. In this lab, the process itself is simulated too. That makes it useful for learning, but it does not validate a real pump, instrument, or safety function.
Read the arrows: measurements travel toward the controller; output requests travel toward the process. The HMI reads values and can send authorized commands. The historian collects selected values. These are logical relationships, not a map of my home network or a claim about a particular product's deployment.
Download the teaching diagram or open the batch explorer.
Follow one value all the way through
Take vessel level. A useful investigation starts at the source and follows the value through each handoff:
- Process: what does the level represent, and what units or scale does it use?
- Controller: which value is used by the sequence, and what happens if it is missing or implausible?
- Display: is the HMI showing a recent value, a cached value, or a substituted value?
- History: which timestamp is recorded, and does the trend actually contain new samples?
An “80” without context is ambiguous. It might mean 80 percent, 80 litres, a raw instrument count, or a stale value that happens to look reasonable. Units, quality, and freshness turn a number into something an operator can interpret.
What the documented tests establish
The lab's October review record contains six accepted batches across the selected process and browser test suites. The tests followed phase progression and completion, checked that a peer cell remained independent, and exercised operator commands through the HMI.
The record also describes fault/recovery checks: an active simulated stop condition prevented reset from bypassing the cause, and recovery was tested after the cause was cleared. Separate role checks distinguished operator actions from engineering privileges.
Those are useful, bounded observations. They support saying that the tested workflows worked during those runs. They do not prove continuous availability, physical safety, every network boundary, or recovery after an arbitrary failure. A small lab benefits from making that distinction as much as a production environment does.
The interesting failure: a healthy page with stale data
A web server can return a successful response while the displayed process value is no longer updating. Equally, a running controller does not prove that the historian is collecting samples or that a passive sensor sees the intended traffic.
It helps to separate three kinds of evidence:
- Availability: the application or endpoint responds.
- Process behavior: the expected sequence progresses and the expected conditions are observed.
- Observability: the measurements are current, meaningful, and arriving where they should.
In the browser exercise, freeze the HMI feed while a batch is running. The generated process continues, but the display retains its last sample. Its quality indicator changes when that sample becomes old. Restoring the feed catches the display up to the current example state; it cannot reconstruct measurements that were never collected.
The freeze scenario is a teaching experiment, not a claim that a particular communications failure occurred in the documented lab tests.
A stop is not the same as a reset
The explorer also lets you apply a simulated stop. Output requests become inactive, but the vessel does not magically empty or cool. Clearing the stop condition does not restart the batch: an acknowledgement and a new start are separate actions.
That is deliberately simplified logic. Real equipment may require cooling, controlled shutdown, stored-energy management, or other responses instead of simply removing output requests. An actual emergency-stop or safety-instrumented function requires its own engineering and validation; this browser model is neither.
What to take away
The most useful result is a better set of questions. What is this value measuring? How old is it? Which component owns the action? What evidence supports the status label? What happens when a prerequisite disappears?
Use the observation worksheet and evidence register to practice asking those questions. You can do that with the browser example before you have a PLC or a lab of your own.
For deeper context, start with NIST's Guide to Operational Technology Security and MITRE ATT&CK for ICS. The learning exercise is about understanding a process first; the frameworks help put that understanding into a wider security context.