Remote Driving: From Technical Train Movements to GoA4 Degraded Operation

by Bastian

Railway automation is often discussed through the most visible target: the autonomous train. This is understandable. A train running without a driver onboard is a powerful image. It concentrates many of the questions raised by GoA4: perception, safety, supervision, degraded situations, train health, operational responsibility and system architecture.

But there is another topic that deserves attention before full autonomous train operation becomes widely available on mainline railways. This topic is remote driving.

Remote driving is sometimes presented as a degraded-mode capability for GoA4: if the automation system cannot continue, a remote driver may take responsibility and move the train from a remote position. This is true. But it is only part of the story.

Remote driving may also become a very practical tool for railway operators facing a more immediate problem: the availability of driving staff.

Many railway systems already face operational pressure due to staff shortages, including driver shortages. In a broader demographic context, this pressure may increase. When driving resources become scarce, the question is not only how to automate trains in the long term. The question is also how to maintain transport service in the short and medium term. This is a business continuity issue.

A railway service does not only require drivers for trains carrying passengers. It also requires drivers for many technical movements that are less visible: depot to platform movements, platform to yard movements, train preparation, stabling, repositioning, shunting-like movements, train composition and recovery. These movements may be short. But they can consume significant staff time.

A driver may need to walk to a train stabled far away, prepare it, move it for a few minutes, then return to another location. In some cases, the time spent reaching the train and returning from it may be much higher than the driving time itself. Remote driving changes this equation.

It allows a trained operator to take control of a train from a remote position, within a defined operational envelope. It can reduce the amount of staff time consumed by low-value technical movements. It can help reallocate driving resources to passenger service. It can provide a recovery capability for automated operation. And, if designed properly, it can become one of the migration steps towards more automated railway operation.

Remote driving is therefore not simply a remote joystick. It is a system-of-systems topic. It relocates the driver outside a railway system that has historically been designed around the assumption that the driver is onboard the train.

That is why remote driving is both attractive and difficult.

Last update: 2026-06
Reading time: 25 min

Article summary

Remote driving is not full autonomous operation. It is a technical and operational capability allowing a remote driver to control a train from a remote position, under defined conditions, using digital interfaces, communication links, video or perception systems, train status information and command channels.

Remote driving may be highly relevant for technical train movements: moving a train from a depot to a platform, from a platform to a yard, inside a depot, inside a controlled area, or in other operational contexts where the movement is necessary but consumes scarce driving resources.

This matters because railway operation is increasingly constrained by staff availability. In a demographic context where many high-income countries face ageing populations and pressure on operational labour markets, driver scarcity can become a direct constraint on the ability to deliver railway service.

If there are not enough drivers, the railway cannot operate the planned service. Remote driving can therefore be understood as a business continuity capability. It does not remove the need for railway driving competence. It changes where this competence is located and how it can be allocated.

Remote driving is also relevant for GoA3 and GoA4. In unattended operation, there is no driver onboard to recover the train when automation reaches the limits of its operational domain. In such situations, remote driving may become one possible recovery mode.

But remote driving is not only a degraded-mode function. It also opens a deeper architectural question.

If train functions become accessible from a remote driving desk, then these functions are being digitalised. Once they are digitally accessible, some of them may be progressively automated. Train wake-up, preparation, self-tests, preconditioning, health-state checks and some start-of-mission activities could eventually move from remote manual control to automated functions supervised by a remote operator. This links remote driving with the concept of intelligent rolling stock. It also links remote driving with GoA4 and DATO.

However, remote driving challenges many railway assumptions. Rolling stock, onboard signalling, ETCS, national ATP systems, cab radio, lineside signalling, operational procedures and safety cases have largely been designed with one assumption: the driver is in the cab. With remote driving, the driver is no longer in the cab.

Direct perception becomes mediated perception. Local action becomes remote command. Cab-based procedures become distributed human-machine processes. This creates new operational, safety, cybersecurity and human factors questions.

Remote driving should therefore be designed not as a short-term isolated add-on, but as an architectural migration capability.

The challenge is not only to drive a train from a distance. The challenge is to design remote driving in a way that supports business continuity today, improves productivity on technical movements, remains safe and acceptable, and prepares the railway system for future automated and autonomous operation.

Content

Introduction
The demographic pressure on railway operation
Remote driving as a business continuity capability
Technical train movements: the first high-value use case
From remote control to automated train functions
What remote driving is — and what it is not
Remote driving challenges railway assumptions
Human factors: from onboard perception to mediated perception
GoA3 and GoA4 degraded operation
Remote driving as a system-of-systems
Responsibility, control and handover
Operational envelopes and limits
From use cases to requirements
Remote driving in the railway automation roadmap
Conclusion

1. Introduction

Remote driving is not a new name for autonomous train operation. It is different.

In autonomous operation, the train and the wider railway system are expected to manage the mission without a driver onboard. In remote driving, a human driver still controls the train, but from a remote position. This distinction is essential.

Remote driving does not remove the human from railway operation. It relocates the human. It moves part of the driving function away from the cab and into a Remote Supervision Centre, a remote driving workstation, or in some cases a local remote-control position close to the train.

At first sight, this may look like a simple technical substitution. Instead of driving from the cab, the driver drives from a screen. But this view is too narrow.

The railway system has not been designed as a neutral object that can be controlled from anywhere. It has been designed around physical presence, direct perception, cab-based interfaces, operational procedures, safety rules and signalling systems that assume a driver onboard.

Remote driving changes this assumption. It creates new possibilities. It can support technical train movements. It can reduce the operational cost of short empty movements. It can help railway undertakings use scarce driving resources more efficiently. It can provide a recovery capability for automated or autonomous operation.

But it also creates new questions.

What does the remote driver see?
What does the remote driver not see?
What train functions can be commanded remotely?
How is responsibility transferred?
What happens if communication is degraded?
How are ETCS and national ATP systems used from a remote position?
How is cybersecurity managed when a train can be controlled remotely?
How is the seriousness of real railway operation preserved when the driver is physically distant from the train?

Remote driving is therefore not only a technical enabler. It is a transformation of railway operation.

This article explores remote driving from that perspective.

2. The demographic pressure on railway operation

Railway automation is often justified by performance, capacity, energy efficiency, punctuality or service frequency. These are valid objectives. But another driver is becoming increasingly important: staff availability.

Railway operation remains a human-intensive activity. Even when signalling and traffic management are highly automated, many operational tasks still depend on people. Drivers are needed to operate trains. Operational staff are needed to prepare, recover and move rolling stock. Technical staff are needed to manage depots, yards, maintenance and disruptions. When staff availability becomes constrained, the railway service itself becomes constrained.

A shortage of drivers does not only affect the ability to add new services. It can affect the ability to operate the existing timetable. If there are not enough drivers available at the right time, at the right place, with the right competence, trains may be cancelled, services may be reduced, and the transport offer may become less reliable.

This is especially problematic because railways are expected to play a larger role in the future mobility system. Rail is needed for decarbonisation. It is needed for modal shift. It is needed for metropolitan capacity, regional connectivity, freight corridors and resilient public transport.

But increasing the role of rail requires the railway to deliver service. If the available workforce becomes a limiting factor, the question becomes very concrete: How can railway operators maintain or increase service levels when driving resources are scarce?

This is where remote driving becomes relevant. Not as a futuristic solution. As a business continuity capability.

Remote driving can help railway operators use driving competence more efficiently, especially for movements where the time spent physically reaching the train may be disproportionate compared with the duration of the movement itself. This is particularly true for technical movements.

3. Remote driving as a business continuity capability

Business continuity is not usually the first expression associated with railway automation. But it should be.

If a railway undertaking cannot provide enough drivers to operate all required services and technical movements, then the railway operation is exposed. It may become impossible to deliver the planned service, not because infrastructure capacity is missing, not because trains are missing, but because operational staff are not available at the right time and place.

Remote driving can contribute to business continuity by reducing the amount of staff time consumed by certain movements. The objective is not to remove driving competence. The objective is to use it where it creates the most operational value.

Today, a driver may be required to physically reach a train, prepare it, perform a short movement, and then return to another location. The actual train movement may last only a few minutes. But the total time consumed by the operation may be much longer.

This is common in depots, yards, stabling areas, terminal stations, technical facilities and operational interfaces between passenger service and rolling stock management. Remote driving changes the allocation model.

A remote driver can take control of a train from a remote position, within a defined operational envelope. The time needed to reach the train physically can be reduced or removed. Several short movements may be handled more efficiently. The railway undertaking may be able to reallocate staff from low-value technical movements to passenger services or other operations requiring physical presence.

This is not only a productivity gain. It is also a resilience gain.

In a context where staff resources are limited, every hour of qualified driving time becomes valuable. Reducing the amount of time consumed by empty or technical movements can help preserve the ability to operate trains with passengers.

This is why remote driving should not be seen only as a GoA4 degraded-mode function. It may also be a practical response to one of the most immediate operational pressures faced by railways.

Figure 1 — Remote driving as business continuity: reducing the amount of scarce driving time consumed by technical train movements.

4. Technical train movements: the first high-value use case

The first high-value use cases for remote driving may not be the most spectacular ones. They may not be high-speed mainline operation. They may be technical train movements. These movements are often invisible to passengers, but they are essential for passenger service.

A train must be moved from a depot to a platform before entering service. It may need to be moved from the platform back to the yard after service. It may be repositioned between stabling tracks. It may need to be prepared, awakened, configured, tested, composed, coupled, uncoupled or moved inside a controlled area. Each of these movements can consume driving resources.

Remote driving is relevant when the movement is operationally simple enough, geographically constrained enough, and sufficiently protected by signalling and operating rules to be considered within a defined remote driving envelope.

Typical use cases include:

waking up a train remotely;
switching on and preparing a vehicle;
performing start-of-mission related steps;
moving a train from yard to platform;
moving a train from platform to yard;
moving a train within a depot;
supporting train composition;
shunting in a centralised area;
repositioning empty rolling stock.

These use cases are not secondary. They are part of the production system of railways.

Without them, passenger trains do not appear at the platform. Rolling stock is not where it needs to be. Maintenance and stabling do not connect smoothly with daily operations.

The productivity question is therefore simple. Should a qualified driver spend significant time walking to a train, taking possession of it, moving it for a short distance, and returning to another place? Or can some of these movements be controlled remotely, with the right operational envelope, safety supervision, communication, procedures and responsibilities?

Remote driving may be one answer. It does not make the railway driver unnecessary. It may make the use of driving competence more efficient.

5. From remote control to automated train functions

Remote driving is often described from the remote desk perspective. A remote driver sits in a Remote Supervision Centre and controls the train through screens, commands and communication links. This is correct.

But from a system architecture perspective, remote driving also means something deeper. It means that onboard train functions must become digitally accessible from outside the train.

The remote driver must be able to observe the train, command it, supervise it, acknowledge some information, understand its state, and interact with functions that were historically accessed directly from the cab.

This changes the nature of the train. The train becomes a digitally accessible asset. It must expose its functions, status, alarms, diagnostics and operational capabilities through interfaces that can be used by a remote system.

Once this is done, a second question appears. If a function can be accessed remotely, should it always be performed manually by a remote driver? Or should some functions be progressively automated?

For example, bringing a train into operation may involve several steps: wake-up, configuration, self-tests, diagnostics, preconditioning, brake-related checks, train health verification and start-of-mission procedures. A remote driver could perform these steps manually from a remote desk.

But a long-term architecture may go further. Some of these steps could be automated by software, while the remote driver remains responsible for supervision, confirmation, exception handling and takeover.

This is where remote driving becomes more than remote manual control. It becomes a digitalisation lever. It creates the conditions for the automation of train functions that are today performed manually by an onboard driver.

This links remote driving with the idea of intelligent rolling stock. In GoA4, the system must know not only where the train is and what it is authorised to do. It must also know whether the train is technically and operationally fit to perform its mission.

Remote driving creates one of the first practical contexts where this becomes necessary. If the driver is no longer onboard, the train must provide more information about itself. It must report its state. It must expose failures. It must support remote diagnosis. It must make train preparation more digital. It must make the remote operator aware of operational limitations. It must help decide whether the train can be moved, prepared, started, recovered or stopped.

Remote driving may therefore start as remote manual operation. But if it is architected correctly, it can become a step towards automated train functions and GoA4-capable operation.

From remote control to automated functions

Figure 2 — From remote control to automated train functions: remote access to train functions can become a digitalisation path towards automation.

6. What remote driving is — and what it is not

Remote driving needs a clear definition. Remote driving is the capability for a remote driver to control a train from a remote position, using dedicated interfaces, communication links, train status information, video or perception data, command channels and safety supervision.

It may be performed from a Remote Supervision Centre. It may also be performed locally, close to the train, depending on the operational scenario and the architecture.

Remote driving can include different levels of engagement.

A remote driver may monitor a train.
A remote driver may request control.
A remote driver may take responsibility for a train.
A remote driver may command traction and braking.
A remote driver may perform specific operational sequences.
A remote driver may hand over control to another driver, to an onboard driver, or to an automated system.

Remote driving is not full autonomous operation.

In autonomous operation, the system is expected to perform the mission without continuous human driving. In remote driving, the human driver still performs the driving task, but from a remote position.

Remote driving is not a replacement for train protection. The train still needs safe supervision. ETCS, national ATP systems, signalling principles, operational rules remain essential.

Remote driving is not a generic permission to drive any train from anywhere. It must be limited by operational envelopes: geography, speed, visibility, communication quality, signalling mode, train status, train type, operational scenario and fallback strategy.

Remote driving is not a simple IT function. It touches rolling stock, signalling, telecommunications, operations, human factors, cybersecurity, safety and regulation.

It is a railway system function. This is why remote driving must be designed with the same level of architectural seriousness as other critical railway automation functions.

7. Remote driving challenges railway assumptions

Remote driving is attractive because it addresses a very concrete operational problem: the railway needs to keep operating while driving resources become increasingly constrained.

But remote driving also challenges one of the deepest assumptions of railway operation. The railway system has been built around the idea that the driver is onboard the train.

Rolling stock functions are designed for a driver in the cab. Train control and management systems are designed around local interaction. ETCS onboard, national ATP systems, cab radio, driver-machine interfaces and operational procedures assume that the driver is physically present in the driving cab. Lineside signalling follows the same logic. Signals are positioned, displayed and operated so that they can be perceived by the driver from the cab. Operational rules and safety cases are built on this assumption. Remote driving changes it.

The driver may still be responsible for the train, but the driver is no longer onboard. The driver may be located in a Remote Supervision Centre, possibly far away from the train.

What was previously direct perception becomes mediated perception. What was previously local action becomes remote command. What was previously a cab-based procedure becomes a distributed human-machine process. This is why remote driving cannot be reduced to driving a train with a video feed.

It requires a reassessment of operational rules, safety assumptions, communication performance, cybersecurity, onboard interfaces, human factors and responsibility allocation. It also breaks traditional technical silos.

A remote driving system may need to access rolling stock functions usually considered under the rolling stock domain. It may need to interact with ETCS onboard, national train protection systems or cab radio, usually considered under the CCS domain. It may require operational rules and degraded mode procedures, usually addressed in the operational domain.

In other words, remote driving sits at the intersection of rolling stock, CCS and operations. This is why it is a system-of-systems topic.

It is not only a remote desk connected to a train. It is a new operational layer inserted into an existing railway system that was not originally designed for it. This is a typical case of technological infusion.

Remote driving will not be deployed in a blank-page railway system. It will be inserted into existing fleets, existing onboard architectures, existing signalling systems, existing operational rules and existing infrastructure.

The short-term need is business continuity. The long-term direction is GoA4 and DATO.

The architectural challenge is to avoid building a short-term remote-control layer that becomes incompatible with future railway automation.

8. Human factors: from onboard perception to mediated perception

Remote driving changes the driver’s relationship with the train. In conventional operation, the driver is physically located in the cab. The driver sees the track environment directly. The driver perceives depth, distance, light conditions, signal visibility, train motion, noise, vibration and sometimes weak signs of rolling stock degradation.

This matters.

A driver does not only drive through formal data. A driver also perceives the train and its environment through experience. An unusual noise, an abnormal vibration, a strange reaction during traction or braking, or a different sound from a component can contribute to understanding the state of the train. This is especially true for older rolling stock or for trains with limited digital diagnostic capabilities.

In remote driving, this direct perception is replaced by mediated perception. The remote driver sees the railway through cameras, displays and data. The environment is reconstructed on screens. The field of view is defined by sensors. The image is two-dimensional. The sound environment depends on microphones. Vibration and physical feedback are no longer directly available.

This is not a detail. It changes how the driver builds situation awareness. It changes how abnormal situations are detected. It changes how responsibility is perceived. It also changes what the train must provide to the remote driver. If noise, vibration or physical sensation are no longer directly available, the train must compensate through diagnostics, alarms, health-state monitoring and better digital reporting.

Remote driving therefore reinforces the need for intelligent rolling stock. It is not enough to transmit video and commands.

The remote driver must receive the right operational context, the right train status, the right alarms, the right degradation information and the right confidence level in the remote perception system.

There is also a psychological dimension. A remote driving desk may look closer to a simulator than to a traditional train cab. This can be an opportunity. It may attract new profiles. It may make some railway jobs more compatible with digital working environments. It may reduce some physical constraints associated with traditional train driving.

But it can also create risks. The system must avoid turning real railway operation into something that feels less real than it is. Remote driving must not become a gamified version of train driving where the physical reality of the train, the infrastructure and the safety risks become psychologically distant.

The challenge is to benefit from modern digital interfaces without reducing the seriousness of the task. The remote driver must remain fully aware that each command affects a real train, on a real infrastructure, with real safety consequences. This is why human factors cannot be treated as a final validation layer. They must shape the architecture of remote driving from the beginning.

9. GoA3 and GoA4 degraded operation

Remote driving is also relevant for automated and autonomous operation. In GoA3 and GoA4, the role of onboard staff changes significantly. In GoA4, no driver or onboard staff is required for train operation. This means that when the automation system reaches the boundary of its operational domain, the railway system must provide another way to manage the situation.

Remote driving can be one of these ways. It can allow a remote driver to take responsibility for the train when automation is degraded, unavailable or unable to continue.

This may be relevant in several situations:

degraded ATO;
degraded perception;
degraded automatic processing;
degraded ETCS or national train protection context;
wayside signalling failure;
communication degradation;
poor visibility;
sensor degradation;
train recovery after an incident;
movement to a safe location.

Remote driving should not be seen as the nominal mode of GoA4. The nominal objective of GoA4 is unattended operation. But no credible GoA4 architecture can ignore recovery.

A train without a driver onboard must still be recoverable. It must be possible to move it, secure it, stop it, isolate it, rescue it or transfer responsibility to another operational mode when the nominal automation cannot continue. Remote driving may provide one such capability.

However, this does not mean that remote driving can solve every degraded situation. Some situations may require the train to stop and wait for staff on site. Some may require infrastructure intervention. Some may require passengers or freight constraints to be managed. Some may be outside the acceptable remote driving envelope.

This is why remote driving must be integrated into degraded mode strategies, not treated as a universal fallback. It is one recovery tool among others. Its value depends on how clearly the operational envelope is defined.

10. Remote driving as a system-of-systems

Remote driving is often imagined as a person controlling a train through a screen. This image is incomplete. A remote driving function requires a distributed system.

It involves at least:

the Remote Driver;
the Remote Supervision Centre;
the remote driving workstation;
the trackside remote control system;
the onboard remote control system;
train-to-trackside communication;
video or perception systems;
command channels;
train status and diagnostics;
TCMS interfaces;
ETCS or national ATP supervision;
cab radio or operational voice communication;
operational rules;
responsibility management;
cybersecurity;
legal recording;
human factors;
degraded mode management.

The remote driving system must access train functions, receive train state, send commands, display information, support handover, ensure driver authentication, preserve safety supervision and maintain traceability.

This is why remote driving is not only a rolling stock topic. It is not only a signalling topic. It is not only a telecom topic. It is not only an operations topic. It is all of them together.

Remote driving crosses TSI LOC&PAS, CCS and OPE boundaries. It may require rolling stock functions to be accessible remotely. It may require interaction with ETCS onboard or national protection systems. It may require the operational rulebook to define who is responsible, under which conditions, and what happens when the remote link is degraded.

It also introduces cybersecurity questions that cannot be treated as secondary. A remote driving system can send commands to a train. This means that authentication, authorisation, communication integrity, intrusion protection, monitoring, logging and fallback behaviours become critical. The system must prevent unauthorised access. It must prevent malicious command injection. It must ensure that the right person controls the right train at the right moment. It must ensure that safety-critical inputs cannot be modified or confirmed without appropriate safeguards.

This is especially important if remote driving includes interaction with ETCS or other train protection systems. Entering incorrect data, confirming inappropriate transitions, or remotely acknowledging the wrong information could have safety consequences.

Remote driving therefore requires a strong architecture. Not only a functional architecture.

A safety architecture.
A cybersecurity architecture.
An operational architecture.
A human factors architecture.
A migration architecture.

This is why remote driving belongs to the broader DATO system-of-systems discussion.

Figure 3 — Remote driving as a system-of-systems: a cross-domain function connecting train, control centre, communication, operations and cybersecurity.

11. Responsibility, control and handover

The central question in remote driving is not only who can send commands to the train. The central question is who is responsible for the train at each moment. This is a fundamental operational issue.

In conventional operation, responsibility is strongly associated with the driver in the cab. The driver is physically present, has access to cab interfaces, observes the environment, communicates with operational staff and performs actions locally.

With remote driving, responsibility becomes more distributed. A train may be monitored by a remote driver without being controlled. It may be controlled by a remote driver. It may be driven by an onboard driver. It may be under automated control. It may be handed over from one remote driver to another. It may be handed over from an autonomous system to a remote driver, or from a remote driver back to automated operation.

Each transition must be explicit.

The system must know:

who is monitoring the train;
who is controlling the train;
who is responsible for the movement;
which mode is active;
whether the train accepts remote commands;
whether the remote driver is authorised;
whether the remote driver is attentive;
whether another driver or system can take over;
what happens if handover fails.

Remote driving therefore requires state management. It requires clear driver statuses, train control statuses and handover procedures. It also requires confirmation of remote driver availability and vigilance. This is not administrative detail. It is a safety and responsibility issue.

A train cannot be in an ambiguous state where several actors believe someone else is responsible. It cannot accept commands from the wrong actor. It cannot continue operating if the responsible driver is no longer available.

Handover is therefore one of the most important topics in remote driving. It is the operational mechanism by which responsibility is transferred without losing safety, traceability or situation awareness.

This also means that remote driving is not only a technical function. It is an organisational function. It changes how driving competence, responsibility and supervision are distributed across the railway operation.

Figure 4 — Responsibility and handover of control: remote driving requires explicit responsibility transfer between onboard driver, remote driver and automated system.

12. Operational envelopes and limits

Remote driving should not be discussed as if it were a universal capability. The right question is not: Can a train be driven remotely? The right question is: Under which operational envelope can a train be driven remotely?

This envelope must define the conditions under which remote driving is allowed, safe, useful and acceptable.

It may include:

geographic area;
infrastructure type;
signalling mode;
train type;
maximum speed;
movement type;
passenger or non-passenger operation;
availability of ETCS or ATP supervision;
video quality;
latency;
communication quality;
visibility conditions;
weather conditions;
availability of train diagnostics;
availability of local staff;
degraded mode strategy;
cybersecurity state;
remote driver workload;
number of trains monitored;
handover rules;
fallback procedures.

For technical movements, the envelope may be limited to depots, yards, stabling areas, platforms, controlled operational areas or specific routes.

For GoA4 degraded operation, the envelope may be more restrictive: move the train to a safe location, recover from a limited failure, clear a line, leave a platform, or reach a predefined operational point.

The more complex the railway environment, the more demanding the remote driving envelope becomes. High-speed mainline remote driving is not the same as depot movement. Passenger operation is not the same as empty rolling stock movement.

Remote driving under degraded visibility is not the same as remote driving with high-quality video and full communication performance. The system must therefore be designed with operational envelopes, not abstract capability statements.

This is also where remote driving connects with standardisation. If remote driving is to become interoperable and scalable, the railway sector will need to define not only technical interfaces, but also operational envelopes, responsibilities, safety assumptions and migration principles.

Otherwise, remote driving may remain a set of local solutions.

13. From use cases to requirements

Remote driving is still an emerging railway automation topic. This is why the recent European work on use cases and requirements is important.

Use cases help structure the operational problem. They identify who does what, when, under which conditions, with which system interactions and with which expected result.

Requirements then translate these operational scenarios into functions, constraints and system needs. This progression matters.

Without use cases, remote driving risks being specified as a technology in search of a railway operation. Without requirements, remote driving risks remaining an idea without a deployable system architecture.

The European FP2-R2DATO work is therefore an important step because it moves remote driving from a general concept towards a structured set of operational use cases and functional / non-functional requirements.

The use cases cover several families:

connection between train and Remote Supervision Centre;
train registration;
remote login;
train wake-up;
train preparation;
start-of-mission activities;
control handover;
routine remote driving;
yard to platform movements;
platform to yard movements;
depot manoeuvres;
shunting;
degraded ATO;
degraded perception;
degraded ATP;
poor visibility;
degraded communication;
remote control specific failures.

This is not yet a complete industrial deployment framework. But it is a necessary step.

Remote driving needs operational clarity before it can become a scalable railway system capability. It must move from “a remote driver can drive a train” to precise definitions of when, how, where, with which information, under which safety constraints, and with which responsibility.

14. Remote driving in the railway automation roadmap

Remote driving must be placed correctly in the railway automation roadmap. It is not the final target. The final target of GoA4 is unattended operation within a safe, reliable and operationally harmonised railway system.

Remote driving is not equivalent to GoA4. But it can support the path towards it.

It can provide an intermediate capability for technical movements. It can help railway undertakings maintain service continuity under staff pressure. It can improve the productivity of short empty movements. It can create remote supervision centres and remote operational roles. It can force the digitalisation of train functions. It can support recovery strategies for automated and autonomous operation.

Remote driving may therefore become one of the practical bridges between today’s driver-centric railway and tomorrow’s automated system-of-systems.

This bridge must be designed carefully. If remote driving is implemented only as a short-term overlay on existing trains, it may create architectural debt.

If it is designed as part of a DATO-compatible trajectory, it can prepare future automation.

This means:

digital interfaces should be designed with future automation in mind;
train functions exposed for remote driving should also support automated workflows where relevant;
human-machine interfaces should be designed for remote operation, not only cab replication;
cybersecurity should be part of the architecture from the start;
handover between onboard driver, remote driver and automated system should be explicit;
operational envelopes should be defined progressively;
remote driving should be aligned with future GoA4 and DATO system architecture.

The key is to avoid treating remote driving as a separate island. Remote driving should be part of the same automation trajectory as ERTMS/ATO, intelligent rolling stock, TMS, GoA4 and DATO.

It is a migration capability. And migration capabilities matter because railways cannot wait for the final target to start solving today’s operational problems.

15. Conclusion

Remote driving is not only a degraded-mode function for autonomous trains. It is a response to a more immediate operational question: how can the railway continue to deliver service when driving resources become scarce?

It is a business continuity capability. It is a productivity lever for technical train movements. It is a way to reduce the amount of qualified driving time consumed by short empty movements, depot moves, yard operations and train preparation activities. It is also a digitalisation step.

By making train functions accessible remotely, remote driving can prepare the automation of some onboard functions. It can push rolling stock towards better diagnostics, better health-state reporting, better remote interfaces and eventually more intelligent train behaviour.

Remote driving is also a recovery capability for GoA3 and GoA4. When automation reaches the boundary of its operational domain, a remote driver may become one of the ways to recover the train, move it to a safe location, or manage a degraded situation.

But remote driving is not simple. It challenges one of the deepest assumptions of the railway system: the driver is onboard the train.

Once the driver is no longer onboard, many things must be reassessed: perception, safety, responsibility, operational rules, ETCS interaction, cab radio, train diagnostics, cybersecurity, human factors and system architecture.

This is why remote driving is a system-of-systems topic. It sits at the intersection of rolling stock, CCS, operations, telecom, safety, cybersecurity and human factors.

The future of remote driving should therefore not be a collection of isolated remote-control solutions. It should be an architectural step in the wider migration towards digital, automated and autonomous railway operation.

Remote driving is not the destination of railway automation. It is one of the bridges.

And in a railway system facing staff scarcity, operational complexity and the long transition towards GoA4, such bridges may become essential.

Documentation

Voie Libre articles

European R&D documentation

FP2-R2DATO — D5.4: Documentation of use cases for Remote Driving
FP2-R2DATO — D6.7: Report on set of non-functional and functional requirements for remote driving