Skip to main content
Account
Systems8 min read

Deterministic State: How Nordic Rail Interlockings Prove Two Trains Cannot Meet

Before a high-speed passenger set clears a single switch outside Gothenburg, boolean interlocking equations evaluate 1,800 track-circuit invariants in under forty milliseconds.

SL
Soren LindqvistSystems Editor
Deterministic State: How Nordic Rail Interlockings Prove Two Trains Cannot Meet

At 05:42 on a sleet-heavy November morning outside Gothenburg Central, nineteen passenger and freight movements converge across forty-six electric point machines. Inside the regional signaling relay room, there are no spinning fans, no garbage-collected runtimes, and no optimistic retries. Every route lock is governed by cyclic boolean equations evaluated on dual-channel processors running lockstep clock cycles.

If Channel A and Channel B disagree on a single bit of track occupancy at the end of a 40-millisecond scan cycle, neither channel negotiates. Both cut power to the output vital relays, gravity drops the armature contacts within twelve milliseconds, and wayside aspects revert immediately to red.

Gravity as the Ultimate Fallback

Modern computerized interlockings inherited their core safety contract directly from mechanical locking frames and vital electromagnetic relays. Standard carbon-silver contacts can weld shut under surge currents; railway vital relays therefore use silver-impregnated carbon contacts that cannot fuse, paired with heavy bronze armatures mounted so gravity alone opens the circuit whenever coil current ceases.

Software engineers accustomed to cloud microservices often find railway interlocking code startlingly austere. Dynamic heap allocation after boot is prohibited under EN 50128 SIL-4 guidelines. Recursion is banned. Every loop has a compile-time upper bound, and state transitions are expressed as pure truth tables verified by SAT solvers against route conflict matrices.

Route Lock Invariant (Simplified Switch 14B):
LOCK_14B_NORMAL := 
  TRACK_14_CLEAR &
  !CONFLICT_ROUTE_22_ACTIVE &
  POINT_14B_PROVED_NORMAL &
  APPROACH_TIMER_EXPIRED;

Lessons for Everyday Infrastructure Software

Most commercial software does not guard 600-tonne locomotives, yet factory automation and clinical equipment routinely suffer outages caused by unbounded state spaces and network dependencies. Moving state close to the machine—as documented in SQLite on the Factory Floor: Local-First Telemetry When the WAN Goes Dark—eliminates whole categories of partial failure. And just as mechanical chronometers make wear visible on the bench in Why Marine Escapements Outlived Their First Century at Sea, deterministic state tables allow an auditor to prove exhaustively what a system can never do before the first train rolls over the viaduct.

Written by

Soren Lindqvist

Distributed-systems engineer covering railway signaling verification, embedded databases, and deterministic control software.

More posts →

Reader Letters (0)

Moderated by editors

No published reader letters on this essay yet. Add a technical note or field observation below.

Write a Reader Letter

Your email address is used solely for editorial verification and is never stored in public comment properties.

Weekly Dispatch

Subscribe to Kestrel Review

New field essays every Tuesday and Friday morning. Reader-funded, zero display ads, unsubscribe in one click.

View all essays →
Tuesday & Friday Dispatch

Subscribe to Kestrel Review

Receive two full-length essays each week on durable hardware, deterministic software, and civic architecture. No tracking pixels, no sponsors.

Please enter your name.
Please enter a valid email address.