Releasing an autonomous truck onto public roads
Bringing up scenario-driven testing for Scania in Sweden, from a blank sheet to a supervised truck on public roads and a fortnightly release — and then watching it become the TRATON programme's global process.
The TRATON programme ships PlusAI’s SuperDrive Level 4 autonomous driver to three of the group’s brands: Scania in Sweden, MAN in Germany, and International in the United States. One driver, three customers, three countries, three sets of expectations about what “released” means.
My part was Scania, in Sweden. I was asked to bring up the test and release activities there. The American side, for International, was run by a colleague of mine out of Santa Clara — this was never a one-person programme, and the rest of this page is about one site of it.
That site was Södertälje, and getting to it meant flying Hannover to Stockholm more than sixty times, which is how I acquired a Lufthansa frequent traveller card I had never especially wanted. It is worth saying, because it is the unglamorous half of what owning a site actually means. None of what follows was designed remotely and handed over. It was built in the room, beside the people who had to run it, and revised every time a fortnight of watching it showed something that did not work.
The goal at that site was specific and unforgiving: get a version of the system released for supervised testing on public roads. Not a demo. A release, to a customer, that put a truck on a Swedish motorway with a safety driver behind the wheel and a defined argument for why that was acceptable.
As with technical compliance a year earlier, there was very little to build on — some testing happened, but not in a form that could be pointed at a release and defended.
Scenarios as the unit of work
What I implemented was a structured, scenario-driven testing approach, built inside Jama Connect so that it lived in the same place as the requirements rather than beside them.
The shape of it is easy to state and was not easy to build. Each release has a scope. That scope selects requirements. Those requirements generate test cases, systematically rather than by someone deciding what seemed worth testing. Those test cases are executed as scenarios on a closed course. The recordings of those executions trace back to the cases that called for them, and the whole chain surfaces in the release documentation.
The value is in the chain being unbroken. If a customer asks why they should accept this release, the answer is not a test report — it is a path from the scope they agreed to, through the requirements it implied, to the recorded evidence that each one was exercised.
Cadence as an engineering requirement
The part I am most pleased with is not the structure but the speed. We ended up able to release to the customer every second week.
That number is a design constraint, not an accident. A release process that takes six weeks is not a slower version of one that takes two — it is a different process, because it forces work to batch up, it makes regressions expensive to locate, and it means the customer sees the system rarely enough that every release becomes an event. Getting to a fortnight meant treating tooling and automation as the actual deliverable and the test cases as the output of a machine rather than the work of a person.
The part I did not expect
A process built for one site is a local convenience. What happened instead is that the workflows we established at Scania were accepted across the TRATON programme as the right way to run the fortnightly release, and they are now being ported to the other test locations and set up as the global process.
That is a different kind of result from the one I was asked for, and I have thought about why it happened. I do not think it was because the process was clever. I think it was because it was portable: it was built out of artefacts and traceability rather than out of the habits of the people at one test site, so there was something to hand over. A process that only works because everyone in the room already knows how things are done here cannot travel, however well it performs at home.
It is also the most useful thing I can say about working across sites. Scania, MAN and International do not want the same things, and a process that survives being moved between them has to be specific about what it guarantees and silent about how each site gets there.
What it led to
This delivery is what moved me to Staff Systems Engineer, and it is the direct predecessor of what I do now. Supervised public-road operation has a safety driver in it — a human whose presence absorbs an enormous amount of residual risk and, in doing so, quietly lowers the evidentiary bar.
Taking that person out is the subject of the next chapter, and it is a much harder problem than it looks from here.