The biggest strength of the software-defined vehicle is that it evolves. A vehicle leaves the factory with a certain set of capabilities, but the OEM is able to leverage usage data and expand those capabilities over the vehicle’s full life cycle through over-the-air updates, enabling it to deliver better driving performance, improve the in-cabin user experience (UX), and otherwise make an aging vehicle feel new every day.
Hardware, however, does not evolve. Historically, once the vehicle left the factory, the hardware remained the same.
This dichotomy eventually presents a challenge to the software-defined vehicle. While centralizing and serverizing compute can be a cost-effective solution for sharing workloads, reallocating resources and extending its usefulness, at some point, the compute hardware will be too outdated to take on new software features that require faster processing, more memory or greater storage capacity.
OEMs can address these limitations with the right software and hardware architecture — one that not only has the flexibility to dynamically reallocate resources in real time, but also allows physical upgrades to just the specific compute components that need it the most, well into the future. Done right, the approach will also help them create independent software and hardware ecosystems while greatly extending the life of their vehicles.
We often think of the compute in a vehicle as its “brain.” After all, just as a human brain takes in information and acts based on that input, the vehicle’s compute platform takes in data from sensors and other outside sources and makes decisions about what to do and what to communicate.
A human brain, however, changes and grows over time. Babies grow into children, and children grow into adults. As their brains physically change, they become capable of greater understanding and more complex reasoning.
In contrast, computers are static, with defined processing limits. As software developers create ever more sophisticated and capable applications, they push those limits until it is necessary to move to the next generation of hardware to enable the functions they create.
In the automotive world, newer hardware could also become necessary to meet evolving safety regulations or to ensure that the vehicle continues to employ the latest cybersecurity measures.
Consumers are used to this upgrade cycle in other contexts. In the mobile phone world, for example, many people upgrade to a new device every two to three years, in part to obtain a processor that can adequately support the latest apps, functions and cybersecurity protections. A key difference, of course, is that the expense of replacing an entire phone is much less than that of replacing an entire vehicle. A vehicle also is obviously far more complex, with hundreds of devices distributed throughout, which are increasingly connected to a central compute unit.
The solution in automotive is to structure the software and hardware architecture so that OEMs can upgrade just the compute needed to execute higher-level functions.