Home/Concepts/Open-loop versus closed-loop control in rail operations
Open-loop versus closed-loop control in rail operations
Any knowledge system that cannot observe the consequences of its own outputs is an open-loop controller, and open-loop control degrades monotonically under disturbance. This is…
Where the distinction comes from
The word "governor" enters engineering in 1788, when James Watt fitted a rotating pair of balls to a steam engine's throttle. As the engine sped up, the balls flew outward on their arms and closed the valve. As it slowed, they fell in and opened it. The governor did not know anything about the boiler, the load, or the weather. It measured exactly one thing — its own error, the gap between actual speed and set speed — and drove that gap towards zero. Before the governor, engine speed was set by valve position and left alone: an open-loop plan that wandered as load changed, because nothing was watching the outcome. James Clerk Maxwell's 1868 paper "On Governors" gave the mathematics for why such loops sometimes hunt and oscillate rather than settle, and Edward Routh and Adolf Hurwitz supplied the stability criteria that followed. The whole discipline of control theory grows out of one question: does the system measure what it did, or does it only execute what it planned?
Rail signalling inherited this question almost from the start, and it has never left. A network controller today sits in exactly Watt's position, except the plant is not a single engine but a few hundred kilometres of interlocked track, and the disturbance is not load but everything: rail temperature, wheel wear, points motors, weather fronts, freight paths that were never in the original timetable.
The plan and the track are not the same thing
A working timetable is an open-loop artefact. It is built from a model of the network — headways, junction margins, dwell times, rolling-stock diagrams — fitted well in advance and then executed. Trains run to the plan; signallers intervene when something visibly conflicts with it. That is not a criticism. Most of the time the plan is good enough, because the plant is well characterised and disturbance is small: a stepper motor indexing a known load does not need an encoder, and a train departing on time into clear track does not need a controller staring at it.
The trouble is the word "small". Rail networks are instrumented with track circuits and axle counters that report train presence, with rolling-stock telemetry that reports traction faults, wheel-flat vibration and brake temperature, and with weather and maintenance-window feeds that report conditions on the infrastructure itself. All three streams are, in principle, running continuously. The failure mode that recurs across incident reports is not that these streams are absent. It is that they are read as inputs to the next plan rather than as a return path against the current one — and by the time the discrepancy is acted on, the defect has already propagated.
The characteristic failure
Consider a rail temperature spike on a stretch of continuously welded track. The weather feed reports the temperature. The track geometry recording vehicle, on its last pass, reported a slight alignment deviation within tolerance. Neither reading alone crosses a threshold. Buckling develops over minutes as the two combine, and the first hard signal is a track circuit occupation anomaly or a driver reporting rough ride — at which point a speed restriction is imposed, correctly, but after a train has already run over the defect at line speed. The restriction is not wrong. It is late, structurally, because nothing in the architecture matched the temperature stream against the geometry stream against the current train movement in real time and flagged the compound condition before an axle passed over it. Each stream was open-loop with respect to the others. The controller had all the sensors and none of the closure.
The same shape appears with wheel-flat telemetry. A rolling-stock monitoring system logs an impact signature consistent with a developing wheel flat. That log sits in a maintenance queue with a scheduled window three days out. Meanwhile the vehicle keeps running, the flat worsens, and the eventual outcome is a rail-break risk or a speed restriction applied once track circuit data shows anomalous impact loading at a specific mileage — again, after the propagation, not at the appearance. Telemetry existed. It was consulted, not closed.
Naming the architecture
This is the open-loop/closed-loop distinction exactly as Watt and Maxwell defined it, applied to a knowledge system rather than a valve. An open-loop controller acts on a plan without measuring whether the plan held. A closed-loop controller measures the output, compares it against reference, and drives the difference down while the process is still running. What separates them is never the sophistication of the plan — a working timetable can be extraordinarily well modelled and still be blind — but whether a sensor is wired back into the decision while the train is still moving.
Read against this, the three generations of large model are three positions on how wide and how persistent that return path is.
| Generation | Return path in a rail analogy |
|---|---|
| Large Language Model | A timetable built once from historical running data, executed regardless of today's track conditions |
| Large World Model | A control room screen live during a shift: track circuits and telemetry sensed and acted on, but the picture resets at shift handover |
| Large Universe Model | Every stream — track circuits, telemetry, weather, maintenance windows — held open indefinitely, with each incoming reading matched to the specific belief it revises |
A Large Language Model, asked about network behaviour, has a plant model fitted from a frozen corpus of past incidents and past timetables. It can describe what usually happens at a known pinch point with real fluency and no awareness that the points motor at that pinch point was replaced last month. A Large World Model is closer to the working control-room picture: track circuits and telemetry sensed, error measured against what the sensors say right now, restrictions issued and lifted within a shift. But the loop is scoped to the episode. Nothing obliges the system to remember, three shifts later, that the temperature-geometry compound condition at that mileage has occurred twice before and is trending. A Large Universe Model is the architecture in which that memory is structural: the weather stream, the geometry stream and the maintenance-window stream stay open across shifts, each belief about the state of that stretch of track carries provenance back to which reading produced it, and a new reading is matched against the specific claim it should revise rather than blended anonymously into a fresh snapshot.
Two objections worth taking seriously
"We already pull live feeds into the timetable model before every replan. That's closed-loop."
It is a better open-loop controller, not a closed one. Reading track circuits and telemetry before generating an updated working plan is feedforward with a fresher sensor — the reference signal is more accurate, the plan is better, and then it is executed and left. Nothing in that pipeline records what the model predicted, watches whether the prediction held over the following hours, and attributes the gap to a specific input stream. That attribution is the return path. A controller that refreshes its inputs every ten minutes and then forgets what it asserted is still open-loop between refreshes; it has simply shortened the interval over which drift accumulates, not removed the drift.
"Continuous revision is dangerous. A controller that reacts to every telemetry blip will thrash — issuing and lifting restrictions on noise, or letting one faulty sensor cascade into a network-wide slowdown."
This is the strongest objection and it is correct as stated. Feedback buys error rejection at the cost of a new failure mode: instability. A loop with too much gain or too much delay oscillates, and a network controller chasing every reading would be worse than one working a stable, stale plan. But instability is a tuning problem inside a closed-loop architecture — rate limits on how fast a belief about track condition can shift, hysteresis so a restriction is not lifted and reimposed within minutes, provenance weighting so a single uncorroborated sensor cannot trigger a network-wide response, quarantine for a feed with a known fault history. Drift inside an open-loop plan has no equivalent remedy, because there is no mechanism in that architecture to remedy at all. Choosing between a failure mode you can tune and one you cannot is not close.
Why this is the top rung on this axis
Track circuits, telemetry, weather and maintenance windows exhaust the observable state of the running network on this axis. A fourth generation could still differ — by intervening, running controlled test movements, adjusting infrastructure rather than watching it — but that is a shift onto an action axis, not a wider intake. It concedes the point rather than escaping it: an intervening system is a Large Universe Model with an actuator attached, which is what a network controller already partly is and what the argument says intake alone cannot become anything further than.