Delete the word “vehicle” and this report is about your product too

The Advanced Propulsion Centre UK published its insight report on Software Defined Vehicle value chains in July. It is a clear, unhyped document, and I would recommend it to anyone building complex products with software in them. It maps where value moves as vehicles shift from hardware-defined to software-defined: central compute and zonal architectures, the on-board and off-board software stack, cloud and data, and the integration loop that ties it together.

I read it twice. The second time I did something else with it. I deleted the word “vehicle” everywhere it appeared and replaced it with “product”. Almost nothing broke.

That is my main take, and I will come back to it. First, four things in the report I think deserve more attention than they will get.

1. There are two kinds of readiness, and most organisations only measure one

The report makes a distinction that I think is the single most useful idea in it. Software readiness is not one question but two. Is the software product mature — requirements, design, integration and safety. And is the software factory mature — pipelines, automation, virtual validation, release governance, OTA packaging, fleet monitoring.

Almost everyone I meet can answer the first question. Very few can evidence the second one on demand.

My test is simple. If you change one line of code today, how many days until you can prove that change is safe, and who signs that proof? If the answer is a shrug, a spreadsheet or a name of a person rather than a process, you do not have a software-defined product. You have a software project with an update button on it.

The consequence is not theoretical. Delivery capability becomes a competitive property. Two companies with identical features and identical hardware will separate on how fast one of them can prove a change and ship it without breaking anything else.

2. The “messy middle” is not a phase, it is the operating environment

The report describes incumbents layering new architecture on top of proven legacy platforms rather than replacing it, and calls the resulting period a messy middle. That is a polite and accurate description of what everyone is actually doing.

I would go further. If your product lives for fifteen years in automotive, and thirty or more in defence, then coexistence between old and new is not a transitional inconvenience. It is the environment, for the whole life of the product, and it will still be there when the next architecture arrives.

Anyone who plans only for the clean end state, and treats the mess as something to survive on the way there, will spend the decade paying for it. The engineering effort, the risk and, frankly, the money all sit in the coexistence layer. That is where I would put my best people.

3. Diagnostics is not an application — it is the observability of a physical product

In the report’s architecture diagram, diagnostics sits in a box next to infotainment and ADAS. For a value chain map that is fair. In practice it undersells what happens next.

The whole SDV model depends on a feedback loop. Data comes off the fleet, becomes insight, becomes a validated change, goes back out. Diagnostics is the sensor on that loop. If the architecture goes service-oriented and centralised while diagnostics stays where it was, you have built a fast pipeline that ends in a narrow pipe. That is precisely why service-oriented diagnostics exists as a standard rather than as a nice idea.

So my slightly self-interested but I think defensible point: when you plan your software factory, plan the diagnostics layer at the same time, not two years later when the fleet is out there and you cannot see into it.

4. Value sits in attributable data, not just actionable data

The report says the commercial opportunity is in actionable intelligence rather than raw data, and notes that different vehicles run different software versions. Both are right. I would sharpen the conclusion.

Fleet data from units running different configurations is not one dataset. It is many datasets wearing the same name. If you cannot say which configuration produced a signal, you cannot use that signal as evidence. And evidence is what you actually deliver to a regulator, an auditor, a customer, or eventually a court.

This is also where AI in our sector either earns its place or quietly becomes a liability. Models are cheap now. Inputs you can prove are not. Every serious AI use case in a safety-relevant product is downstream of a boring question about configuration control and traceability.

Now the part the report does not cover: everything that is not a car

The APC wrote about vehicles because that is their mandate. But look at what the report actually describes. A physical product with an expected life measured in decades. Functions delivered in software. Features and fixes arriving after the product has shipped. Hardware and software decoupling. A feedback loop between the field and engineering. Regulation that demands you can prove your update process, not just your product.

That is a ship. It is a radar. It is an artillery system, a wind turbine, a grid substation, an industrial robot, a modular reactor, a hospital imaging system.

Five things hold across all of them.

The product outlives its release. There is always a next version in development. Which means the engineering organisation cannot be disbanded at delivery, and the supplier you choose has to be one that can still be there in year twelve.

Decoupling needs an owner. An abstraction layer between hardware and software is what makes reuse and updates possible. An abstraction layer that nobody owns is not architecture, it is a liability with a diagram.

The feedback loop is also your attack surface. The same channel that lets you improve the product lets someone else reach it. Security and safety are not a layer in the stack, they run through all of them — and that is not a slogan, it is an audit requirement.

Delivery capability is part of the product. See point 1. The factory is in scope.

Evidence is the deliverable. Traceability from requirement to test to release to what is running in the field. In a software-defined product, that chain is not documentation about the product. It is part of the product.

And four things change by domain, which is where people get burned by copying automotive practice wholesale.

Connectivity cannot be assumed. A car sits on a driveway with an LTE connection overnight. A vessel at sea, a system in the field or an isolated OT network does not. Update mechanisms have to work staged, signed, reversible and sometimes carried in by a human being with a case. Design for that from the start and the connected case is easy. Design for the connected case only and the disconnected one becomes a project.

Rollback is not always a partition. Activating a new software partition overnight with automatic rollback is elegant in a car. In a weapon system or a plant, rollback is a procedure with people, authority and a clock in it.

The regulatory frame arrives from a different direction. Automotive got there first through UNECE R155 and R156, which is why the report treats cybersecurity management and software update management as given. Everyone else gets the same logic through the EU Cyber Resilience Act. Vehicles are largely outside its scope precisely because UNECE already covers them. The rest of the connected product world is not. Reporting duties for actively exploited vulnerabilities apply from 11 September 2026, full conformity from December 2027. In other words, this report is a fairly accurate preview of the next five years for machinery, energy, industrial and defence-adjacent manufacturing.

Someone has to own the deploy button. For a consumer product that is the manufacturer, and nobody thinks about it. For defence and critical infrastructure it becomes a requirement in its own right. The operator has to be able to run the loop themselves, sometimes without the OEM, sometimes without a network, sometimes without a cloud that sits in another jurisdiction. That is not a technical preference. It is sovereignty, expressed as an architecture decision.

Five questions worth putting to your own leadership team

1. If we change one line of code, how many days until we can prove it is safe, and who signs?
2. Can we state which software configuration every unit in the field is running today, without asking the field?
3. If our main software supplier disappeared tomorrow, could we still build, sign and deploy?
4. How much of the data we store can be tied to a specific configuration, and how much is just noise we are paying to keep?
5. When a vulnerability is actively exploited in one of our products, can we detect it within 24 hours, which is what the reporting clock now assumes?

If four out of five make the room uncomfortable, that is useful information, and it is cheaper to find out now than during an audit.

Why I care about this particular report

At Diadrom we have spent twenty-five years on diagnostics and integration for products where a failure is not an inconvenience. Cars, then trucks, then defence systems. The pattern that keeps repeating is that each new wave of the industry rediscovers, under a new name, the problem diagnostics has always had. Prove what is out there. Prove what it did. Prove that the change you are about to make is safe.

The SDV transition has not created that problem. It has just made it impossible to postpone, and it has moved it from the workshop to the boardroom.

Or as we put it internally, in slightly fewer words: nothing works until everything works.

The APC report is worth your time. Read it, then read it again with the word “vehicle” removed, and see how much of it lands on your desk.

Source: Advanced Propulsion Centre UK, Software Defined Vehicle Value Chains, insight report, July 2026. A version of this article was first published on LinkedIn on 31 August 2026.