Remote Driving System (RDS)

Updated 6 July 2026

Remote Driving System (RDS) is a socio-technical framework that enables remote execution of the Dynamic Driving Task using real-time sensor feedback and actuation.
Its architecture integrates vehicle sensors, a robust communication link, and a remote control station using modalities like direct control, trajectory guidance, and remote assistance.
Key challenges include managing latency, ensuring human operator adaptation, and designing fallback strategies to maintain safety when automation is insufficient.

Searching arXiv for recent and foundational papers on Remote Driving System (RDS) to support the encyclopedia article. A Remote Driving System (RDS) is a socio-technical vehicle-control arrangement in which a remote driver, not seated in a position to manually exercise in-vehicle control commands, performs the Dynamic Driving Task (DDT) from afar by perceiving the vehicle and environment through transmitted sensor information and issuing steering, acceleration, braking, and route decisions in real time. In current road-traffic research, RDS is treated as part of the broader remote-operation or teleoperation spectrum for Level 4 and 5 deployment, especially when an Automated Driving System (ADS) reaches the limits of its Operational Design Domain (ODD) and no physical driver remains in the vehicle (Hans et al., 18 Jul 2025, Shi et al., 9 Jun 2026). The concept is technically defined not by cockpit resemblance or by the mere existence of a remote link, but by the fact that remote input is processed on the vehicle-side Act stage, so that the remote driver executes the DDT rather than merely advising an onboard automation stack (Shi et al., 9 Jun 2026).

1. Conceptual definition and terminological boundaries

In contemporary literature, RDS is distinguished most sharply from Remote Assistance Systems (RAS). Remote driving is direct, full DDT control: the remote driver takes over vehicle motion control in real time and over an extended period. Remote assistance is indirect: the remote operator provides guidance or limited support, such as perception modification, collaborative path planning, waypoint guidance, or trajectory guidance, while the ADS remains responsible for executing the DDT (Hans et al., 18 Jul 2025). This distinction has operational consequences. RDS can drive through a problematic situation, whereas RAS often presupposes that the vehicle has already reached a static or safer state, commonly via a Minimum Risk Maneuver (MRM), before meaningful assistance can be applied (Hans et al., 18 Jul 2025).

A parallel taxonomy is provided by the literature on remote human input systems (RHIS), which treats remote driving as the low-level, direct-control end of a broader hierarchy. In that taxonomy, RHIS levels 1–2 correspond to remote driving, RHIS levels 3–5 to progressively more abstract remote assistance, and RHIS level 0 to remote monitoring without intervention (Bogdoll et al., 2021). The same survey notes substantial terminological inconsistency across academia, industry, standards, and legislation: “teleoperation,” “remote control,” “remote driving,” “teleoperated driving,” “remote guidance,” and “remote assistance” are often used with overlapping meanings, and SAE J3016 explicitly warns that “teleoperation” is not consistently defined in the literature (Bogdoll et al., 2021).

More recent framework work reframes the distinction in information-processing terms. On the human side, the operator is modeled as sense–plan–act; on the vehicle side, the Driving Automation System (DAS) is similarly decomposed into sense, plan, and act. Remote assistance is then defined as remote information processed on the DAS sense and/or plan stages, while remote driving is remote information processed on the DAS act stage (Shi et al., 9 Jun 2026). This formulation clarifies why input-device form factors are not decisive: a steering wheel or pedals at the remote workplace do not by themselves imply remote driving if the received input is transformed into higher-level information rather than direct actuation (Shi et al., 9 Jun 2026).

The literature also distinguishes event-based remote driving from continuous remote driving. Event-based remote driving is the dominant framing for Level 4/5 services: the ADS drives until an exceptional situation arises, then a remote driver takes over temporarily. Continuous remote driving, in which the whole trip is remotely driven without an active ADS, is explicitly treated as outside the scope of some conceptual work on public-road remote operation (Shi et al., 9 Jun 2026). This suggests that, in road-vehicle research, RDS is increasingly understood less as a wholesale replacement for automated driving than as a tightly integrated support layer for driverless mobility services.

2. System architecture and bidirectional control loop

The canonical RDS architecture comprises three coupled elements: the vehicle, the communication link, and the remote control station. For road vehicles, the vehicle side typically includes a camera-based in-vehicle sensing setup, actuation interfaces, communication equipment, and safety-related hardware or software; the control-center side includes displays, input devices, and session-management software; the communication layer carries uplink perception data and downlink control commands (Hans et al., 18 Jul 2025, Brettin et al., 14 Feb 2025).

Real deployments illustrate this structure concretely. Vay Technology’s Las Vegas system consists of a retrofitted vehicle with extra cameras, sensors, a safety controller, antennas/modems, and a proprietary connectivity stack; a Remote Control Station (RCS); and a Remote Driver (RD) who directly controls the vehicle remotely (Hans et al., 31 Mar 2025). The cockpit-like human–machine interface (HMI) provides three screens with left/front/right views, audio via microphones/speakers and headphones, steering wheel, throttle, brake, and column switches, plus visual overlays including speed, gear selection, system latency, remaining range, a planned trajectory line, and a “safety corridor” next to the planned path (Hans et al., 31 Mar 2025).

Open-source research stacks decompose the same loop more explicitly. A ROS-based teleoperated driving stack separates vehicle side, operator side, and network. On the vehicle side, a Bridge interfaces with hardware, while Perception modules handle Video, Lidar, and Projection; on the operator side, Manager, Visual, Input Devices, and Control modules support session orchestration and driving; the Network layer transports serialized ROS messages, using UDP for latency-critical data such as control commands and LiDAR and TCP via MQTT for less time-critical status information (Schimpe et al., 2021). The newer ROS 2-based TUM Teleoperation stack generalizes this pattern into Vehicle Interface, Network, Operator Interface, State Machine, Monitoring, Safety, and Logging modules, with a generic automation interface intended for automated driving stacks such as Autoware (Kerbl et al., 16 Jun 2025).

The communication loop is a first-order systems constraint because remote drivability depends on both latency and latency predictability. In the MASA Living Lab, remote driving is modeled as a bidirectional loop with continuous vehicle-to-operator video uplink and operator-to-vehicle control-command downlink. Experiments comparing ITS-G5/DSRC and 5G found that the time-difference metric

$\Delta Time = t_{\text{5G},i} - t_{\text{DSRC},i}$

was negative in 96.7% of cases, indicating that DSRC packets arrived earlier than 5G in almost all cases where coverage existed (Cauchi et al., 11 Jun 2026). The same study measured glass-to-glass latency of about 150–160 ms and estimated total end-to-end remote-driving latency at roughly 162–178 ms after adding network delay (Cauchi et al., 11 Jun 2026).

A more aggressive communication design was demonstrated over commercially available LTE using slice-based H.264 intra-refresh, forward error correction, multiple LTE modems, rate control, and scheduling. That system reported sub-50 ms roundtrip latencies for 720p, 60 FPS video, with average PSNR 36 dB, along with 46 ms average network roundtrip time and 90 ms average one-way video end-to-end latency (Belogolovy et al., 2022). These results do not eliminate the network as a constraint, but they show that the RDS architecture can be pushed well beyond the latency levels often assumed for ordinary cellular teleoperation.

3. Control modalities and remote-operation interaction concepts

RDS research no longer treats “remote driving” as a single interaction style. At least three operator-authority regimes recur: direct control, trajectory-based control, and higher-level remote assistance. Direct Control (DC) is the most traditional form: the operator continuously sends steering and velocity or steering, throttle, and brake commands, typically at the stabilization level (Schimpe et al., 2021, Kerbl et al., 16 Jun 2025). This is the mode most closely aligned with the SAE-style definition of remote driving as real-time DDT execution by the remote human (Hans et al., 18 Jul 2025).

Trajectory Guidance (TG) shifts the operator upward from continuous actuation to trajectory specification. In the UNICAR.agil implementation, the operator does not directly steer or modulate speed continuously; instead, waypoints and a goal are specified through the HMI, the path is converted into a smooth trajectory using cubic $C^2$ spline interpolation and equidistant path points, a trapezoidal velocity profile is assigned subject to curvature, maximum velocity, acceleration, and jerk constraints, and the vehicle then tracks the reference trajectory autonomously (Majstorovic et al., 2024). The operational workflow is staged: teleoperation request, takeover, trajectory creation, trajectory check, trajectory approval, trajectory tracking, monitoring, emergency stop, and automated operation or handover (Majstorovic et al., 2024).

Remote assistance introduces still higher abstraction. In the ROADS study on road works, three concepts were compared for handling up to four concurrent automated-vehicle requests: path planning, trajectory guidance, and waypoint guidance. Path planning asked the operator to select among system-generated candidate paths; waypoint guidance asked the operator to place individual points that were then connected into a route; trajectory guidance asked the operator to draw a path by mouse drag (Colley et al., 18 Feb 2025). The study reported a clear preference for path planning, the highest usability for path planning with SUS $M = 82.47$ , and the highest workload for trajectory guidance with NASA-TLX $M = 9.74$ ; trajectory guidance also resolved the fewest requests (Colley et al., 18 Feb 2025).

The principal interaction concepts can therefore be organized as follows.

Concept	Operator action	Vehicle-side role
Direct Control	Continuous steering, throttle, brake, and secondary commands	Follows low-level commands in real time
Trajectory Guidance	Specifies waypoints and destination; approves path	Verifies feasibility and tracks trajectory autonomously
Path/Waypoint-based assistance	Selects candidate path or places waypoints	Executes selected/constructed path while keeping ADS functions active

The comparative evidence suggests a trade-off rather than a strict hierarchy. Direct control maximizes remote human authority but is most sensitive to communication instability and operator workload (Majstorovic et al., 2024, Kerbl et al., 16 Jun 2025). Trajectory Guidance adds planning overhead—average total teleoperation time was 72.6 s versus 56.7 s for direct control in a construction-site comparison—but its actual driving phase was shorter, at 51.2 s versus 56.7 s, and average velocity was slightly higher at $\bar{v}_{tg} = 4.32$ km/h versus $\bar{v}_{dc} = 4.09$ km/h (Majstorovic et al., 2024). High-level path selection scales better to multi-vehicle oversight but presupposes a capable onboard autonomy stack able to execute the chosen path (Colley et al., 18 Feb 2025). A plausible implication is that the internal structure of an RDS increasingly depends on how far low-level stabilization and scene execution are delegated back to the vehicle.

4. ODD governance, safety architecture, and fallback behavior

ODD analysis is a primary design variable for RDS rather than a mere deployment constraint. A structured selection method based on the PEGASUS six-layer framework—road conditions; traffic infrastructure; temporal manipulations of layers 1 and 2; movable and dynamic objects; environment conditions; and communication, digital information, network coverage—argues that RDS should be chosen when the remote system must directly execute the DDT, handle dynamic or time-critical situations, perform controlled takeover, or continue driving through complex scenarios without stopping (Hans et al., 18 Jul 2025). RAS is favored when assistance can be delivered from a static fallback state, for strategic or advisory tasks, or under limited bandwidth and latency (Hans et al., 18 Jul 2025). The same analysis identifies a key limitation of RDS: network dependence can create fragmented ODD coverage, described as “ODD-Islands” (Hans et al., 18 Jul 2025).

Vehicle-side safety architectures are correspondingly designed to couple runtime ODD monitoring with remote human takeover. The Connected Dependability Cage (CDC) approach combines onboard monitoring and an off-board Remote Command Control Center (CCC). The cage continuously checks at least two safety requirements: that the ADS shall not cause a collision of the ego-vehicle with static obstacles in the vehicle’s environment, and that the ADS shall operate only if the image data provided by the ego-vehicle’s camera sensor is valid (Aniculaesei et al., 2023). These are implemented through safe zone computation, a LiDAR detector, and a camera validator, while a mode-control component implemented as a SCADE state machine computes cage mode and driving mode transitions (Aniculaesei et al., 2023).

The resulting mode structure explicitly formalizes responsibility transfer. Driving modes are Fully Autonomous Driving, Limited Autonomous Driving, Remote Manual Driving, In-Place Manual Driving, and Emergency Stop (Aniculaesei et al., 2023). Responsibility resides with the ADS in Fully Autonomous Driving, with the remote safety driver in Remote Manual Driving, In-Place Manual Driving, and Emergency Stop, and is shared in Limited Autonomous Driving (Aniculaesei et al., 2023). The architecture’s operational principle is that emergency stop can be triggered either by the remote safety driver via the CCC or automatically by the cage when the monitored safety requirements are violated, but recovery to full autonomy is not automatic; the remote safety driver must assess the situation and explicitly request a new mode (Aniculaesei et al., 2023).

Fallback selection remains a major controversy. A study on connection-loss fallback strategies argues that immediate braking to a standstill in public urban traffic constitutes a “safety blind spot.” Using naturalistic car-following scenarios derived from the uniD dataset, it reports that for a front-vehicle deceleration of $-3.41\ \mathrm{m/s^2}$ , collision rates rise from 0.03% at 0.0 s reaction time to 8.74% at 1.0 s, 46.65% at 1.5 s, 73.09% at 2.0 s, and 86.09% at 2.5 s under the Intelligent Driver Model; the corresponding Sudden Braking Model values reach 65.13% at 2.5 s (Brettin et al., 14 Feb 2025). Even a more moderate front-vehicle deceleration of $-1.71\ \mathrm{m/s^2}$ still yields substantial collision rates at longer reaction times (Brettin et al., 14 Feb 2025). The paper explicitly interprets this as a SOTIF-relevant hazard and argues that “braking-to-stop” should not be treated as an intrinsically acceptable universal fallback (Brettin et al., 14 Feb 2025).

Taken together, these strands establish a characteristic RDS safety pattern: continuous assessment of whether the current situation remains inside the combination of ADS and network capability; explicit allocation of control authority across automation, remote human, and safety-layer logic; and increasing skepticism toward fallback strategies that preserve vehicle self-containment at the cost of external traffic safety (Aniculaesei et al., 2023, Brettin et al., 14 Feb 2025).

5. Human performance, operator adaptation, and motion quality

RDS performance is constrained not only by actuation and networking but also by the altered perceptual and vestibular conditions imposed on the remote driver. An explorative study comparing remote driving (RD) and normal driving (ND) in the same slalom manoeuvre, using a Research Concept Vehicle-model E (RCV-E) and a remote control tower (RCT), found that motion sickness and steering velocity both increase by about one quarter from ND to RD, with paired t-test results of $p = 0.0008$ for motion sickness and $p = 0.0003$ for steering velocity (Papaioannou et al., 2023). Motion sickness increased by about 26% and steering velocity by about 25%, while ride comfort did not show a statistically significant overall difference ( $C^2$ 0) and throttle input variations did not significantly differ between ND and RD ( $C^2$ 1) (Papaioannou et al., 2023).

That study operationalizes comfort through weighted accelerations in six degrees of freedom, extending ISO-2631 concepts. For each axis,

$C^2$ 2

and the overall score is

$C^2$ 3

Frequency weighting is applied as

$C^2$ 4

In remote driving, both motion sickness and ride comfort depend exclusively on steering velocity in multiple regression, with $C^2$ 5, $C^2$ 6, $C^2$ 7, and $C^2$ 8, $C^2$ 9, $M = 82.47$ 0 (Papaioannou et al., 2023). The authors therefore argue that remote steering feedback should be designed not to mimic normal driving perfectly, but to improve situational awareness and reduce steering-velocity spikes (Papaioannou et al., 2023).

Large-scale operational data similarly show that remote driving skill is highly trainable but front-loaded. An analysis of 14,291.65 km and 38,854.67 minutes of remote driving by 25 RDs in an urban Las Vegas ODD identified 183 disengagements attributable to RD performance and found a pronounced reduction in Safety Driver (SD) interventions within the first 400 km of driving experience, with improvement largely plateauing by 400–500 km (Hans et al., 31 Mar 2025). Chi-square tests reported significant differences for RD-L1 versus RD-L2 ( $M = 82.47$ 1, $M = 82.47$ 2) and RD-L1 versus RD-L3 ( $M = 82.47$ 3, $M = 82.47$ 4), but not for RD-L2 versus RD-L3 ( $M = 82.47$ 5, $M = 82.47$ 6) (Hans et al., 31 Mar 2025). The most common intervention scenarios were “Impatient for other traffic participants/obstacles,” “Braked too late for signs,” “Leaving the lane left/right,” and traffic-light decisions when the signal turned yellow or red (Hans et al., 31 Mar 2025).

A closely related study classifies human-performance-related challenges through SD interventions, harsh driving events, and questionnaire data. It reports 1,646 harsh events across 2,644.48 km, with 558 braking, 979 acceleration, 15 left steering, and 127 right steering events, and confirms that braking is perceived as the largest challenge by 57.9% of respondents (Hans et al., 12 Mar 2025). The defined harsh-event thresholds include braking events at $M = 82.47$ 7, acceleration events at $M = 82.47$ 8, and right and left steering events at $M = 82.47$ 9 and $M = 9.74$ 0 respectively (Hans et al., 12 Mar 2025). The same work attributes remote-driving difficulty to latency, limited haptic feedback, video limitations, and camera-perspective distortions, and notes that experience shifts behavior from cautious or uncertain modulation toward more anticipatory control (Hans et al., 12 Mar 2025).

A further urban ODD study based on 24,221.5 km of remotely driven distance found that Remote Driving Efficiency (RDE),

$M = 9.74$ 1

increases most strongly during the first 300 km, stabilizing around 400 km in the range of 0.35–0.42 km/min, with improvement in vehicle control continuing up to about 600 km (Hans et al., 29 Mar 2025). The same paper reports that detailed road-section-based ODD training outperformed scenario-based ODD training especially in braking, with mean braking deceleration of $M = 9.74$ 2 versus $M = 9.74$ 3 and a Mann–Whitney U-test result of $M = 9.74$ 4 (Hans et al., 29 Mar 2025). Across these studies, the common finding is that RDS safety and quality depend heavily on targeted early training, especially for braking judgment, urban intersection handling, lane control, and adaptation to missing haptic and vestibular cues.

6. Software stacks, connectivity engineering, and experimental platforms

The research ecosystem around RDS increasingly relies on reusable software infrastructure. An early open-source teleoperated driving stack built on ROS isolates vehicle-specific adaptation inside a Bridge package and keeps the rest of the architecture reusable across platforms, with configurable actuation limits, sensor names, coordinate frames, transform trees, RTSP video pipeline settings, and LiDAR receiver pairs (Schimpe et al., 2021). The stack was demonstrated on a full-size Audi Q7, an F1TENTH 1:10-scale RC car, and the SVL simulator (Schimpe et al., 2021). For the Audi Q7, a 40 Hz, 520p video feed transmitted over a wired connection to a 144 Hz monitor yielded glass-to-glass latency of approximately 104 ms, while zoomed actuation plots showed approximately 100 ms actuation latency (Schimpe et al., 2021). For the F1TENTH platform, the reported glass-to-glass latency was 241 ms at 15 Hz and 520p (Schimpe et al., 2021).

The TUM Teleoperation stack extends this logic into a ROS 2, Autoware-compatible framework that jointly supports Remote Driving and Remote Assistance. Its Network layer contains Video, LiDAR, Data, and Config modules; the Video module uses GStreamer, H.264 with ultra-low-latency settings, and separate RTSP channels, and supports a multi-router setup with different mobile network providers for redundancy (Kerbl et al., 16 Jun 2025). The stack was demonstrated on EDGAR, a real-world research vehicle using Autoware; vEDGAR, its digital twin with CARLA; and RoboRacer, a small-scale vehicle (Kerbl et al., 16 Jun 2025). On EDGAR, video transmission latency over LTE was measured at 150–200 ms with a median of 160 ms at 40 Hz camera frame rate; in-vehicle and LAN configurations were both around 125 ms, implying a network contribution of about 35 ms (Kerbl et al., 16 Jun 2025). Control-command transmission latency over LTE averaged $M = 9.74$ 5 ms with TCP and $M = 9.74$ 6 ms with UDP, while serialization/deserialization plus DDS local transmission overhead remained below 1 ms (Kerbl et al., 16 Jun 2025).

Connectivity studies reinforce the need for technology-aware network design. In the MASA Living Lab, DSRC/ITS-G5 provides lower latency and strong reliability within RSU coverage, while 5G offers route-wide continuity with higher and more variable delay; the resulting deployment recommendation is a hybrid multi-RAT architecture in which ITS-G5 acts as the primary low-latency bearer and 5G as the fallback continuity layer (Cauchi et al., 11 Jun 2026). The LTE teleoperation study likewise shows that low-latency remote driving over commercial cellular infrastructure is feasible only through explicit rate control, scheduling, multi-modem diversity, forward error correction, and video-pipeline designs that minimize buffering (Belogolovy et al., 2022). RDS communication engineering therefore functions less as a transport afterthought than as part of the control loop itself.

7. Formal abstractions and extensions beyond passenger-road teleoperation

Although the most developed RDS literature concerns road vehicles, the underlying idea generalizes across formal methods and adjacent mobility domains. A holistic ability-graph framework describes remote-operated, autonomous, and human driving using a common, solution-neutral graph of abilities and their quality dependencies (Pfab et al., 2024). In that framework, the same public-road driving abilities—perception, localization, prediction, planning, vehicle handling, traffic-rule handling, monitoring, and secondary driving tasks—must exist regardless of whether they are realized by an in-vehicle human, an automated stack, or a remote operator mediated by communication infrastructure (Pfab et al., 2024). For RDS specifically, the framework is useful because the required abilities are distributed across onboard sensing and actuation, offboard human cognition, and networking, while the graph itself intentionally models dependency of quality rather than information flow (Pfab et al., 2024).

Railway remote driving foregrounds a different subsystem: low-latency video delivery to a remote operator. A railway-oriented study compares RTSP and WebRTC over RTP on a 5G Standalone network with VPN, using industrial Basler cameras and a Jetson Xavier media server (Mejias et al., 2024). Under sufficient bandwidth, it reports Screen-to-Screen latency around 150 ms and End-to-End latency around 60–70 ms for both protocols, while favoring RTSP for multi-access operating models in which both the remote control center and the cab may need the same stream (Mejias et al., 2024). The paper also introduces a three-level adaptive bitrate controller over HIGH, MEDIUM, and LOW profiles of 5 Mbps, 3.5 Mbps, and 2 Mbps at 1920×1080 and 30 fps, driven by RTCP jitter and packet-loss feedback (Mejias et al., 2024). This work is not a full train-control RDS, but it isolates one enabling layer that road-vehicle work also repeatedly identifies as safety-critical: stable, low-latency perception delivery.

The acronym also appears in planetary robotics, where “remote driving systems” refers not to public-road teleoperation centers but to architectures that preserve remote drivability under extreme environmental stress. The DISTANT design moves traction motors, steering motors, and suspension actuation elements from wheel modules into a thermally protected warm box inside the rover body, transmitting power and steering via cardan joints, bevel gears, and a capstan drive (Luna et al., 7 Oct 2025). The selected configuration—double wishbone suspension, dual cardan-joint wheel traction transmission, and capstan steering—targets a 50 km traverse requirement without performance degradation, with steering efficiency of approximately 91% and wheel transmission efficiency ranging from 43% to 99% depending on articulation angle (Luna et al., 7 Oct 2025). In road-traffic terms, this is not an RDS in the SAE sense; however, it demonstrates that the broader design problem of “remote driving systems” can also mean re-architecting actuation and feedback paths so that remote or delayed human supervision remains viable under thermal cycling, dust contamination, and long-duration wear (Luna et al., 7 Oct 2025).

Across these formal and cross-domain extensions, a consistent pattern emerges. RDS is not reducible to a video link plus a steering wheel. It is a distributed control system whose performance depends on where sensing, planning, actuation, monitoring, and fallback authority are placed; how those functions are represented formally; and how robustly the combined human–machine loop can be maintained under ODD limits, network disturbance, and environment-specific stress (Pfab et al., 2024, Mejias et al., 2024, Luna et al., 7 Oct 2025).