[jandrese]

Lets say the modern CPU gets itself really tied up in knots and is out of action for a staggering 10ms. During that time a speeding train doing 350kph travels not quite a meter. Do trains run such tight scheduling that this isn't sufficient time to cause delay on actuating a switching element and cause an accident?

[skissane]

You have a legacy safety-critical system, which incorporates legacy hardware peripherals. How sensitive is it to changes in timing? You may not actually know. Do you want to do the engineering analysis necessary to prove that replacing one part of that system with potentially different timing is not going to cause problems? Or do you just seek out a replacement whose timing is as close as possible to the original?

The big issue may not be with the trains themselves but the communications protocols used to talk to signalling equipment and other peripherals. Changing the timing in the communication with them may lead to problems.

And what if the original software has race condition bugs which have never been surfaced, and the occasional inaccuracy in timing starts to surface them? Good luck fixing bugs in some obscure piece of PDP-11 software that was written in the 1970s.

[mycall]

You could always setup a train in a box system and iterate all the control logic sequences to verify being within margin of error. Once you know that, equipment substitution is straightforward.

[bluGill]

I have no idea. If this is real time control that could mean you keep running the motors in the switch long enough to damage something. Or maybe you go past the end of travel switch signal without reading it, the switch turns off and you never stop... There are a lot of ways real time systems can fail.

You are correct that 10ms is well within the margin of error for safety stopping a train, but it may be out of the margin for some subsystem in the control.