Traffic Management System: From Traffic Supervision to Automated Railway Operations

by

Railway automation is often presented from the train perspective. Automatic Train Protection supervises the train. Automatic Train Operation drives the train. ERTMS/ATO makes automatic driving interoperable. GoA4 transfers operational responsibilities from the driver and onboard staff to a wider technical and operational system.

But one question remains. Who orchestrates railway operation when trains become increasingly automated? This is where the Traffic Management System becomes essential.

A railway network is not a set of independent trains moving separately. It is a shared system, where each train movement interacts with other trains, infrastructure availability, operational constraints, rolling stock resources, crew constraints, energy management, passenger connections, freight paths, disruptions and degraded situations. Automation cannot therefore be understood only at train level.

A train may be able to drive automatically. But the railway still needs to decide when the train should run, where it should pass, which route it should take, how conflicts should be resolved, how delays should be managed, how disruptions should be recovered, and how the operational plan should be adapted in real time.

This is the role of the Traffic Management System. The TMS of the future is not only a supervision tool. It becomes the operational orchestration layer of automated railway operations.

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

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

Last update: 2026-06

Reading time: 25 min

Article summary

Railway automation is not only about automating train driving. It also requires the automation of railway operation.

In GoA2, ERTMS/ATO can control traction and braking under ETCS supervision, while the driver remains responsible for operational supervision. In GoA4, responsibilities previously managed by the driver and onboard staff must be transferred to a wider technical and operational system.

This transfer cannot be achieved only by adding more intelligence onboard the train. It also requires a more intelligent operational layer. This is the role of the Traffic Management System (TMS).

A TMS manages the operational plan of the railway network. It monitors the traffic situation, detects deviations, predicts future conflicts, supports regulation decisions, updates the real-time plan and coordinates with traffic control systems. When connected with ATO or C-DAS, the TMS becomes even more important.

The TMS can provide a Real-Time Traffic Plan. This plan defines routes, timing points, stopping and passing times, and operational constraints for trains. ATO or C-DAS can then translate this plan into a Train Path Envelope, which defines the constraints within which the train trajectory must be generated.

This creates a new architecture.

The TMS operates at network level. ATO/C-DAS operates at train trajectory level. ETCS supervises the safety envelope. The train executes the movement.

The challenge is to make these layers work together.

The future TMS must also support feedback loops. It must receive train status, forecasts and operational feedback. It must update the plan when traffic conditions change. It must interact with planning systems, simulation tools, neighbouring TMS, disruption management systems, rolling stock and crew management, energy management and passenger information.

In this sense, the TMS becomes more than a dispatching tool. It becomes the system that translates railway operation into executable and continuously updated constraints. This is why the TMS is a key building block of digital and automated railway operation.

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

Content

1. Why traffic management matters for railway automation

Railway automation is often discussed through onboard functions. This is understandable. The train is the visible object. The driver is in the train. Automatic driving is performed onboard the train. GoA4 is usually described as a train running without a driver or onboard staff.

But railway operation is not performed only inside the train. A train runs in a network. It interacts with other trains. It depends on routes set by traffic control. It follows an operational timetable. It may be delayed by another train. It may be rerouted because of a disruption. It may have to wait for a connection, give priority to another service, reduce speed to avoid a future conflict, or recover time when operational margins are available.

This means that 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 optimal speed profile. But if this profile is not aligned with the actual traffic situation, the result may be suboptimal. The train may save energy locally, but create a conflict downstream. It may arrive too early at a constrained point and then wait in front of a red signal. It may use available margins without considering another train that needs the same infrastructure later. It may follow a timetable that is already obsolete because the network situation has changed.

This is why traffic management is central to automation. The TMS provides the operational context in which automatic train operation becomes meaningful. It is the layer that sees the network. It knows the operational plan. It monitors deviations. It detects conflicts. It updates train paths. It supports regulation. It coordinates decisions that cannot be taken by a single train alone.

In a manually driven railway system, many operational adjustments are still managed through human interpretation, communication and dispatching decisions. In an automated railway system, these adjustments must become more structured, more digital and more directly usable by train-level automation systems.

This is the architectural role of the future TMS. It does not replace ATO. It does not replace ETCS. It does not replace traffic controllers. But it becomes the operational system that connects them.

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

2. What is a Traffic Management System?

A Traffic Management System is the system used to support the management of railway traffic. At a basic level, it helps monitor trains, supervise the operational plan, detect deviations, support regulation and provide information to traffic controllers.

But this definition is too narrow for the railway automation context. The future TMS must not only display what happens on the network. It must help decide what should happen next.

This includes several functions:

  • monitoring the current traffic situation;
  • comparing actual train movements with the planned timetable;
  • detecting delays and deviations;
  • forecasting future train positions;
  • identifying potential conflicts;
  • supporting conflict resolution;
  • updating the operational plan;
  • coordinating route setting with traffic control systems;
  • exchanging data with ATO and C-DAS;
  • interacting with neighbouring TMS;
  • supporting disruption management;
  • feeding passenger and freight information;
  • supporting planning feedback loops.

The TMS is therefore not only a user interface for dispatchers. It is a coordination system. It connects the timetable, the infrastructure, the real-time traffic situation, the regulation strategy, the control system and the trains.

This is particularly important in the European railway context. Mainline railway networks are heterogeneous. They involve multiple infrastructure managers, railway undertakings, rolling stock fleets, national rules, signalling systems and operational practices. Automation cannot scale in this environment if each train is optimised independently.

The railway system needs an operational reference shared between network-level decision-making and train-level execution. This shared reference is the real-time operational plan. The future TMS is the system that maintains this reference.

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 defines when trains are expected to run. It allocates capacity. It structures passenger services, freight paths, rolling stock rotations, crew planning and infrastructure usage.

But a timetable is not enough. Real traffic is dynamic. Trains may be delayed. Infrastructure may become unavailable. Dwell times may be longer than expected. A freight train may depart late. A passenger connection may need to be preserved. A temporary speed restriction may appear. A degraded mode may reduce capacity. This means that the operational plan must be updated. This is the role of the Real-Time Traffic Plan.

The Real-Time Traffic Plan, or RTTP, is the operational plan updated according to the current and predicted traffic situation. It is not only a static timetable. It is the live reference used to coordinate railway operations. It includes routes, timing points, stopping and passing times, and operational constraints. It allows the system to know not only what was planned, but what should now happen.

This distinction is essential for automation. ATO cannot simply follow yesterday’s timetable. It needs an operational plan that reflects the actual network situation. If a train is delayed, the question is not only how this train should recover. The question is how the network should be reorganised so that the global operation remains robust.

The TMS therefore updates the RTTP based on several functions:

  • traffic state monitoring;
  • traffic state prediction;
  • conflict detection;
  • conflict resolution;
  • operational plan update.

This creates a first key principle. The TMS is responsible for maintaining the real-time operational truth of the network. This truth must then be translated into information usable by the train. That is where the Train Path Envelope becomes important.

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

4. From Real-Time Traffic Plan to Train Path Envelope

ATO and C-DAS do not operate directly at network level. They operate at train level. Their task is to compute or follow a trajectory for a specific train: when to accelerate, when to coast, when to brake, how to respect timing constraints, how to save energy, how to stop accurately, how to remain compatible with signalling constraints.

The TMS, however, works at network level. It must coordinate all trains. This creates an architectural question: How can network-level decisions be translated into train-level constraints?

The answer is the Train Path Envelope. The Train Path Envelope, or TPE, defines the constraints within which the train trajectory must be generated. It can include timing points, time targets, time windows, and possibly additional constraints needed to ensure that the train movement remains compatible with the network plan.

The TPE is not the trajectory itself. It is the envelope within which the trajectory can be computed. This is an important distinction.

If the TMS directly imposed a detailed speed profile on the train, the system would risk becoming too rigid. The train would have little room to optimise energy, comfort or local driving strategy. If the TMS provided only a broad timetable, the train might not have enough information to avoid conflicts or remain aligned with the network plan.

The TPE is the compromise. It gives the train enough constraints to remain compatible with network operation, while allowing ATO or C-DAS to compute an efficient trajectory.

In other words:

  • The RTTP expresses the network-level plan.
  • The TPE translates this plan into train-level constraints.
  • The train trajectory is the local movement solution within these constraints.

This is one of the most important concepts for the future TMS–ATO architecture. It creates a clean separation of responsibilities.

The TMS coordinates the network. ATO/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.

5. TMS and ATO/C-DAS: the feedback loop

The relationship between TMS and ATO/C-DAS should not be one-way. It is not sufficient for the TMS to send a plan to the train. ATO/C-DAS must also provide operational feedback to the TMS, based on the train status, location, speed, forecasts and expected arrival times. This is the feedback loop.

The TMS needs to know how trains are actually progressing. It needs reliable information about location, speed, delays, forecasts, operational status and expected arrival times. It needs to know whether a train can still meet the planned timing points, whether it will arrive late, whether it can recover, whether a conflict is likely to appear, or whether a regulation decision must be changed.

This feedback is especially important when ATO or C-DAS is used. With a connected train, the TMS can receive more accurate forecasts of train behaviour. It can understand whether the current trajectory is compatible with the plan. It can update the RTTP with better information. It can refine conflict detection. It can compute better regulation decisions.

The loop becomes:

  • The TMS provides the updated operational plan.
  • ATO/C-DAS translates the plan into trajectory constraints.
  • The train computes or follows a trajectory.
  • ATO/C-DAS provides feedback to the TMS based on train status, location, speed, forecasts and expected arrival times.
  • The TMS updates the operational plan.
  • New constraints can be sent to the train if needed.

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

This does not mean that everything becomes automatic. Human operators remain important. Traffic controllers still need to understand the situation, validate decisions, manage exceptional cases, and supervise the behaviour of the system.

But the system becomes more capable of supporting them. It can detect deviations earlier. It can forecast conflicts earlier. It can propose solutions earlier. It can transmit operational constraints to trains more directly. It can reduce the dependency on voice communication. It can make railway operation more consistent.

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

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

6. Decision support and automated decisions

Traffic management is a decision-making activity. When the network operates normally, decisions may be limited. The timetable is followed. Routes are set. Trains run according to plan. But as soon as deviations appear, decisions become necessary.

Which train should go first? Should a train be held to preserve a connection? Should a freight train be overtaken? Should a train be rerouted? Should a speed instruction be sent to avoid stopping later? Should a platform change be used? Should a conflict be solved locally, or should the whole operational plan be updated?

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

Automation increases the need for explicit decision logic. When the driver is still in the cab, many 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 form that the technical system can use. This is why future TMS functions increasingly include decision support and, where appropriate, automated decision-making. Decision support does not mean replacing the traffic controller. It means supporting the traffic controller with better information, better forecasts and better scenario evaluation.

A decision support system can help:

  • detect conflicts before they occur;
  • compare several possible regulation strategies;
  • estimate the impact of each decision;
  • evaluate punctuality, capacity, energy or passenger consequences;
  • test “what-if” scenarios;
  • propose an optimised solution;
  • support the implementation of the selected solution.

This is particularly useful for very short-term decisions. In dense traffic, conflicts may develop quickly. A late decision can reduce the available options. If the TMS can detect a future conflict early and propose countermeasures, the traffic controller can act before the situation becomes critical.

In some constrained cases, certain decisions may even be automated. But this must be approached carefully. Railway traffic management is a safety-critical and operationally complex domain. Automated decisions must be explainable, traceable, validated and supervised. They must respect operational rules, responsibilities and safety constraints.

The objective is not to remove humans from traffic management. The objective is to make the human-system organisation more efficient. The TMS becomes a decision layer. It helps transform traffic data into operational choices.

7. Disruption management and resilience

A railway system is not defined only by nominal operation. It is also defined by its ability to recover. Disruptions are part of railway operation.

A train can fail. Infrastructure can fail. A signal can be unavailable. A platform can be blocked. A passenger incident can occur. A maintenance intervention can become necessary. Weather can affect operations. A delay can propagate through the network.

In these situations, the TMS must support more than traffic regulation. It must support disruption management. Disruption management is not only about finding a new train order.

It involves several actors:

  • infrastructure managers;
  • railway undertakings;
  • traffic controllers;
  • operational control centres;
  • maintenance teams;
  • station managers;
  • crew management;
  • rolling stock management;
  • customer information systems;
  • emergency services in some cases.

This is where the TMS becomes part of a multi-actor coordination system.

A disruption creates operational questions: What happened? Which assets are affected? Which trains are impacted? Which resources are needed? How long will the disruption last? Which services should be cancelled, rerouted, delayed or turned back? How should passengers be informed? How should freight customers be informed? Which maintenance intervention is required? Which operational plan is now feasible?

The future TMS cannot answer all these questions alone. But it can provide a structured environment in which the relevant information is collected, prioritised and used. Decision support becomes essential here.

In disrupted situations, workload increases. Information becomes uncertain. Several actors must coordinate. The risk of inconsistent decisions grows. A TMS integrated with disruption management can help present the relevant situation, rank alarms by severity, support root cause identification, propose procedures, coordinate communication and support recovery.

This is important for automation. As railways become more automated, degraded situations must be handled more explicitly.

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.

8. TMS as a system integration layer

The future TMS cannot work in isolation. This is one of the most important system architecture points.

A TMS must interact with several systems:

  • traffic control and supervision systems;
  • interlockings and route setting systems;
  • ETCS trackside systems;
  • ATO trackside systems;
  • C-DAS systems;
  • planning systems;
  • neighbouring TMS;
  • yard management systems;
  • station management systems;
  • energy management systems;
  • crew management systems;
  • rolling stock management systems;
  • asset and maintenance systems;
  • passenger information systems;
  • freight information systems;
  • simulation tools;
  • data integration platforms.

This is why the TMS should not be seen only as a software tool used by 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/C-DAS allows network-level plans to become train-level trajectories. The link with planning systems allows real operations to improve future timetables. The link with energy management allows operational decisions to consider energy constraints. The link with crew and rolling stock management allows the traffic plan to remain compatible with operational resources. The link with maintenance systems allows infrastructure restrictions and asset failures to be included in traffic 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 why the TMS of the future becomes an integration layer. Not in the technical sense of being the only data platform. But in the operational sense of coordinating the systems that railway operation depends on.

This is especially important in Europe. A train may cross several infrastructure domains. A corridor may involve several traffic management centres. Disruptions may propagate across borders. Traffic regulation decisions in one country may impact trains in another.

If automation is to become interoperable, traffic management must also become more interoperable. This does not mean one single European TMS. It means standardised processes, data exchanges, interfaces and operational concepts that allow different TMS environments to cooperate.

The future TMS is therefore not only a national operational tool. It is also a component of European railway interoperability.

9. From planning to operations and back

Railway planning and railway operation are often treated as separate worlds. Planning defines the timetable. Operations execute it.

But in reality, the two worlds must continuously interact. The timetable is only valuable if it can be operated robustly. Operations are only efficient if the timetable provides realistic margins, good capacity allocation and workable recovery options. This is why feedback loops between planning and operations are essential.

A TMS can provide operational data that helps improve future planning:

  • where delays occur;
  • where conflicts frequently appear;
  • where margins are too small;
  • where dwell times are unrealistic;
  • where overtaking patterns are fragile;
  • where infrastructure constraints reduce robustness;
  • where ATO or C-DAS could improve performance;
  • where energy-efficient driving conflicts with timetable constraints;
  • where capacity simulations do not match operational reality.

This information can be used to improve timetable design, capacity allocation, simulation models and operational rules.

In the opposite direction, planning systems can provide the TMS with better information about intended capacity usage, operational priorities and planned constraints. This creates a loop. Planning informs operation. Operation informs planning. Simulation helps assess both.

This is important for automated railway operation because automation needs high-quality data and realistic constraints. If the timetable is unrealistic, ATO will not fix it. If the operational plan is not updated, automatic driving may optimise against obsolete targets. If simulation models are disconnected from real operations, capacity gains may remain theoretical.

The TMS is therefore a bridge between planned railway and operated railway. It helps turn the railway into a learning system. This is a major step for the digital railway.

Figure 5 — Feedback loops between planning, operations and simulation.

10. Human factors and 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 even 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. They must intervene when needed. They must manage situations that are outside the nominal scope of automation.

This requires careful HMI design. 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/C-DAS and supports disruption management, the operator must be able to understand the logic behind the recommendations. Otherwise, automation can increase workload instead of reducing it.

The challenge is not only to add functions. The challenge is to make the human-system interaction usable.

A traffic controller should not be overwhelmed by alarms, forecasts, alternative plans and technical data. The system should support situation awareness. It should show what is happening. It should show what may happen. It should explain why a conflict is detected. It should help compare solutions. It should make the consequences of a decision visible. It should support traceability. It should allow the operator to remain in control of the operational process.

This is why human-in-the-loop simulation is important. Before deploying future TMS functions in real operation, they must be tested with operators, realistic scenarios, disturbed situations, ATO/C-DAS interactions and feedback loops.

The question is not only whether the algorithm works. The question is whether the operational system works. This includes humans, interfaces, procedures, roles, responsibilities and training.

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

11. TMS and GoA4

GoA4 is often discussed through train automation:

  • perception;
  • automatic processing;
  • remote supervision;
  • train health monitoring;
  • mission fitness;
  • onboard intelligence;
  • remote driving;
  • operational fallback.

But the TMS is also essential for GoA4. In GoA4, there is no driver or onboard staff required for train operation. This means that more operational responsibilities must be handled by the system. The train must not only move. It must execute a mission within 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. The TMS is one of the systems that provides this operational context.

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

This is why GoA4 is a system-of-systems issue. The automated train needs an operational orchestrator. The TMS does not replace onboard autonomy. But it provides the network-level intelligence that onboard autonomy needs.

This is also why the future TMS must be linked with ATO, C-DAS, traffic control, planning, disruption management and operational data platforms. In GoA2, the TMS can improve automatic driving. In GoA4, the TMS becomes part of the architecture that makes unattended operation operationally possible.

12. System architecture perspective

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

12.1 The network layer

At network 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.

12.2 The train path layer

At train path level, the TMS interacts with ATO/C-DAS. The RTTP is translated into Train Path Envelopes, Journey Profiles, Segment Profiles or other operational constraints depending on the architecture and standards used. This is the level where network decisions become usable by train-level systems.

12.3 The train trajectory layer

At train trajectory level, ATO/C-DAS computes or follows a trajectory. It considers the constraints received from the operational layer, the train characteristics, the infrastructure data, the signalling constraints, the energy optimisation strategy and the actual train status. This is the level of traction, braking, coasting, stopping accuracy and timetable adherence.

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/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.

13. What the TMS is not

It is also important to clarify what the TMS is not.

The TMS is not the train protection system. ETCS remains the train protection layer. It supervises movement authorities, speed limits and braking curves. It 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, follows the operational targets and supports energy-efficient and punctual movement.

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

The TMS is not the only disruption management system. Disruption management involves several actors and systems, including maintenance, stations, rolling stock, crew, passenger information and emergency procedures.

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 technical systems it coordinates.

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

14. Migration: from today’s TMS to automated operations

The transition to future TMS will not happen in one step. Today, traffic management practices differ between networks. TMS maturity differs. Interfaces differ. The level of automation differs. ATO and C-DAS deployment differs. Data models differ. Operational rules differ.

This means that the migration must be progressive. A realistic migration path could follow several steps.

First, improve the real-time operational plan. The TMS must maintain a reliable and up-to-date view of the traffic situation, including routes, timings, constraints, deviations and forecasts.

Second, improve forecasting and conflict detection. The system must detect future conflicts early enough to allow useful regulation decisions.

Third, connect TMS with C-DAS and ATO. The operational plan must become usable by train-level systems. This requires standardised data exchanges, Train Path Envelopes, Journey Profiles, feedback messages and interface rules.

Fourth, introduce feedback loops. Connected ATO/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.

Fifth, support decision support and scenario evaluation. Traffic controllers should be able to compare alternative regulation strategies and understand their consequences.

Sixth, extend the integration to disruption management and neighbouring systems. The TMS must interact with maintenance, rolling stock, crew, energy, station, yard and passenger information systems.

Seventh, progressively increase automation. Some decisions may remain advisory. Some may be semi-automated. Some may become automated in well-defined contexts.

This is similar to the broader logic of railway automation. The target is not reached through a single technological jump. It is reached through a sequence of operational envelopes.

Each envelope defines what can be automated, under which conditions, with which interfaces, and with which human supervision. This is the right approach for TMS as well.

15. 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 system interoperability.

The future TMS maintains the Real-Time Traffic Plan. It translates network-level decisions into train-level constraints through concepts such as the Train Path Envelope. It receives operational feedback from connected ATO/C-DAS functions, based on train status, forecasts and expected arrival times. It updates the operational plan when the traffic situation changes. It supports conflict detection and resolution. It helps operators manage disruptions. It connects railway operation with planning, simulation, energy, rolling stock, crew, stations, yards and neighbouring networks.

This is why the TMS is central to digital and automated railway operation.

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

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