Railway automation is often described as a progression from automatic driving to autonomous trains. This is true, but incomplete.

The move from GoA2 to GoA4 is not only an increase in automation level; it is a transfer of operational responsibilities from the driver and onboard staff to a wider technical and operational system. That transfer changes the architecture of the railway.

This article explains why mainline GoA4 is not simply “ATO without a driver”, but a system-of-systems transformation involving train protection, automatic driving, perception, rolling stock intelligence, traffic management, remote supervision, data architecture, operational rules and migration.

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

Executive Summary

GoA2 automates train driving while keeping the driver in the cab. The ATO system manages traction, braking, speed regulation, stopping accuracy, timetable adherence and energy optimisation. ETCS supervises the safety envelope. The driver remains responsible for operational supervision, external observation, degraded situations and many decisions that are not fully automated.

GoA3 and GoA4 change the nature of the problem. In GoA3, the driver is no longer continuously operating the train, but onboard staff may still be present. In GoA4, neither a driver nor onboard staff is required for train operation. This means that responsibilities previously handled onboard must be reallocated to the wider railway system.

The central challenge is therefore not only to make the train drive itself. It is to make the railway system capable of operating, supervising, recovering and authorising train movements without relying on a driver or onboard staff to manage the residual operational responsibilities.

This requires several capabilities to work together: ETCS for the protection layer, ATO for automatic driving, automated processing of operational actions, perception of the environment, rolling stock intelligence, train health monitoring, mission fitness, remote supervision and driving, Traffic Management System integration, operational rules, cybersecurity and data coordination.

GoA4 should not be understood as a property of the train alone. A train may be technically capable of GoA4, but the actual Grade of Automation depends on the infrastructure area, traffic conditions, operational rules, staff availability, system availability, degraded situations and the mission being executed.

From an architecture perspective, the transition from GoA2 to GoA4 is a migration from driver-supervised automation to system-managed operation. It will not happen in one step. It should be built progressively through bounded use cases, operational envelopes, safety evidence, industrial maturity and European harmonisation.

Last modified: 2026-06

Content

1. Why GoA4 is not simply “ATO without a driver”
2. GoA2: automatic driving with human supervision
3. From GoA3 to GoA4: removing onboard dependency
4. Why mainline GoA4 is harder than metro automation
5. GoA as an operational context
6. From driver responsibilities to system responsibilities
7. The architecture behind GoA4
8. Intelligent rolling stock and mission fitness
9. Remote supervision, Remote Driving and degraded operation
10. Migration from GoA2 to GoA4
11. Architecture perspective
12. Conclusion
13. Documentation and further reading

1. Why GoA4 is not simply “ATO without a driver”

The expression “autonomous train” is attractive. It suggests a train able to move by itself, without human intervention, as if railway automation were mainly a question of onboard intelligence.

But this expression can be misleading.

A train never operates alone. It runs inside a railway system made of infrastructure, signalling, traffic management, rolling stock, operational rules, safety procedures, energy systems, passenger interfaces, maintenance processes and emergency management. Even in GoA4, the train receives a mission, follows a route, depends on movement authorities, interacts with traffic management, exchanges data with trackside systems and must be recovered when nominal operation is no longer possible.

The train may be unattended, but the operation is not isolated.

This distinction is essential. If we look only at the train, we may focus mainly on sensors, onboard decision-making, artificial intelligence, perception and automatic driving. These topics matter, but they are not enough. GoA4 is not only the automation of the driving task. It is the automation, redistribution or remote supervision of the many responsibilities that were previously concentrated around the driver and onboard staff.

This is the real shift from GoA2 to GoA4.

GoA2 asks whether the train can drive automatically while the driver remains present. GoA4 asks whether the railway system can operate the train without relying on anyone onboard to supervise, interpret, diagnose, intervene or recover the situation.

The first question is about automatic driving.
The second is about autonomous railway operation.

That is why GoA4 must be approached as a system architecture problem.

2. GoA2: automatic driving with human supervision

GoA2 is already a major step for mainline railways. In GoA2, the ATO system manages the driving task. It controls traction and braking, follows timing points, supports stopping accuracy, respects operational targets and can improve regularity and energy efficiency.

In the European interoperable architecture, ERTMS/ATO operates within the protection envelope provided by ERTMS/ETCS. This separation is fundamental. ATO computes how the train should drive. ETCS supervises that the train remains within its authorised movement and braking limits. If the train exceeds the limits supervised by ETCS, the protection system intervenes.

GoA2 therefore creates an important functional distinction.

ATO drives.
ETCS protects.
The driver supervises.

This is why GoA2 should not be confused with autonomy. The train may drive automatically, but the operational system still relies on the driver in many situations. The driver observes the environment, detects abnormal situations, interprets alarms, communicates with traffic management, applies operational rules, handles degraded modes and remains the immediate human fallback when automation reaches its limits.

In GoA2, automation improves the driving task. But it does not remove the human layer that makes the operation resilient.

This is not a weakness. It is the architecture of GoA2.

The driver remains part of the railway system. The driver compensates for incomplete information, handles many exceptional situations and provides judgement when the system cannot interpret the context. The automation system can therefore remain focused on driving optimisation within a supervised safety envelope.

The transition to GoA4 begins when this assumption is no longer valid.

ERTMS/ATO (GoA2) overview

3. From GoA3 to GoA4: removing onboard dependency

GoA3 is an intermediate step. The driver is no longer continuously operating the train, but onboard staff may still be present. This staff can support passenger-related operations, degraded situations, evacuation, incident handling or operational actions that the technical system cannot yet fully manage.

GoA3 therefore reduces dependency on the driver in the cab, but it does not remove all human presence from the train.

GoA4 goes further. No driver and no onboard staff are required for train operation. This is usually described as unattended train operation. But the word “unattended” can hide the real issue.

The people disappear from the train.
The responsibilities do not disappear.

If something abnormal happens in GoA2, the driver may notice it, interpret it and react. If a door behaves unexpectedly, if the train gives an unusual alarm, if the environment seems unsafe, if an operational instruction is ambiguous, or if the train does not behave as expected, the driver can intervene.

In GoA4, the system must provide another answer.

Some responsibilities may be automated. Some may be transferred to remote supervision. Some may be allocated to traffic management. Some may require field intervention. Some may remain human decisions, but no longer from the cab. The key point is that each responsibility must be explicitly allocated.

This is why GoA4 is not simply the absence of the driver. It is the redesign of the responsibility model.

The question becomes: who or what performs each function previously performed by the driver or onboard staff?

Automatic driving is only one part of that question.

4. Why mainline GoA4 is harder than metro automation

GoA4 already exists in urban railways. Many metro systems operate without drivers or onboard staff. They can rely on integrated train control, dedicated infrastructure, controlled environments, homogeneous rolling stock and relatively constrained operational scenarios.

Mainline railways are different.

They are open systems. They involve mixed passenger and freight traffic, multiple operators, heterogeneous rolling stock, different infrastructure configurations, national operational rules, open environments, level crossings, yards, terminals, long distances between stations, cross-border traffic, degraded modes and long migration periods.

In a metro, automation can often be designed as an integrated system for a specific line. The infrastructure, rolling stock, stations, operation and control centre can be designed together. The operational domain is narrow and stable.

On the mainline network, GoA4 must coexist with complexity.

A GoA4-capable train may run through infrastructure areas with different technical capabilities. It may operate in a GoA4-ready area, then pass through a lower-capability area, then face a degraded situation requiring a lower automation context. It may share tracks with GoA2 trains, manually driven trains, freight trains or vehicles with different onboard capabilities.

This changes the nature of automation.

The Grade of Automation is not only a property of the train. It is the result of a combination between train capability, infrastructure capability, operational rules, mission type, system availability and the current traffic situation.

A train may technically support GoA4. But if the infrastructure does not, if the operational context does not allow it, or if the system is degraded, the train cannot operate in GoA4.

This is why mainline GoA4 must be understood as a system capability, not as a train feature.

5. GoA as an operational context

A common misunderstanding is to treat GoA as a label attached to a train. This train is GoA2. That train is GoA4. But in mainline operation, this is too simplistic.

GoA is an operational context.

It depends on the GoA requested for the mission, the GoA supported by the train, the GoA supported by the infrastructure, the operational rules applicable in the area, the availability of systems, the availability of staff, the state of traffic management and the presence of degraded situations.

This means that a GoA4-capable train may not always operate in GoA4. It may operate in GoA2 when the driver is present, in GoA3 when onboard staff remain available, in GoA4 in a suitable operational domain, or in a degraded mode when automation is partially unavailable.

This makes GoA management a system function.

The system must know which mode is active, who is responsible, which functions are automated, which functions remain human-supervised, whether remote supervision is required, whether onboard staff are available, whether the train is allowed to enter a specific area, and how transitions between GoA levels are requested, authorised, inhibited or cancelled.

Changing GoA is therefore not only a technical mode change. It is a responsibility transition.

This is why GoA transitions must be explicit, traceable and operationally governed. The railway system must avoid ambiguous states where the train is technically moving, but responsibility is unclear.

In GoA2, the responsibility model remains close to today’s operation: the system drives, the driver supervises. In GoA4, the responsibility model becomes distributed across technical and organisational actors.

That is the heart of the transition.

6. From driver responsibilities to system responsibilities

The driver currently performs many functions. Some are directly related to driving: applying traction, braking, respecting speed limits, stopping at the right location and following the timetable. These are the first functions addressed by ATO.

But the driver also performs many other functions.

The driver observes the environment. The driver interprets signals from the train. The driver reacts to abnormal situations. The driver communicates with traffic management. The driver applies operational rules. The driver handles degraded situations. The driver may decide whether the train can continue, stop, request assistance or apply a restrictive procedure.

These responsibilities are not always visible when automation is discussed from a pure driving perspective. Yet they are essential to railway operation.

GoA4 requires these responsibilities to be redistributed.

Some responsibilities are allocated to ATO. Some remain under ETCS supervision. Some require perception of the environment. Some depend on rolling stock intelligence and TCMS integration. Some move to traffic management. Some require remote supervision or Remote Driving. Some remain human decisions, but taken from a remote or operational control position. Some require new operational rules and recovery procedures.

This redistribution is the essence of autonomous railway operation.

It also explains why GoA4 cannot be specified only by adding new onboard modules. The real work is to identify what the driver and onboard staff currently do, decide which responsibilities can be automated, which ones must be remotely supervised, which ones require human intervention, and how the interfaces between all these actors should be defined.

This is system architecture.

The goal is not to pretend that the driver simply disappears. The goal is to make the railway system capable of absorbing the responsibilities that remain.

7. The architecture behind GoA4

Several building blocks become essential when moving from GoA2 to GoA4.

ETCS remains the train protection layer. This continuity is important. GoA4 does not bypass train protection. The unattended train must still operate inside a safe movement envelope defined and supervised by the signalling and protection system.

ATO remains the automatic driving layer. It manages traction, braking, speed regulation and stopping accuracy. But in GoA3 and GoA4, automatic driving is necessary but no longer sufficient. The system must also manage what happens around the movement.

This is where automated processing of operational actions becomes important. The system must be able to process events, trigger actions, execute parts of the mission, react to operational conditions and coordinate with onboard or trackside systems. The problem is no longer only how to move the train. It is how to manage the mission.

Perception is another major building block. In GoA2, the driver remains responsible for observing the environment. In GoA4, this responsibility must be supported by technical systems able to detect relevant objects, events or conditions. Perception is therefore not simply a sensor function. It is part of the responsibility transfer from human observation to system-supported awareness.

The Traffic Management System also becomes central. A GoA4 train cannot manage the network alone. It must be inserted into traffic, react to operational changes, receive missions and constraints, support regulation decisions and report its status. The onboard system executes the mission, but the railway operation remains coordinated at network level.

The rolling stock layer is equally important. Many actions previously requested or interpreted by the driver involve the train itself: doors, traction, braking, pantograph, circuit breaker, diagnostics, alarms and passenger-related systems. In GoA4, these functions must be accessible, monitored and interpreted through digital interfaces.

Finally, GoA4 requires a stronger data architecture. The automated train needs infrastructure data, mission data, operational data and train data. It must retrieve the right information, from the right source, in a consistent form, and distribute it to the onboard functions that need it.

This is where a repository or onboard data coordination layer becomes important. Its role is not only to move data around. It supports the transition from a driver-supported interoperability model to a system-supported interoperability model.

GoA4 is therefore built from several layers: protection, driving, operational processing, perception, rolling stock intelligence, traffic management, remote supervision and data coordination.

None of these layers is sufficient alone.

The architecture is the way they work together.

8. Intelligent rolling stock and mission fitness

One responsibility often underestimated in GoA4 discussions is the assessment of the train itself.

A driver does not only drive the train. The driver also experiences it. They hear it, feel it, observe how it behaves, receive alarms and interpret weak signals that are not always fully digitalised. An abnormal vibration, an unusual noise, a degraded traction response, a braking behaviour, a door issue or a smell can influence operational judgement.

The driver can then decide whether the train can continue, whether it should stop at the next suitable location, whether the failure is only a maintenance issue, or whether it creates an operational or safety limitation.

In GoA4, this judgement cannot rely on a person in the cab.

The train must therefore provide more than isolated alarms. It must expose its operational capability to the automation system. It must tell the system not only that a fault exists, but what this fault means for the mission.

Can the train start? Can it depart? Can it continue? Can it brake as expected? Can it operate unattended? Can it enter a specific infrastructure area? Can it complete the mission with restrictions? Should it stop? Should it request remote supervision? Should it trigger recovery?

This introduces a concept broader than diagnostics: mission fitness.

Mission fitness is the ability of the train, in its current technical state, to safely and operationally perform the mission that has been assigned to it.

This concept is essential for GoA4. Without onboard staff, the system must continuously evaluate whether the train remains fit for its mission and what operational reaction is required when its capability is reduced.

This is not only a rolling stock topic. It connects rolling stock, automation, traffic management, maintenance, remote supervision, incident management and operational rules.

The intelligent train is therefore one of the missing building blocks of mainline GoA4. A GoA4 train is not only a train that can be driven automatically. It is a train capable of explaining its state to the wider railway system.

Perception allows the system to understand the external environment.
Train health and mission fitness allow the system to understand the train itself.

Both are needed.

9. Remote supervision, Remote Driving and degraded operation

A GoA4 system must also address degraded situations. Even a highly automated train will encounter events that cannot be solved only through nominal automatic driving.

A passenger alarm may be triggered. A door may fail. A communication link may be degraded. A perception function may become unavailable. The train may stop unexpectedly. An infrastructure incident may occur. A failure may require the train to be moved to a safe location. A recovery procedure may be needed.

In GoA2, the driver is already onboard and can take immediate operational responsibility. In GoA4, this is no longer the case.

The system must therefore provide other mechanisms.

Remote supervision is one of them. It allows the railway operation to monitor unattended trains, manage exceptional situations, interact with operational staff and decide whether the train can continue, stop, request assistance or enter another operational mode.

Remote Driving may also become relevant. It can provide a way to move a train remotely under defined operational conditions, especially for degraded situations, recovery, technical movements or bounded operational domains. It is not a universal fallback, but it may be one of the bridges between today’s staffed operation and future unattended operation.

This is why GoA4 must be designed together with incident management and recovery procedures. A train that can run automatically in nominal conditions is not enough. The system must also know what to do when nominal operation is no longer possible.

This is often where the maturity of an automation architecture is tested.

The easy question is whether the train can run automatically when everything works.
The difficult question is how the railway recovers when something does not.

GoA4 depends on that second answer.

10. Migration from GoA2 to GoA4

The transition from GoA2 to GoA4 will not happen in one step.

GoA2 is already a significant transformation for mainline railways. It requires ERTMS/ATO, ERTMS/ETCS, onboard and trackside integration, traffic management interfaces, standardised data exchanges and operational adaptation.

GoA3 and GoA4 add another layer of complexity. They require perception, automated operational processing, remote supervision, mission management, incident management, deeper TCMS integration, train health monitoring, mission fitness, remote operation capabilities and more structured interaction with traffic management.

They also require new operational concepts. Who is responsible in each operating context? When can a train enter a GoA4 area? How are GoA transitions requested and authorised? How are degraded situations managed? When is remote supervision required? How are passengers protected? How is rescue organised?

These questions show why the migration must be progressive.

GoA4 should not be treated as a single jump from automatic driving to full unattended mainline operation. It should be treated as a sequence of operational envelopes.

Each envelope should define where GoA4 can be used, for which type of movement, under which infrastructure conditions, with which rolling stock capabilities, with which fallback mechanisms, with which communication performance, with which operational rules and with which responsibility allocation.

This is also important for European harmonisation.

If GoA4 is treated only as a complete end-state, harmonisation may remain too complex and too distant. If it is decomposed into useful and bounded operational use cases, it becomes possible to define earlier minimum viable specifications, support industrialisation and progressively scale towards more complex mainline automation.

The question is therefore not only how to harmonise GoA4 in Europe. The question is where to start.

Depots, yards, technical movements, low-speed movements, recovery, remote assistance or specific bounded mainline contexts may provide earlier opportunities than a fully harmonised GoA4 mainline operation.

This is not a reduction of ambition. It is how complex systems become deployable.

11. Architecture perspective

From an architecture perspective, the path from GoA2 to GoA4 is a transfer of operational responsibility.

In GoA2, the architecture is relatively clear. ETCS protects the train, ATO drives the train, and the driver supervises the operation. The driver remains the human integration layer for many exceptional situations.

In GoA4, that human integration layer is no longer onboard.

The responsibilities that were concentrated around the driver must be redistributed across the system. Some move to onboard automation. Some move to trackside systems. Some move to traffic management. Some move to remote supervision. Some remain human decisions, but from another location. Some require new data flows, new safety arguments and new operational rules.

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

It requires technical architecture, operational architecture, safety architecture, data architecture and migration architecture.

If the onboard automation works but the traffic management system cannot manage GoA transitions, the system is incomplete. If perception works but there is no operational rule defining the reaction, the system is incomplete. If the train can run unattended but cannot evaluate its own mission fitness, the system is incomplete. If Remote Driving exists but responsibilities between railway undertaking, infrastructure manager and remote staff are unclear, the system is incomplete. If the train can operate nominally but cannot be recovered efficiently, the system is incomplete.

GoA4 is therefore not defined by the absence of a driver. It is defined by the presence of a complete operational system able to absorb the responsibilities that the driver previously carried.

That is the architectural challenge.

12. Conclusion

GoA2 automates train driving. GoA4 transforms railway operation.

This is the key difference.

In GoA2, ERTMS/ATO controls traction and braking while ERTMS/ETCS supervises the train. The driver remains present and continues to manage many operational responsibilities: observing the environment, interpreting degraded situations, interacting with onboard systems, communicating with traffic management and deciding whether the train can continue.

In GoA4, neither a driver nor onboard staff is required for train operation. These responsibilities must therefore be transferred to a wider technical and operational system.

This transfer requires perception to understand the external environment, automated processing to manage operational actions, integration with train protection and traffic management, remote supervision, incident management, operational rules, safety validation and cybersecurity.

It also requires the train itself to become more intelligent. Rolling stock must no longer be considered only as an object controlled by ATO and protected by ETCS. It must be able to report its health state, operational limitations and mission fitness, so that the system knows not only where the train is and what it is authorised to do, but also whether it is still technically and operationally fit to perform its mission.

The path from GoA2 to GoA4 is therefore not a technological roadmap alone. It is an architectural transformation.

It will not be achieved by waiting for a fully harmonised European autonomous railway in one step. A more realistic path is to define limited operational envelopes, build minimum viable interoperable solutions, validate the safety and operational principles, and progressively expand the scope as maturity grows.

The future autonomous train is not only a train that drives itself.

It is part of a railway system able to operate without relying on a driver or onboard staff to perform the responsibilities that still make railway operation safe, reliable and usable.

That is the real meaning of railway automation: from automatic driving to autonomous operation.

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
• Migration to ERTMS/ATO
• Traffic Management System
• Remote Driving
• DATO as a System-of-Systems
• Railway Automation, ERTMS and DATO Glossary

European R&D documentation

• FP2-R2DATO — D6.5: ATO GoA3-4 Specifications and Modelling
• FP2-R2DATO — D6.5 Annex 1: SRS ATO up to GoA3/4