1) Engineer selects the train's starting position (the station and departure gate) and selects the route.

2) Train software presses the equivalent of a 'trip reset' button that our cars have had forever. Current Position = 0.0

3) The train and the engineer each program a maximum speed. The train determines the maximum speed by selecting the maxSpeed which has the highest Position less than currentPosition. The engineer determines the maximum speed as she normally would.

4) The train's speed must not exceed the lower of the two configured maximum speeds.

This probably runs into issues with accumulated error, especially if the error in speed measurement has a serial correlation.

Typically there's no single nor double integration required for a wheeled ground vehicle; distance (revolutions times wheel circumference) is the primary measurement, with speed being trivially computed from that plus an accurate clock.

The lack-of-integration common in wheeled ground vehicles is highly beneficial to long-term speed & distance accuracy; it's a main reason why odometers were accurate for literally thousands of years prior to anyone knowing how to build an equally-accurate aircraft/spacecraft IMU. (The Romans were able to achieve <0.5% errors over hundreds of miles by the first century AD, something that no aircraft IMU was consistently able to achieve until after WWII).

That said, inertial nav can take a plane across the country without correction and get within sight of the target.

I think integrating actual speed while on rails would be vastly more accurate.

And really, it just need to augment gps.

And why would it be outdated if it works, and we (US) aren't using it.