It was just a software problem! For more detailed details, follow the link.
People used to joke, darkly, about signalling systems like
ETCS▸ being dependent for their safety on the software teams that write the stuff, who know nothing about railway signalling, never making any mistakes. (Now such scare stories are about AI.) This was an example, as the safety-critical parts of the system were not (
RAIB▸ said) really at SIL4 as required.
Speed restrictions are stored centrally, and sent to the train by radio. Temporary ones are loaded from a file, which involves a number of servers, with several processes running on each. One of those processes stopped, and none of the others, or anything else, registered that. But the display the signallers had to check the
TSRs▸ were being sent out said they were when they weren't.
Which proves what? That writing software to this kind of high integrity level and getting it right is hard, and checking it's been done right is hard too. Basing this one in part on an existing system, but not the basis for any further work, made some of this harder still. What it says more generally about the practicability of making such high-integrity systems for a reasonable cost - or at all - is by no means clear.