Remote Driving is often misunderstood as simply “driving a train from somewhere else”. In railway automation, it is more useful to see it as a cross-domain capability for operational continuity, degraded modes and selected technical movements. It connects rolling stock functions, train control, communications, perception, cybersecurity, human supervision and operational rules.
This makes Remote Driving a system-of-systems topic rather than a standalone onboard feature. This article explains how Remote Driving can support the transition from today’s technical train movements towards future GoA4 degraded operation.
Executive Summary
Remote Driving is not autonomous train operation. It is a capability allowing a qualified operator to control a train from a remote position, under defined operational conditions, using communication links, train status information, remote interfaces, video or perception data, command channels and safety supervision.
Its first value may not be the spectacular image of a mainline train driven remotely at high speed. The more realistic early value lies in bounded operational contexts: technical train movements, depot-to-platform movements, stabling, yard operations, train preparation, repositioning, recovery and selected degraded situations. These movements are often invisible to passengers, but they consume scarce driving resources and are essential to daily railway production.
Remote Driving should therefore be understood as a business continuity and productivity capability. It does not remove the need for railway driving competence. It changes where that competence is located and how it can be allocated. In a context where staff availability may become a constraint on railway service, this is not a marginal topic.
At the same time, Remote Driving is also relevant to the GoA4 trajectory. A train without staff onboard must still be recoverable when automation reaches the boundary of its operational domain. Remote Driving may provide one possible degraded-mode or recovery capability, provided that the operational envelope is clearly defined.
The architectural challenge is that Remote Driving breaks one of the deepest assumptions of railway operation: the driver is in the cab. Direct perception becomes mediated perception. Cab-based interaction becomes remote human-machine interaction. Local action becomes remote command. 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 is a cross-domain system capability connecting train interfaces, ETCS or national protection systems, TCMS, communications, perception, cybersecurity, operational rules, human factors, safety cases and degraded mode strategies.
If designed only as a short-term remote-control overlay, it may create architectural debt. If designed as part of a DATO-compatible trajectory, it can become a migration capability: useful today for technical train movements and operational continuity, while preparing the railway system for future automated and autonomous operation.
Last modified: 2026-06
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
- Documentation and further reading
1. Why Remote Driving matters
Railway automation is often presented through a long-term image: the autonomous train. This image is powerful because it concentrates many of the questions raised by GoA4. How can a train operate without staff onboard? How does it perceive its environment? How does it know whether it is fit to continue its mission? How is degraded operation managed? Who supervises the system? Who is responsible when something goes wrong?
These questions are essential. But before full autonomous operation becomes widely available on mainline railways, another capability deserves attention: Remote Driving.
Remote Driving is sometimes presented as a degraded-mode capability for GoA4. If the automation system cannot continue its mission, a remote driver may take control and move the train to a safe location or through a limited operational scenario. This is true, but it is only part of the story.
Remote Driving may also answer a more immediate question: how can railway operators maintain service when driving resources become scarce?
Railway operation remains highly dependent on qualified operational staff. Drivers are needed not only for trains carrying passengers or freight, but also for many technical movements that make the service possible. Trains must be moved from depots to platforms, from platforms to stabling areas, from yards to maintenance tracks, or from one operational position to another. These movements are often short, but they can consume significant driving time.
A driver may spend much more time reaching a train, taking possession of it, preparing it and returning afterwards than actually driving it. 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. It can help preserve driving resources for passenger or freight service. It can support recovery. It can also create one of the migration steps towards more automated railway operation.
This is why Remote Driving should not be seen as a futuristic curiosity. It is a practical railway capability. Its value lies not only in what it may enable in GoA4, but also in what it can solve before GoA4 becomes fully mature.
2. Remote Driving is not autonomous operation
Remote Driving is not a new name for autonomous train operation. The distinction is essential.
In autonomous operation, the technical system is expected to manage the mission without continuous human driving. In Remote Driving, a human still performs the driving task, but from a remote position. The driver is no longer in the cab, but the driving competence remains human.
This means that Remote Driving does not remove the human from railway operation. It relocates the human.
The remote driver may be located in a Remote Supervision Centre, at a dedicated remote driving workstation, or in some cases in a local remote-control position near the train. The exact architecture may vary according to the use case, the operational context and the level of ambition. But the principle remains the same: the driver controls the train through mediated interfaces rather than through the physical cab.
This distinction matters because Remote Driving and autonomous operation do not raise the same 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. The second is about remote allocation of control, perception and responsibility.
Remote Driving is also not a replacement for train protection. The train still needs safe supervision. ETCS, national ATP systems, signalling principles, operational rules and movement authorities remain essential. A remotely driven train is not a train outside the railway safety system. It is a train controlled differently within the railway safety system.
Remote Driving is also not a generic permission to drive any train from anywhere. It must be bounded. The operational envelope must define where Remote Driving 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 not be the most spectacular ones.
They may not be high-speed mainline operation. They may not be passenger trains running in open environments. They may be technical train movements.
This is important because railway production depends on many movements that passengers rarely see. 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 question is not: can we drive a train remotely? The better question is: where does remote control of a train solve a real railway production problem with 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
Remote Driving is often described from the remote desk perspective. A remote driver sits in a workstation, observes the train through displays, receives train status information, communicates with operational staff, and sends commands through secure channels. This is correct, but it does not capture the deeper architectural change.
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 historically designed for a driver in the cab. The train must 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 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. But if it is architected correctly, it can 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.
In other words, Remote Driving sits at the intersection of rolling stock, CCS, telecom, operations, safety, cybersecurity and human factors.
This is why it is 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 shift 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
Remote Driving is also relevant for GoA3 and GoA4.
In GoA4, no driver or onboard staff is required for normal train operation. This means that when the automated system reaches the limits of its operational domain, the railway must still provide a way to manage the situation.
A train without a driver onboard must remain recoverable.
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.
This may be relevant when ATO is degraded, when perception is degraded, when automatic processing is unavailable, when communication is limited, when visibility is poor, when sensors are degraded, when the train must be recovered after an incident, or when the operational system decides that human remote control is preferable to continued automated movement.
However, Remote Driving should not be presented 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.
This is why Remote Driving must be integrated into degraded mode strategies, not treated as a magic recovery function.
The key question is not whether Remote Driving can theoretically support GoA4. The key 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 discussed as an abstract universal capability.
The right question is not: can a train be driven remotely? The right question is: 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.
This is where Remote Driving connects 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.
This is why Remote Driving cannot 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 good 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 is why use cases and requirements matter.
A technology cannot be industrialised only 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 is important 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.
This is why a progressive approach is 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 still be 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