Proving a truck safe enough to drive with nobody in it

There is a moment in every autonomous driving programme that everything else is arranged around: the moment the safety driver gets out.

Up to that point, a human being is sitting behind the wheel absorbing risk. They are the answer to a very large number of awkward questions, and their presence lowers the bar for everything else. Once they are gone, every one of those questions comes back, and this time the answer has to be written down.

Leading the verification and validation effort for driverless, unsupervised public-road operation is the work I am doing now, and it is among the most success-critical parts of the programme. Not because it is the hardest engineering — the perception and planning teams would have something to say about that — but because it is the part that decides whether any of the rest of it is allowed to leave the test track.

The safety case is a claim; V&V is the evidence

A safety case is an argument. It says: this system is acceptably safe for this operational design domain, and here is why. The argument is only as good as the evidence underneath it, and evidence at this scale is not something you collect. It is something you manufacture, continuously, with machinery built for the purpose.

That is what the V&V strategy has to deliver. Not a test plan — pipelines. Systems engineering defines what has to be shown. Software builds the execution. Data engineering makes the volume tractable and the results queryable. My job is to hold the shape of the whole thing: to know which claim each pipeline serves, and to notice when we are producing a great deal of evidence for something nobody is asking about.

Coordinating across those disciplines is most of the role. The technical decisions are rarely made in isolation, and the failure mode is not a wrong decision — it is three teams making locally reasonable decisions that do not compose into an argument.

Two standards, two different anxieties

The safety work splits along a line that took me a while to appreciate properly.

ISO 26262 — functional safety — asks what happens when something breaks. I am responsible for the verification and validation of the Functional Safety Concept: the argument that our safety mechanisms detect and handle the failures we claim they do.

ISO 21448 — SOTIF, the safety of the intended functionality — asks the harder question. Nothing broke. Every component performed exactly as designed. And the outcome was still unsafe, because the world presented a situation the design did not anticipate. There is no fault to find, which means there is no fault to fix, which means the only defence is knowing the shape of your own ignorance.

The V&V strategy is a core pillar of the higher-level safety case that sits above both, and SOTIF is the reason that strategy cannot simply be “write more tests”. You cannot test your way out of a space you have not characterised. Both of my conference talks are, in different words, about that problem.

Five spaces, not a sequence

People expect a programme like this to run on stage gates — a system requirements review, a preliminary design review, a critical design review, each one a milestone you either pass or do not. We do not have them, and I would not want them.

Stage gates assume the requirements hold still long enough for a gate to mean something. Ours do not. A stakeholder changes what they need; a truck comes back from a week of public road operation having seen something nobody had thought of. Either event invalidates work that a gate had already blessed.

What replaces them is not a pipeline. It is easy to describe this as a chain of artefacts updated in order, and I have caught myself doing it, but the ordering is the least interesting part. What actually holds the thing together is a separation of concerns, and ISO/IEC/IEEE 15288 gives it its shape: five spaces.

Problem space describes the world and what is expected in it, and says nothing at all about our system: the operational design domain, the topographies, the functional scenarios, and the stakeholder requirements — which for us arrive from two directions at once, legislation and the customer.

Solution space is the specification that solves that problem. This is where our own decomposition lives: decision logics, atomic features and their requirements, functions and function requirements. That is how a problem stated in terms of driving becomes a specification at descending levels of abstraction — behaviour, then manoeuvre, then the individual functions of perception, localization, planning and control.

Implementation space is the hardware and the software, built to that specification.

Then the two on the right, and the discipline is in what each is forbidden to know.

Verification space is ignorant of the problem. It asks one question — does the system as delivered match the specification? — and answers it in controlled conditions.

Validation space is ignorant of the solution. It does not care what we specified or how we built it. It asks whether the problem has actually been solved and every stakeholder expectation met.

That mutual ignorance is the whole point, and it is the thing a stage gate cannot give you. A verification that knows the problem starts quietly excusing the specification. A validation that knows the solution starts grading the system against what it happens to do rather than against what was needed.

Why the metrics live on the right-hand side

Metrics belong to validation space, and they are statistical because they have no choice.

A verification result is a fact about specific conditions: under this scenario, with these parameters, the system did what the specification said. A stakeholder requirement is not a claim about specific conditions. It is a claim about always — and “always”, in a world as large as public roads, is not something a test can demonstrate. You establish it by accumulating enough operational evidence to say something defensible about a distribution you can never enumerate.

That is also why the baseline matters more than the gate. Granular traceability between the atomic items of each artefact is held as relationships in PALM, the lifecycle platform we built to replace Jama, and consistency across them is checked by AI agents, because at this scale nobody notices by reading that a scenario moved and three test cases downstream no longer follow from it. The baseline is what a gate was supposed to give you — a known, frozen, referenceable state — except it is produced on demand by a change rather than on a date by a calendar.

I have some sympathy for the stage-gate model. It is legible, and it forces a conversation to happen on a date. But it buys that legibility by pretending the world holds still, and in autonomy the world is the thing you are trying to characterise.

Who supplies whom

We supply software to our customers, which makes the internal structure less obvious than it sounds. From the systems team’s point of view the supplier is the software and data teams: they produce the pipelines, the tooling and the data products that the V&V effort consumes.

Much of my week is that negotiation — establishing what V&V needs, agreeing what will be delivered and when, and tracking it against a release that has a date. It is supplier management with the contract replaced by a shared employer, which removes the leverage and leaves only the part that was always doing the work: being specific about what you need and why, early enough that it can be planned rather than escalated.

One scenario, four environments

Verification is where the strategy turns into environments, and choosing them is the part of the job I find most interesting.

They are not a ladder where higher means better. Each integrates something different. Software-in-the-loop tests and integrates individual software components — cheap and endlessly repeatable, which is where a scenario runs ten thousand times with its parameters perturbed. Hardware-in-the-loop integrates the software with the hardware it will run on, and so with the whole class of problems that exist only because a signal arrived four milliseconds late. Closed course and public road integrate and test the system as a whole: real physics, real sensors, and on the road a world you did not author.

What ties them together is the scenario. The same scenario that exercises the planner as a single software component in SiL exercises the entire vehicle on a closed course. That reuse is why scenario-driven testing was worth building instead of a set of per-environment test suites — the environment changes what is integrated, not what is being asked.

Each environment is designed around what it is meant to catch. I think of the targets as three distinct things, because they fail differently:

• a fault — something is wrong inside the system,
• a failure — something stopped doing what it was specified to do,
• a performance insufficiency — everything worked to specification and the specification was not enough.

That third one is SOTIF’s territory, and it is the reason you cannot simply run more tests at the cheapest level. A performance insufficiency does not show up as a red result. It shows up as a green result on a test that was never asking the right question — which is why it is answered on the validation side, statistically, rather than by adding verification runs.

So the design work is matching method to level to safety-relevant aspect: deciding what each environment is genuinely capable of demonstrating, and refusing to let a cheap environment carry an argument it cannot support. My formal functional safety training — a week covering FMEA and the wider family of inductive and deductive analysis methods — is what gave me the vocabulary for the other half of that. Reasoning bottom-up from a component failure to its effect, and top-down from a hazard to the things that could cause it, are two different habits of mind, and a test strategy needs both. One tells you what to look for. The other tells you when you have looked enough.

The company’s process auditor

Alongside the programme work I became the internal process auditor for the organisation, and completed two weeks of training as a provisional ASPICE assessor. When a business unit inside the company wants to reach process compliance, I am the first person they come to.

I did not expect to enjoy this as much as I do. Assessing somebody else’s process is the fastest way I have found to see your own clearly — you spend a week asking a team to show you the traceability from a requirement to its verification, and you come back to your own programme with different eyes.

The part that is not technical

A share of every week goes somewhere other than engineering: mentoring — programme managers, junior systems engineers, senior ones — and advising directors and VPs on technical decisions. A handful of times over the years that has meant presenting to our CTO, which is a different exercise again, and rare enough that I still remember each one.

That is not an interruption to the Staff role. It is a large part of what the role is.

Those audiences want opposite things. An engineer needs the reasoning, because they have to extend it. An executive needs the consequence and the confidence attached to it, because they have to bet on it. Learning to give each of them the version they can act on, without diluting it into something true but useless, is the hardest part of the job — harder than the standards.