Remote assistance in a self-driving vehicle pilot

A remote person can change the legal question

A shuttle stops at unexpected roadworks. Its automated system cannot classify a temporary sign and asks a remote support worker what the obstruction is. That worker describes the sign; the vehicle independently chooses whether and how to proceed. Now change one fact: the worker steers the vehicle around the cones using a live video feed. These two operations may look similar on a control-room screen, but they raise different questions about who performs the driving task, whether the vehicle is driving itself and whether the no-safety-driver pilot guidance is the right route.

Section 8 of the Automated and Electric Vehicles Act 2018 says a vehicle is driving itself when an individual is not controlling it and does not need to monitor it. The Department for Transport's pilot applicant guidance recognises that some remote assistance may occur. It also says the pilot guidance does not apply where a safety driver is needed to control the vehicle or monitor it with a view to immediate safety-critical intervention while the automated system is engaged. In its operator assessment table, the DfT describes remote assistance as advice only and expects documented, tested response plans.

This page owns the boundary between remote advice, monitoring and remote control in the present Great Britain no-driver pilot. The pilot overview owns the general application path. The 2018 Act listing decision has its own vehicle-focused case. The broader future Automated Vehicles Act 2024 regime has different role concepts and commencement questions. A company should not borrow a future operator label to avoid analysing today's remote worker's actual activity.

A short description such as remote supervisor is insufficient. The applicant needs a function-by-function account of what the person sees, decides and can command, when they are expected to act and whether the vehicle can remain safe if nobody answers. Specialist legal and engineering reviewers must assess the precise design. This guide supplies questions and an evidence structure, not an eligibility decision for a named pilot.

Separate advice, observation and control

Remote advice gives information or a limited choice to an automated system that retains responsibility for the driving task. The vehicle must validate the input against its own safety constraints and choose the motion. An example might be an operator identifying a static obstruction after the vehicle has already stopped safely. Even that example needs design review. If the vehicle accepts a command to enter a hazardous gap without independent assessment, the operation may be much closer to remote control than the interface description suggests.

Remote observation can serve several purposes. An operator might monitor fleet health, passenger requests or whether a vehicle has reached a stop. The legal concern is sharper where a person must watch the road or vehicle surroundings so they can intervene immediately in how the vehicle drives. A team should therefore document the purpose and timing of each video feed, alert and dashboard. Is the human expected to prevent a collision by pressing an emergency control? Would the vehicle remain safe if the person looks away for thirty seconds? An answer that depends on continuous human vigilance is difficult to reconcile with a no-safety-driver claim.

Remote driving involves a person controlling the vehicle's motion from elsewhere. Steering, braking, acceleration and commands that determine a trajectory may all matter. The legal label depends on the actual function, not the location of the person or whether the interface is marketed as assistance. A remote driver also raises questions about licensing, insurance, communication failure, visibility and responsibility that this article cannot settle. The applicant should obtain specialist advice before treating remote driving as part of a current self-driving pilot.

A useful function table lists each command, its inputs, its effect on motion, the vehicle's independent checks, the human's expected response time and the fallback when the human does not respond. Include indirect controls. Selecting a waypoint, approving a route around a barrier or changing a speed limit may affect motion even if the operator never touches a virtual steering wheel. The key question is whether the automated system remains capable of the entire dynamic driving task and can safely reject unsuitable advice.

Test the monitoring expectation, not only the user interface

A control centre may say its staff only monitor exceptions. That claim needs a workload analysis. How many vehicles may call one person at once? What does the vehicle do while waiting? Could an event turn hazardous before the operator can respond? Is the person watching a live road feed continuously, or receiving a request after the vehicle has already reached a safe state? A feature design that requires a response in two seconds may effectively create an immediate human safety monitor even if the job description says advisor.

The DfT pilot guidance says the pilot route does not apply to a vehicle requiring a safety driver for control or for monitoring with a view to immediate safety-critical intervention. The 2018 Act's definition of driving itself also directs attention to control and required monitoring. The applicant should compare those tests with actual system timing. Demonstrate what happens if the operator is absent, distracted, busy with another vehicle or disconnected. If the vehicle cannot keep itself safe in those circumstances, changing the staffing ratio may not solve the underlying route issue.

An alert is not proof of safe monitoring. The engineering team should show when the system detects the need for help, how it reaches a safe condition, what information is sent, and what it does while waiting. The human factors team should examine whether the operator can understand the scene from the available data and whether the requested action is within training. The legal team should consider whether the person has become part of the driving task. All three reviews are needed because an answer in one discipline can expose a problem in another.

A company might argue that its remote worker is not a driver because the vehicle normally handles the route. The exceptional event still matters. If the planned fallback relies on immediate remote steering at every difficult junction, the automated system may not perform the claimed task independently in the intended circumstances. Record both routine and foreseeable exceptional operations rather than analysing only the best demonstration run.

Design a safe waiting state

Remote assistance is easier to defend when the vehicle can reach and maintain a safe state before asking for help. The actual safe state depends on the road, vehicle, passengers and local hazards. Stopping in a live lane may be safer than uncontrolled motion but can still create a serious traffic obstruction. The technical team must justify the fallback, signalling, location choice, hazard awareness and recovery procedure for the defined route. Do not call every stopped vehicle safe by definition.

Describe the decision sequence. The automated system detects an uncertain condition, determines whether it can continue within its operating boundary, moves or stops as designed, sends a request, validates any response and resumes only when its own conditions are met. The operator should see enough context to answer the request without guessing. If the system cannot reliably distinguish a harmless object from a child or cyclist, the support worker's label should not override the vehicle's safety constraint. Test deliberately misleading or stale advice.

Set a maximum time the vehicle can wait before escalation based on safety and passenger needs. A blocked pavement, school gate or emergency route may require a different response from a quiet depot. The operator may need to send a recovery team, notify traffic management or support passengers. Those actions are service and safety management, even if they do not constitute driving. The pilot application should show how the operator detects a stuck vehicle and prevents repeated requests from overwhelming the team.

A fallback plan should also address power failure, sensor failure and loss of remote connection. Can the vehicle safely remain in place? Can it move to a safer position without human control? Who can access it? Are first responders given a way to secure it? The official first-responder guidance may help with those operational interfaces. The applicant must test the actual vehicle and route rather than copy a generic stopping procedure.

Validate communications and workload

The DfT guidance identifies latency, bandwidth, coverage, fallback protocols, system-level testing and functional safety assurance as part of remote-assistance assessment. Test them where the vehicle will actually operate. A network that performs well at the depot can fail between tall buildings or during a crowded event. Record measured coverage and delay, not only a provider's map. Test both the request and the operator's response, including authentication, timestamps and whether a delayed message can be mistakenly applied to a changed scene.

Bandwidth affects what the remote worker can understand. A compressed or frozen video feed may conceal a pedestrian. A single camera angle may omit a hazard behind the vehicle. If the person must make a safety-relevant judgment, specify the minimum information quality and what the system does when it falls below that limit. Do not infer that a successful laboratory demonstration proves the interface works in rain, darkness or poor connectivity.

Workload testing should include simultaneous requests, shift changes, breaks and an incident requiring prolonged attention. A ratio of operators to vehicles can be an operating constraint, but a number alone does not show whether staff can handle the worst credible combination of events. Use scenarios with realistic arrival patterns and recovery times. Record when an operator declares overload, how the vehicle queue is prioritised and whether new trips are stopped. A specialist should review both the human factors and the functional safety argument.

Cyber security is inseparable from communications. Authenticate advice, limit operator privileges, log commands and protect the channel against impersonation or replay. The separate pilot cyber assurance case should examine the architecture in depth. This page asks whether the remote-assistance function still behaves safely when a message is lost, delayed, duplicated or malicious. A secure channel is useful but does not make an unsafe command safe to execute.

Define competence and authority

A remote assistant needs training on the vehicle, operating domain, interface, limits of authority and escalation. The training should distinguish giving advice from controlling motion. Staff should practise when to decline a request because the scene is unclear. They should know how to contact a recovery team, passenger support or emergency services. Competence cannot be inferred from a conventional driving licence alone, and this guide does not claim that a single statutory remote-assistant qualification applies to all pilots.

Specify who can change a route, unlock a vehicle, approve movement after a stop, alter an operating limit and close an incident. Those powers may belong to different roles. An operator should not gain a technical command merely because it is needed in an emergency. If a command can make the vehicle move, assess whether the function changes the legal and safety character of the service. Include supervisor overrides and maintenance modes in the analysis. A hidden engineering interface can create a remote-driving capability even when the normal operator screen lacks one.

Record identity, role, training version, supervised practice and reassessment trigger. A new route, software interface or vehicle model can change the skill required. Watch real operations for patterns of incorrect advice, slow response or workarounds. Use those findings to update training and, where necessary, suspend a function. The existence of a training certificate does not prove the person can interpret a live scene under time pressure.

Contracted support requires the same clarity. A supplier control room may operate the remote interface while another company holds the VSO or passenger permit. The application should state who employs and supervises staff, who owns logs, who can suspend the service and how incidents are escalated. The DfT guidance says operator requirements can apply to contracted parties performing operator functions. A contract should enable the pilot applicant to obtain evidence and carry out its own safety duties.

Keep a traceable assistance record

For each material request, capture the vehicle, software build, location, time, reason, vehicle state, information shown to the operator, response, automated-system validation, resulting motion and any failure. This is a proposed evidence design, not a universal legal field list. The detail should be proportionate to safety and data protection needs. A useful record lets an investigator distinguish advice from human control and reconstruct whether the vehicle followed its own safety constraints.

Classify requests by cause. Repeated uncertainty at one junction may reveal a perception weakness or a route that lies outside the supported operating domain. A high volume of operator help may undermine the claim that the automated system can perform the task without human monitoring. Analyse rates, contexts and trends, not only whether each journey ended without injury. If staff routinely give the same instruction, consider whether a system change or route restriction is needed.

Logs also support accountability when a communication fails. The record should show whether the vehicle received a response, whether the response was stale and why it chose to proceed or remain stopped. If two operators can respond to the same request, the system should prevent conflicting commands. If a supplier hosts the log, the pilot applicant needs prompt lawful access for an incident and for authority review. Protect personal and sensitive data and set a justified retention schedule.

Link the assistance record to the vehicle safety case and operator safety management system. A failure mode identified in testing should have a monitoring signal and an operational response. An incident should update the test scenario library if it reveals a new hazard. The purpose is to show that the pilot learns from real operations, not to accumulate a large archive of unreviewed video.

Recheck the role when the system changes

Remote help can evolve gradually. A first release may only label static objects. A later release may allow a worker to select a path, set a speed or command a vehicle to leave a queue. Each added function should trigger a legal, safety, cyber and insurance review before deployment. The applicant should compare the new function with the 2018 Act definition, DfT pilot guidance, the issued VSO and any passenger permit. Do not assume the original permission silently covers a broader human role.

The future Automated Vehicles Act 2024 framework includes concepts for vehicles without a user in charge and operators, but most of that full authorisation system remains subject to commencement and implementing rules in the current pilot period. This guide does not apply those future concepts as if they had replaced the present 2018 Act listing route. Recheck commencement when a pilot continues into a new regulatory phase. A system can also change from a no-driver pilot back to a supervised trial; the right guidance follows the actual operation, not the project's original branding.

A change example makes the boundary concrete. A supplier proposes a button that lets a remote worker move a stopped shuttle ten metres past roadworks. The distance is short, but the function may give the person direct control of motion. The applicant should not approve it as a minor user-interface improvement. It should identify what the vehicle independently checks, who monitors the scene, what happens if the link drops and whether the person now performs part of the dynamic driving task. A specialist legal review should decide whether the pilot route remains appropriate. The engineering team should withhold the function until that assessment and any required authority engagement are complete.

A practical design review table

This table helps a project team expose assumptions. It is not an official pass mark or a legal classification tool. The strongest evidence is a matched set of design documents, measured tests and observed operator behaviour for the actual route. A policy stating that the operator never drives remotely is contradicted if an engineering screen can command motion in live service.

Where Complys may fit

An organisation may need to track remote-assistance procedures, staff competence, test evidence, supplier agreements and review dates. Complys can be assessed for administrative evidence control in a demonstration. This article does not claim that Complys provides a remote-control centre, monitors vehicles, analyses latency, determines whether a person is a driver or submits a pilot application. Product-owner confirmation is needed before any specific feature promise is published.

In a demonstration, use a lost-connectivity scenario and a proposed new operator command. Ask how the team would link the training and test evidence to the relevant vehicle, assign the legal review, mark the function as pending and retrieve the old decision after an incident. If live telemetry or control remains in another system, say so. The AV software overview provides a wider buying script. The AV checker can help orient a reader to possible regimes, but cannot decide whether a remote worker has become a driver.

The next step is to list every remote function and test its effect on control, monitoring and safe fallback. Have AV engineering, human factors and road-law specialists review the same function table. A convincing no-driver pilot is one in which the automated system can carry the driving task within its defined limits while remote people provide bounded support. That conclusion must be demonstrated for the actual design rather than inferred from a job title.