Traffic Management System: From Traffic Supervision to Automated Railway Operations

by

The train is the most visible part of railway automation. It is where automatic driving happens, where ETCS supervision is displayed, and where the transition towards GoA4 becomes immediately tangible.

But railway operation is not performed inside the train alone.

A train runs in a shared network. Its movement interacts with other trains, infrastructure availability, platform occupation, passenger connections, freight priorities, rolling stock resources, energy objectives, disruptions and degraded situations. The best local trajectory for one train is not always the best operational trajectory for the network.

This is where the Traffic Management System becomes central.

The future TMS is not only a tool for traffic supervision. It is the operational orchestration layer that maintains the real-time railway plan, coordinates train movements, supports regulation decisions, connects network objectives with train-level systems and makes automated operation usable at railway scale.

In automated railway operations, ATO drives the train, ETCS protects the train, and TMS orchestrates the railway operation.

Recommended reading

For a good understanding of the concepts discussed in this article, I recommend reading first:

  1. ERTMS: the European Rail Traffic Management System
  2. ERTMS/ETCS: the European Train Control System
  3. ERTMS/ATO: Europe’s Interoperable Train Autopilot
  4. Railway Automation: From Automatic Driving to Autonomous Operation

Executive Summary

Railway automation cannot be reduced to automatic train driving. ATO can control traction and braking. ETCS can supervise the safety envelope. GoA4 can transfer responsibilities from onboard staff to the wider railway system. But none of these capabilities can operate effectively without a network-level layer able to coordinate railway operation in real time.

This is the strategic role of the Traffic Management System. The TMS maintains the operational plan of the railway network, detects deviations, predicts future conflicts, supports regulation decisions and translates network-level objectives into constraints that can be used by train-level systems.

The Real-Time Traffic Plan is central to this architecture. It represents the operational plan updated according to the current and predicted traffic situation. It defines not only what was originally planned in the timetable, but what should now happen on the network.

The Train Path Envelope translates this network-level operational plan into train-level constraints. It does not define the detailed speed profile of the train. Instead, it defines the envelope within which ATO or C-DAS can compute an efficient trajectory while remaining compatible with the network plan. This preserves a clean separation of responsibilities: the TMS coordinates the network, ATO or C-DAS optimises the train movement, ETCS supervises the safety envelope, and the train executes the movement.

The TMS–ATO relationship must also work as a feedback loop. The TMS sends operational constraints to train-level systems, but the train also provides feedback: status, location, speed, forecasts, expected arrival times and operational constraints. This feedback allows the TMS to refine conflict detection, update the Real-Time Traffic Plan and support better regulation decisions.

The future TMS must also support decision-making, disruption management and resilience. Automated railway operation requires operational decisions to become more explicit, more traceable and more directly usable by technical systems. This does not mean removing traffic controllers. It means giving them better forecasts, better scenario evaluation, clearer operational consequences and better tools for managing complexity.

From an architecture perspective, the future TMS is not simply a software tool for traffic controllers. It is a system integration layer connecting planning, real-time operation, traffic control, interlockings, ETCS, ATO, C-DAS, neighbouring TMS, rolling stock and crew management, energy management, maintenance systems, passenger information and freight information.

This is why TMS is central to DATO. A GoA4 train cannot decide network priorities alone. It cannot resolve every conflict locally. It cannot coordinate passenger connections, freight priorities, rolling stock rotations, maintenance interventions and cross-border traffic by itself. Automated trains need an operational orchestrator.

ATO drives the train. ETCS protects the train. TMS orchestrates the railway operation.

Last modified: 2026-08

Reading time: 28 min

This article by Bastian Simoni is licensed under CC BY-NC-SA 4.0

Written by Bastian Simoni

Bastian Simoni is a railway system architect working at the intersection of signalling, automation and digital railway operations. Voie Libre is his personal blog on the system architecture behind the future European railway: ERTMS, DATO, automation, migration and interoperability.

LinkedIn

Content

  1. Why traffic management matters for railway automation
  2. From supervision to operational orchestration
  3. From timetable to Real-Time Traffic Plan
  4. From network plan to train-level constraints
  5. The TMS–ATO feedback loop
  6. Decision support, disruption and resilience
  7. TMS as a system integration layer
  8. Human-in-the-loop operation
  9. TMS and GoA4
  10. Architecture perspective
  11. Migration towards automated railway operations
  12. Conclusion

1. Why traffic management matters for railway automation

The train is the natural starting point for railway automation. It is the object that moves, the place where the driver sits, and the system where ATO, ETCS onboard, traction and braking functions become visible.

Yet a train never operates alone.

It runs through a network made of routes, junctions, platforms, gradients, speed restrictions, maintenance windows, level crossings, yards, stations, energy constraints and operational priorities. It interacts with other passenger trains, freight trains, empty stock movements, technical movements, delayed trains and trains coming from neighbouring control areas. Its operational value depends not only on how well it moves by itself, but on how well its movement is coordinated with the rest of the railway.

A train can compute a locally efficient trajectory and still create a poor network result. It may save energy while arriving too early at a constrained point. It may optimise its own movement while creating a conflict downstream. It may recover time that another train needs more. It may follow targets that are no longer relevant because the traffic situation has changed.

This is the reason traffic management becomes central to railway automation. Automated driving needs an operational context. It needs to know not only how the train should move, but why it should move in a certain way at a given moment in the network.

The Traffic Management System provides this context. It maintains the operational plan, monitors deviations, predicts conflicts, supports regulation, updates train paths and connects planning, operation and train-level execution.

In a manually driven railway, many adjustments can still be handled through human interpretation, radio communication, route knowledge and local judgement. In an increasingly automated railway, these adjustments must become more structured, more digital and more directly usable by technical systems. This does not mean that the TMS replaces traffic controllers. It means that the TMS becomes the system that makes operational intent executable by a digital railway.

Figure 1 — TMS as the operational orchestration layer: from planning systems to train execution, with operational feedback.

2. From supervision to operational orchestration

A conventional traffic management tool helps operators understand what is happening on the network. It displays train positions, highlights delays, shows conflicts and gives traffic controllers a shared view of the operational situation. This supervision role remains necessary, because railway operation will always need a reliable view of the current traffic state.

But future railway automation requires more than visibility.

The railway needs a system able to define what should happen next. It must transform a planned timetable into a real-time operational plan, detect conflicts before they materialise, compare regulation strategies, coordinate train movements with infrastructure availability and maintain consistency with rolling stock resources, crew constraints, station operations, passenger information, freight priorities, energy objectives and neighbouring traffic management domains.

This changes the nature of the TMS. It is no longer only an interface for dispatchers. It becomes a coordination system.

The key point is that railway automation cannot scale if each train optimises itself independently. A railway network is not a set of isolated trajectories. It is a shared and constrained operational system. Capacity, punctuality, robustness and resilience are network properties, and they emerge from coordination.

The TMS is therefore the operational layer that keeps the railway coordinated. It connects the timetable, the real-time traffic situation, traffic control systems, train-level automation and operational decision-making. Its value lies not only in displaying information, but in maintaining a shared operational reference that the rest of the system can use.

This shared reference is the Real-Time Traffic Plan.

Figure 2 — TMS, interlocking, ATO/C-DAS and ETCS: different systems, different responsibilities.

3. From timetable to Real-Time Traffic Plan

A timetable gives the railway its planned structure. It allocates capacity, defines train paths, organises passenger services and freight paths, and supports rolling stock rotations, crew planning and infrastructure usage.

Operation begins when the timetable meets reality.

Trains may be delayed. Dwell times may vary. Freight trains may depart late. Infrastructure may become unavailable. Temporary speed restrictions may appear. Passenger connections may need to be preserved. Maintenance interventions may change the available capacity. A degraded mode may reduce the number of trains that can be operated safely through a given area.

The operational plan must therefore evolve continuously. The railway does not only need a timetable. It needs a live operational reference.

This is the role of the Real-Time Traffic Plan.

The Real-Time Traffic Plan, or RTTP, represents the operational plan updated according to the current and predicted traffic situation. It defines not only what was originally planned, but what should now happen. It can include routes, timing points, stopping and passing times, operational constraints and regulation decisions derived from the current network state.

This distinction is essential for automation. ATO cannot simply follow a static timetable. It needs targets that reflect the actual operational situation. If a train is delayed, the question is not only how that train should recover. The question is how the network should be reorganised so that the overall operation remains robust.

The TMS therefore maintains the real-time operational truth of the railway network. It observes the traffic state, predicts its evolution, detects conflicts, supports regulation and updates the plan.

This is already important in today’s railway. It becomes critical when train movements are increasingly computed and executed by technical systems. Once the railway starts to automate execution, the operational plan must be expressed in a form that those systems can understand.

This is where the TMS becomes the bridge between railway operation and train-level automation.

Figure 3 — From planned timetable to Real-Time Traffic Plan.

4. From network plan to train-level constraints

ATO and C-DAS operate at train level. Their role is to compute or support the trajectory of a specific train: when to accelerate, when to coast, when to brake, how to respect time targets, how to save energy, how to stop accurately and how to remain compatible with signalling constraints.

The TMS works at network level. It must consider all trains, conflicts, operational priorities, infrastructure constraints and regulation objectives.

The architecture challenge is to connect these two levels without making the system either too centralised or too fragmented.

If the TMS directly imposed a detailed speed profile on every train, the system would become too centralised and rigid. The train would have little room to optimise energy, comfort, adhesion, local driving constraints or rolling stock behaviour. Conversely, if the TMS provided only a broad timetable, train-level systems might not have enough information to remain aligned with the actual network situation.

The Train Path Envelope provides one possible answer.

The Train Path Envelope, or TPE, defines the constraints within which the train trajectory must be generated. It may include timing points, time windows, operational constraints and other information required to ensure that the movement of the train remains compatible with the network plan.

The TPE is not the trajectory itself. It is a constraint envelope. It allows the TMS to express the operational constraints that matter for the network, while leaving ATO or C-DAS enough freedom to compute an efficient train trajectory.

This separation of responsibilities is fundamental. The TMS coordinates the network. ATO or C-DAS optimises the train movement. ETCS supervises the safety envelope. The train executes the movement.

Without this separation, railway automation would risk becoming too centralised or too fragmented. A future TMS–ATO architecture must avoid both extremes.

5. The TMS–ATO feedback loop

The relationship between TMS and ATO cannot be one-way. Sending a plan to the train is not enough. The train must also inform the TMS about what is happening and what is likely to happen next.

This is the TMS–ATO feedback loop.

The TMS needs reliable information about train status, location, speed, delay, forecasted arrival times, operational constraints and expected behaviour. It needs to know whether a train can still meet its planned timing points, whether it is likely to create a conflict, whether it can recover time, whether it should be regulated, or whether the plan should be changed.

Connected ATO and C-DAS can make this feedback more accurate and more useful. The TMS can receive better forecasts of train behaviour. It can understand whether the current trajectory remains compatible with the operational plan. It can refine conflict detection. It can update the RTTP with more reliable information. It can generate better regulation decisions.

The loop is simple in principle, but powerful in operation. The TMS provides an updated operational plan. ATO or C-DAS translates this plan into train-level constraints. The train computes or follows a trajectory. The train sends operational feedback. The TMS updates the plan. New constraints can then be sent if needed.

This is the shift from static timetable execution to dynamic railway operation. The timetable is no longer treated as a fixed object that the railway tries to follow as much as possible. It becomes part of a continuously updated operational reference.

This does not mean that everything becomes automatic. Human operators remain essential. Traffic controllers must understand the situation, validate decisions, manage exceptions and supervise the behaviour of the system. But the system becomes more capable of supporting them. It can detect deviations earlier, forecast conflicts earlier, compare scenarios earlier and transmit operational constraints more directly.

This is one of the major benefits of linking TMS with ATO and C-DAS. Train movement becomes more predictable for the network, and the network plan becomes more usable by the train.

Figure 4 — TMS–ATO feedback loop: the network plan informs ATO, and ATO informs the network.

6. Decision support, disruption and resilience

Traffic management is a decision-making activity.

When the network operates close to the timetable, decisions may remain limited. Trains follow their planned paths, routes are set, and small deviations are absorbed. But when the network moves away from nominal operation, decisions become central.

A traffic controller may need to decide which train should go first, whether a passenger train should be held to preserve a connection, whether a freight train should be overtaken, whether a train should be rerouted, whether a regulation decision should remain local, or whether the whole operational plan should be updated. The best decision may depend on punctuality, passenger impact, freight priorities, energy consumption, available rolling stock, crew constraints and the expected duration of the disruption.

These decisions are already difficult today. Automation makes them more explicit.

When the driver remains in the cab, part of the operational adjustment can still be managed through experience, radio communication and local interpretation. As more functions become automated, operational decisions must be expressed in a way that technical systems can use. A decision is no longer only a human instruction. It becomes a structured operational constraint, a revised plan, a route allocation, a timing objective or a recovery strategy.

Future TMS functions will therefore increasingly include decision support and, in some bounded contexts, automated decision-making. Decision support does not mean replacing the traffic controller. It means supporting the controller with better forecasts, better comparison of alternatives and clearer understanding of consequences.

A future TMS can help detect conflicts before they occur, compare regulation strategies, evaluate punctuality, capacity, energy or passenger impacts, test scenarios and support the implementation of the selected plan.

Automated decisions must still be approached carefully. Railway traffic management is operationally complex and safety-relevant. Decisions must be explainable, traceable, validated and supervised. They must respect operational rules, roles, responsibilities and safety constraints. The purpose is not to remove humans from traffic management. The purpose is to build a better human-system organisation.

This becomes particularly important in disruption management. A railway system is not defined only by nominal operation. It is also defined by its ability to recover.

Disruptions involve more than train order. They involve infrastructure managers, railway undertakings, traffic controllers, maintenance teams, station managers, rolling stock management, crew management, passenger information, freight customers and sometimes emergency services.

A disruption creates questions that no single system can answer alone: what happened, which assets are affected, which trains are impacted, which resources are needed, how long the disruption may last, which services should be cancelled, rerouted, delayed or turned back, and which operational plan remains feasible.

The TMS cannot solve all these questions by itself. But it can provide the structured operational environment in which these questions can be addressed.

This matters for automation because degraded situations must become more explicit. In GoA4, the train cannot rely on a driver or onboard staff to interpret every situation. The operational system must detect, decide, communicate and recover through structured processes. The TMS is one of the systems that makes this possible.

7. TMS as a system integration layer

The future TMS cannot work in isolation.

Railway operation depends on many systems: traffic control, interlockings, ETCS trackside systems, ATO trackside systems, C-DAS, planning tools, neighbouring TMS environments, yard management, station management, energy management, crew management, rolling stock management, maintenance systems, passenger information, freight information, simulation tools and data platforms.

The TMS does not replace these systems. It coordinates them from an operational perspective.

This makes the TMS part of a wider operational architecture. Each interface matters. The link with traffic control systems allows operational plans to become route-setting actions. The link with ATO or C-DAS allows network-level plans to become train-level constraints. The link with planning systems allows real operations to improve future timetables.

The link with energy management allows regulation decisions to consider energy constraints. The link with rolling stock and crew management ensures that the traffic plan remains compatible with available resources. The link with maintenance systems allows infrastructure restrictions and asset failures to be included in operational decisions. The link with neighbouring TMS is essential for corridors and cross-border traffic. The link with passenger information systems is essential for service quality.

This is also why TMS is a European interoperability topic. Europe does not need one single TMS. But it does need traffic management environments that can cooperate across borders, corridors and operational domains. This requires standardised processes, data exchanges, interfaces and operational concepts.

If railway automation is to scale in Europe, traffic management must also become more interoperable.

This is not only a technical interface question. It is an operational architecture question. Different TMS environments must be able to share operational intent, constraints, traffic status, predictions and decisions in a way that supports cross-border and multi-actor railway operation.

The future TMS is therefore not only a national operational tool. It is one of the components of European railway interoperability.

8. Human-in-the-loop operation

The future TMS will be more automated, but humans will remain central to traffic management. In fact, automation makes the human role more important, because the operational system becomes more powerful and more complex at the same time.

Traffic controllers, dispatchers and operational staff must understand what the system is doing. They must trust the information provided. They must be able to validate decisions, intervene when needed and manage situations outside the nominal scope of automation.

A more capable TMS can also create new risks if the human-system interaction is poorly designed. If the system generates forecasts, detects conflicts, proposes solutions, updates the RTTP, exchanges data with ATO and supports disruption management, the operator must understand the logic behind the recommendations. Otherwise, automation may increase workload instead of reducing it.

The challenge is therefore not only to add functions. The challenge is to make the operational system usable.

The TMS should support situation awareness. It should show what is happening, what may happen, why a conflict is detected and what the consequences of different decisions may be. It should help compare alternatives without overwhelming the operator. It should support traceability and allow the operator to remain in control of the operational process.

This is why simulation and human-in-the-loop validation are essential. Future TMS functions should be tested with operators, realistic scenarios, degraded situations and ATO/C-DAS interactions before being deployed in real operation.

The question is not only whether the algorithm works. The question is whether the operational system works.

Railway automation is never only software automation. It is socio-technical automation. The future TMS must be designed with this in mind.

9. TMS and GoA4

GoA4 changes the responsibility model of railway operation.

In GoA4, no driver or onboard staff is required for normal train operation. This does not mean that operational responsibilities disappear. It means that more responsibilities must be carried by the wider railway system.

The train must not only move automatically. It must execute a mission inside a network. It must know where to go, when to go, under which constraints, how to react to changes, how to report its status, how to request assistance, how to remain coordinated with other trains and how to be recovered when needed.

A GoA4 train cannot decide network priorities alone. It cannot resolve every conflict locally. It cannot determine the global impact of a delay. It cannot coordinate passenger connections, rolling stock rotations, maintenance interventions, freight priorities and cross-border traffic by itself.

The automated train therefore needs an operational orchestrator.

The TMS does not replace onboard autonomy, and it does not make the train intelligent by itself. But it provides the network-level operational context that onboard automation needs. It connects the train mission to the traffic situation, the operational plan, the regulation strategy and the wider railway system.

In GoA2, the TMS can improve the performance of automatic driving. In GoA4, the TMS becomes part of the architecture that makes unattended operation operationally possible.

This is an important shift. ATO can be introduced as a train-level automation function. GoA4 requires the railway operation itself to become more structured, digital, connected and resilient.

This is why the TMS is one of the key building blocks of DATO.

10. Architecture perspective

From an architecture perspective, the future TMS can be understood through three layers.

The first is the network layer. At this level, the TMS manages the operational plan. It monitors traffic, predicts future states, detects conflicts, supports regulation, updates the RTTP and coordinates with neighbouring networks. This is the level of capacity, punctuality, resilience and traffic priorities.

The second is the train path layer. At this level, network decisions are translated into constraints usable by train-level systems. The Train Path Envelope is one example of this translation. Journey Profiles, Segment Profiles or other operational constraints may also be used depending on the architecture and applicable standards.

The third is the train trajectory layer. At this level, ATO or C-DAS computes or supports the movement of the train. It considers operational constraints, train characteristics, infrastructure data, signalling constraints, energy optimisation and actual train status.

These three layers must be aligned. If the network layer does not update the plan, the train path layer receives obsolete information. If the train path layer does not provide useful constraints, ATO or C-DAS cannot optimise effectively. If the train trajectory layer does not provide feedback, the TMS cannot predict traffic accurately.

The architecture must therefore be designed as a feedback system rather than a linear chain. The network plan informs the train path envelope. The train path envelope constrains the train trajectory. The train trajectory produces operational feedback. This feedback updates the plan. The loop is the core of automated railway operation.

The TMS is also defined by its boundaries.

It is not the train protection system. ETCS remains the protection layer, supervising Movement Authorities, speed limits and braking curves, and ensuring that the train remains within the safe envelope.

It is not the automatic driving system. ATO drives the train, controls traction and braking, and follows operational targets.

It is not the traffic control system alone. Traffic control and interlocking systems manage route setting and field elements. The TMS provides the operational plan and regulation logic that traffic control can execute.

It is not a magic optimiser. It cannot compensate for unrealistic timetables, insufficient capacity, poor data quality, missing interfaces or unclear operational responsibilities.

The TMS is an orchestration layer. Its value depends on the quality of the data it receives, the interfaces it has, the operational rules it follows, the human users it supports and the systems it coordinates.

The future TMS must therefore be designed as part of a wider railway architecture.

11. Migration towards automated railway operations

The transition towards future TMS capabilities will not happen in one step.

Traffic management practices differ between networks. TMS maturity differs. Interfaces differ. ATO and C-DAS deployment differs. Data models differ. Operational rules differ. The level of automation differs. Migration must therefore be progressive.

A realistic migration path starts with improving the real-time operational plan. The TMS must maintain a reliable and up-to-date view of routes, timings, constraints, deviations and forecasts. Without this foundation, more advanced automation will not have a stable operational reference.

The next step is better forecasting and conflict detection. The system must detect future conflicts early enough to allow useful regulation decisions. This requires reliable data, accurate train behaviour forecasts and appropriate models of infrastructure, timetable and operational constraints.

Then comes the connection with C-DAS and ATO. The operational plan must become usable by train-level systems. This requires standardised data exchanges, train path constraints, feedback messages and clear interface rules.

Once connected train-level systems provide status, forecasts and expected arrival information, the TMS can use this feedback to update the plan and improve decisions. The railway then moves from a static planning logic towards a dynamic operational loop.

More advanced decision support, scenario evaluation and disruption management can then be introduced. Traffic controllers should be able to compare regulation strategies and understand their consequences before implementing them.

Finally, some decisions may progressively become automated in well-defined contexts. This should not be understood as a sudden jump towards fully automated traffic management. It should be treated as a sequence of controlled operational envelopes. Each envelope defines what can be automated, under which conditions, with which interfaces, with which data quality and with which human supervision.

This is similar to the broader logic of DATO. The target is not reached through a single technological leap. It is reached through controlled technology infusion.

For TMS, this means that migration must focus not only on software deployment, but on operational maturity. The railway must learn how to express operational intent digitally, how to make decisions traceable, how to exchange constraints with train-level systems, how to manage feedback loops and how to keep humans effectively in the loop.

The future TMS is not only a new tool. It is a new operating architecture.

12. Conclusion

ATO automates train driving. ETCS protects train movement. TMS orchestrates railway operation.

This is the key idea.

As railway automation progresses, the Traffic Management System becomes more than a supervision and regulation tool. It becomes the operational layer that connects planning, real-time traffic management, ATO, C-DAS, traffic control, disruption management, decision support, simulation and interoperability.

Without a strong TMS, ATO risks remaining a local train automation function. With a strong TMS, ATO becomes part of a coordinated railway operation.

This is especially important for Europe. The European railway network is heterogeneous, open, cross-border and progressively migrated. Automation will not scale only through onboard functions. It will require interoperable operational orchestration.

The TMS of the future is one of the systems that makes this possible. It is the bridge between the planned railway and the operated railway, between network optimisation and train trajectory, between human traffic management and automated railway operation.

The future of railway automation is therefore not only about trains that drive automatically. It is also about railway networks that can coordinate, adapt and recover more intelligently.

That is the role of the Traffic Management System: from traffic supervision to automated railway operations.

Documentation and further reading

Voie Libre articles

Railway grades of automation
Automatic Train Protection
Automatic Train Operation
ERTMS: the European Rail Traffic Management System
ERTMS/ETCS: the European Train Control System
ERTMS/ATO: Europe’s Interoperable Train Autopilot
Railway Automation: From Automatic Driving to Autonomous Operation

European R&D documentation