Articles Hello, Auto!
The real constraint on the software-defined vehicle isn't software
Record electronics recalls, the sprint to zonal architecture and the copper-to-aluminium wiring shift share one root cause: the timing of the in-vehicle network underneath.
15 July 2026
Everyone's been telling the software-defined vehicle story as a software story: over-the-air updates, in-cabin AI, subscription features, faster development cycles. Three numbers from the last few months tell a different story.
A record recall quarter, driven by electronics.
In the first quarter of 2026, automakers recalled 12.1 million vehicles in the US alone. It was the highest quarterly total ever recorded, and the cause wasn't brakes or airbags. It was electronics and software, almost across the board. That follows a 2025 in which software and electronics defects had already become the single most common recall category, covering more than eight million vehicles across 119 separate campaigns.
The industry-wide sprint to zonal architecture.
At the same time, Volkswagen is finishing winter validation testing on its new Scalable Systems Platform, the architecture meant to underpin up to 30 million future vehicles. The headline numbers: over 50% fewer electronic control units, and roughly 40% less wiring harness, compared with the domain-based architecture it replaces.
The copper-to-aluminium wiring shift.
And separately, copper prices pushed toward $15,000 a tonne in early 2026, roughly four times the cost of aluminium. Automakers from Tesla to Ferrari have started swapping copper wiring for aluminium wherever they can, partly for cost, partly because a lighter harness means real range and handling gains in an EV.
Three stories. One root cause.
The CAN story.
It helps to remember why the current approach ever made sense. The communication buses running through most cars today, CAN chief among them, were designed in the 1980s and 90s for a very different vehicle: a handful of electronic functions, mostly independent of one another, none of them making split-second decisions on behalf of the driver. Asynchronous, "send when you have something to say" communication was perfectly adequate for that car. It is proving far less adequate for a car trying to run dozens of interdependent software functions, several of them safety-critical, off the same electromechanical skeleton.
Today.
A modern vehicle can carry more than a hundred separate control units, each historically bolted onto whichever mechanical assembly it controls, wired back to the rest of the car over buses built for occasional signalling, not for real-time, safety-critical coordination. Every new feature (another camera, another sensor, another driver-assist function) adds another node, another few metres of copper, another point where timing can drift and software can fail in ways that used to be purely mechanical problems.
Zonal architecture is the industry's answer on the hardware side: group components by physical location rather than by function, run fewer and more powerful zone controllers, and cut both the wiring and the ECU count in one move. The aluminium swap is the industry's answer on the materials side: take the weight and cost savings wherever copper's extra conductivity isn't strictly needed. Both are real, useful changes. Neither one, by itself, addresses the thing that actually drives a lot of these software recalls: the timing problem underneath.
Time is of the essence...
When electromechanical systems talk to each other asynchronously, each on its own clock, batching and forwarding data whenever it's ready, the information arriving at any given moment describes slightly different instants in time. At low speed, that barely matters. Above roughly 60 to 80 km/h, and especially with more automated driving functions layered on top, that timing drift becomes the difference between a command executing cleanly and a control loop turning unstable. It's a principle control engineers have understood for decades. It's only become an acute, headline-generating problem now that cars are trying to run dozens of software-defined functions off the same electromechanical skeleton that used to run a handful.
No coordination.
You can see the shape of the problem in the recalls themselves. Toyota, Lexus and Subaru pulled back nearly 21,000 electric vehicles this year after finding that software inside the high-voltage battery control unit could shut the electric drive down while the car was moving. Honda recalled close to 295,000 vehicles for a fuel-injection ECU fault that could cause engine stall or power loss. Neither defect was a wiring fault in the narrow sense. Both were coordination failures between control units that were never designed to reason about the car as a single, synchronised system.
That coordination gap is also proving expensive to fix after the fact. Industry data for 2025 shows 232 software-related recall campaigns, affecting close to 18 million vehicles, with a rework rate of 13.4%, meaning more than one in eight fixes had to be redone. That is a validation and testing problem as much as an engineering one, and it sits uncomfortably alongside functional-safety standards, such as ISO 26262, that were themselves written for a car with far fewer interacting software functions than today's.
More Compute!
Meanwhile, the compute stack sitting on top of all this wiring keeps getting heavier. NVIDIA and Qualcomm are both racing to put more powerful, more centralised compute platforms into production vehicles, from Qualcomm's Snapdragon Ride and Cockpit lines to NVIDIA's Orin and Thor chips, with central-compute hardware revenue for software-defined vehicles projected to reach around $755 billion by 2029. All of that additional intelligence still has to talk to the same motors, sensors and actuators, over whatever architecture happens to be wired into the car beneath it. A faster brain does not fix a slow, uncertain nervous system.
That's worth watching closely over the next twelve to eighteen months. Volkswagen's SSP reference vehicles are in extreme-climate testing this quarter, with the first production model, the ID.EVERY1, due in 2027 on Qualcomm's compute platforms. If recall rates for electronics and software genuinely fall once zonal, more synchronised architectures reach the road at scale, that's strong evidence the industry has correctly diagnosed its own problem. If they don't fall, the more interesting, and more expensive, conversation will be about what the industry got wrong about where the real bottleneck sits...
This piece first appeared in ASG's Hello, Auto! newsletter on LinkedIn.