Software-Defined Cars

Automotive architectures are becoming increasingly software-driven, a shift that simplifies upgrades and makes it easier to add new features into vehicles.

All of this is enabled by the increasing digitalization of automotive functions and features, shifting from mechanical to electrical design, and increasingly from analog to digital data. That enables OEMs to add or up-sell features years after a car was originally purchased, such as autonomous driving capabilities. It also allows carmakers to keep vehicles up-to-date over their lifetimes as safety requirements and connectivity protocols change.

But for a vehicle to be truly software-defined, the hardware and architecture of that whole automotive platform must be designed to enable it. And that is not how vehicles are being built today.

“What that means is most OEMs are settling on a central compute architecture,” said David Fritz, senior director for autonomous and ADAS SoCs at Siemens Digital Industries Software. “This can be heterogeneous or homogeneous. That part doesn’t matter, as long as it’s one architecture — one software architecture, one hardware architecture — because that allows the OEM to say, ‘I’m going to let my customer download a new application that can completely change their driving experience.’”

Others point to similar trends. “You’ve got this hardware that’s moving you around,” said Steven Woo, fellow and distinguished inventor at Rambus. “It should be the case that you can customize it to the look and feel you want, similar to profiles in streaming media services and the like. Why shouldn’t it be that way?”

These capabilities already have been demonstrated at conferences and trade shows. “At CES you can see concepts for what cars can look like,” Woo said. “One of them had LEDs blanketing the outside and the inside of the car. Different drivers could have the equivalent of an avatar or a skin in gaming. You customize it to your mood, and you might have one particular preset. From a software-defined perspective it should be the case that, based on the need and the time of day and the mood you’re in, or whatever you need at that moment, you can customize what the interior looks like, along with the type of music you’re playing, the type of video you’re getting, even the types of feeds and things that are brought to your attention. Like homepages get customized almost automatically in some ways, those are the kinds of things that likely will happen.”

Fritz said an executive in Germany showed him a car and said, “‘This is our vision.’ When he fired it up, all the lights came on inside it and you hear, ‘Scotty reporting back to Captain Kirk.’ It’s like riding in the Starship Enterprise. He said, ‘Imagine people downloading this kind of experience. Maybe I don’t want to be in Star Trek. Maybe I want to be Wonder Woman, or I want to have an Avengers experience. I want to be able to choose my experience and have the vehicle adapt itself.’ It’s the supporting of the ‘skin’ of the vehicle that is going to be a differentiator. It’s either that or cupholders.”

Making this all work requires a layered approach to the entire vehicle system. “This includes the hardware stack, which is the car and the engine, and so on,” said Marc Swinnen, director of product marketing, semiconductor business unit at Ansys. “On top of that is the silicon stack that controls the lidars, the radars, the engine, and this silicon drives the hardware. Then, on top of that is an operating system, which many OEMs are building today to manage all of the operations in the vehicle. Additionally, there is an application stack, with a software stack on top of that, and the car will be interfaced through these applications. So it’s a more traditional electronic system model, and the car is just the hardware layer in that stack.”

Defining the software-defined architecture
Software-defined automotive is a nice label, but what exactly does it mean? “At the end of the day, we have to go back to the starting point to see what it really means, then how it impacts the system, and why is it there,” said Marc Serughetti, senior director for embedded software solutions and systems at Synopsys. “Ultimately, it’s all about the functionality that the OEM wants to bring in the car. Today, the automotive market is driven by EV. It is driven by ADAS, heading toward autonomous driving. We know it is driven by connectivity, shared mobility, and things like this. The challenge for the OEM is, given that these are things the consumers want, how do you start delivering a product that enables all those capabilities? In the past, the way the automotive ecosystem developed was, ‘Here’s a new function. Let me throw in a new piece of hardware that addresses this function.’ These new trends don’t allow that approach. It doesn’t work anymore because those functions do not work independently. They are connected with each other. The other piece is that the consumers who want advanced capabilities know their mobile phone gets updates and upgrades, and that’s what they want in their cars.”

This is a big driver behind the OEMs and Tier 1s now questioning what all of this means for them, how they will differentiate themselves going forward, and how they can achieve their goals.

“The way you achieve this is by having a lot of that functionality addressed in software,” Serughetti said. “A lot of companies in the automotive ecosystem are talking about a ‘software first’ strategy, and how that impacts the product and delivery. Taking it to the hardware, there are a number of implications. First, you cannot have the same architecture that you had before. You cannot have an architecture where all those ECUs are distributed all over and each has its own function. No, you need a change in the electronics architecture of the car, and this is why people are talking about central compute/zonal gateway domain controller and the like. There’s an entire evolution on that side that’s happening, and that’s to support software.”

The second piece of the puzzle is what type of chips are needed. “You’re going to need chips that are very powerful in terms of computing, in terms of what you can do, along with AI support. The third piece is software. Now, because there are so many computing elements, and you want to leverage that computing power such that if a zonal architecture is being considered, for example, you say, ‘I have different zone controllers, and I’m trying to do a calculation. Why can’t I use the computing power provided by one of those zone architectures, and if I don’t have enough out of that, why can’t I use another part of the computing power in the car?’ This whole software-driven approach is impacting the electronics system, as well, which means hardware and software together. And that also has implications. From a software perspective, what does that mean in terms of operating system? This is where we’re starting to see the OEMs recognize the need to have their own operating system. And we’re not just talking real-time operating systems. They are talking about complete infrastructure.”

Functional and safety concerns
That raises a bunch of new issues, said Frank Schirrmeister, senior group director, solutions and ecosystem at Cadence. “Does the software work? Is it safe enough? Safety, comfort and convenience are really driving these things, and cars seem to be becoming living objects. Vehicles are becoming a continuously evolving hardware/software platform. Looking across industries, vehicles are basically an IoT device, which become a consumer hub. Underlying all this is the elegance of the decoupling of software and hardware, all while having software improvements running in parallel — almost like an agile development environment.”

While these shifts toward software-defined vehicles include what the next generation of vehicle architectures look like, they also determine where the functions are going in vehicles.

“We’re moving right now away from a distributed approach, where each function in the car has its own ECU, and they’re all distributed around the vehicle with more microcontrollers than you know what to do with,” noted Robert Day, director of automotive partnerships, Automotive and IoT Line of Business at Arm. “That started to change into something called a domain architecture, where each domain in the car had its compute, and then it had its own ECUs connected to it. There would be one for ADAS, one for in cabin entertainment, etc. That meant a bit more consolidation, but it’s consolidation around function. Each function has its own microprocessor and bunch of microcontrollers. This is where we are today in this domain controller world.”

Fig. 1: Rising complexity in a software-defined vehicle. Source: Arm

The next shift is going to be into something that’s more zonal, where each zone will have its own zonal controllers. So each corner of the car will have all of the different sensors, and they will feed into a zonal controller. That zonal controller will pass the information from its zone to a big central compute.

“We’ve gone from domains to zones, where each zone then talks to a big compute and then that big compute element, which is high-performance compute in the car — often termed ‘data center on wheels’ — will then do whatever functions are necessary with the information coming from the different zones,” said Day. “This is where we can implement software-defined functions, because this big central compute doesn’t have a specific job to do. It does whatever the software running on it tells it it’s going to do. That’s where you would then start bringing in the software-defined functions on a big central compute unit.”

Upselling
And this is where architectures get really interesting. “If everything is software-defined, this thing is looking more like your cell phone or computer, as far as running different applications on it, often at the same time,” said Day. “Also, these software applications are defining how the vehicle is going to function. This is the software-defined vehicle. Because the OEMs can make a car where how it functions is done by the software, you’re going to run on it. You could have the same platform that has premium functions for the high end, and not-so-premium functions for the lower-end vehicles, and the compute could stay the same. Architecturally, this might mean the developer may choose to overprovision the hardware to start with, since one of the other key things about software-defined functions is they also could become upgradeable — a bit like your phone or your computer. So the car doesn’t just stay the same from when it leaves the dealership to when you sell it. It actually matures, or upgrades, or gets better, or evolves.”

This is well understood in consumer electronics, he noted. “We, as users, are now very used to that because that’s what we do in our personal device world. Why should that be any different for the car? Given that you don’t really know what applications might be running on it, or what those applications will affect performance-wise, it means you’ll probably want to over-provision the hub to start with. You’re saying, ‘I want this hardware to still be working effectively in the lifetime of the car.’ Let’s say it’s five years. You can say, ‘Even though I don’t necessarily need all the performance right now, there’s a good chance that we’ll have another application, such as a more advanced ADAS feature that comes in. We’ll still use the sensors that we’ve got, because we’re going to have all these different sensors in the vehicle, but the actual function it’s going to do is going to be more advanced potentially in the future than it is today.’”

To enable all of this, Cadence’s Schirrmeister noted that the vehicle must be connected for over-the-air updates. “But you really don’t want to break your car like you would break your cell phone if an upgrade doesn’t work. This means lots of things have to be considered in a very detailed and safe way. But you can make updates that are related to safety, as well, like better algorithms for recognizing obstacles, etc., as these are not static. These are going to require organizational changes driven by the complexity. It’s changing the mindset, as well. The vehicle is getting further consumerized, and the kinds of upgrades in the consumer world with TVs, with game stations, with phones — the car in that sense gets consumerized and becomes one of the hubs. It’s one of the endpoints the users are interacting with, and it’s a question of how much consumer experience to put in there. But it’s definitely consumerization.”

Supply chain disruption
Another aspect of the shift to software-defined vehicles is value generation, noted Moritz Neukirchner, head of software architecture at Elektrobit. “Where do you see innovation in the vehicle being made? We are largely looking at making innovation, making progress in automotive via software be it a functional level, such as how you develop applications or ADAS systems, but also on how to actually build and maintain the software. How is the vehicle integrated? Previously, we were putting boxes together, and connecting them by wires. We are now very much looking at putting software components together, integrating them as software parts, being able to separately update those instead of replacing individual boxes in the vehicle so the entire development practice changes. This way is less focused on mechanics, less focused on buying boxes or wiring harness, but much more focused on how to put functions together, how functions are structured from a logical perspective, because it’s driven by software.”

All of this must be considered up front with safety, security, autonomy, infotainment, etc., along with the maintenance and keeping the lifecycle of innovation very well controlled, Neukirchner said. “OEMs are now taking much more ownership in software. We see this at essentially every OEM. Each one is creating their own, even sometimes a legal entity, to develop software. Otherwise, big organizational units within the OEM are taking ownership of software platforms. We also see a trend that some OEMs want to increase their IP and software, and they want to understand how to do software integration rather than buying boxes from Tier 1s. We also see in automotive OS a trend toward sourcing from middleware suppliers directly, rather than going to the Tier 1s, so the automotive supply chain is being disrupted here.”

Automotive OEMs want to be able to anticipate potential problems, especially making sure the central compute is not failing or compromised in any way. This is changing the thinking of OEMs and, in turn, the entire supply chain.

Arm’s Day noted this has shifted the responsibilities in the system a bit. “It’s not about how this one hardware module has to behave. It’s about how the software behaves on it. For example, you can have a hardware platform, and that hardware platform has enough performance to run both the infotainment and the ADAS system. It’s really going to be a software definition as to how those things run. Let’s say I need these things to be independent from one another, even though they’re running on the same hardware system. That may mean I need to bring a hypervisor in to separate those, and have freedom from interference. But I also need to be able to get my software workloads easily on and off these things. What does that look like? That’s a software architecture versus a hardware architecture tradeoff. You’re still going to have to have the reliability, the auto qualification certification, etc., for the hardware system, but how it functions and what it’s going to be will be defined by software. That’s the big shift here. You’re going to have to make sure this will still run reliably. You still may want to put elements of redundancy into it, either within the SoCs themselves or with multiple SoCs. But there’s an interesting potential here in that you can actually shift applications around.”

Fig. 2: A wholly upgradeable vehicle. Source: Arm

The future
A software-defined approach also increases system complexity, and makes the engineering team’s job more difficult.

“The complexity is increasing, while at the same time the development productivity that the design engineer has is not really increasing today,” said Synopsys’ Serughetti. “The engineer is looking at this daunting task, and now also has to think about how all it is working together, including how to test this in 8 million miles of driving. From that perspective, there are impacts on the development approach — not only with software and integration, but also in terms of the SoC architecture and looking at it from the perspective of defining an SoC. The engineering teams have to include very early exploration of the architecture for performance and for power. Because of this, the collaboration aspect of that is growing more important between the semiconductor developers, the Tier 1s, the OEMs. Everybody’s looking at what type of SoC is needed. Does the OEM need to build it themselves? Do they work with a semiconductor company to build it?”

Here, the challenge is the use cases — the work or the workloads that are driving the SoC performance. “How do I validate early, or explore that early enough to achieve the right performance in my SoC? That’s another aspect, how architecture plays a role, from the SoC architecture all the way to architecture at the vehicle level between the different compute elements,” Serughetti explained. “The collaboration element can’t be underestimated. Before, a lot of development could be done in isolation. Now it’s essential that development is done in collaboration within the ecosystem, and that collaboration needs to have the infrastructure to enable that collaboration. How do you exchange data? How do you move more into an executable specification of what you’re doing? Today’s systems are more complex. You cannot do it through a spreadsheet. You cannot just do it in the mind of one person, thinking ‘Oh, that’s how it’s going to work.’ You really must have a collaboration platform for that type of activity. That’s something in the day-to-day activity of the people looking at electronics, who are going to be affected by this change towards a software-defined approach.”

Michal Siwinski, chief marketing officer at Arteris IP, agreed that fundamentally automotive development is going to be software-defined. But he noted the lines are still being drawn in terms of how much will be in software and how much in hardware. “In the context of chiplets, chips potentially might change some of [what happens in the software-defined vehicle]. Remember, power management used to be part of the silicon. Then it moved out of the silicon to become a separate chip. Now, as we move into chiplets where the memory could be in 5nm, the digital content could be in 4nm, analog might be in 28nm, MEMS on 130nm, and who knows which process the antenna will be in — all of a sudden, it’s back to a heterogeneous re-computation of what the system-on-chip is. Some of the pieces that went out of the chip potentially could move back into this bigger chip, because you still want to have the proximity and the optimization. Likewise, some of the things that are purely in software, or more software-driven, actually might find their way a bit toward being in hardware, because you have better control while still being software-controlled. Time will tell.”