The term “software-defined vehicle” (SDV) always seemed like a bit of meaningless buzz to me. Cars have been defined by software for decades, I figured, with lots of little computers to control various electronic functions. Hell, Bendix came out with electronic fuel injection in 1956. (Admittedly, it didn’t work at the time, but the principle was there.)
But, there’s a huge difference between a vehicle with lots of electronic systems, each with its own software, and what the automotive industry considers an SDV. It turns out that “having software” is very different from being fully “software-defined,” the way things are trending.
Our colleagues at InsideEVs interviewed Rivian CEO RJ Scaringe for their podcast, and he explained the difference well:
‘The way most vehicles are defined today, their software and electronics layout, is you have hundreds of little, tiny computers—the industry term is ECUs, electronic control units—that have a little island of software that performs some domain-based function. So you’ll hear this called a ‘domain-based’ architecture. So you’ll have a seat controller, you’ll have a door window mechanism controller, you’ll have an HVAC controller, each of those being a separate computer.’
Rivian Zonal Archicecture
Photo by: Rivian
This all started with fuel injection. Automakers moved on from carburetors to electronic fuel injection systems controlled by a computer, which aided efficiency and power. Then car companies added more and more electronic systems in a kind of piecemeal way: computers for seat controllers, climate controls, safety systems, door window mechanisms, etc.
But they used to be isolated, Scaringe said, and did not talk to one another. “It just proliferated in a really organic, completely unplanned way, just a system of weeds,” he said. “Nothing architected as a system.”
On top of all that, Scaringe said, many of these electronic systems weren’t even made by the car companies, but rather separate supplier companies—and the software within them may have been created by another separate sub-contractor.
Lots of little computers, all working in parallel to each other. This is fine, up to a point.
If you were starting from scratch today, it’s not how you’d build a car. Scaringe said that, instead, you’d build a car with as few separate computers as possible. “We want very clear, centralized compute,” he said. “A clear [operating system] designed around modern techniques of networking.”
You’d want what Rivian is doing: a zonal architecture, he said.
“Depending on the size of the vehicle, maybe two computers in the car, one in the front, one in the back—If it’s bigger, like an R1, maybe there are two in the back, one in the front—that do all the decisioning across one common software platform running on a standard in-house built [operating system], and so we built that.”
There’s a downside to the traditional way of doing things, Scaringe said, where these ECUs are like little, isolated islands. They all communicate through a vehicle’s CAN bus architecture, but they are speaking separate languages. “To do something like an over-the-air update requires all this coordination amongst third parties, and you have all this unused capacity, because you have all these little computers, none of which is fully being utilized,” Scaringe explains.
This helps explain why some car companies have done OTA updates better than others, but arguably, none as extensively and cohesively as Tesla or Rivian. Think about it: your car may get updates to its navigation system, but can it get a software update that adds a bunch of horsepower? Or more advanced self-driving features? Or a wholly new infotainment system? That takes a lot more doing.
This is a fundamental rethink of how cars work. Rivian is arguably the leader among automakers outside of China in SDVs, but other startups, like Tesla and Lucid, have similar software architectures. Tesla, in fact, was the first to do this sort of thing. Traditional automakers have struggled with this, just because their methods—including outsourcing computer parts and code to so many suppliers—evolved from years of the industry using domain-based architectures. Institutional inertia.
Zonal architecture is a huge part of how Rivian was able to get adaptive drive beam headlights in the new R1T and R1S before the rest of the industry, as an example. Its lights can talk with all the other vehicle systems, and because Rivian writes the software, it can make changes far more easily than it would if it had to work with external suppliers.
Zonal architecture is also why Volkswagen made a huge investment in Rivian to create a joint venture for its cars to use Rivian software. VW’s own attempt at a software revolution, Cariad, failed spectacularly, so it decided it should look to Rivian to leapfrog the competition and make up for lost time.
You’re seeing other traditional automakers working towards SDVs as they recognize the benefits of this approach. Ford’s coming $30,000 electric pickup will use such an architecture, and last week, Ford officials made clear that this is a major priority for this platform. The Honda and Acura EVs coming on its new electric-car platform will do the same.
Ultimately, the goal is more advanced features via software, but also getting you to pay more over time for these features. Car companies have big dreams of recurring revenue through subscriptions and even one-time downloads. So far, adoption has been slow. But over time, expect them to use these systems to monetize the ownership experience over the life of the car, not just when you buy it.
Right now, Scaringe argues that you can have feature parity between zonal- and domain-architected cars, though this requires huge effort, and those days are winding down regardless. “In the fullness of time, it’s like trying to ride a bike with 10 anchors dragging through the mud, if you’ve got a domain-based architecture versus a zonal,” Scaringe said. “And so I think it’s just impossible to see how those work in the end.”