Blog

The potential for software-defined vehicles (SDVs) is vast. IDTechEx, for one, has predicted that by 2029, SDV platforms will generate US$755 billion (£561.3bn) in hardware revenue alone. But what are the key trends underpinning this, and what challenges lie ahead? An engaging panel session on the Embedded Systems stage at Microelectronics UK put a few ideas together. 

Andy Birnie, VP, automotive system engineering at NXP, moderated the session. “It takes, roughly, an automotive company about five years to develop a new vehicle,” he began. “And five years for a new vehicle does not meet the demands of the consumer.” 

There are two key elements to consider for SDVs, Birnie noted. The first was lifecycle management, a ‘proper CI/CD process.’ Every vehicle you encounter potentially has different software to yours; it all has to play nicely together and be ultra-reliable. The second was data, and as Birnie noted, “as soon as you have a conversation about data, you have a conversation about AI.” 

The moderator was able to stem the inevitable AI chat – for a little while at least. With SDVs, the industry is moving from vehicles where every box performs a separate function, to a smaller number of larger processors. Bigger boxes, multiple functions. What does this mean for the software? 

James Dickie, sales director at ETAS, noted that the problem hadn’t changed; it had just been reframed. Today, the automotive industry has a large network of small boxes communicating with each other, with many safety-critical and real-time-dependent. “If you start aggregating those functions onto one bigger processor, you’ve till got that same real-time engineering problem,” said Dickie. “Just because it’s a big processor, it doesn’t make it any easier.” It makes it now a software engineering process, Dickie added, and not a networking integration process. 

David Palmer, chief product officer and co-founder of Pairpoint by Vodafone, looked at it from the perspective of distributed architecture. With low latency and high bandwidth, Palmer noted, what can be offloaded to the network as opposed to the car? 

“I think as we move forwards, we’re moving to this AI economy, we’re also moving to agentic AI architectures,” argued Palmer. “When you do that, a lot of the car’s interaction is going to be through agents to other things… payments, retail, safety, predictive maintenance. And that can’t all be in the car.  

“So the car needs to move from being self-sufficient, to preparing to be interactive.” 

The AI conversation could be stemmed no longer. What were the panellists’ best use cases for AI in the car? Ahmed Ebada, professor of informatics and AI and a senior product manager at BMW Group, dug into the very foundations of car ownership, lifestyle, and how owners interact with their vehicle. “When you build a car, it’s not just a product – it will be part of the person’s life,” he noted. Dickie noted the increasing prevalence of virtual sensors; good examples of these are to assess tire and brake wear.  

Palmer looked towards an assistant-type role, personalised to preferences, location, or driving style. Could your car eventually order your coffee by default as you’re heading towards the drive-through, for example? Small language models working inside the car could make a lot of sense, Palmer noted, yet he added: “I think what is clear is that the car cannot be isolated.” 

For the automotive industry, being safe and deterministic as its modus operandi; two words, Birnie argued, which do not as easily roll off the tongue for AI. Can AI be made safe and deterministic? Ebada advocated for a modular design, saying it was a challenge. “I think the safety depends on how you’re training the models,” said Dickie. “At the moment, we’ve come from a background where you train a model to do a task, and that’s fine, but once you get into these vehicle applications, I think safety has to become part of the training.” 

“I think the jury’s out,” added Palmer. “AI is [only] as good as the data that’s going into it.”