Write the Interlocking once. Compile it on every station.
GRAIL is a language for Interlocking logic. Rules are written once per object type, and the compiler instantiates them on every concrete object of the plant, from that station’s own topology.
A few rules, a few hundred conditions.
What a signalling engineer writes is short. What the plant runs is not, and the difference is produced by the compiler rather than by hand.
An Interlocking is a set of logic conditions. A route is requested, locked, released. A point is driven normal or reverse and detected there. A signal clears only when everything ahead of it agrees. A real plant has hundreds of such logics, and they differ in the objects they are attached to, not in what they say.
GRAIL is written to that grain. A rule describes one object type; the compiler expands it over every object of that type the plant actually contains. Change station and the same rules recompile unchanged against a different topology.
Two independent inputs
- The rules: what the Interlocking does, per object type
- The schematic: which objects exist and how they are connected
They are independent on purpose. The same rules compile on different plants, and the same plant compiles with different rules. That independence is what turns a national signalling standard into something encoded once rather than reinterpreted per project.
Nothing topological is left to run time.
The station is known when the rules are compiled, so the compiler walks the topology once, at build time. A rule that speaks of every point a route runs over becomes, for each concrete route, the explicit list of the points that route actually runs over.
What runs in the field is therefore only the conditions that this station needs: no search through the plant, no loop, nothing that depends on how large the station is. That keeps the generated logic reviewable and its timing predictable.
A language deliberately small.
- Boolean-oriented, readable by signalling engineers
- Seven reserved words in total; everything else is contextual
- Variable names can come from plant specifications written by other people
- Object types include STATION, ROUTE (main, shunting, calling-on), SIGNAL, POINT, TC, LEG and LEVEL CROSSING
- Restricted enough to make verification tractable
What the compiler produces.
Four files. Three of them are for the people who wire the plant and configure the displays, which is why they are CSV and open in Excel.
Reproducible by design.
Two builds of the same plant produce identical files, down to the byte. Without that, two versions cannot be compared, and a signalling change that cannot be compared is a change that has to be reviewed from scratch.
The terminal map is a wiring document.
Passing the previous map keeps assigned terminals from moving, because a terminal that moves is wiring to be redone in the field. One board serves one direction, so two variables cannot land on the same physical terminal from opposite sides. A variable no longer in the plant is a warning, not an error, and its terminal returns to the free pool.
The failure mode nobody talks about.
Decoding by position is fast and compact. It also has one serious way to break, and GRAIL closes it explicitly.
The viewer payload is the raw dump of the attribute structure, decoded by position. A viewer holding yesterday’s map against a node running today’s binary would shift everything by one byte, and the result would not be an error. It would be a plausible, false plant: the right aspect on the wrong object.
Both the generated header and the viewer file carry a layout fingerprint, and it travels with the payload.
Maturity, stated rather than implied.
- What is yours: the rules themselves and their validation, the safety case, site acceptance and approval
- What we will publish once permitted: a worked example on one real station, showing the artefact at each step
- What we will not claim: that the logic derives itself from the topology. It does not. The rules are written; the expansion over the topology is what is deterministic