Inside a Modern Vital Interlocking: How ElectroLogIXS Works

Most of us learned this discipline on relay logic. A vital relay is honest in a way software never quite is: it is heavy, it is slow, and when the coil loses current, gravity drops the armature to the de-energized position whether the circuit designer was having a good day or not. The whole safety case of a classic interlocking rests on that one physical fact. Current does work against gravity; the absence of current does nothing; and "nothing" is the safe answer. (If that framing is new, the companion piece on relay interlocking logic is the mental model everything below is built on.)

So when you replace a room full of shelf-type relays with a single chassis running a 32-bit processor, the first and only interesting question is: where did gravity go? How does a box full of software reproduce the property that a fault resolves toward red, not toward a false clear?

This piece is about how one widely deployed platform, ElectroLogIXS, answers that question. It has a long pedigree: the vital interlocking line that passed from Harmon Industries into GE Transportation Systems, then to Alstom, and now sits under the KB Signaling name. You will find it under control points across North American freight and transit properties. Everything below is drawn from the platform's published Operation and Maintenance documentation, from the public patent literature covering its vital remote links (US Patent 11,724,724), and from the standard body of railway safety-engineering theory that every SIL-4-style interlocking is built on. No magic, just the same fail-safe reasoning the relay men used, pushed down into silicon.

One chassis is one control point

The mental model to start with: one ElectroLogIXS chassis is one location. Where you once had a control point's worth of vital relays, approach-locking sticks, and time-element relays spread across a bungalow, you now have a single rack that reads the field, computes the interlocking, and drives the signals and switches for that one control point.

The field side is deliberately conventional. The chassis still talks to real track circuits, real switch machines, real lamp filaments, and (where fitted) cab signal rates. The vital I/O boards are purpose-built: track interface cards, lamp drivers with filament proving, discrete vital I/O, cab-rate drivers, and battery and ground-fault monitoring. From the field's point of view, nothing has changed. A lamp driver still has to prove current through a filament; a track card still has to prove a shunt. The revolution is entirely upstream of the field terminals, in how the decision to energize that lamp gets made.

The VPM-3: three CPUs that do not trust each other

The brain of the chassis is the vital processor module. The single most important thing to understand about it is that it is not one computer. It is three, and they are arranged specifically so that no single one of them can clear a signal on its own.

Tap to enlarge One chassis, three processors. A and B are the vital pair and must agree; C is non-vital; the watchdog is the outer envelope.

Two of the processors, call them A and B, are the vital pair. They run the same safety logic over the same inputs, independently, and then they have to agree. The third processor, C, is non-vital. It handles everything that is important but not safety-critical: the dispatcher (CTC) communications, the web and diagnostic interfaces, logging, the housekeeping an operator or maintainer interacts with.

This is two-out-of-two (2oo2) diverse redundancy, and it is the software heir to an old relay trick. A vital relay circuit is often arranged so that two independent contacts must both make before an output can pick. One contact welded closed does not create a false clear, because the second contact is still honest. ElectroLogIXS does the same thing with two processors: A computes a result, B computes the result, and the output only moves if the backplane cross-check says the two agree. A software fault, a stuck bit, a cosmic-ray upset on one core is not trusted, because the other core is still honest and the disagreement itself is treated as a fault.

The processor is a 32-bit Motorola ColdFire, a big-endian embedded core from the 68k lineage. The choice is unglamorous and deliberate: a vital platform wants a processor that is well understood, deterministic in its timing, and free of the speculative cleverness that makes modern application CPUs fast and unpredictable. You do not want branch prediction and out-of-order execution in something whose entire value proposition is that the same inputs always produce the same outputs.

Sitting above all three processors is one more layer of the old gravity: a hardware watchdog that the non-vital processor must keep petting. If the software stops behaving (a scan overruns, a task hangs, the health monitor goes quiet) the watchdog times out and resets the entire module, vital cores included. A reset drops every vital output. That watchdog is the outermost fail-safe envelope of the whole design: when in doubt, stop, and stopping means everything goes dark and therefore red.

Three layers of software, each checking the one below

The code inside the module is a short, strict stack of three layers, and each layer's first job is to verify the next before trusting it.

The bootloader is the first slice of flash to run at reset. Its only real responsibility is to decide whether the main firmware image is intact and genuine, and to refuse to launch it if it is not. It checks the image against a stored integrity value (a CRC over the image body) and a type tag before it ever transfers control. A corrupted or wrong-type image does not boot into some degraded half-state; it fails to a recovery halt. Note the pattern already, at the very first instruction: the default outcome of uncertainty is do nothing, and doing nothing is safe.

The executive is the platform firmware proper: the real-time kernel, the scheduler, the I/O layer, the communications stacks, and the safety supervisor that enforces the vital rules at runtime. The executive is common to a whole class of installations; it is not customized per site. What is customized is which kind of executive you run, and the platform encodes that in the part number. The product family splits the executive by application class (an interlocking build, a grade-crossing build, a combined build, a PTC build), and the hardware revision of the module is keyed to accept only the matching class. A crossing module will reject an interlocking executive at boot. You cannot accidentally load the wrong brain into the wrong box.

The application is the part that is unique to your control point. It is the boolean signaling logic for this interlocking: the specific routes, the specific locking, the specific aspects, this plant's track and switch layout expressed as equations. The engineer authors it in the platform's logic editor, it is compiled into a compact form the executive can execute, and it is loaded from a module on the chassis at boot after the executive has verified its integrity and confirmed it matches the configured location identity. Change the plant, you change the application. The executive and bootloader underneath do not change at all.

The cyclic scan: how a railroad gets computed

Here is the heart of it, and it will feel familiar to anyone who has worked with a safety PLC, because the discipline is the same.

ElectroLogIXS does not react to events. It runs a cyclic scan. Every cycle, in a fixed and bounded amount of time, it does exactly four things in exactly this order.

Tap to enlarge One cycle. Inputs are frozen at the top; a failed check or an A/B mismatch takes the restrictive branch, not the permissive one.

1. Sample the inputs. Track occupancies, switch correspondence, local panel and dispatcher requests, and the status coming in from neighboring interlockings are all read in and frozen for this cycle. Once the scan begins, the inputs do not change under it.
2. Evaluate every equation, once, in dependency order. The logic is sorted so that whenever an equation depends on the result of another, the one it depends on has already been computed this cycle. Feedback paths (the software equivalent of a relay whose own front contact sits in its pick circuit, which is how stick and latch logic is built) are handled explicitly. Every equation is evaluated exactly once per cycle; there is no iterating until things settle, and no equation that gets skipped because "nothing changed."
3. Run the vital checks and the A/B comparison.
4. Drive the outputs, but only if every check passed.

Because the inputs are latched at the top of the cycle and the equations are evaluated in a fixed order, the scan is fully deterministic: the same inputs, every time, produce the same outputs. This is not a performance optimization. It is the foundation of the entire correctness argument. A deterministic system can be reasoned about, tested exhaustively against known input vectors, and certified. A system whose output depends on timing or evaluation order cannot. The published theory of operation leans on exactly this property, and it is the single most important thing the software borrowed from the relay world: a relay interlocking is also, in effect, a continuously re-evaluated combinational network with a bounded settling time. ElectroLogIXS just made the "cycle" explicit and the evaluation order fixed.

If anything in step 3 fails (a check does not pass, A and B disagree) step 4 does not happen in the permissive direction. The outputs de-energize. The scan starts over at the top of the next cycle with fresh inputs. There is a small, bounded tolerance for a single disagreeing cycle (a transient upset gets one chance to not repeat), but a persistent fault collapses the plant to its restrictive state and keeps it there.

What actually makes it "vital"

A cyclic scan on a reliable processor gives you a correct computer. It does not yet give you a vital one. Correctness says "when the hardware works, the answer is right." Vitality has to say something much stronger: "when the hardware does not work, the answer is safe." Those are different claims, and the second one is the whole game.

ElectroLogIXS gets there with layers that stack on top of the 2oo2 diversity already described.

Coded (checked) representation of truth. This is the deep idea, and it has a long published history in railway safety computing (the lineage of coded-monoprocessor and fail-safe coded-logic techniques going back decades, the same family of ideas behind systems like SACEM and the fail-safe serial messaging formats used across North American vital products). The principle: in a vital computation you do not represent a boolean as a single bit, where 0 is false and 1 is true. A single bit is far too easy for a fault to forge. One stuck line, one dropped bit, and a restrictive condition reads as permissive. Instead, "true" is represented by a large, specific, checked codeword, and every operation that consumes a value re-verifies that the codeword is the right one in the right place before believing it. A random corruption does not land on a valid codeword; it lands on garbage, and garbage is interpreted as false.

Sit with why that is so powerful. In a naive representation, half of all random bit patterns read as "true," so a fault is as likely to create a dangerous false clear as a safe false stop. In a coded representation, essentially no random pattern reads as "true," so a fault overwhelmingly produces "false," and in an interlocking false means de-energized means restrictive. The designers did not try to detect every possible fault. They changed the representation so that the overwhelmingly probable result of any fault is the safe one. That is the software recreation of gravity. A corrupted vital value falls toward red the way a relay armature falls toward its de-energized contacts.

Diverse A/B execution with a cross-check, already covered: two processors, same logic, must agree, disagreement de-energizes.

Integrity checks at every seam. The bootloader CRC-checks the executive. The executive verifies the application and confirms it matches the configured site identity. Messages between interlockings carry their own authentication. At every boundary where data crosses from one trust domain to another, there is a check, and a failed check fails restrictive.

Put those together and you get the unifying principle of the whole platform:

Tap to enlarge The thesis of the platform in one picture: every uncertainty resolves in the same direction.

That is the entire design philosophy. Everything else is engineering in service of it.

Vital and non-vital, and the direction a request flows

A real interlocking is not only vital logic. Someone has to talk to the dispatcher, drive the indication lamps on the panel, keep the logs, serve the diagnostic screens. None of that is safety-critical, and you do not want it sharing a trust domain with the logic that decides whether a signal can clear.

So the application inside one chassis is actually two applications that run in different places: a vital (V) application on the A/B pair, carrying the signal, switch, and track logic, and a non-vital (NV) application on the C processor, carrying the CTC interface, indications, and monitoring. A real plant runs on the order of a few hundred vital equations and a smaller set of non-vital ones, though it varies widely with the size of the interlocking.

Tap to enlarge The dispatcher asks; the interlocking decides. The request bridge is one-directional: non-vital into vital.

The two halves are isolated from each other, and that isolation is the point. They communicate only through one explicit, audited bridge across the backplane: a defined block of status flows from the vital side to the non-vital side (so the panel can show what the interlocking is actually doing), and a separate defined block of request bits flows from the non-vital side to the vital side.

That second direction is the one worth burning into memory, because it is the safety-critical invariant of the dispatcher interface. A dispatcher request enters non-vitally and proceeds into the vital logic. It never is the action. It is only a request. The CTC asks for a route by setting a request bit in the non-vital application; that bit crosses the bridge into the vital application; and the vital logic decides, by the full weight of the interlocking and locking rules, whether granting it is safe. If it is, the vital side drives the signals and switches and sends indications back across the bridge so the dispatcher sees what happened.

The dispatcher, in other words, is never trusted to clear a signal. The dispatcher is trusted only to ask. The grant is always the vital side's decision, computed from proven field conditions, and the non-vital side has no path to energize a vital output on its own. This is the exact software analogue of a CTC code system feeding a relay interlocking: the code line delivers a request to the control machine, but the vital relay logic is what actually lines the route, and it will refuse a request that locking forbids.

Talking to the neighbors: vital links between interlockings

A control point does not exist alone. Approach locking, speed propagation, and the simple truth of whether the next block is occupied all require that adjacent interlockings share state. Historically this was line circuits and code lines. ElectroLogIXS does it with vital serial links between chassis, and the design basis for that mechanism is public: it is described in US Patent 11,724,724.

Tap to enlarge A chain, not a hub. Lose a link and that neighbor reads as all-false, the most restrictive state, exactly as a broken line wire once dropped a relay.

The architecture is a point-to-point chain, not a hub. Each interlocking links directly to the control points on either side of it, and status propagates hop by hop along the line. A junction with several neighbors simply runs several links. There is no central vital server whose failure takes down the subdivision; the vitality lives at each link.

The messaging is fail-safe in the now-familiar way. Each link exchanges a small fixed set of status in each direction on a fast, fixed polling cycle, and every message is authenticated so that a stale, replayed, corrupted, or wrong-neighbor message is rejected rather than believed. Crucially, the link has a loss-of-communication timeout, and when it fires, the link's contribution to the local logic does not freeze at its last value, and it does not read as "all clear." It collapses to all-false. A neighbor you cannot hear from is treated as a neighbor reporting the most restrictive possible state. Lose the link, and approach locking tightens and permissions drop, exactly as a broken line wire would once have dropped a relay. The non-vital C core runs the transport, but the vital A/B cores consume only the authenticated result, so even the link stack cannot forge a vital input.

Where the logic comes from

One last layer, because it closes the loop on how the safe railroad above got into the box in the first place.

The site logic is not written in C by a firmware team. It is authored by signal engineers in the platform's dedicated logic-design environment, in a form that reads much like boolean equations (close kin to the Boolean and ladder statements a signal engineer already thinks in). That source is run through the platform's compiler, which does more than translate: it performs the dependency analysis that fixes the evaluation order for the scan, and it generates the integrity values the executive will later use to prove the application was loaded intact. The output is a compact encoded form the executive executes directly, the same way, in the same order, every cycle, forever.

This separation is itself a safety feature. The people who write the interlocking logic for a specific plant work in the vocabulary of interlocking logic, not in the vocabulary of processors and memory. The platform underneath (the coded representation, the A/B cross-check, the scan discipline, the fail-safe seams) is written once, verified once, and reused unchanged under every site's equations. The signal engineer designing a control point does not re-derive the safety properties of the computer. They inherit them, and they express the plant.

The one idea to take away

If you remember nothing else about how a modern microprocessor interlocking works, remember this: the engineers did not make the computer incapable of faults. That is impossible, and they knew it. What they did instead was arrange every layer so that the result of a fault is the safe state.

• A corrupted value reads as false, so it de-energizes.
• Two processors that disagree de-energize.
• A firmware image that fails its check does not launch.
• A neighbor that goes silent is assumed to be reporting the worst.
• A scan that overruns trips the watchdog and resets the box.
• A dispatcher can only ask; the vital logic decides.

Every one of those is the same move. It is the move the relay interlocking made when it let gravity, not current, be the default. The clever part of ElectroLogIXS is not that it computes a railroad. Lots of things can compute a railroad. The clever part is that when it stops computing correctly, it stops in the one direction that keeps trains apart. Gravity never left. It just moved into the design, where a corrupted codeword falls toward red as surely as an armature falls toward its rest.

That is the whole theory of operation. Everything else is detail.