Moving Block Train Control

Moving-block operation requires a railway simulation to account for changing separation between trains. Train length, speed, acceleration and the surrounding network all affect how movements interact.

The requirement extends beyond trains following one another along a line. Junctions, single-track sections, passing loops, dwell times and speed restrictions introduce different operating conditions that need to remain consistent within the same simulation.

Closures and changing speed restrictions can alter the conditions during a run, requiring train behaviour to respond as the simulated operation changes.

The purpose of this work is to represent those behaviours for operational modelling and decision support. It concerns train movement within a simulation, rather than control of an operating railway.

I chose a separate C++ library for the decision engine because the control problem is computationally intensive. The aim was to keep simulation run times practical as the detail and complexity of the model increased.

Planimate provides the operational simulation around that component. My work included the integration, model construction, train graphs and reporting used to exercise and inspect its behaviour.

The separation allows the control behaviour to be tested independently of the wider simulation. The same C++ source is designed to build for Windows and Linux.

Keeping the engine separate also provides room to extend train-performance modelling when a project requires it. A full train-performance calculator is a possible future addition, subject to project scope.

Testing began with a small network and simple movements. I then added operating features, including node dwell and section speed restrictions, before building a larger network containing duplicated track, single-track sections and passing loops.

This progression made it possible to examine individual behaviours before reviewing their interaction across a more complex railway. The Planimate models provided an environment in which to observe movements, inspect data and repeat scenarios after changes.

Train graphs were the main visual review tool. They show movements across the network over time, making unexpected stops, prolonged waits and conflicting movements easier to identify. Data review provided a further check on train speeds and headways.

The train graphs exposed behaviours that required correction: a train remaining at a node while other trains passed it, an abrupt stop from running speed, or trains passing one another on single track. They also made it apparent when the operation became stuck because a train did not resume its journey.

These observations directed further investigation and correction. The identified behaviours were retested after changes, and there are no currently known operational problems in the tested scenarios.

Extended simulation runs also examined whether trains continued to circulate. Reaching the configured end time is insufficient if meaningful operational activity stopped earlier; movement records provide the evidence needed to distinguish the two.

The component is ready for integration into a project model, with final API documentation to complete. It has not yet been delivered to a client.

Further capability will be driven by project requirements, including whether more detailed train-performance calculations are needed.