Record who controlled an automated trial vehicle and what happened

The question an investigator will ask

A safety driver says the vehicle braked unexpectedly before a crossing. An engineer says the automated system had already handed control back. Video appears to show a pedestrian entering the carriageway, but the camera clock differs from the vehicle log. The investigation cannot proceed from impressions alone. It needs a reliable account of the vehicle configuration, operating mode, commands, driver action, environment and timing. The trial organisation should decide how to produce that account before it puts the vehicle on a public road.

The Department for Transport's automated-vehicle trialling code, updated in June 2026, says trial vehicles should be fitted with devices able to capture relevant sensor, control and movement data. At minimum, the records should make it possible to determine who or what controlled the vehicle. It recommends further data fields, secure storage, full preservation after an incident and cooperation with relevant authorities. Its suggested recording frequencies and time windows are guidance to be assessed for the actual trial, not universal statutory settings copied into every vehicle.

This guide owns the evidence design and reconstruction of a mode or driver intervention. The safety-driver article owns competence and practice. The incident-response guide owns people, authority contact, trial hold and restart. The safety-case guide owns the argument that these controls make the trial acceptable. The no-safety-driver pilot may have different recording or reporting conditions in an order or permit. The supervised-trial code is the primary source here.

Define the event before choosing a recorder

List the questions the trial needs to answer. When was automation engaged? Was a takeover requested? Did the driver steer or brake before or after the request? Did a remote person send advice or a command? Which software build and map were active? What did the vehicle detect and how did it respond? Where was it, and were weather or roadworks outside the operating domain? These questions determine which signals and supporting records must be linked. Buying a camera first and deciding later what it proves can leave important gaps.

An intervention is not automatically a failure. A driver may take control because the run reached a planned end point, because a roadworker redirected traffic or because the system behaved unexpectedly. The record should distinguish planned handovers, cautionary interventions and safety-critical events. Define each category so teams use it consistently, but preserve the raw facts even when the category later changes. A label such as “driver error” or “system fault” should be a conclusion after review, not the only data kept at the moment of the event.

The recording design should include ordinary runs as well as incidents. Baseline data can show whether a stop or takeover was unusual for that route. It also helps the team identify repeated interventions at one junction or under one lighting condition. Retention and privacy rules may differ between routine data and evidence placed on hold after an incident. The team should define those rules with a data-protection specialist rather than keep everything forever or delete it before investigation is possible.

Record control mode and configuration together

The code lists the automated system, software and hardware versions, mode, speed, steering and braking commands, location, connectivity and driver interventions among recommended data. A mode label without an accurate timestamp or configuration is not enough. If the system was in “automated” mode, what feature and version did that mean? If manual control resumed, which driver input caused the transition and when did it take effect? The engineer must understand the vehicle's control logic well enough to interpret the record rather than assume every logged state means what its name suggests.

Synchronise clocks across the vehicle, cameras, remote support and incident log. Record how each device obtains time and what happens when the clock drifts or loses a connection. A few seconds can reverse the apparent order of a warning and a driver response. Where perfect synchronisation is impossible, preserve enough information to estimate uncertainty. Do not silently edit raw timestamps to make a timeline look neat. A reconstruction should show both original values and any documented adjustment.

Keep the configuration record alongside the event. It should identify vehicle, sensors, control hardware, automated-driving software, map version, calibration and any relevant maintenance or defect status. A later software patch can change how an old log is interpreted. The investigator needs to know which build was actually running, not the current build displayed on a project dashboard. Link the event to the applicable operating-domain and safety-case versions too.

Capture the driver's part without guessing intent

Record steering, braking or other control inputs and the automated system's response where technically feasible. The code specifically mentions interventions made by the safety driver, including their time. A factual driver statement can explain what the person saw, heard and did, but it should not replace the control data. Conversely, vehicle data may show a brake input without explaining a pedestrian gesture or a confusing warning. Use both sources and make uncertainty visible.

Driver monitoring raises separate privacy and human-factors questions. A camera aimed at the driver may help assess attention or handover, but it records a person continuously and may capture passengers. The organisation should identify its purpose, legal basis, proportionality, notice, access and retention before deployment. The Information Commissioner's Office guidance on surveillance in vehicles addresses risks for drivers and passengers. It does not grant a blanket right to record everyone because a project calls itself a trial.

Plan for useful sensor and movement evidence

The DfT code recommends a set of movement and system data that can include acceleration, speed, steering, braking, lights, location, connectivity and sensor information about nearby objects. It also discusses video and audio as possible additions, not replacements for core sensor and control records. The right design depends on the vehicle and hazards. A low-speed shuttle and a motorway trial may need different evidence to reconstruct a critical event. A technical specialist should specify sampling, triggers and data integrity rather than copy a generic rate into a procurement brief.

The code suggests at least 10 Hz for certain routine trial data and, for an event recorder, a suggested minimum period around an incident with a higher recommended frequency. These are recommendations in the code. They should not be described as universal legal thresholds. The team should show why its actual system can capture the sequence needed for its safety case and investigations. If the recorder loses data when power fails, that failure mode belongs in the safety case and contingency plan.

Test the retrieval path, not merely the hardware specification. Can a responsible person extract the relevant period from a real trial vehicle after a run? Are sensor and control files intelligible to someone outside the developer team? Can the organisation provide a usable explanation to police or another relevant investigator without requiring them to install proprietary engineering tools? The code strongly recommends plans for prompt investigator access that maintain forensic integrity and says trial organisations should support interpretation of data that is not immediately intelligible.

Rehearse a failed upload as well. Some vehicles store a local copy and send a second copy over a network. If the connection fails at the same moment as an intervention, the team must know whether the local recorder continued, who can secure it and whether the system might overwrite it on the next trip. Record the tested recovery procedure and its limits. A cloud dashboard showing “no event” can mean the upload failed, not that the vehicle had no event. This distinction matters before anyone decides that investigation data is complete.

Preserve originals and make a reproducible timeline

After a serious event, stop ordinary deletion or overwrite for the affected data. Identify the original source, acquisition method, person, date, file hash or other integrity control where appropriate, and storage location. Create working copies for analysis. Record each transformation used to align clocks, filter signals or produce a visualisation. A chart is useful only if another competent reviewer can trace it back to the unaltered source and reproduce its meaning.

The event timeline should separate observed data from inference. “Brake request at 14:03:12.400” is different from “the system braked because it classified a cyclist”. The second statement requires evidence about classification and control logic. A driver statement that an alert sounded should be placed beside any system log of that alert. If the sources disagree, preserve the disagreement and investigate it. Do not delete inconvenient records or force a single narrative before the technical review is complete.

The code expects cooperation with relevant authorities. An access plan should name the person who can preserve and provide data, the technical expert who can explain it and the legal or privacy owner who checks the request. A responder may need immediate vehicle safety information while an investigator later needs full raw logs. Those are different information tasks. A single unrestricted file share is unlikely to be appropriate for both.

Make privacy part of the recording design

Road-facing sensors may capture faces, number plates, homes and pedestrians who never chose to participate. In-cabin systems may capture passengers and employees. Location data can reveal journeys and behaviour. UK data-protection law applies when information identifies people or can do so in context. The DfT code points to fair, lawful and secure processing and says a privacy assessment is a useful planning tool. The ICO's surveillance guidance gives more detail on proportionality, transparency and rights. A specialist should decide whether a data protection impact assessment is legally required for the actual high-risk processing.

Minimise data where this is compatible with safety and investigation needs. Ask whether continuous audio is necessary, whether a narrower camera view can support the purpose, and whether identifiers can be restricted in routine analysis. Define who may access raw footage, engineering logs and reports. A driver-training reviewer may not need the same data as a collision investigator. A public safety report should not expose passers-by. Privacy protection does not mean destroying evidence that must be preserved after an incident, but preservation should have a documented purpose and access rule.

Retention is not a single number for all records. Routine development data, a reportable incident file, an insurer dispute and a subject-access request can create different needs. Document the lawful basis, schedule, hold process and deletion method with legal and privacy advice. The code does not impose a blanket 15-month minimum on every supervised trial log. Avoid importing a pilot-guidance recommendation into a different route or treating unlimited storage as a safety measure.

Prepare for an access request and disclosure

Someone recorded by a trial vehicle may ask about their data. An investigator or insurer may request relevant material. The organisation should know which system holds it, whether a third-party supplier is a processor or independent controller, and how it can search without disclosing unrelated people. Record the decision and any redaction. Security-sensitive vehicle information may need careful handling, but that does not excuse an organisation from its lawful duties. The exact response belongs with privacy and legal specialists.

Contracts should make these duties workable. A camera supplier may store footage in a cloud account that the trial organiser cannot export quickly. A vehicle developer may hold raw logs while an operator promises investigators prompt access. Resolve such handoffs before an incident. A contract saying “supplier owns the data” is not a substitute for deciding controller roles, access rights, preservation and the ability to explain the information.

Turn interventions into learning, not just counts

An intervention log can help identify repeated domain exits, confusing takeover alerts or a driver-training gap. Review the context and severity, not merely the number per kilometre. A high intervention count may reflect deliberate cautious testing, while a low count can hide missed hazards. The reviewer should compare route, traffic, weather, system version and driver observations. Link each finding to a decision to continue, narrow the domain, retest or stop.

Create a feedback path from event analysis to the safety case and operating-domain record. If the system repeatedly hands back control near temporary traffic lights, the organisation may exclude that condition until testing and driver procedures improve. If clock drift prevents reconstruction, the data system needs repair before the next run. If a driver misunderstands an alert, the interface or training may need change. The evidence trail should show what changed and how the team verified the response.

The incident-response guide should own the immediate safety and reporting decisions. This page owns the technical and privacy record needed to understand what happened afterward. A trial organisation should avoid having two conflicting “master incident records”. It can use a single event identifier that links the operations log, driver statement, vehicle data and review decision while keeping access controlled according to content.

A record design that can be tested

This table is an internal planning aid, not a DfT form or technical specification. The vehicle data architecture, sampling and privacy controls require competent specialist design. Test the full process with a simulated intervention before the first public run. If the team cannot produce a coherent timeline from a routine closed-track event, a real road incident will be harder.

Where Complys may fit

Complys could be evaluated as a place to index the event, assign review actions and retain controlled documents if its current product demonstrates these functions. The public AV workspace preview is noindex and does not prove a released data-recording module. This page does not claim that Complys captures sensor streams, synchronises vehicle clocks, preserves forensic images, determines legal reportability or processes subject-access requests. A product owner should verify any specific feature promise before publication.

In a demonstration, give the vendor a vehicle event identifier, an original log held in an engineering system, a driver statement and a safety-case change. Ask how the relationship is recorded, how an access-restricted file is referenced, how the previous decision is preserved and how a reviewer can export an evidence index. If Complys is only the workflow layer, say so clearly and keep the primary vehicle data in the system designed for it. The AV software overview gives a broader buying test. The AV checker is a nonbinding regime pointer and does not analyse trial data.

The practical next step is to run a reconstruction exercise using one actual test intervention. Ask whether an independent engineer can determine the mode, configuration, driver action and road context without relying on the memory of the original development team. Then review the privacy and access plan before using the same design on public roads.