The first image is easy to understand: a train driven from another location.
But Remote Driving is not only remote control. It is a cross-domain railway capability that connects rolling stock functions, train control, communication links, perception, cybersecurity, operational rules, human factors and safety supervision.
Its first value may not come from spectacular mainline operation at high speed. It may come from much more ordinary railway situations: depot-to-platform movements, stabling, yard operations, train preparation, repositioning, recovery and selected degraded situations. These movements are not always visible to passengers, but they are essential to daily railway production.
Remote Driving also matters for the GoA4 trajectory. A train without staff onboard must remain recoverable when automation reaches the boundary of its operational domain. Remote Driving may become one of the bridges between today’s staffed operation and tomorrow’s more automated railway system.
This article explains why Remote Driving should be designed not as a short-term remote-control overlay, but as an architectural migration capability: useful today for technical train movements and operational continuity, while preparing future DATO-compatible degraded operation.
For a good understanding of the concepts discussed in this article, I recommend reading first:
Executive Summary
Remote Driving allows a qualified operator to control a train from a remote position under defined operational conditions. The driver is no longer physically present in the cab, but the driving responsibility remains human. The train is controlled through communication links, remote interfaces, train status information, video or perception data, command channels and safety supervision.
This distinction is essential. Remote Driving is not autonomous train operation. In autonomous operation, more responsibility is transferred to the technical system. In Remote Driving, an existing human responsibility is relocated and exercised through mediated interfaces. The railway does not remove the driver from the operational model; it changes where the driver is located and how control is allocated.
The early value of Remote Driving may lie in bounded operational contexts. Technical train movements, depot-to-platform moves, stabling, yard operation, train preparation, repositioning and recovery activities consume scarce driving resources. They can also affect resilience when trains must be prepared, moved, recovered or returned to service. Remote Driving can support business continuity by allowing driving competence to be used more flexibly.
At the same time, Remote Driving is relevant to GoA4. A train without staff onboard must remain recoverable when automation cannot continue its mission. Remote Driving may provide a degraded-mode or recovery capability, provided that the operational envelope is clearly defined: where it can be used, at which speed, with which communication quality, with which perception capability, with which protection mode, and under which responsibility rules.
The architectural challenge is significant because Remote Driving challenges one of the deepest assumptions of railway operation: the driver is in the cab. Direct perception becomes mediated perception. Local interaction becomes remote human-machine interaction. Cab-based procedures become distributed operational processes. Responsibility, control and handover must therefore be explicitly managed.
Remote Driving is not only a rolling stock function, not only a signalling function, not only a telecom function and not only an operational procedure. It connects TCMS, train protection, communications, perception, cybersecurity, operational rules, human factors, safety cases and degraded mode strategies.
If designed as a local remote-control overlay, Remote Driving may create architectural debt. If designed as part of a DATO-compatible trajectory, it can become a migration capability: useful today for business continuity and technical movements, while preparing the railway system for future automated and unattended operation.
Last modified: 2026-08
This article by Bastian Simoni is licensed under CC BY-NC-SA 4.0
Written by Bastian Simoni
Bastian Simoni is a railway system architect working at the intersection of signalling, automation and digital railway operations. Voie Libre is his personal blog on the system architecture behind the future European railway: ERTMS, DATO, automation, migration and interoperability.
Content
- Why Remote Driving matters
- Remote Driving is not autonomous operation
- Technical train movements: the first credible use case
- From remote control to digital train functions
- The driver is no longer in the cab
- Mediated perception and human factors
- Remote Driving for GoA4 degraded operation
- Responsibility, control and handover
- Operational envelopes and limits
- Architecture perspective
- From use cases to industrialisation
- Conclusion
1. Why Remote Driving matters
The long-term image of railway automation is usually the autonomous train: a train able to operate without staff onboard, perceive its environment, execute its mission and recover from abnormal situations through a wider technical and operational system.
That image is important. It concentrates many of the questions raised by GoA4: how the train understands its environment, how it knows whether it is fit to continue, how degraded operation is managed, who supervises the system and where responsibility is located when something goes wrong.
But the railway does not need to wait for full autonomous operation before Remote Driving becomes relevant.
There is a more immediate railway problem: how to use qualified driving resources where they create the most operational value.
Railway operation depends on many movements that passengers rarely see. Trains must be moved from depots to platforms, from platforms to stabling areas, from yards to maintenance tracks, from preparation areas to operational starting points, or from one controlled area to another. Freight operation adds composition, repositioning, shunting, coupling and uncoupling contexts. These movements are often short, but they can consume significant driving time.
The driving time itself is not always the problem. The problem is the full operational sequence around it: reaching the train, taking possession of it, preparing it, moving it, handing it over and returning afterwards. In a context where qualified driving resources are limited, this becomes a production issue.
Remote Driving changes this equation. It allows driving competence to be used from a remote position, within a defined operational envelope. It can reduce the amount of staff time consumed by low-value technical movements, preserve driving resources for passenger or freight service, support recovery and create one of the practical migration steps towards more automated railway operation.
This makes Remote Driving a very concrete railway capability. Its value does not only lie in what it may enable in a future GoA4 system. It also lies in the operational problems it can solve before GoA4 becomes fully mature.
2. Remote Driving is not autonomous operation
Remote Driving and autonomous operation are different answers to different questions.
In autonomous operation, the technical system is expected to manage the mission without continuous human driving. More responsibility is transferred to automation, onboard intelligence, operational supervision and the wider system.
In Remote Driving, the driving task remains human. The driver is no longer in the cab, but the driving competence remains with a qualified operator who controls the train from another location.
The railway does not remove the human. It relocates the human.
The remote driver may be located in a Remote Supervision Centre, at a dedicated remote driving workstation, or in a local remote-control position near the train. The architecture may vary depending on the use case, the operational area, the train type and the level of ambition. But the principle remains the same: the train is controlled through mediated interfaces instead of through the physical cab.
This distinction matters because the two concepts do not create the same architecture questions.
Autonomous operation asks how much responsibility can be transferred to the technical system. Remote Driving asks how an existing human responsibility can be exercised from another location. The first question is about automation of responsibility. The second is about remote allocation of control, perception and decision-making.
Remote Driving is also not a replacement for train protection. The train still needs to remain inside the railway safety system. ETCS, national ATP systems, signalling principles, operational rules and movement authorities remain essential. A remotely driven train is not a train outside the protection architecture. It is a train controlled differently within that architecture.
It is also not a generic permission to drive any train from anywhere. Remote Driving must be bounded. The operational envelope must define where it is allowed, under which conditions, at which speed, with which train type, in which signalling mode, with which communication performance, with which perception capability, with which fallback strategy and with which responsibility allocation.
This is why Remote Driving must be designed as a railway system capability, not as a remote joystick connected to a train.
3. Technical train movements: the first credible use case
The first high-value use cases for Remote Driving may be ordinary rather than spectacular.
They may not involve high-speed mainline operation. They may not start with passenger trains running in complex open environments. They may start with technical train movements.
This matters because railway production depends on many movements that remain almost invisible from the passenger perspective. A train must be prepared before entering service. It must be moved from a depot to a platform. It may need to be repositioned after service. It may need to move between stabling tracks, maintenance facilities, washing plants, yards, platforms or controlled operational areas. In freight contexts, it may be involved in composition, shunting, coupling, uncoupling or repositioning.
These movements are necessary, but they are not always the best use of scarce driving time.
Remote Driving becomes relevant when the movement is sufficiently bounded, the area is controlled, the speed is limited, the signalling and operational rules are clear, communication performance is sufficient, and the train can provide the information needed by the remote driver.
This is why depots, yards, stabling areas, terminal interfaces or selected technical movements may be more credible early use cases than broad mainline Remote Driving. They offer more controlled environments, lower speeds, fewer external uncertainties and clearer operational boundaries.
This does not make them secondary. On the contrary, they are part of the railway production system. If trains are not prepared, moved, positioned, recovered or returned to service, the passenger or freight operation is affected.
Remote Driving should therefore be assessed through operational value, not only technological ambition. The useful question is not whether a train can technically be driven remotely. It is where remote control of a train solves a real railway production problem within an acceptable operational envelope.
For many operators, the answer may start with technical train movements.
Figure 1 — Remote driving as business continuity: reducing the amount of scarce driving time consumed by technical train movements.
4. From remote control to digital train functions
A remote driving desk is the visible part of the system. The remote driver sits at a workstation, observes the train through displays, receives train status information, communicates with operational staff and sends commands through secure channels.
But the deeper change is not the desk.
From a system perspective, Remote Driving means that train functions must become accessible from outside the train. The remote driver must observe the train, understand its state, command it, supervise it, acknowledge information and interact with functions that were historically designed around a driver in the cab.
The train must therefore expose its status, alarms, diagnostics, operational limitations and command interfaces through digital channels that can be used remotely.
This changes the nature of the train.
The train becomes a digitally accessible operational asset.
Once this happens, another question appears. If a train function can be accessed remotely, should it always be performed manually by a remote driver? Or should some functions progressively become automated, with the remote operator supervising, confirming, handling exceptions and taking over when needed?
Train preparation is a good example. Bringing a train into operation may involve wake-up, configuration, diagnostics, self-tests, preconditioning, brake-related checks, train health verification and start-of-mission activities. A remote driver could perform some of these tasks manually from a remote desk. But a longer-term architecture may automate part of the workflow, leaving the remote operator to supervise, validate and intervene when something does not behave as expected.
This is where Remote Driving becomes more than remote manual control. It becomes a digitalisation path.
It forces the train to expose information about itself. It requires better train diagnostics, better health-state reporting, better remote interfaces and more structured operational states. It makes train preparation, train movement and train recovery more dependent on digital functions. It creates conditions that are also needed for intelligent rolling stock and GoA4.
In GoA4, the system must know whether the train is technically and operationally fit to continue its mission. Remote Driving is one of the first practical contexts where this question becomes unavoidable. If the driver is no longer onboard, the train must explain itself more clearly to the system.
Remote Driving may therefore begin as a productivity tool for technical movements. If it is architected correctly, it can also become a step towards automated train functions and DATO-capable rolling stock.
Figure 2 — From remote control to automated train functions: remote access to train functions can become a digitalisation path towards automation.
5. The driver is no longer in the cab
Remote Driving challenges one of the deepest assumptions of railway operation: the driver is in the cab.
Rolling stock functions have been designed around that assumption. Driver-machine interfaces are in the cab. Train control and management systems support local interaction. ETCS onboard, national train protection systems, cab radio, vigilance devices and operational procedures assume physical presence. Lineside signalling, where it remains, is positioned so that it can be perceived from the cab. Many rules, habits and safety assumptions are built around the same idea.
Remote Driving changes this assumption.
The driver may still be responsible, but the driver is no longer physically present in 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 a camera and a control desk.
It requires a reassessment of operational rules, safety assumptions, communication performance, onboard interfaces, degraded modes, cybersecurity, human factors and responsibility allocation. It also breaks traditional technical boundaries.
A remote driving system may need access to rolling stock functions usually considered under the rolling stock domain. It may need interaction with ETCS onboard, national ATP 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. It may depend on telecommunications, cybersecurity, remote supervision centres, data recording, human-machine interfaces and organisational processes.
Remote Driving sits at the intersection of rolling stock, CCS, telecom, operations, safety, cybersecurity and human factors.
That makes it a system-of-systems topic.
It is not only a remote-control layer added to the train. It is a new operational layer inserted into an existing railway system that was not designed for it. This is a typical case of technology infusion in a brownfield railway.
The architectural risk is clear: Remote Driving could be implemented as a short-term overlay that solves a local productivity issue but becomes incompatible with future automation. The architectural opportunity is equally clear: if designed as part of the DATO trajectory, Remote Driving can create reusable capabilities for remote supervision, digital train functions, handover, diagnostics, recovery and GoA4 degraded operation.
The short-term need is business continuity. The long-term direction is DATO.
Remote Driving must serve both.
6. Mediated perception and human factors
The move from onboard driving to Remote Driving changes how the driver understands the railway environment.
In conventional operation, the driver is physically located in the cab. The driver sees the track environment directly. The driver perceives distance, light, signal visibility, weather, train motion, sound, vibration and sometimes weak signs of degradation. Driving is not only a matter of formal data. It is also a matter of experience and embodied perception.
In Remote Driving, perception becomes mediated.
The remote driver sees the railway through cameras, displays, sensors, data streams and alarms. The environment is reconstructed through screens. The field of view is defined by the sensor architecture. Depth, motion, sound and peripheral cues are different. Some physical sensations disappear. The driver no longer feels the train in the same way.
This is not a minor ergonomic detail. It changes situation awareness.
If vibration, noise or physical feedback are no longer directly available, the train must compensate with better information. Diagnostics become more important. Alarms become more important. Train health monitoring becomes more important. The remote perception system must not only show images. It must give confidence, context and limits.
The remote driver must know what is visible, what is not visible, what is reliable, what is degraded and what the system cannot guarantee. The interface must support railway seriousness. It must not make real train operation feel like a simulator or a game.
This is a human factors challenge, but also an architecture challenge.
The remote driver’s workload, attention, vigilance, perception, confidence and responsibility must be considered from the beginning. The system must be designed to support real operational decision-making, not only to transmit video and commands.
A remote driving workstation may attract new profiles and reduce some physical constraints associated with traditional driving. It may create more flexible operating models. But it must also preserve the professional seriousness of driving a real train on real infrastructure with real safety consequences.
Human factors are therefore not a validation activity at the end of the project. They are part of the architecture of Remote Driving.
7. Remote Driving for GoA4 degraded operation
GoA4 removes the dependency on staff onboard for normal train operation.
It does not remove the need for recovery.
A train without a driver onboard must remain recoverable when automation reaches the boundary of its operational domain. It may face degraded ATO, degraded perception, limited communication, poor visibility, unavailable automatic processing, sensor degradation, an infrastructure event, an operational incident or a situation where the system decides that human control is preferable to continued automated movement.
Remote Driving can be one of the recovery capabilities.
It may allow a remote driver to take responsibility for the train when automation is degraded, unavailable or unable to continue. It may help move the train to a safe location, clear a line, leave a platform, reach a predefined operational point or support a controlled degraded operation.
But Remote Driving should not be treated as a universal fallback.
Some situations may require the train to stop and wait for staff on site. Some may require infrastructure intervention. Some may require passenger or freight-specific procedures. Some may exceed the acceptable remote driving envelope. Some may be incompatible with the available communication, perception or protection mode.
Remote Driving must therefore be integrated into degraded mode strategies, not treated as a magic recovery function.
The central question is not whether Remote Driving can theoretically support GoA4. The central question is under which operational conditions it can safely and usefully contribute to recovery.
This makes Remote Driving one of the bridges between today’s railway and future GoA4 operation. It can provide value before full autonomy, and it can remain valuable when autonomy exists.
But only if the operational envelope is clear.
8. 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.
In conventional operation, responsibility is closely associated with the driver in the cab. The driver is physically present, observes the environment, interacts with cab systems, communicates with operational staff and performs actions locally.
With Remote Driving, responsibility becomes more distributed.
A train may be monitored by a remote operator without being controlled. It may be under automatic operation. It may be controlled by a remote driver. It may be handed over from an onboard driver to a remote driver, from a remote driver to another remote driver, from automation to remote driving, or from remote driving back to automation.
Each transition must be explicit.
The system must know who is monitoring the train, who is controlling it, who is responsible for the movement, which mode is active, whether remote commands are accepted, whether the remote driver is authorised, whether the remote driver is attentive, and what happens if handover fails.
This is not administrative detail. It is safety logic.
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 under Remote Driving if the remote driver is no longer available. It cannot move from one control mode to another without traceability.
Remote Driving therefore requires state management. It requires driver statuses, train control statuses, handover procedures, authentication, authorisation, vigilance management and clear fallback rules.
It also requires legal and operational traceability. The system must record who took control, when, under which conditions, which commands were sent, what the train state was, and how responsibility was transferred.
Handover is one of the most important topics in Remote Driving because it is the operational mechanism by which responsibility is transferred without losing safety, traceability or situation awareness.
This is also where Remote Driving becomes organisational. It changes the way driving competence, responsibility and supervision are distributed across the railway operation.
Figure 3 — Responsibility and handover of control: remote driving requires explicit responsibility transfer between onboard driver, remote driver and automated system.
9. Operational envelopes and limits
Remote Driving should never be defined as an abstract universal capability.
The useful question is always contextual: under which operational envelope can this train be driven remotely, for this use case, in this infrastructure area, with this signalling mode, at this speed, with this communication quality and with this fallback strategy?
The operational envelope defines the conditions under which Remote Driving is allowed, safe, useful and acceptable.
It may include geography, infrastructure type, signalling mode, train type, maximum speed, passenger or non-passenger operation, movement type, video quality, communication latency, train status, visibility, weather, availability of ETCS or ATP supervision, availability of local staff, cybersecurity state, degraded mode strategy, remote driver workload and handover rules.
For technical movements, the envelope may be limited to depots, yards, stabling areas, platforms, maintenance facilities or controlled routes. For GoA4 degraded operation, the envelope may be more restrictive: move the train to a safe location, clear a line, leave a platform or reach a predefined operational point.
The more complex the environment, the more demanding the envelope becomes. Remote Driving inside a controlled depot is not the same as Remote Driving on a mainline. Low-speed empty train movement is not the same as passenger operation. A short technical movement under strong operational control is not the same as open-ended remote mainline driving.
Operational envelopes also connect Remote Driving with standardisation and industrialisation.
If Remote Driving is to become scalable, the sector will need more than local solutions. It will need common ways to describe operational envelopes, responsibilities, interfaces, safety assumptions, cybersecurity principles and migration steps.
Without this, Remote Driving may remain fragmented. It may become a set of local projects, each solving a local problem but not contributing to a harmonised automation trajectory.
Operational envelopes are therefore not a limitation of ambition.
They are the way ambition becomes deployable.
10. Architecture perspective
From an architecture perspective, Remote Driving can be understood through five connected layers.
The first layer is the train layer. The train must expose functions, status, diagnostics, commands, alarms and limitations. It must support remote interaction with TCMS, traction, braking, doors, preparation functions, communication systems and train protection interfaces where relevant.
The second layer is the safety and protection layer. Remote Driving does not replace ETCS, national ATP or signalling principles. The train must remain supervised. Movement authority, speed limits, braking constraints and protection rules remain fundamental.
The third layer is the communication and perception layer. The remote driver needs video or perception data, train status, voice or operational communication, command channels, latency control, availability monitoring and degraded communication management.
The fourth layer is the operational layer. Remote Driving must be embedded in rules, procedures, operational envelopes, degraded mode strategies, responsibility transfer and traffic management. It must be compatible with how the railway is actually operated.
The fifth layer is the cyber and human factors layer. Authentication, authorisation, command integrity, logging, monitoring, workload, vigilance and situation awareness are not optional. They are part of the system architecture.
These layers must work together. If the train does not expose the right functions, the remote driver cannot act. If perception is degraded, the driver cannot build situation awareness. If communication is unreliable, the operational envelope must change. If responsibility is ambiguous, the system is unsafe. If cybersecurity is weak, remote command becomes unacceptable.
Remote Driving cannot therefore be allocated to one subsystem alone.
It is not only rolling stock. It is not only CCS. It is not only telecom. It is not only operations. It is not only a remote centre.
It is a cross-domain capability.
This makes Remote Driving a useful example of the wider DATO challenge. The future railway will increasingly depend on functions that cross subsystem boundaries. The architecture must therefore manage interfaces, responsibilities, data, cybersecurity, safety and operations together.
Remote Driving is not the destination of railway automation. But it reveals the kind of architecture railway automation requires.
Figure 4 — Remote driving as a system-of-systems: a cross-domain function connecting train, control centre, communication, operations and cybersecurity.
11. From use cases to industrialisation
Remote Driving is still an emerging railway automation capability. This makes use cases and requirements essential.
A technology cannot be industrialised from a generic statement such as “a train can be driven remotely”. The sector needs to define when, where, why, how, by whom and under which constraints Remote Driving is useful and acceptable.
Use cases are the first step. They structure the operational problem. They identify the actors, the sequence, the system interactions, the conditions, the degraded cases and the expected outcome.
Requirements then translate these use cases into system needs: functions, interfaces, data, command channels, performance constraints, safety assumptions, cybersecurity controls, operational procedures and validation conditions.
This progression matters because Remote Driving is not one single use case. It may cover 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, poor visibility, degraded communication or remote-control failures.
These scenarios do not all require the same architecture. They do not all have the same risk. They do not all have the same industrial urgency. They do not all have the same regulatory complexity.
A progressive approach is therefore needed.
Remote Driving should not wait for a complete GoA4 framework before any industrialisation starts. But it should also not be deployed as isolated local experimentation without a long-term architectural direction.
The right path is controlled technology infusion.
Start with bounded use cases. Define operational envelopes. Validate the human-machine process. Prove the safety and cyber architecture. Learn from operation. Extend the envelope progressively. Feed the lessons into standardisation, regulation and future DATO architecture.
This approach would allow Remote Driving to deliver value before full autonomous operation, while still preparing the sector for GoA4 degraded operation and DATO.
The risk would be to do the opposite: to demonstrate Remote Driving repeatedly without creating a credible path towards industrialisation. That would leave the technology in the valley between R&D maturity and market deployment.
Remote Driving needs more than prototypes.
It needs a deployment trajectory.
12. Conclusion
Remote Driving is not simply driving a train from somewhere else.
It is a response to a practical operational pressure: the need to use scarce driving resources more efficiently. It can support business continuity by reducing the time consumed by technical train movements, depot moves, yard operations, train preparation and recovery activities.
It is also a digitalisation step. By making train functions accessible from a remote position, Remote Driving pushes rolling stock towards better diagnostics, better remote interfaces, better train health reporting and more structured operational states.
It is also a GoA4 enabler. A train without staff onboard must remain recoverable when automation reaches the boundary of its operational domain. Remote Driving may be one of the capabilities that allows the railway system to recover, move the train to a safe location, or manage selected degraded situations.
But Remote Driving is not simple. It challenges the assumption that the driver is in the cab. It transforms perception, responsibility, command, handover, safety assumptions, cybersecurity and human factors. It crosses rolling stock, CCS, telecom, operations and regulation.
This is why Remote Driving should not be designed as a short-term remote-control overlay. It should be designed as an architectural migration capability.
Its value is immediate because it can support technical train movements and business continuity. Its value is strategic because it prepares the railway system for a future where train functions, supervision, recovery and automation are increasingly distributed.
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 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: Lineside Signalling Interpretation
- Railway Automation: From Automatic Driving to Autonomous Operation
- Traffic Management System: From Traffic Supervision to Automated Railway Operations
- DATO as a System-of-Systems