Software-defined... Headache?
Experts say the auto industry has to change its methods to effectively and efficiently develop the software central to new-age vehicles.

The “software-defined vehicle” is the auto industry’s latest fascination. Probably with due cause, as engineers and other experts and analysts understand that the vehicle-electrification transformation rests on the back of software. But an auto industry wedded to its ingrained methods needs to drastically adapt its engineering processes to develop software — and the change isn’t coming easy.
That’s at least in part because there’s wide disagreement even about what “software-defined” really means. In an informal late-spring talk with media, Peter Waeltermann, CEO of testing and validation specialist dSpace — a company at the tip of the spear when it comes to cutting-edge software development — bemusedly said of the software-defined vehicle (SDV), “I don’t know if anybody really understands it.”
The intrigue runs deeper. In an interview with SAE Media, Maria Anhalt, CEO at Elektrobit, the 35-year-old developer of software products and services for the auto industry that is an independently operated but wholly owned subsidiary of global supplier Continental, Anhalt maintained that the bulk of vehicle software is non-differentiating. “We estimate that approximately 60% of the software that is in the car is something that you’re not seeing — you as an end-user,” she said. “You’re not seeing and you’re not experiencing it.”

Anhalt was one of the participants in a panel session titled “Moving Towards a Software-Defined Vehicle” at late-April’s SAE International 2023 WCX conference in Detroit. The speakers noted a variety of chicanes in the SDV race. Software-development problems aren’t related merely to disrupting long-standing engineering routines. Some are based in human nature: few people genuinely embrace change.
Before the auto sector can adapt from the century plus of its established product-development methods — a process all on the panel agreed must happen to effectively create SDVs — those in charge of the transformation must step up to foster the systemic change. “We have to change people first,” said Matt Jones, Ford’s executive director – tech strategy + R&A. The big teams that historically have been engaged in vehicle development generally don’t work, he said, in the context of software design and deployment.

“The hardest thing in the world to do is change human behavior,” added Stephen Rober, vice-president and head of advanced technology at Stellantis. He said the traditional “top-down” style of automotive development needs to change to bring the agility required for engineering for a software-centric future. A little more humility won’t hurt, either, he added. “Everybody needs to understand the don’t know everything.”
Partner approach
The conference session’s panel was in virtual agreement regarding another point of required product-development change: automotive OEMs and suppliers must embrace a partner mindset to replace the traditional relationship that has for decades been in place between automotive OEMs and the suppliers of auto-centric components. “I avoid the word ‘supplier’ — I prefer the term ‘vendor,’ said Elektrobit’s Anhalt during the discussion.
Anhalt said the auto sector needs to increasingly view the software-development relationship as one of “mutual cooperation” and that “the Tier model is evolving.” Anhalt and Stellantis’ Rober said that development of “base” or foundational software is what most benefits from collaborative relationships; think of that 60% of “non-differentiating” software Anhalt mentioned. Following that, brand - or company-specific differentiation still can happen “on top” of the base software in a process an OEM or Tier 1 supplier can guide to produce more discrete requirements. “Nobody ever bought a car for it’s operating system,” quipped Jones in supporting the notion that much of the work of software development can and should be collaborative because so much is unseen by vehicle consumers.
“Software transformation is being managed with a hardware perspective,” agreed Glen De Vos, SVP, transformation & special programs at Aptiv. He said there is much to be learned from how industries such as telecommunications and aerospace/defense embraced software development and deployment.
Learn from mistakes, leverage what knowledge and existing work already is available — and nurture software developers as partners, added Elektrobit’s Anhalt. “It goes to collaborations,” said William Foy, director, Automotive Solutions for Amazon.
Speed and standards

Apart from ripping up the top-down development approaches of the past, effective processes for software-defined vehicles have to change because, some panelists insisted, the old ways simply are too slow. Moreover, the collaborations that have helped in the past — development of standards, for one — also are inherently plodding, consensus-centric models that mitigate against the speed that customers of software-driven products demand.
Ford’s Jones suggests one approach is to view software development as little different from how vehicle development occurred in the middle of the last century, when the factory was the focus of the process. “What is the equivalent of a software factory,” he asked rhetorically. He said that a similar, automation-intensive mindset would help to bring efficiency — and speed — to software development.
Aptiv’s De Vos said that the partnering relationships most of the experts recommended to help create a better end product also serve to improve the software-development speed. “We need to partner, without trying to grow organically,” he stressed. “It takes too much time.”
Standards can be important to aiding the software-creation process, De Vos said, but “standards take time.” Moreover, added Stellantis’ Rober, “Nobody can agree on a standard.” Ford’s Jones added that a patchwork of alliances between OEMs and software developers hasn’t helped to create consensus-based standards or an open-source ecosystem — tools that once developed are generally agreed to reduce future development time and cost.
However, even open-source agreements aren’t a panacea, said Elektrobit’s Anhalt. She noted that more open-source projects have failed than have succeeded. And Rober added that in individual companies’ haste to gain competitive advantage, “We never allow for a standard to change and grow.”
Despite the session panelists’ agreement that the auto industry is in the early days of a transformation that’s required if the software-driven vehicle is to fulfill its promises, most expressed optimism that the change will happen — and happen for the better. “We’re at a really interesting point in our industry,” said De Vos. It’ll be exciting to see how this plays out.”
Top Stories
INSIDERManned Systems
Army Launches M1E3 Tank Development, Cancels M1 Abrams Upgrade Program -...
INSIDERDefense
The B-21 Raider Starts Flight Testing - Mobility Engineering Technology
INSIDERDefense
Air Force Awards JetZero $235 Million to Develop Blended Wing Body Demonstrator...
INSIDERAerospace
Air Force Receives First eVTOL Six Months Ahead of Schedule - Mobility...
ArticlesPower
Rim-Driven Electric Aircraft Propulsion - Mobility Engineering Technology
INSIDERManned Systems
DoD's First Electric Aircraft Charging Station is a BETA Supercharger -...
Webcasts
Automotive
The Path to ISO/SAE 21434 Cybersecurity Compliance
Sensors/Data Acquisition
Understanding Technological Advancements in IR Detection Modules
Automotive
NVH Prediction in Electric Powertrains: Considering Inverter and...
Automotive
Electrifying Off-Highway Drivetrains
Medical
What Really Changed: A Look at the Updated FDA Guidance Document for ISO 10993-1