Replacing the requirements tool with one of our own
PALM, an in-house application lifecycle management platform built to fit Level 4 systems engineering — developed top-down from stakeholder requirements, shipped fortnightly, and compliant with the same standards as the systems it manages.
Every organisation that does serious systems engineering eventually has the same argument about its requirements management tool. Ours had it too, and this time the answer was to leave.
Jama Connect had served us well — I had built the technical compliance toolchain on it, and the scenario-driven testing structure for TRATON lived inside it. But the systems engineering task for a Level 4 autonomous driving system is a peculiar shape. The traceability graph is enormous, it spans requirements, architecture, scenarios, recorded executions and safety-case claims, and it is queried in ways that a general-purpose requirements tool is not built to make cheap.
We decided to build our own. I was asked to lead it, and the result is PALM — our internal application lifecycle management platform.
Systems engineering, applied to itself
There is an obvious joke about building a requirements tool without requirements, and I was determined not to be its punchline. So PALM is developed top-down, the same way I would develop any safety-relevant system.
It starts with user stories and high-level stakeholder requirements — and the interesting ones there are not features. They are the reliability, security and performance concerns, the properties that decide whether anyone can trust the tool with the evidence for a driverless vehicle. Design documents sit beneath those. Beneath those sit low-level requirements, decomposed from the higher-level artefacts and allocated deliberately:
- to each surface of the frontend,
- to each endpoint of the API,
- to each table of the database,
- to each aspect of the deployment infrastructure.
Allocation is the part people skip, and it is the part that does the work. A requirement that belongs to “the system” belongs to nobody. A requirement allocated to a specific endpoint has an owner, a verification method, and a place where its absence becomes visible. It is the same discipline as allocating a vehicle-level safety requirement down to a particular ECU, applied to software that happens to run in a data centre rather than in a truck.
Learning a second kind of system
The other reason I wanted this project is that it took me somewhere I had never been.
I had spent years inside autonomous driving systems — sensors, control, scenarios, safety cases. PALM is an IT system, and IT systems fail in their own dialect, and building it has meant learning that dialect properly: PostgreSQL, which holds the operational data, and the cost of a schema decision made early; APIs and what a contract means when the consumer is a browser rather than another ECU; frontend state; FastAPI and Next.js; Celery workers with Redis as both message broker and cache, and the specific misery of a task queue that silently retries.
Then the parts around the application, which turned out to interest me most. Infrastructure as code with Terraform and Ansible, and virtual machines that exist because a file says they should. Delivery through GitHub and Jenkins. And observability as a first-class concern — Prometheus for metrics, Loki for logs, Grafana to look at both, Alertmanager and PagerDuty to decide when a human should be woken up.
That last one landed hardest, because it is the same question I ask about a truck. What is this system’s evidence that it is currently healthy, and who finds out when it is not? Monitoring is runtime verification. I had simply never seen it wearing these clothes.
Speed that does not cost rigour
The development machinery is built around agentic workflows, and the throughput is the most striking thing I have seen in my career. We ship a release every second week — the cadence I built for TRATON releases, now applied to the tool that manages them.
The claim I actually care about is narrower than “fast”. Plenty of things are fast if you are willing to stop being careful. The workflows execute the entire flow — requirements through design, implementation, verification and release — at a pace that would have been unimaginable to me two years ago, while remaining compliant with the automotive standards that apply to safety-critical development. Not a lighter process for an internal tool. The same one.
PALM is an enterprise application compliant with ISO 9001 and ISO 27001 — and, the one that actually bites, with ISO 26262 Part 8, which sets out how a software tool used in safety-critical development has to be qualified before anyone is entitled to rely on it.
That last one changes what kind of project this is. Quality management and information security are properties of how you build and run a thing. Tool qualification is a claim about what happens when the tool is wrong: how far a defect in it could reach into the safety of the product it helps build, and how likely you are to catch that defect before it propagates. Answer those badly and it is not that the argument weakens — the evidence the tool produced stops counting.
Which is why the compliance was a requirement from day one rather than something retrofitted before an audit. A tool that holds the requirements, the verification evidence and the safety-case traceability for a driverless vehicle programme is itself part of the argument that the programme is under control. If its own quality management, information security and fitness for purpose cannot be demonstrated, it quietly undermines everything stored in it.
Three years apart, the same lesson as the compliance work I started with: build the machinery, hold it to the standard you hold the product to, and the deliverables take care of themselves.