---
title: Remote Driving System (RDS)
url: https://www.emergentmind.com/topics/remote-driving-system-rds
type: topic
---

# Remote Driving System (RDS)

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 [2507.14347][2606.11336]. 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 [2606.11336].

## 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 [2507.14347]. 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 [2507.14347].

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 [2109.08599]. 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 [2109.08599].

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 [2606.11336]. 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 [2606.11336].

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 [2606.11336]. 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 [2507.14347][2502.10243].

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 [2504.00246]. 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 [2504.00246].

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 [2109.11252]. 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 [2506.13933].

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 [2606.13292]. 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 [2606.13292].

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 [2209.09794]. 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 [2109.11252][2506.13933]. This is the mode most closely aligned with the SAE-style definition of remote driving as real-time DDT execution by the remote human [2507.14347].

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 [2402.10014]. The operational workflow is staged: teleoperation request, takeover, trajectory creation, trajectory check, trajectory approval, trajectory tracking, monitoring, emergency stop, and automated operation or handover [2402.10014].

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 [2502.12680]. 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 [2502.12680].

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 [2402.10014][2506.13933]. 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 [2402.10014]. High-level path selection scales better to multi-vehicle oversight but presupposes a capable onboard autonomy stack able to execute the chosen path [2502.12680]. 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 [2507.14347]. RAS is favored when assistance can be delivered from a static fallback state, for strategic or advisory tasks, or under limited bandwidth and latency [2507.14347]. The same analysis identifies a key limitation of RDS: network dependence can create fragmented ODD coverage, described as “ODD-Islands” [2507.14347].

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 [2307.06258]. 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 [2307.06258].

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 [2307.06258]. 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 [2307.06258]. 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 [2307.06258].

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 [2502.10243]. Even a more moderate front-vehicle deceleration of $-1.71\ \mathrm{m/s^2}$ still yields substantial collision rates at longer reaction times [2502.10243]. 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 [2502.10243].

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 [2307.06258][2502.10243].

## 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 [2305.07370]. Motion sickness increased by about 26% and steering velocity by about 25%, while ride comfort did not show a statistically significant overall difference ($p = 0.109$) and throttle input variations did not significantly differ between ND and RD ($p = 0.139$) [2305.07370].

That study operationalizes comfort through weighted accelerations in six degrees of freedom, extending ISO-2631 concepts. For each axis,
$$
RC_{W_i} = \left( \frac{1}{t} \int_0^t a_{i_W}^2 \, d\tau \right)^{1/2},
$$
and the overall score is
$$
RC = \left( \sum_{i=1}^{6} k_i^2 RC_{W_i}^2 \right)^{1/2}.
$$
Frequency weighting is applied as
$$
A_{w_i} = WP_i \cdot WA_i \cdot A_i.
$$
In remote driving, both motion sickness and ride comfort depend exclusively on steering velocity in multiple regression, with $RC: y \sim 1 + SV$, $R^2 = 0.47$, $p = 0.0051$, and $MS: y \sim 1 + SV$, $R^2 = 0.57$, $p = 0.0012$ [2305.07370]. 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 [2305.07370].

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 [2504.00246]. Chi-square tests reported significant differences for RD-L1 versus RD-L2 ($\chi^2 = 21.70$, $p = 0.006$) and RD-L1 versus RD-L3 ($\chi^2 = 19.61$, $p = 0.012$), but not for RD-L2 versus RD-L3 ($\chi^2 = 5.70$, $p = 0.681$) [2504.00246]. 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 [2504.00246].

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 [2503.09865]. The defined harsh-event thresholds include braking events at $a_x < -2.5\ \mathrm{m/s^2}$, acceleration events at $a_x > 2.0\ \mathrm{m/s^2}$, and right and left steering events at $a_y > 2.9\ \mathrm{m/s^2}$ and $a_y < -2.9\ \mathrm{m/s^2}$ respectively [2503.09865]. 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 [2503.09865].

A further urban ODD study based on 24,221.5 km of remotely driven distance found that Remote Driving Efficiency (RDE),
$$
\text{RDE} = \frac{\text{remotely driven distance (km)}}{\text{remotely driven time (min)}},
$$
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 [2503.22992]. The same paper reports that detailed road-section-based ODD training outperformed scenario-based ODD training especially in braking, with mean braking deceleration of $-2.89\ \mathrm{m/s^2}$ versus $-3.08\ \mathrm{m/s^2}$ and a Mann–Whitney U-test result of $p = 0.001$ [2503.22992]. 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 [2109.11252]. The stack was demonstrated on a full-size Audi Q7, an F1TENTH 1:10-scale RC car, and the SVL simulator [2109.11252]. 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 [2109.11252]. For the F1TENTH platform, the reported glass-to-glass latency was 241 ms at 15 Hz and 520p [2109.11252].

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 [2506.13933]. 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 [2506.13933]. 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 [2506.13933]. Control-command transmission latency over LTE averaged $15.55 \pm 2.37$ ms with TCP and $15.49 \pm 1.81$ ms with UDP, while serialization/deserialization plus DDS local transmission overhead remained below 1 ms [2506.13933].

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 [2606.13292]. 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 [2209.09794]. 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 [2406.12669]. 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 [2406.12669]. 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 [2406.12669].

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 [2406.02062]. 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 [2406.02062]. 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 [2406.02062]. 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 [2510.05981]. 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 [2510.05981]. 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 [2510.05981].

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 [2406.12669][2406.02062][2510.05981].

Source: https://www.emergentmind.com/topics/remote-driving-system-rds