Continuous V&V for software-defined vehicles
Software changes weekly, validation evidence is shaped like a monthly document. This closes the gap by putting verification state on the objects themselves.
The problem
In a software-defined vehicle the software changes every week, but validation evidence is document-shaped and produced on a monthly rhythm. The two never line up.
The practical result is that nobody can answer what the current build is verified against without a person spending days correlating requirement versions, test plans and run logs.
- Requirements in one system, tests in another, runs in a third
- A requirement change does not invalidate anything automatically
- MiL, SiL, HiL and fleet results land in reports rather than on records
- Release readiness is a slide, produced by hand, stale on arrival
How it works here
The verification plan stays a sheet and the results stay a sheet. The change is what the rows are, not where they live.
A verification points at what it verifies and at the run that produced its evidence. Changing the source marks the downstream verification stale instead of leaving it silently green.
The automotive pack knows what a verification method is, what coverage means and which gate a result has to reach.
Walkthrough
Every capture below is the running product, in the order the work happens.
- Step 1
Start from the thing being built
The item definition, its operating modes and its assumptions are objects, so every requirement and test downstream can reference them precisely rather than restating them.
1Phrases inside the document carry identity, so a test can cite a specific assumption. - Step 2
The verification plan carries the link, not a reference number
Each verification row names its method and its acceptance criteria and points at the hazard or requirement it discharges. The link is the relationship, not a string someone typed.
224 verifications, 3 blocked, 1 failed — read from the graph, not tracked in a side sheet. - Step 3
Results land on the record that asked for them
A bench, HiL or vehicle run attaches its result to the verification it was run for, with the revision it was run against. Evidence has provenance by construction.
3A result bound to an old revision reads as stale, not as a pass. - Step 4
The interface register keeps the allocation honest
Signals, rates and owning elements are objects, so a change to an element surfaces on every interface and every test that depended on that interface.
4“1 rate conflict” and “2 unclassified” are continuous checks, not review findings. - Step 5
Release readiness is a query, not a slide
Gates read the state of the verification chain directly, so readiness moves when the work moves and a failed re-run reopens the gate.
5The critical path is named by the verification that is holding it up.
What changes
- Verification status correlated by hand each cycle
- Requirement changes silently leave old evidence green
- Readiness reported monthly and already out of date
- Fleet and bench evidence live outside the record
- Changing a requirement marks downstream verification stale
- Every result is bound to the revision it was run against
- Readiness is current at any moment
- One chain from requirement to run to release decision
The captures show a braking programme; the same chain applies to any function where software cadence outruns document cadence.