ERTMS/ATO is often introduced as the European interoperable train autopilot. This is true, but it is only part of the story.

ERTMS/ATO is not simply a system that drives the train automatically; it is the first standardised automation layer designed to operate inside the ERTMS/ETCS safety envelope. It translates operational intent into train-level driving behaviour while preserving interoperability between infrastructure, rolling stock, ATO and ETCS.

This article explains why ERTMS/ATO is a key migration step from protected train movement towards Digital and Automatic Train Operation.

Recommended reading

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

1. Automatic Train Protection
2. Automatic Train Operation
3. ERTMS: the European Rail Traffic Management System
4. ERTMS/ETCS: the European Train Control System
5. ETCS Capacity

Executive Summary

ERTMS/ATO is the European interoperable solution for Automatic Train Operation in GoA2. It allows the train to drive automatically while the driver remains in the cab and continues to supervise the operation. The ATO system manages traction, braking, timetable adherence, stopping accuracy and energy-efficient driving, while ERTMS/ETCS remains responsible for the safety supervision of speed and distance limits.

The central architectural principle is simple: ATO drives, ETCS protects. ATO computes and executes the optimal driving behaviour, but it must remain compatible with the movement authority, braking curves, speed limits and supervision information provided by ETCS. ERTMS/ATO is therefore not a replacement for train protection. It is an operational automation layer embedded inside the ETCS safety envelope.

The European value of ERTMS/ATO lies in interoperability. Proprietary automation systems already exist in metro environments, where infrastructure, rolling stock and operations can be designed as one integrated system. Mainline railways are different. They are open, heterogeneous, multi-operator, cross-border and progressively migrated. ERTMS/ATO provides a standardised framework in which ATO Onboard, ATO Trackside, ETCS Onboard and rolling stock interfaces can work together across suppliers and networks.

The current standardised ERTMS/ATO scope is primarily GoA2. It provides a foundation for automatic driving, but it does not by itself deliver GoA3 or GoA4. The transition towards higher automation levels requires additional capabilities: perception, automated operational processing, rolling stock intelligence, mission fitness, remote supervision, Remote Driving, stronger TMS integration and new operational rules.

ERTMS/ATO should therefore be understood as a bridge. It is already useful for energy efficiency, punctuality, smoother driving, stopping accuracy and better use of the capacity envelope. But it is also a migration step towards DATO. It introduces standardised automation into the mainline railway system, while preserving the separation between operational automation and safety protection.

From an architecture perspective, ERTMS/ATO is not the final target of railway automation. It is the first interoperable automation layer on which future DATO capabilities can be built.

Last modified: 2026-06

Content

1. Why ERTMS/ATO matters
2. ATO inside the ETCS safety envelope
3. From timetable to digital mission data
4. ATO Trackside and ATO Onboard
5. Journey Profile and Segment Profile
6. The ATO driving function
7. The driver in GoA2
8. Interfaces and interoperability
9. Migration and operational value
10. Capacity, energy and infrastructure lifecycle
11. From ERTMS/ATO to DATO
12. Architecture perspective
13. Conclusion
14. Documentation and further reading

1. Why ERTMS/ATO matters

Automatic Train Operation is not new. Many metro systems have used automatic driving for decades. In these environments, automation can be designed as an integrated system: rolling stock, platform interfaces, signalling, operation and control centre are often procured and engineered together. Communication-Based Train Control systems have made this model common in urban rail.

Mainline railways are different.

They are open systems. They involve multiple railway undertakings, infrastructure managers, suppliers, rolling stock fleets, operating rules and migration constraints. A train may cross borders, run under different traffic management domains, interact with legacy systems, and operate on lines where technical renewal happens progressively over decades.

This is why a proprietary automation model cannot simply be transferred from metro to mainline railways.

Europe needed an interoperable approach to automatic train operation. This is the purpose of ERTMS/ATO.

ERTMS/ATO brings automatic driving into the harmonised ERTMS framework. It allows an ATO Onboard system to receive operational and infrastructure data from ATO Trackside, compute a driving strategy and control traction and braking, while remaining under ERTMS/ETCS supervision.

This may sound like a narrow technical function. It is not.

ERTMS/ATO is the first large-scale attempt to standardise how automatic driving can be deployed on an open mainline railway network. It introduces automatic train operation without breaking the fundamental European requirement: interoperability.

The objective is not only to make trains drive automatically. It is to make automatic driving compatible with the European signalling system, with multi-supplier onboard architectures, with heterogeneous rolling stock and with progressive migration.

That is why ERTMS/ATO matters.

It is not only a train autopilot. It is the first interoperable automation layer of the European railway system.

2. ATO inside the ETCS safety envelope

The most important principle of ERTMS/ATO can be expressed in one sentence:

ATO drives, ETCS protects.

This distinction is fundamental.

ERTMS/ATO is not a train protection system. It does not replace ETCS. It does not create the movement authority. It does not define the safe braking envelope. It does not decide whether the train is authorised to enter a section. These remain ETCS responsibilities.

ATO manages the operational driving task. It computes how the train should move within the constraints provided by ETCS and by the operational mission. It can optimise energy consumption, respect timing points, improve stopping accuracy, smooth driving behaviour and reduce variability between drivers.

ETCS supervises the safety envelope. It ensures that the train remains within authorised speed and distance limits. If the train exceeds the supervised limits, ETCS intervenes.

This separation is one of the reasons ERTMS/ATO can be introduced into the European mainline railway system. It allows automatic driving to be added without weakening the safety role of ETCS.

The driver is still present in GoA2. The driver supervises the operation, remains responsible for many operational tasks and can take over when necessary. But the driving behaviour itself becomes automated.

This creates a clear three-layer model:

ETCS protects the train.
ATO drives the train.
The driver supervises the operation.

This model is powerful because it preserves continuity with today’s railway operation while introducing a standardised automation layer. It allows the sector to gain experience with automatic driving before moving towards more advanced DATO capabilities.

It also avoids a common misunderstanding. ERTMS/ATO is not about making ETCS smarter. It is about adding an operational automation function that remains constrained by ETCS.

The safety envelope and the operational optimisation remain separated. This separation is one of the architectural strengths of ERTMS/ATO.

Image: ERTMS/ATO system overview, with onboard and trackside equipment. Credit: Siemens.

This decomposition illustrates the architectural purpose of ERTMS/ATO. The trackside part adapts local operational data into a standardised format. The onboard part uses this standardised information to drive the train in an interoperable way.

3. From timetable to digital mission data

A driver does not drive in the abstract. They drive a mission.

They know where the train must go, where it must stop, when it must arrive, what speed limits apply, what operational restrictions exist and how the train should behave along the route. Traditionally, part of this information is carried by the timetable, operating documents, route knowledge, signalling information and traffic management instructions.

ATO also needs a mission. But because ATO is a technical system, this mission must be expressed as digital data.

This is one of the core purposes of ERTMS/ATO.

The system must transform operational intent into information that the ATO Onboard can use. The train needs to know not only the destination, but the sequence of infrastructure segments, timing targets, stopping points, route-related constraints and operational restrictions.

This is where ERTMS/ATO becomes more than a driving algorithm.

A train autopilot is useless if it does not know the mission to be performed. It cannot optimise energy if it does not know the required arrival times. It cannot stop accurately if it does not know the stopping point. It cannot anticipate restrictions if it does not receive the relevant infrastructure data.

The key architectural function of ERTMS/ATO is therefore the translation of operational data into standardised mission data usable by the train.

In a proprietary metro system, this translation can be solved inside an integrated system. In a mainline European context, it must be solved in an interoperable way.

This is the role of the Journey Profile and the Segment Profile.

4. ATO Trackside and ATO Onboard

ERTMS/ATO is structured around two main subsystems: ATO Trackside and ATO Onboard.

ATO Trackside is the trackside part of the automation system. It is connected to the infrastructure manager’s information systems, especially the traffic management environment. Its role is to prepare and provide the data needed by ATO Onboard.

ATO Trackside should not be imagined as a signalling system in the traditional sense. It is closer to a standardised gateway between local operational systems and the interoperable onboard automation function. It receives, transforms or manages mission-related and infrastructure-related data, then makes this data available to the train in a standardised form.

ATO Onboard is the trainborne automation function. It receives mission data, retrieves the required segment information, computes the driving strategy and controls traction and braking through the rolling stock interface. It also interacts with ETCS Onboard so that automatic driving remains compatible with the ETCS supervision envelope.

This decomposition is essential.

The infrastructure manager’s systems are not all identical. Traffic Management Systems differ between networks. Operational processes differ. Infrastructure data sources differ. If ATO Onboard had to understand every local information system directly, interoperability would be impossible.

ATO Trackside absorbs part of this local diversity. It provides the standardised interface to the train.

ATO Onboard can therefore remain interoperable. It does not need to understand the internal IT architecture of each infrastructure manager. It needs to understand the standardised ERTMS/ATO data provided through ATO Trackside.

This is one of the main architectural purposes of ERTMS/ATO: to separate local operational systems from interoperable onboard automation.

The trackside side adapts local railway operation into standardised ATO data.
The onboard side uses that standardised data to drive the train.

5. Journey Profile and Segment Profile

The Journey Profile and Segment Profile are central concepts in ERTMS/ATO.

The Journey Profile describes the mission of a specific train. It tells ATO Onboard which route is to be followed and which Segment Profiles are needed. It also contains the operational data required for the mission, such as timing points, stopping information, arrival times, tolerances and relevant constraints.

The Segment Profile describes the infrastructure data needed for the train to perform the mission. It provides information about the track segments used by the route, including the data required by the ATO Onboard to compute its driving strategy.

Together, they answer two questions.

What is the train supposed to do?
What infrastructure information does the train need to do it?

This distinction is important.

The Journey Profile is mission-oriented. It is related to the train service to be performed. It connects the train to the operational plan.

The Segment Profile is infrastructure-oriented. It describes the relevant characteristics of the route segments needed for ATO computation.

The ATO Onboard first obtains the Journey Profile, then requests or uses the associated Segment Profiles. With these data elements, it can calculate how the train should move along the route while respecting operational objectives and infrastructure constraints.

This architecture also supports versioning and consistency. The train does not simply receive a vague timetable. It receives structured data that can be identified, requested, checked and updated.

This is one of the reasons ERTMS/ATO is important beyond GoA2. It introduces the idea that operational railway intent must be digitally expressed and exchanged in a structured form.

DATO will require much more of this.

ERTMS/ATO is one of the first places where this transformation becomes operationally visible.

6. The ATO driving function

The visible part of ERTMS/ATO is automatic driving.

The ATO driving function computes and applies a driving strategy based on several objectives. The train must respect the mission. It must remain compatible with the ETCS supervision envelope. It must stop accurately. It should optimise energy consumption where possible. It should provide a smooth and consistent driving behaviour.

This makes ATO more than a cruise control.

An ATO system must balance several constraints at the same time. It must follow timing points without being too early or too late. It must take into account train characteristics, gradients, restrictions, stopping points and the maximum speed profile allowed by ETCS. It must manage traction and braking in a way that remains operationally useful and compatible with the train.

This is why the ATO driving function is usually decomposed into sub-functions. Some relate to timetable speed management. Some relate to the supervised speed envelope. Some relate to automatic stopping. Some relate to traction and brake control.

But the architectural message is more important than the detailed decomposition.

ERTMS/ATO turns driving into a standardised system function.

The driver’s driving style is replaced, for part of the operation, by a repeatable and optimised control strategy. This can reduce variability between drivers. It can improve timetable adherence. It can support energy-efficient driving. It can help use capacity more consistently. It can improve stopping accuracy.

This is why ATO is often associated with energy savings and punctuality. But its importance goes beyond these operational benefits.

ATO makes train movement more predictable.

And predictability is one of the foundations of automated railway operation.

A Traffic Management System can better regulate traffic if train behaviour is more predictable. A capacity model is more reliable if driving variability is reduced. A high-frequency railway is easier to operate if trains respond consistently to timing constraints.

This does not mean that ATO alone creates capacity. Capacity remains a system property. But ATO can reduce one source of variability inside the system.

That is already valuable.

This functional decomposition shows that ATO is not only a speed control algorithm. It is a system function combining timetable compliance, signalling supervision, stopping accuracy and rolling stock control.

7. The driver in GoA2

ERTMS/ATO, in its current standardised mainline form, is primarily a GoA2 system.

This means that the driver remains in the cab.

The driver can engage or disengage ATO. The driver monitors the train and the environment. The driver remains responsible for operational supervision and for situations that are not handled by the automated driving function. The driver can take over when necessary.

This is a key difference between GoA2 and GoA4.

In GoA2, ATO automates the driving task, but the responsibility model remains close to current operation. The driver is still physically present. The driver remains the immediate human fallback. The driver can interpret abnormal situations and manage degraded modes according to applicable rules.

This has important consequences for the architecture.

Because the driver remains onboard, the ATO system does not need to absorb all responsibilities of railway operation. It does not need to handle every possible situation without human presence. It does not need to solve the full problem of perception, mission fitness, remote supervision, incident management and unattended recovery.

This is why GoA2 is a realistic and important migration step.

It brings automation into the railway system without requiring the full redesign of operational responsibility. It allows the sector to learn how to integrate ATO with ETCS, rolling stock, TMS, DMI, onboard data and operational processes.

At the same time, GoA2 should not be mistaken for the final automation target.

The driver in the cab hides many unresolved questions. As long as the driver remains present, the railway system can rely on human interpretation, experience and fallback. When the driver is removed, these hidden responsibilities must be allocated somewhere else.

This is why ERTMS/ATO is a foundation for DATO, but not DATO itself.

8. Interfaces and interoperability

The real strength of ERTMS/ATO is its interface architecture.

In a closed automation system, the supplier can design the whole chain. The onboard equipment, trackside equipment, communication, train interface and control centre can be integrated as one solution. This may be efficient in a metro environment, but it is not sufficient for open European mainline railways.

Europe needs automation that works across suppliers, fleets and networks.

This requires standardised interfaces.

The ATO Onboard / ATO Trackside interface allows standardised exchange between the trainborne and trackside parts of the ATO system. This is where Journey Profiles, Segment Profiles and ATO status exchanges are managed.

The ATO Onboard / ETCS Onboard interface allows ATO to receive the information needed to remain compatible with ETCS supervision. This is the interface that gives technical meaning to the expression “ATO drives, ETCS protects”.

The ATO Onboard / Rolling Stock interface allows ATO to control traction and braking and interact with the train functions needed for automatic driving.

These interfaces are not administrative details. They define whether ERTMS/ATO can become an interoperable system or remain a supplier-specific integration.

They also define part of the migration challenge.

Retrofitting ERTMS/ATO is not only about adding an ATO computer. The train must expose functions through appropriate interfaces. ETCS Onboard must provide the relevant data. Rolling stock systems must accept control commands. The DMI must support driver interaction. The communication architecture must support the exchange with ATO Trackside.

This is why ERTMS/ATO is also a rolling stock integration topic.

On new trains, these interfaces can be designed from the beginning. On existing trains, they may require adapters, software changes, train interface modifications, validation, certification and operational testing.

This is a recurring pattern in railway digitalisation. The standard may define the target interface, but brownfield integration determines the real cost and pace of deployment.

9. Migration and operational value

ERTMS/ATO brings several operational benefits.

The first is energy efficiency. By computing an optimised speed profile, ATO can reduce unnecessary acceleration and braking. It can support coasting, smoother driving and better use of the available time margin.

The second is punctuality. ATO can help trains respect timing points more consistently. It can reduce variation between drivers and make operation more predictable.

The third is stopping accuracy. This is important for passenger comfort, platform operation and, in some contexts, future interaction with platform systems.

The fourth is capacity usage. ATO does not create infrastructure capacity by itself, but it can help operate closer to the planned capacity envelope by reducing driving variability and improving timetable adherence.

The fifth is fleet harmonisation. A fleet of automatically driven trains can behave more consistently than a fleet driven by many different driving styles.

These benefits are important, but they should be framed carefully.

ERTMS/ATO does not solve all capacity problems. It cannot compensate for an unrealistic timetable, insufficient infrastructure, poor traffic regulation, degraded ETCS deployment, rolling stock limitations or weak operational rules. It cannot replace a modern TMS. It cannot turn a fragmented railway system into a high-capacity railway by itself.

This is why ERTMS/ATO must be seen as part of a wider system.

To unlock its full operational value, it needs ETCS deployment, preferably in a radio-based architecture for high-capacity contexts. It needs a Traffic Management System able to provide relevant real-time operational data. It needs rolling stock integration. It needs operational rules and migration strategies.

In other words, ERTMS/ATO is not a standalone capacity solution. It is a capability that contributes to capacity, energy efficiency and robustness when the rest of the railway architecture is ready to use it.

This is a typical system-of-systems lesson.

A function may be technically available, but its operational value depends on the systems around it.

The ERTMS/ATO solution was tested in France, on the Longwy–Longuyon line equipped with ERTMS/ETCS Level 1. The BB27000 locomotive of the Train de Fret Autonome project, equipped with an Alstom ERTMS/KVB bi-standard system and with ERTMS/ATO, ran in October 2020 for the experiment.

10. Capacity, energy and infrastructure lifecycle

ERTMS/ATO is usually discussed through three benefits: energy savings, punctuality and capacity.

Energy savings come from smoother and more optimised driving. Punctuality comes from better adherence to timing points. Capacity benefits come from reduced driving variability and more predictable train behaviour.

These benefits remain valid. But another perspective is becoming increasingly important: infrastructure lifecycle.

The way trains are driven affects the wheel–rail interface. Acceleration, braking, adhesion conditions, torque application, wheel slip and speed profiles influence wear mechanisms. If ATO can produce smoother and more consistent traction and braking behaviour than manual driving in some contexts, it may also influence maintenance costs and infrastructure degradation.

This idea should be treated carefully. The effect depends on the ATO algorithm, rolling stock characteristics, adhesion conditions, infrastructure, speed profile, train type and operational context. It cannot be generalised too quickly.

But it opens an important architectural point.

ATO is not only an operational performance function. It may also become a lifecycle function.

If automatic driving can reduce excessive slip, wheel burns, wheel flats or other wear-related phenomena, then ATO may contribute not only to punctuality and energy efficiency, but also to infrastructure and rolling stock asset management.

This creates another requirement for future ATO systems. They may need better knowledge of adhesion conditions, train behaviour and infrastructure constraints. Real-time or near-real-time estimation of wheel–rail conditions may become valuable. The driving algorithm may need to adapt not only to timetable and ETCS constraints, but also to adhesion, wear and lifecycle optimisation.

This is a good example of how railway automation evolves.

A function initially introduced for driving automation becomes connected to energy, capacity, maintenance, infrastructure lifecycle and data.

This is why automatic driving should not be understood only as an onboard control function. It is part of a broader railway performance architecture.

11. From ERTMS/ATO to DATO

ERTMS/ATO is a key step towards DATO, but it is not the whole DATO architecture.

The current standardised scope is mainly GoA2. The driver remains onboard. The system automates traction and braking, but many responsibilities remain with the human operator. This is already useful, but GoA3 and GoA4 require more.

Higher automation levels require the system to manage responsibilities that are not covered by GoA2 ATO alone.

The railway will need automated operational processing. It will need perception systems to replace or support human observation. It will need rolling stock intelligence to assess train health and mission fitness. It will need remote supervision and, in some cases, Remote Driving for degraded operation or recovery. It will need stronger TMS integration. It will need cybersecurity, data governance and explicit responsibility allocation.

This is why ERTMS/ATO should be understood as a foundation, not as the destination.

Its value is that it introduces a standardised automation layer into the ERTMS system. It creates interoperable interfaces. It defines how mission data can be exchanged. It clarifies the relationship between automatic driving and ETCS protection. It provides operational experience with automated driving on mainline railways.

These are all necessary steps.

But the future DATO system will be broader. It will need to coordinate train, infrastructure, traffic management, rolling stock, safety, data and operations as a system-of-systems.

ERTMS/ATO is therefore one of the building blocks of DATO. It is the first automation layer, not the complete automated railway.

The architectural challenge is to ensure that today’s ERTMS/ATO deployment prepares tomorrow’s DATO capability, rather than creating another isolated layer.

12. Architecture perspective

From an architecture perspective, ERTMS/ATO can be understood through four separations.

The first separation is between protection and automation. ETCS protects the train. ATO automates the driving task. This separation allows automatic driving to be introduced without replacing the safety supervision layer.

The second separation is between local operational systems and interoperable onboard automation. Infrastructure managers may use different TMS and IT systems, but ATO Trackside provides standardised data to ATO Onboard. This allows local diversity to be managed without destroying interoperability.

The third separation is between mission data and infrastructure data. The Journey Profile describes the train mission. The Segment Profile describes the infrastructure information needed to perform that mission. Together, they allow the train to understand what to do and where to do it.

The fourth separation is between current GoA2 operation and future DATO capability. In GoA2, the driver remains the human fallback. In DATO, more responsibilities must be allocated to technical systems, remote supervision and operational architecture. ERTMS/ATO introduces automation, but it does not remove the need for a wider system-of-systems.

These separations are not theoretical. They are what make the architecture manageable.

Without the separation between ATO and ETCS, automatic driving would interfere with train protection. Without the separation between local TMS and standardised ATO data, interoperability would be difficult. Without the separation between Journey Profile and Segment Profile, mission and infrastructure data would be harder to manage. Without the separation between GoA2 and DATO, the sector might overestimate what ERTMS/ATO alone can deliver.

The role of architecture is to make these boundaries explicit.

ERTMS/ATO is a good example of controlled integration. It connects several systems, but it does not merge their responsibilities. It creates interfaces, but preserves functional separation. It brings automation, but keeps safety supervision clear.

This is exactly the kind of architectural discipline that DATO will require at a larger scale.

13. Conclusion

ERTMS/ATO is Europe’s interoperable train autopilot. But this description is not enough.

Its deeper significance is architectural.

ERTMS/ATO shows how automatic train operation can be introduced into an open, interoperable mainline railway system without replacing ETCS, without locking automation into proprietary architectures, and without assuming that every infrastructure manager or railway undertaking has the same local systems.

It provides a standardised way to connect operational mission data, infrastructure data, onboard automation, ETCS supervision, rolling stock control and driver interaction.

Its core principle is simple and powerful: ATO drives, ETCS protects.

This makes ERTMS/ATO a natural first step in the automation of the European railway system. It can improve energy efficiency, punctuality, stopping accuracy and operational consistency. It can support better use of the capacity envelope when combined with ETCS, TMS and appropriate operational rules. It may also contribute to smoother driving and, in some contexts, to better infrastructure lifecycle performance.

But ERTMS/ATO should not be confused with full DATO.

It is not GoA4. It does not remove the driver. It does not by itself solve perception, mission fitness, remote supervision, degraded recovery, train health management or operational responsibility allocation.

That is why ERTMS/ATO must be seen as both a useful capability today and a migration step towards tomorrow.

It is the first interoperable automation layer.

DATO will require more layers, more interfaces, more data, more operational rules and more system integration. But without ERTMS/ATO, the European railway would lack one of the essential bridges between protected train movement and automated railway operation.

ERTMS/ATO is therefore not the end of the automation journey.

It is where interoperable mainline automation begins.

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
• From Fixed Blocks to Moving Block: Unlocking Capacity on Existing Railway Infrastructure
• Migration to ERTMS/ATO
• Traffic Management System
• Railway Automation: From GoA2 to GoA4
• Remote Driving
• DATO as a System-of-Systems
• Railway Automation, ERTMS and DATO Glossary

ERTMS/ATO specifications

• SUBSET-125 — ERTMS/ATO System Requirements Specification
• SUBSET-126 — ATO Onboard / ATO Trackside FFFIS Application Layer
• SUBSET-130 — ATO Onboard / ETCS Onboard FFFIS Application Layer
• SUBSET-139 — ATO Onboard / Rolling Stock FFFIS Application Layer
• SUBSET-147 — CCS Consist Network Communication Layers
• SUBSET-148 — ATO Onboard / ATO Trackside Transport and Security Layers
• ERTMS/ATO Glossary

European R&D documentation

• FP1-MOTIONAL — Requirements for the deployment of TMS linked with ATO/C-DAS
• FP1-MOTIONAL — TMS and ATO/C-DAS Timetable Test & Simulation Environment
• FP2-R2DATO — ATO GoA3/4 specifications and modelling
• FP2-R2DATO — ATO impact on infrastructure assessment analysis report
• Shift2Rail X2RAIL-4 — ATO up to GoA4 specification and test reports
• TAURO project — Technologies supporting migration towards ERTMS/ATO