ERTMS/ATO is now the European interoperable solution for automatic train operation.
In GoA2, it allows a train to be driven automatically, while the driver remains in the cab and continues to supervise the operation. The ATO system manages traction and braking, follows the timetable, respects signalling constraints provided by ERTMS/ETCS, and supports more regular and energy-efficient train operations. This is already a major step for mainline railways.
But moving from GoA2 to GoA3 and GoA4 is not just about making the train “more automatic”. It changes the nature of the problem.
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. This transfer is the real subject of railway automation.
In this article, we will explore how railway automation evolves from automatic driving to autonomous operation, why GoA4 is not simply “ATO without a driver”, and why mainline railway autonomy must be understood as a system architecture problem.
For a good understanding of the concepts discussed in this article, I recommend reading first:
ERTMS : European Railway Traffic Management System
Article summary
ERTMS/ATO GoA2 automates train driving in the presence of a driver.
The system controls traction and braking, follows the Journey Profile and Segment Profiles, respects the signalling constraints provided by ERTMS/ETCS, and can improve regularity, stopping accuracy and energy efficiency. But in GoA2, the driver is still present.
The driver supervises the operation, observes the environment, detects abnormal situations, interprets the state of the train, communicates with operational staff and remains the human fallback when the system reaches its limits. This is why GoA2 is mainly a driving automation step.
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 to support degraded situations or passenger-related operations.
In GoA4, neither a driver nor onboard staff is required for train operation. The responsibilities previously handled onboard must therefore be transferred to a wider technical and operational system.
This transfer requires more than an automatic driving algorithm.
It requires perception, automatic processing of operational actions, remote supervision, incident management, Traffic Management System integration, TCMS integration, train health monitoring, mission fitness assessment, operational rules, safety validation and a data architecture able to support interoperability.
This is where two components become particularly important.
The train itself must become more intelligent. It must be able to report its health state, detect degraded conditions, support self-diagnosis and inform the automation system whether it remains fit to continue its mission.
The Repository, or REP, must structure the data exchanges between the onboard automation system and trackside systems. It retrieves and coordinates infrastructure data, mission data, operational data and train data, and distributes them to the onboard components that need them.
GoA4 is therefore not only “ATO without a driver”. It is a system-of-systems transformation.
The core question is not: Can a train drive itself?
The real question is: Can the railway system safely and efficiently operate a train without relying on a driver or onboard staff to manage the operational responsibilities that still exist?
This is the transition from automatic driving to autonomous operation.
Last revision: 2026-05
This article by Bastian Simoni is licensed under CC BY-NC-SA 4.0
Table of contents
- Why “autonomous train” is an incomplete expression
- GoA2: automatic driving with a driver
- From GoA2 to GoA3: removing the driver from the cab
- GoA4: unattended train operation
- Why mainline GoA4 is harder than metro automation
- The system architecture behind autonomy
- ETCS: the train protection layer
- ADM: the automatic driving function
- APM: the automatic processing of operational actions
- PER: perception of the environment
- TCMS and rolling stock intelligence
- TMS and Operational Execution
- Mission Profile and Journey Profile
- REP: the interoperability and data coordination layer
- GoA as an operational context
- From driver responsibilities to system responsibilities
- The intelligent train: health state and mission fitness
- Remote operation and degraded situations
- Migration from GoA2 to GoA4
- European harmonisation: from full GoA4 ambition to minimum viable use cases
- Why GoA4 is a system-of-systems problem
Conclusion
Documentation
1. Why “autonomous train” is an incomplete expression
The expression “autonomous train” is attractive. It suggests a train able to move by itself, without human intervention, as a kind of railway equivalent of an autonomous car. But for railways, this expression is often misleading.
A train does not operate in isolation. It runs within a railway system composed 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 is not “alone”. It is connected to a broader operational system.
It receives a mission. It follows a route. It is supervised by train protection. It exchanges data with traffic management systems. It relies on infrastructure data. It may require remote operation in degraded situations. It must react to events in its physical environment. It must be recovered when it cannot continue. This is why “autonomous train” is too narrow.
The train may be unattended, but the operation is not isolated.
A more accurate expression is autonomous railway operation. This distinction is important because it changes the way the problem is framed. If we focus only on the train, we may think mainly about sensors, artificial intelligence, obstacle detection and onboard decision-making.
These topics are important. But they are not sufficient.
If we focus on railway operation, we must also consider system architecture, responsibility allocation, operational contexts, degraded modes, remote supervision, traffic management, safety, certification and migration. This is the real challenge of GoA4.
Train de Fret Autonome (credit Benoît ABISSET)
2. GoA2: automatic driving with a driver
GoA2 is the first major step towards railway automation on the mainline network. In GoA2, the train can drive automatically, but the driver remains in the cab. The ATO system manages the driving task:
- traction;
- braking;
- speed regulation;
- stopping accuracy;
- timetable adherence;
- energy optimisation.
The driver remains responsible for operational supervision. This is the fundamental balance of GoA2.
The system drives. The driver supervises.
In the ERTMS/ATO architecture, the ATO onboard system receives operational data through the Journey Profile and Segment Profiles. It uses this data to determine how the train should move along its route. It also receives signalling constraints from ERTMS/ETCS, which remains the train protection layer. This separation is essential.
ATO is an operational automation system. ETCS is the safety supervision system.
ATO computes how to drive the train efficiently. ETCS supervises that the train remains within the safe envelope. If the train exceeds the limits allowed by ETCS, the train protection system intervenes.
GoA2 therefore brings important benefits:
- more homogeneous driving behaviour;
- reduced energy consumption;
- better timetable adherence;
- improved stopping accuracy;
- reduced operational variability;
- potential capacity gains.
But GoA2 does not remove the driver from the operational system. The driver is still there to monitor the environment, react to unexpected situations, manage degraded modes and take over when necessary. This is why GoA2 should not be confused with autonomous operation. It is automatic driving, not unattended operation.
ERTMS/ATO (GoA2) overview
3. From GoA2 to GoA3: removing the driver from the cab
GoA3 changes the operational model. In GoA3, there is no driver continuously operating the train from the cab. However, this does not mean that the train is fully unattended. Onboard staff may still be present. This staff can support degraded situations, manage passenger-related issues, help with evacuation, or perform operational actions that the system cannot yet manage alone. This is why GoA3 is an intermediate step between automatic driving and fully unattended operation. It removes the driver from the driving function, but it does not remove all human presence from the train. The system must therefore take over more responsibilities than in GoA2, but not necessarily all of them.
This distinction is important for long-distance applications. On a metro line, the environment is often closed, homogeneous and highly controlled. Stations are frequent, the infrastructure is dedicated, and operational scenarios are more constrained.
On the mainline railway network, the situation is different. A train may run through open environments, long interstation distances, tunnels, level crossings, yards, mixed traffic areas, degraded signalling situations, and areas with different technical capabilities. In such conditions, onboard staff may still be valuable for managing some operational situations. GoA3 can therefore be seen as a transition step. It reduces dependency on a driver in the cab, while maintaining a human operational presence onboard when needed.
4. GoA4: unattended train operation
GoA4 is the target level of automation where no onboard staff is required for train operation. This is the level usually associated with unattended train operation. But GoA4 is not simply GoA2 without a driver. The difference is deeper.
In GoA2, when something unexpected happens, the system can rely on the driver. In GoA4, it cannot.
The system must therefore be able to manage situations that were previously handled by the driver or onboard staff. This includes, depending on the operational context:
- detecting obstacles;
- reacting to abnormal situations;
- managing passenger alarms;
- handling door incidents;
- managing train failures;
- reacting to infrastructure events;
- communicating with passengers;
- requesting remote assistance;
- stopping at a safe location;
- supporting recovery or rescue operations.
Some of these functions are onboard functions. Some are trackside functions. Some depend on remote supervision. Some depend on operational rules. Some depend on external human intervention, but not necessarily onboard.
This is why GoA4 requires a distributed architecture. It is not a single onboard computer replacing the driver. It is a complete operational system where the responsibilities previously concentrated in the driver are distributed across several technical and organisational components.
In GoA4, the driver disappears from the cab. But the responsibilities of the driver do not disappear. They must be reallocated.
5. Why mainline GoA4 is harder than metro automation
GoA4 already exists in urban railways. Many metro systems operate without drivers or onboard staff. They use integrated train control systems, platform screen doors in some cases, dedicated infrastructure, controlled environments and homogeneous fleets.
Mainline railways are different. They are open systems.
They involve:
- mixed passenger and freight traffic;
- multiple operators;
- heterogeneous rolling stock;
- different signalling systems;
- national operating rules;
- open environments;
- level crossings;
- long distances between stations;
- degraded modes;
- cross-border interoperability constraints;
- long migration periods.
This makes GoA4 much harder on the mainline network. In a metro system, automation can often be designed as an integrated system for a specific line. On the mainline network, automation must coexist with a large and evolving railway system.
It must work with ERTMS/ETCS, legacy signalling systems, Traffic Management Systems, rolling stock interfaces, Digital Maps, perception systems, telecom networks, operational rules and safety processes.
It must also support migration. A GoA4 train may not always run in a GoA4 environment. It may encounter lower GoA areas, degraded situations or infrastructure limitations. The applicable automation level depends not only on the train, but also on the trackside capabilities, operational decisions and system availability. This is a key point.
The Grade of Automation is not only a property of the train. It is the result of a combination between the train, the infrastructure, the operational context and the mission. A train may technically support GoA4, but if the infrastructure only supports GoA2, or if a degraded situation requires a lower operating context, then the actual operation must be adapted.
This is why GoA4 must be designed as a system capability, not as a simple train feature.
6. The system architecture behind autonomy
To understand GoA4, we need to look at the system architecture. Several building blocks become essential.
FP2-R2DATO D6.5 Reference Architecture
6.1 ETCS: the train protection layer
ERTMS/ETCS remains the train protection layer. It supervises train movements, movement authorities, speed limits and braking curves.
In GoA4, the role of ETCS remains central. The automation system must operate under train protection. The train may be unattended, but it must still be supervised by a safety layer. This continuity is important.
GoA4 is not a reason to bypass ETCS. On the contrary, the target architecture for interoperable mainline automation is based on ERTMS/ATO over ERTMS/ETCS.
6.2 ADM: the automatic driving function
The Automatic Driving Module is responsible for the automatic driving task. It manages the movement of the train: speed profiles, traction, braking, stopping accuracy and timetable compliance.
In GoA2, this is the visible part of ATO. The train drives automatically, but the driver remains in charge of operational supervision.
In GoA3 and GoA4, automatic driving remains necessary, but it is no longer sufficient. The system must also automate or support functions beyond traction and braking.
6.3 APM: the automatic processing of operational actions
The Automatic Processing Module is one of the key concepts for GoA3 and GoA4. Its purpose is to manage actions and reactions that are no longer performed by the driver. This includes operational supervision, incident handling, mission execution logic, reaction to events and interaction with other onboard or trackside systems. In other words, the APM represents the shift from driving automation to operational automation.
It is not only about moving the train. It is about managing what happens around the movement.
This is why APM is central to GoA4. It helps redistribute the responsibilities previously held by the driver into a system of automated processes and interfaces.
6.4 PER: perception of the environment
Perception is another key building block.
In GoA2, the driver remains responsible for observing the environment and detecting many external hazards. In GoA3 and GoA4, this responsibility must be supported by technical systems.
The perception system must monitor the environment, detect relevant objects or events, and provide information to the rest of the automation system. This may include obstacle detection, track monitoring, detection of people or vehicles, level crossing situations, smoke, animals, infrastructure anomalies or other environmental events.
Perception is therefore not just a sensor function. It is part of the operational responsibility transfer.
The system must not only see. It must understand enough of the environment to support a safe and operationally meaningful reaction.
6.5 TCMS and rolling stock intelligence
The Train Control and Monitoring System is the interface with the rolling stock. Many actions previously performed or requested by the driver involve the train itself:
- doors;
- traction;
- braking;
- pantograph;
- circuit breaker;
- lighting;
- acoustic warning;
- diagnostics;
- passenger alarms;
- onboard failures.
In GoA4, these functions must be commanded, supervised or monitored through automated interfaces. But this is not sufficient.
In mainline unattended operation, the rolling stock must also become capable of providing a reliable and usable view of its own health state. Today, the driver is not only a user of the train. The driver is also part of the diagnostic chain.
Drivers receive alarms from onboard systems, but they also interpret weak signals that are not always fully digitalised: abnormal noise, vibration, smell, unexpected behaviour, degraded traction or braking performance, door behaviour, pantograph issues, or other signs that something is wrong with the train. The driver can then assess whether the train can continue the mission, whether it must stop at the next operational point, or whether continuing the movement could create a safety issue.
In GoA4, this assessment cannot rely on a driver in the cab. The train must therefore provide more than isolated alarms. It must provide information that can be used by the automation system to determine whether the train remains fit for its mission. This implies new or reinforced rolling stock capabilities:
- continuous health monitoring;
- self-diagnosis;
- automated self-tests;
- detection of degraded equipment states;
- reporting of operational limitations;
- reporting of reduced traction or braking capability;
- monitoring of door, pantograph, braking, suspension, HVAC and passenger-related systems;
- detection of abnormal onboard conditions;
- communication of maintenance-relevant information;
- capability assessment before and during the mission.
This is a key point for GoA4. An unattended train cannot only be a train controlled by ATO. It must also be a train able to inform the wider automation system about its own ability to continue operating. The TCMS therefore becomes a central partner of the automation system.
GoA4 cannot be achieved only through signalling, ATO and perception. It also requires deep integration with rolling stock functions, and a much more explicit concept of train health, operational capability and mission fitness. In other words, the train must become an intelligent asset within the railway automation architecture.
6.6 TMS and Operational Execution
The Traffic Management System and operational execution functions remain essential.
A GoA4 train must receive a mission. It must be inserted into traffic. It must react to timetable changes, route changes, conflicts, degraded modes and operational decisions. The automation system must therefore interact with trackside operational systems.
This is where the railway system becomes truly distributed. The onboard system cannot decide everything alone.
The trackside system manages traffic, infrastructure constraints and operational planning. The onboard system executes the mission, supervises train functions, reacts to local events and reports its status. GoA4 requires both sides to work together.
6.7 Mission Profile and Journey Profile
In GoA2 ERTMS/ATO, the Journey Profile is already a key input. It defines the route and timing points required for automatic driving.
For GoA3 and GoA4, the Mission Profile becomes increasingly important.
The Journey Profile tells the train where and when it must run. The Mission Profile describes what the train must do.
This distinction is important.
Autonomous operation is not only about travelling along a route. It also includes operational tasks: starting up, changing GoA, coupling, splitting, passenger service, freight operations, parking, recovery, and other mission-related activities. The Mission Profile therefore supports the transition from driving automation to operational automation. It gives structure to the tasks that the automated system must execute.
6.8 REP: the interoperability and data coordination layer
The Repository, or REP, is one of the most important components in the GoA3/4 architecture. Its role is to manage interoperable communication between onboard automation components and trackside systems.
In GoA2 ERTMS/ATO, the onboard ATO system already needs operational and infrastructure data, such as Journey Profiles and Segment Profiles. In GoA3 and GoA4, the need becomes broader. The train must receive and coordinate several categories of data:
- infrastructure data from the Infrastructure Manager;
- operational data from traffic management;
- mission data from the Railway Undertaking;
- train data required for automated operation;
- information needed by ADM, APM, PER, localisation and other onboard components.
REP acts as the onboard data coordination layer. It collects information from different sources, structures it, checks its consistency and distributes it to the onboard components that need it. This is a major difference between GoA2 and GoA4.
In GoA2, the driver is still present and can compensate for missing, inconsistent or incomplete information through operational knowledge, radio communication or manual procedures. In GoA4, this human layer is no longer onboard.
The automated system must therefore rely on a more explicit and more structured data architecture. REP becomes the component that makes this possible.
It is not only a technical gateway. It is a logical component designed to support interoperability. It standardises the way onboard equipment communicates with trackside systems, including systems belonging to different Infrastructure Managers and Railway Undertakings.
This is especially important for mainline railways. A GoA4 train is not expected to operate only on one closed, homogeneous line. It may have to run across different infrastructure domains, operational areas or national environments. The onboard automation system must therefore be able to establish communication with the relevant trackside servers, retrieve the appropriate data, and ensure that the information used onboard is consistent with the current route, mission and movement authority.
In this sense, REP is one of the architectural enablers of cross-border railway automation. It supports the transition from a driver-centric interoperability model to a system-centric interoperability model.
Today, many interoperability issues are managed through a combination of driver knowledge, national rules, onboard systems and operational procedures. In GoA4, part of this burden must be transferred to the system.
REP is one of the components that allows this transfer to happen. It connects the onboard automation system to the data world of the Infrastructure Manager and the Railway Undertaking. It ensures that the automated train receives the right information, from the right source, in a form that can be used by the right onboard component.
Without such a component, GoA4 would risk multiplying direct interfaces between onboard applications and trackside systems, creating fragmented and non-interoperable architectures. With REP, the architecture becomes more structured.
The train can retrieve, check and distribute the data needed for autonomous operation through a common onboard repository. This is why REP should be considered one of the cornerstones of interoperable GoA4 railway automation.
7. GoA as an operational context
A common misunderstanding is to treat GoA as a simple label attached to a train. In reality, GoA is an operational context. It depends on several elements:
- the GoA requested by the railway undertaking for the mission;
- the GoA supported by the train;
- the GoA supported by the trackside infrastructure;
- dynamic inhibitions from traffic management;
- staff availability;
- degraded situations;
- system availability.
This is why a GoA4-capable train may not always operate in GoA4. If the trackside infrastructure only supports GoA2, the train cannot operate unattended in that area. If onboard staff is required for a specific section or situation, the train may operate in GoA3 rather than GoA4. If a driver takes control, the operational context changes again.
This makes GoA management a system function. It is not only a technical configuration. It is a responsibility allocation mechanism. The system must determine who is responsible for what at a given time:
- the system;
- the driver;
- onboard staff;
- remote staff;
- the infrastructure manager;
- the railway undertaking.
This is why the GoA transition must be managed explicitly. Moving from GoA2 to GoA4 means changing the operational responsibility split. And changing responsibilities is always more complex than changing a technical mode.
GoA Operating Context from FP2-R2DATO D6.5 Documentation.
8. 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 correct location;
- following the timetable.
These functions are the first to be automated in GoA2. But the driver also performs many other functions:
- observing the environment;
- reacting to obstacles;
- managing degraded situations;
- interacting with onboard systems;
- interpreting operational instructions;
- communicating with traffic management;
- managing passenger-related events;
- applying operational rules;
- deciding whether the train can continue.
GoA3 and GoA4 require these functions to be redistributed. Some functions are allocated to ATO. Some are allocated to ETCS. Some are allocated to TCMS. Some are allocated to perception. Some are allocated to remote supervision. Some remain with human staff, but no longer necessarily onboard.
This redistribution is the essence of autonomous railway operation. It also explains why GoA4 cannot be specified only as “automatic driving without a driver”. The real work is to identify all the functions performed by the driver and onboard staff, determine which ones must be automated, which ones must be remotely supervised, which ones require human intervention, and how the interfaces between all these actors must be defined. This is system architecture.
9. The intelligent train: health state and mission fitness
One responsibility often underestimated in discussions about GoA4 is the assessment of the rolling stock itself. A driver does not only drive the train. They also experience the train.
They hear it. They feel it. They observe how it behaves. They receive alarms, but they also interpret many signals that are not always formally captured by today’s onboard systems. This is especially important on the mainline network.
A metro operating in a closed and homogeneous environment can rely on a highly integrated system, short distances between stations, dedicated infrastructure and controlled operational scenarios. Mainline railway operation is different. Trains may run for long distances, in open environments, with mixed traffic, complex rolling stock configurations and fewer immediate recovery options. In this context, the train’s health state becomes a central input for automation.
The system must know whether the train is still able to perform its mission. Can it continue at nominal speed? Can it continue with reduced traction capability? Can it brake as expected?
Are the doors, pantograph, HVAC, suspension, passenger alarm, onboard communication and safety-related subsystems in a state compatible with the mission? Is the failure only a maintenance issue, or does it create an operational limitation? Could the failure become a railway safety issue if the train continues to run?
These questions are often answered today through a combination of onboard diagnostics, driver experience, operating rules and human judgement. In GoA4, this combination must be redesigned.
The rolling stock must be able to expose its operational capability to the automation system. This means that train health monitoring must not only support maintenance. It must also support real-time operational decisions.
The automation system needs to know whether the train is fit to start, fit to depart, fit to continue, fit to enter a given area, fit to operate unattended.
This introduces a concept that is 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 a driver or onboard staff, the system must continuously evaluate whether the train remains capable of performing its mission, and what operational reaction is required when this capability is reduced.
This may lead to different decisions:
- continue normally;
- continue with restrictions;
- reduce speed;
- skip part of the mission;
- stop at the next suitable location;
- request remote supervision;
- request maintenance intervention;
- trigger rescue or recovery procedures;
- prevent departure.
This is not only a rolling stock issue. It is an interface issue between rolling stock, automation, traffic management, remote supervision, maintenance and operations.
The intelligent train is therefore one of the missing building blocks of mainline GoA4.
Perception allows the system to understand the external environment. Train health monitoring allows the system to understand the train itself. Both are required for autonomous operation.
10. Remote operation and degraded situations
A GoA4 system must also address degraded situations. Even a highly automated train will encounter events that cannot be solved only by nominal automatic driving.
Examples may include:
- passenger alarm;
- door failure;
- onboard fire alarm;
- obstacle on track;
- infrastructure incident;
- unexpected stop;
- train failure;
- communication loss;
- need for rescue;
- need for local movement.
In GoA2, the driver is already onboard and can take immediate operational responsibility. In GoA4, this is no longer the case. Therefore, the system must provide other mechanisms.
One of them is remote operation.
Remote operation can support the management of irregular situations without sending staff immediately to the train. It does not mean that every degraded case is solved remotely. Some situations may still require field intervention, rescue or local staff. But remote operation becomes part of the GoA4 operating model. It is one of the ways to compensate for the absence of onboard staff.
This is also 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.
11. 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, TMS interfaces, standardised data exchanges and operational adaptation.
GoA3 and GoA4 add another layer of complexity. They require new technical enablers:
- perception;
- advanced localisation;
- automated operational processing;
- remote supervision;
- mission management;
- incident management;
- deeper TCMS integration;
- more automated traffic management.
They also require new operational concepts:
- who is responsible in each operating context;
- when a train may enter a GoA4 area;
- how GoA changes are requested and granted;
- how degraded situations are managed;
- when remote operation is required;
- how passengers are informed and protected;
- how rescue is organised.
This means that GoA4 deployment will be progressive.
This migration is not only technical. It is also organisational. It requires confidence in the system, validated safety concepts, mature operational rules, clear interfaces and demonstrated recovery procedures.
The migration from GoA2 to GoA4 should therefore not be understood as a single jump from automatic driving to full unattended mainline operation.
It should be understood 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, and with which responsibilities allocated to the railway undertaking, infrastructure manager, remote supervision and onboard systems.
This is important for European harmonisation.
If GoA4 is treated only as a complete end-state, harmonisation will remain too complex and too distant. If it is decomposed into limited and useful operational use cases, it becomes possible to define earlier minimum viable specifications, support industrialisation, and progressively scale towards more complex mainline automation.
12. European harmonisation: from full GoA4 ambition to minimum viable use cases
GoA4 will not become interoperable only because the required technologies exist. It will become interoperable when the operational behaviour of the system is harmonised, and when the corresponding technical requirements are consistently reflected in the relevant European specifications.
This is a major challenge.
For GoA4, technical harmonisation cannot start only with the CCS subsystem or the rolling stock subsystem. Before defining what shall be specified in CCS or LOC&PAS, the railway sector must first agree on how GoA4 operation is expected to work.
Who is responsible for authorising a GoA4 movement? Who supervises the train when there is no driver and no onboard staff? How is a degraded situation managed? When should the train stop, continue, request remote supervision or trigger recovery? How should the system interact with the infrastructure manager, the railway undertaking, passengers, remote staff and emergency actors?
These are operational questions before being technical questions.
This means that the operational layer, and therefore the operational TSI, is a prerequisite for full GoA4 harmonisation. Only once the operational behaviour is sufficiently defined can the corresponding requirements be consistently allocated to CCS, LOC&PAS, rolling stock interfaces, remote supervision, perception, train health monitoring and onboard data architecture. This creates a timing issue.
The harmonisation of operational rules is already difficult for GoA1 and GoA2 in an ERTMS/ETCS context. Expecting a complete European operational harmonisation of mainline GoA4 by 2032 would therefore be unrealistic.
This does not mean that nothing can be done before then. It means that the sector should avoid treating GoA4 as an all-or-nothing target. A more pragmatic approach would be to define a progressive harmonisation path based on limited and well-defined use cases.
Instead of trying to harmonise “GoA4 mainline operation” as a whole, the sector could identify a first set of GoA4 use cases with a constrained operational scope, limited interfaces and manageable risk.
They could provide a first harmonised operational envelope. Within this envelope, a first technical MVP could be specified: a minimum viable GoA4 system, limited to defined contexts, with explicit operational rules, clear responsibility allocation and a restricted set of technical requirements.
This would provide two major benefits.
First, it would give railway undertakings and operators visibility. They would know that GoA4 harmonisation is not an abstract long-term ambition, but a progressive path starting with concrete use cases.
Second, it would give industry a realistic industrialisation target. Instead of remaining in the world of prototypes and demonstrators, suppliers could start developing scalable GoA4 products for a defined scope, with a clear path for future extension.
This is how GoA4 could move from research to deployment.
Not by waiting for a fully harmonised European autonomous railway system.
But by defining the first interoperable operational envelopes, standardising the minimum technical capabilities required for them, and progressively increasing the scope as operational maturity, safety evidence and industrial capability grow.
13. Why GoA4 is a system-of-systems problem
GoA4 brings together many systems that were historically designed with different assumptions.
- ERTMS/ETCS assumes a train protection role.
- ERTMS/ATO GoA2 assumes a driver remains present.
- TCMS assumes interaction with onboard staff or driver commands.
- Traffic management assumes human-driven trains in many situations.
- Operational rules assume human presence onboard for many actions.
- Passenger management assumes staff availability in some cases.
GoA4 challenges these assumptions. It requires these systems to interact differently.
This is why GoA4 must be treated as a system-of-systems problem. The objective is to make the complete railway system capable of operating trains without onboard human intervention in the target context.
That includes:
- technical architecture;
- operational architecture;
- safety architecture;
- data architecture;
- migration architecture.
Each of these architectures matters.
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 clear operational rule for the reaction, the system is incomplete. If remote operation exists but responsibilities between railway undertaking and infrastructure manager are unclear, the system is incomplete. If the train can run unattended but cannot be recovered efficiently, the system is incomplete.
This is the real challenge of autonomous railway operation.
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 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 is the core of railway automation.
It requires perception to understand the external environment, automatic processing to manage operational actions, integration with train protection and traffic management, remote supervision, incident management, operational rules and safety validation.
It also requires the train itself to become more intelligent. The 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.
GoA4 also requires a new data architecture.
The automated train must retrieve and coordinate infrastructure data, mission data, operational data and train data coming from both the Infrastructure Manager and the Railway Undertaking. This is the role of the Repository. REP turns part of interoperability from a driver-supported operational process into a system-supported technical architecture, by distributing consistent data to ADM, APM, PER, localisation and other onboard functions.
This is why the path from GoA2 to GoA4 is not only a technological roadmap. It is an architectural transformation.
There is also a European harmonisation challenge.
GoA4 cannot be harmonised only by specifying new technical components in CCS or rolling stock regulations. The first question is operational: how should an unattended train behave, who supervises it, who authorises it, and how are degraded situations managed?
Only once these operational principles are sufficiently clear can the technical requirements be consistently reflected in TSI CCS, LOC&PAS and the related interface specifications. A full European harmonisation of mainline GoA4 is therefore unlikely to happen in one step.
A more realistic path is to start with limited GoA4 use cases and define minimum viable interoperable solutions for them.
Such an approach would create a bridge between research demonstrators and industrial deployment. It would give operators visibility, give industry a concrete product scope, and allow Europe to progressively scale GoA4 harmonisation from constrained use cases towards more complex mainline operation.
The future autonomous train is therefore not only a train that drives itself.
It is 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
Voie Libre articles
ERTMS/ATO: Europe’s Interoperable Train Autopilot
Migration to ERTMS/ATO: Lineside Signalling Interpretation
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