No, Really, What’s an SDV?

The answer depends on who is answering the question.

August 26, 2024

Sebastian Blanco

The ‘hyperscreen’ cabin display of the 2024 Mercedes-Benz E-Class. Mercedes-Benz said it intends to deploy an in-house-created software operating system – a direction it seems most panelists at the 2023 WCX session on software-defined vehicle development would advise against. (Mercedes-Benz)

What is an SDV? No, you can’t just say “software defined vehicle,” because that’s not precise enough. Software has been part of modern vehicles for decades, but the code didn’t define the car. So, what is an SDV? It’s a question worth exploring. What are the components required? What are the dependencies? What is the tipping point when you can finally call a vehicle “software-defined”?

One person with an answer is Elektrobit’s Moritz Neukirchner, who I spoke with last year on this topic and have since followed on social

media. He recently posted a proposal to describe SDVs using a scale similar to the SAE’s five levels of automated driving. The list starts with Level 0, which simply means “software enabled” or a vehicle that uses some sort of software, and ends with the Level 5 “innovation platform,” which would be a full SDV that has the same sort of upgrade functionality as a smartphone, where new apps can allow the same hardware to do things it couldn’t before.

It’s the intervening stages that are the most revealing. They require us to think through what it takes to actually build an SDV. Level 2 on Neukirchner’s list is “updateable vehicle,” which means an OEM can update the software, but the feature set is the same. If the code breaks, engineers can put a bit of fixing on it. Level 3, or “upgradeable vehicle,” is where we start getting into SDV-like behavior with “dynamic functionality on a static target hardware.” Level 4, then, is a car that’s really a “software platform,” which “breaks up the lifecycles of hardware and software” and allows software updates to target a fleet of vehicles that can all accept the software even if the “target hardware onto which it is deployed [changes] over the years with new vehicles being released.”

Neukirchner’s post was an excellent counterpart to a panel I watched at the Center for Automotive Research’s Management Briefing Seminar in Traverse City, Michigan in August. The host asked the panelists to collectively explain how they defined SDVs, including the broader effects SDVs are likey to have on the industry.

The panelists started with the fact that an SDV separates hardware from software, and is updatable and upgradable. So far, so good. SDVs should enhance the user experience, they said. Also, SDVs do not necessarily have to be EVs, since improved software can just as easily be used to improve ICE vehicles.

Creating an SDV means an OEM has to put software in the center stage of vehicle development. Everyone understands that software is now a key part of any new vehicle, but SDVs ramp that up to extreme levels. The panelist said there’s an upside here for OEM software engineers, since SDVs might allow automakers to reduce the amount of software they need to develop. Like a smartphone OS, the code in an SDV could last for many years with regular updates. This code – when used in Neukirchner’s Level 4 or 5 SDVs – could be applied across model generations instead of each model year requiring its own software. Finally, the growth of SDVs could take place within a larger ecosystem that includes software-defined homes and infrastructure. Perhaps this brings us to the real definition of SDVs, which is just one more example of that oft-mentioned situation where something is both a difficult challenge and an opportunity.