Throw Out All Those Black Boxes and Say Hello to the Software-Defined Car
We speak to Oliver Hoffmann, Audi's head of technical development.
— Jonathan M. Gitlin | May 31, 2023
The prototype of the Q6 e-tron is the first on the new Premium Platform Electric (PPE) technology architecture.
One of the auto industry trends I'm most excited about these days is the move to clean-sheet designs for car platforms and architectures. For decades, features have accumulated like cruft in new vehicles: a box here to control the antilock brakes, a module there to run the cruise control radar, and so on. Now engineers and designers are rationalizing the way they go about building new models, taking advantage of much more powerful hardware to consolidate all those discrete functions into a small number of domain controllers.
The behavior of new cars is increasingly defined by software, too. This is merely the progression of a trend that began at the end of the 1970s with the introduction of the first electronic engine control units; today, code controls a car's engine and transmission (or its electric motors and battery pack), the steering, brakes, suspension, interior and exterior lighting, and more, depending on how new (and how expensive) it is. And those systems are being leveraged for convenience or safety features like adaptive cruise control, lane keeping, remote parking, and so on.
Of course, this only works if that software is any good. "There is absolutely no question that software has been treated like a stepchild—I always say the fifth wheel in the car. So like a necessity, but not something that has been managed with care," said Maria Anhalt, CEO of the automotive supplier Elektrobit, which develops digital systems and software for OEMs.
"But what we also see is that every OEM and every SOP and every product line starts from scratch in procurement and doing things for the first time. So part of the complexity is doing things multiple times and not thinking of reuse and architecture and modularity and upgradability," Anhalt explained.
Domain-Controlled Architecture
One can certainly see the appeal of a clean-sheet design that leverages modern computing to simplify a car's underlying design.
"It is much more elegant," said Oliver Hoffmann, Audi's board member in charge of technology development. That doesn't make it easy, though. "But to be honest, it is challenging, because all those functions which were located all over the car—a lot more than 200 controllers—you have to bring all those functions into the domain controller. But it is a very smart solution," he said.
"So as an example we have what we call the high compute platform, and we have a dedicated domain for infotainment, and we are able to update but also to upgrade, so that every year or every two years you can bring an upgrade in terms of hardware, and we are able to run over-the-air updates," Hoffmann told me.
The first Audi we'll see adopt this approach is next year's Q6 e-tron, an electric SUV that is one of the first EVs to use Volkswagen Group's new PPE (Premium Platform Electric) architecture, which will also be used to create the A6 e-tron and the next Porsche Macan.
All the domains—which include driving behavior, thermodynamics, and energy management as well as infotainment—are upgradeable over the air; some earlier implementations of OTA updates by automakers have only allowed for certain systems in those vehicles (like infotainment, but not the powertrain) to be easily updated. "So [it's] a very, very big advantage with this kind of platform, and it's a smart solution," he said.
Audi now uses a 48 V electromechanical stabilizer bar in the suspension that can react within milliseconds.
I was curious if the move from tens or hundreds of discrete black boxes meant completely rewriting all those functions from scratch. While that's always an option, Hoffmann said that Audi was able to use its experience to make the job a little easier. But for PPE that still meant a new way of working.
"It was a completely new way to work together with suppliers," Hoffmann said. "So in the past you had a supplier responsible for the ABS, which was a separate and dedicated controller. Now, there's an interaction between all these domain controllers, so you have to double-check if all this works together with all these other domains or with the rest of the software in the main controller, which makes it very complex," he explained. The solution was to organize "supplier parties" to bring everyone together. This was also complicated, Hoffmann told me, "but I think it is the new way for a collaboration model," he said.
Another advantage of the move away from legacy designs is that digital security can be baked in from the start rather than patched onto components (like a car's central area network) that were never designed with the Internet in mind. "If you design it from scratch, it's security by design, everything is in by design; you have it there. But keep in mind that, of course, the more software there is in the car, the more risk is there for vulnerabilities, no question about this," Anhalt said.
"At the same time, they're a great software system. They're highly secure. They're much more secure than a hardware system with a little bit of software. It depends how the whole thing has been designed. And there are so many regulations and EU standards that have been released in the last year, year and a half, that force OEMs to comply with these standards and get security inside," she said.
Software-defined vehicles might give automakers more flexibility in terms of the features and functions they can create, but it comes with some headaches on their end, including ensuring that a car works in each market where it's offered.
"All the requirements are different for each region, and the complexity is so high. And from my perspective, this is the biggest challenge for engineers. Complexity is so high, especially if you sell cars worldwide. It is not easy. So in the past, we had this world car, so you bring one car for each market. We are not able to bring this world car for all regions anymore," Hoffmann told me.
"In the past, it was not easy, but it was very clear—more performance, more efficiency, focus on design. And now that's changed dramatically. So software became very important; you have to focus on the ecosystem, and it is very, very complex. For each region you have, you have dedicated and different ecosystems," he said.
"The very simple example is our Q7 [Audi's three-row SUV]. So it's a very, very big car in the European market, but it's a very small car in the US market," he joked.
Oliver Hoffmann (member of the Board of Management for Technical Development) and Gary Telaak (Exterior Design, AUDI AG) check out the Audi Urbansphere concept. This concept was designed with China in mind.
Satisfying The Regulators
A good example is the differing approaches taken by US and European regulators. In the US, automakers "self-certify" their products, declaring to the government that their cars conform with all the applicable safety standards and so on. But in Europe, they practice "type approval"; here, an automaker submits a representative example that a country's regulator will check over and issue a type approval certificate if it conforms.
"From my perspective, [self-certification] is not easier because you are responsible; you're not given a rulebook. The pressures are on our side. And it is a little bit easier in Europe because if they say, 'okay, approved by us,' they are with us," Hoffmann told me.
The move to software-defined vehicles complicates this, as it applies to software as well as hardware. That means each update needs to be signed off by a regulator before being sent out over the air.
"Because in the past, you're able to run a test. You say, 'Okay, you have to crash at 50 kilometers per hour, and if you fulfill everything, you're fine.' But now, it is software-driven. So you run all these corner cases in the software, and you say, 'okay, we have a big improvement in the software,' but how can you test it? You're not able. This is a virtual testing and virtual validation process. And this is a dramatic change," he said.
The most glaring example is the behavior of advanced driving assistance systems. As we've seen from Tesla's example, buggy or badly written ADAS software can lead to crashes and recalls, but edge cases abound. "So this is more or less a validation of your tools and no longer of the product you will bring in the market. And this is especially true when you develop ADAS functionalities; this is the biggest challenge for the future," Hoffmann said.
— Jonathan M. Gitlin is the Automotive Editor at Ars Technica. He has a BSc and PhD in Pharmacology. In 2014 he decided to indulge his lifelong passion for the car by leaving the National Human Genome Research Institute and launching Ars Technica's automotive coverage. He lives in Washington, DC.
