Traffic Management System: From Traffic Supervision to Automated Railway Operations

by

Railway automation is often presented from the train perspective: ATP supervises the train, ATO drives the train, and GoA4 transfers more responsibilities from humans to the technical system.

But automated trains do not operate alone; they run inside a shared network where every movement interacts with other trains, infrastructure constraints, disruptions, energy, resources and operational priorities. This is why railway automation also needs an operational orchestration layer.

The Traffic Management System provides this layer by maintaining the real-time operational plan, supporting regulation decisions and translating network-level objectives into constraints usable by train-level systems.

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 optimise traction and braking, ETCS can supervise the safety envelope, and GoA4 can transfer responsibilities from onboard staff to the technical system. But none of these capabilities can operate effectively without a network-level system able to coordinate railway operation in real time.

This is the strategic role of the Traffic Management System. The TMS is not only a supervision tool for traffic controllers. It is becoming the operational orchestration layer of automated railways: the system that maintains the Real-Time Traffic Plan, detects deviations, predicts conflicts, supports regulation decisions and translates network-level objectives into constraints that can be used by train-level systems.

The core architectural challenge is the alignment between three layers: the network layer, where traffic is planned and regulated; the train path layer, where network decisions are translated into train-level constraints; and the train trajectory layer, where ATO or C-DAS computes the actual movement of the train. The Train Path Envelope is one of the concepts that makes this separation possible. It allows the TMS to constrain train behaviour without directly imposing every detail of the speed profile.

The future TMS must also operate as a feedback system. It sends operational constraints to trains, but it must also receive train status, forecasts, expected arrival times and operational feedback. This feedback loop is essential for moving from static timetable execution to dynamic railway operation.

As automation progresses, the TMS becomes central to disruption management, resilience, human-in-the-loop decision-making and GoA4. A GoA4 train cannot coordinate network priorities, recover from disruption or optimise the whole railway alone. It needs an operational system that can see the network, manage dependencies and coordinate decisions.

From an architecture perspective, the TMS is therefore one of the systems that transforms ATO from a local train function into part of a coordinated railway operation. Without a strong TMS, automation remains fragmented. With a strong TMS, railway automation becomes operationally scalable.

Last modified: 2026-06

Reading time: 27 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
  13. Documentation and further reading

1. Why traffic management matters for railway automation

Railway automation is often discussed through the train. This is understandable. The train is the visible object. The driver is in the train. Automatic Train Operation controls traction and braking onboard the train. GoA4 is usually described as a train running without a driver or onboard staff.

But railway operation does not take place only inside the train. A train runs in a network. It depends on routes set by the traffic control system. It follows a timetable. It interacts with other trains. It may need to preserve a connection, give priority to another service, wait for an available platform, recover from a delay, avoid a future conflict, or adapt to a degraded infrastructure situation.

This is why the performance of an automated train is not only determined by its onboard automation. It is determined by the coordination between the train and the network.

A train can compute an efficient speed profile, but that profile may not be optimal for the railway system. It may save energy locally while creating a conflict downstream. It may recover time on one section only to wait at the next constrained point. It may follow a timetable that is already obsolete because the network situation has changed. It may optimise its own trajectory without considering another train that needs the same infrastructure later.

This is the reason traffic management becomes central to railway automation. Automation needs an operational context. It needs to know not only how a 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 sees the network. It knows the operational plan. It monitors deviations. It predicts conflicts. It supports regulation. It updates train paths. It connects planning, operation and train-level execution.

In a manually driven railway, many adjustments are still managed through human interpretation, communication and local judgement. In an 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 their 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 Traffic Management System is often described as a system used to monitor trains, supervise the timetable, detect deviations and support traffic controllers. This definition is correct, but it is too limited for the future automated railway.

In a conventional view, the TMS helps the operator understand what is happening. It supports supervision. It displays train positions. It detects delays. It gives traffic controllers a view of the operational situation.

In an automated railway, this is no longer enough.

The future TMS must help define what should happen next. It must support the transformation of a planned timetable into a real-time operational plan. It must detect future conflicts before they become operational constraints. It must help compare regulation strategies. It must coordinate train movements with infrastructure availability, rolling stock resources, crew constraints, energy considerations, station operations, passenger information, freight paths and neighbouring traffic management domains.

This changes the nature of the TMS. It is no longer only a user 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 collection of isolated trajectories. It is a shared and constrained system. Capacity, punctuality, robustness and resilience are network properties. 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

Railway operation starts from a timetable. The timetable allocates capacity. It defines train paths. It structures passenger services, freight paths, rolling stock rotations, crew planning and infrastructure usage.

But a timetable is not the same as operation.

Real traffic is dynamic. Trains are delayed. Dwell times 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.

This means that the operational plan must continuously evolve. 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 planned, but what should now happen. It can include routes, timing points, stopping and passing times, constraints and operational 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 the 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 automatic train operation is introduced. Once train movements are increasingly computed and executed by technical systems, 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 do not operate at network level. They 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 another level. It coordinates the network. It must consider all trains, conflicts, priorities, infrastructure constraints and operational objectives.

This creates one of the central architecture questions of automated railway operation: how can network-level decisions be translated into train-level constraints without making the system too rigid?

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. This distinction is important. 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, the train might not have enough information to remain aligned with the actual network situation.

The TPE is the compromise. 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 either too centralised or too fragmented. Too centralised, if the network tries to compute every detail of every train trajectory. Too fragmented, if each train optimises itself without sufficient network context.

The future TMS–ATO architecture must avoid both extremes.

5. The TMS–ATO feedback loop

The relationship between TMS and ATO cannot be one-way. It is not enough for the TMS to send a plan to the train. 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.

With connected ATO or C-DAS, this feedback becomes 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 becomes 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 planning to dynamic railway operation.

The timetable is no longer a fixed object that the railway tries to follow as much as possible. It becomes part of a continuously updated operational reference. The railway becomes more capable of adapting to the real traffic situation.

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, propose solutions earlier and transmit operational constraints more directly.

This is one of the major benefits of linking TMS with ATO and C-DAS. The 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 normally, decisions may remain limited. Trains follow the timetable, routes are set, and deviations remain small. But as soon as the network moves away from nominal operation, decisions become central.

Which train should go first? Should a passenger train be held to preserve a connection? Should a freight train be overtaken? Should a train be rerouted? Should a regulation decision be local, or should the whole operational plan be updated? Should a train slow down now to avoid stopping later? Which solution is best for punctuality, energy, passengers, freight and network recovery?

These decisions are already difficult today. They become even more important in automated railway operation.

Automation increases the need for explicit decision logic. When the driver remains in the cab, some operational adjustments can be managed through experience, radio communication and local interpretation. When more functions are automated, the operational decision must be expressed in a way that the technical system can use.

This is why future TMS functions increasingly include decision support and, in some bounded cases, 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 better 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.

However, automated decisions must 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 is especially 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. This is one of the most important architecture points.

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 is why the TMS should not be seen only as a software tool for traffic controllers. It is 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 this does not mean that humans disappear from traffic management.

On the contrary, automation makes human factors more important.

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 powerful TMS can also become more complex. 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 not only to add functions. The challenge is to make the human-system interaction usable.

The system 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 is often discussed through train automation: perception, onboard intelligence, train health monitoring, mission fitness, automatic processing, remote supervision, remote driving and fallback strategies.

But GoA4 is not only a train problem.

In GoA4, no driver or onboard staff is required for normal train operation. This means that more operational responsibilities must be handled by the 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.

This is why GoA4 is a system-of-systems challenge.

The automated train 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.

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. But 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 the 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.

This is why the architecture must be designed as a feedback system. It is not a linear chain. It is a loop.

Network plan. Train path envelope. Train trajectory. Operational feedback. Updated plan.

This loop is the core of automated railway operation.

The TMS is also defined by what it is not. It is not the train protection system. ETCS remains the protection layer. It supervises movement authorities, speed limits and braking curves, and ensures that the train remains within the safe envelope.

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

The TMS 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.

The TMS 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.

This is why the future TMS must be designed as part of a wider railway architecture.

11. Migration towards automated railway operations

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

Today, 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. This means that the migration must 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.

The next step is better forecasting and conflict detection. The system must detect future conflicts early enough to allow useful regulation decisions.

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.

The next step is the feedback loop. Connected ATO and C-DAS functions must provide status, forecasts and expected arrival information to the TMS. The TMS must use this feedback to update the plan and improve decisions.

Then the TMS can support more advanced decision support, scenario evaluation and disruption management. Traffic controllers should be able to compare regulation strategies and understand their consequences.

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. It is the bridge between network optimisation and train trajectory. It is the bridge 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