An integration error caught at architecture review costs almost nothing. The same error caught in the field, as a warranty claim, costs roughly a thousand times more. At a European automotive group's flagship electric platform, SPREAD's job is to shift errors leftward on that curve. The shift is worth €20M+ a year.
The instrument is an engineering ontology, live since 2024: one integrated graph over ARXML (AUTOSAR XML), ReqIF (Requirements Interchange Format), BoMs (bills of materials), and CAD (computer-aided design files). Three product applications sit on the graph: Product Explorer for the architect, Error Inspector for the quality engineer, Action Tower for the program manager. In SPREAD's vocabulary the graph is a Product Twin.
The cost curve in software-defined vehicle programs
There is a cost curve that runs through every software-defined vehicle (SDV) program. An error caught at architecture review costs almost nothing. The same error caught at HiL (hardware-in-the-loop) test costs ten times more. Caught after a physical build, a hundred times. Caught in the field as a warranty claim, a thousand times.
The job of an engineering ontology at a program of this scale is one thing: shift errors leftward on this curve.
What the cost curve actually looks like
Each step right on the curve is roughly an order of magnitude. The €20M+ in annual savings on the flagship electric platform is what happens when a program of this scale shifts a measurable share of its integration errors from the right side of the curve back to the left.
The framing that put this in motion
The framing question came from the program's Delivery Manager:
"Can AI enable the group to master SDV complexity across all brands, built on one E/E and SW architecture?"Delivery Manager, flagship electric platform
The question doesn't ask whether AI can build a better architecture. It asks whether AI can make the existing electrical/electronic (E/E) architecture answerable to the engineering organization's questions, at the cadence those questions arrive.
What changes for the engineer
An architect puts a software change on the table for the powertrain variant. Before it ships, one question has to be answered:
"If I change signal X, what breaks across the platform family?"
The blast radius is real: multiple vehicle variants, plus the shared platform output to sister brands. Tens of millions of signal connections. Hundreds of ECUs (electronic control units).
- Open ARXML in the architecture tool
- Query ReqIF in the requirements tool
- Walk the BoM exported to Excel
- Cross-reference variants by hand
- Pin down the cross-domain colleague who knows
- Reconcile and document, for each affected brand
- Issue the graph traversal
- Review the surfaced dependency set
- Confirm or escalate the residual
A platform program produces thousands of these queries a year. Compressing each from days to minutes restructures who can be in the room when a change is debated, and how late in development a regression is allowed to surface. 10× engineer leverage on architecture work: one architect now covers the territory that previously required ten, because the architect is no longer reconciling tool exports; they're querying a graph and interpreting the answers.
Three personas, one Product Twin
The architect's question is one vantage. Two more sit on the same Product Twin.
The questions don't reduce to each other. The graph that answers them does. Ingestion of ARXML, ReqIF, BoMs, and CAD is paid once; each new product surface pulls value out of integration work already done.
The footprint
R&D at the group isn't a single deployment. Four group entities ingest the same Product Twin: Group HQ, the passenger-vehicle entity, the software unit, and Aftersales. Five sub-workstreams run off the same ingestion: the flagship electric platform plus four adjacent platforms across R&D and aftersales. Each new sub-workstream is cheaper to stand up than the last because the engineering ontology doesn't replicate.
The customer procured all three product surfaces on the flagship platform. The ontology compounds across them; that is what the multi-product footprint reports.
Program shape
| Program | European automotive group R&D, flagship electric platform |
|---|---|
| Live since | 2024 |
| Vehicles in scope | Multiple variants on one E/E and software architecture |
| Graph inputs | ARXML · ReqIF · BoM · CAD |
| Graph scale | Tens of millions of signals · hundreds of ECUs |
| Products on the same Product Twin | Product Explorer · Error Inspector · Action Tower |
| Annual savings (integration risk detection) | €20M+ |
| Engineer leverage on architecture | 10× |
| Change-impact tracing time | Days → Minutes |
| Group entities on the same Twin | 4 (Group HQ · passenger-vehicle entity · software unit · Aftersales) |
| Sub-workstreams on the same Twin | 5 platforms · R&D + aftersales |