What do you think about software-defined vehicles? Experts have something to say

”

The automotive ecosystem is transitioning to software-defined vehicles, giving rise to new architectures that include more software. Semiconductor Engineering discussed the change with a number of industry experts, including Suraj Gajendra, vice president of products and solutions for Arm's automotive business line; Chuck Alpert, Cadence Automotive R&D Fellow; Steve Spadoni, Area Controller & Power Distribution Application Manager, Infineon; Rebeca Delgado, Chief Technology Officer and Chief AI Engineer, Intel Automotive; Cyril Clocher, Senior Director, High Performance Computing Automotive Product Line, Renesas; David Fritz, Vice President, EDA Hybrid & Virtual Systems, Siemens; Marc Serughetti, Senior Director, Systems Design Group, Synopsys. The following is an excerpt from that discussion.

SE: The automotive ecosystem is undergoing an unprecedented technological evolution, including a shift to software-defined vehicles. To set a baseline for this discussion, what is your definition of SDV?

Gajendra: The software-defined car is a concept, a trend, an idea, and the entire ecosystem can bring new features and new user experiences to the car, from the moment the car is delivered to the user to the end lifecycle. It's quite a rich concept. There is a lot of infrastructure that needs to be put together, such as software development in the cloud, seamless deployment of software development to the car, overall deployment of over-the-air updates, and connectivity. In short, the concept of software-defined vehicles looks forward to a time when we can bring new experiences, new features, and new features throughout the life cycle of the car.

Alpert: When thinking about what SDV means, one example is batteries – especially in electric vehicles. I'm not talking about evolving battery technology, I'm talking about the past when you wanted to charge your car in the garage and you were worried about starting a fire, you would think, 'No, don't don't do this because your whole house could burn down.'" "The idea is that in the past, maybe we might have put a temperature sensor on the battery, but now we actually have software that can monitor it. It may even have artificial intelligence to predict if the battery reaches a certain state that could cause a fire in the future. You may also have some devices that you can connect to the grid and know when it's a good time to charge, as it's cheaper because it's a low-usage period. It's just part of the car, but you can imagine you want to put a whole suite of software on it in order to connect to the universe. You need a software-defined vehicle platform so that this platform, or all other parts of the car, communicates with the world and provides the best user experience.

Spadoni: Infineon's definition of a software-defined vehicle is a redefinition of the architecture, specifically, the electrical and electronic architecture, the distribution of functions, and the entire topology of the vehicle, from generation and storage to power distribution and high computing. This really means new electrical architectures and will have an impact on the business model of every OEM and Tier 1 supplier involved. This is a significant change from the previous approach over the past 30 years.

Delgado: Software-defined vehicles are more than just over-the-air updates. It's really a new methodology and a new philosophy about how to build each component of a vehicle to continue to deliver value over time, where value is tied to the software that delivers the user experience. Ultimately, this architecture must support different practices on how to deliver this new value over time. Interestingly, many other industries have done these moves to software-defined architecture. Intel has a lot of tradition and has actually helped transform these industries. This shift is indeed what we are observing here. It's an incredible opportunity, and if not done well, it can also lead to a crisis.

Clocher: To use an analogy, a car is the new smartphone. But for us, it doesn't stop there. Yes, I've heard about this platform, and it's the main architectural evolution we're going to see in the next decade. For Renesas, as the industry moves from decentralized classical computing to centralized classical computing with a zonal architecture, it will be a journey that enhances the user experience and creates new revenue streams for the industry. We can apply all of these buzzwords to software-defined vehicles. These platforms will require mainframe computers and heavy-duty complex hardware solutions that will generate evolution and upgrades throughout the life cycle of the vehicle, but we know that – at least at Renesas and certainly some other players and chip suppliers – will require significant hardware resources to manage our idea of deploying this platform.

Fritz: I think software-defined vehicles are a little bit different from what has been mentioned so far. Over the years, the hardware team did the design, the software team did the design, and all of that finally needed to come together. In the automotive space, this is going to be an integration storm, which is a nightmare. This is compounded by the fact that new computing requirements have already been mentioned. So my perception is that as people with an engineering background, we tend to dig into how we're going to do things. We talk about "how" prematurely, and a lot of the discussion here is an example of this approach. When I study software-defined vehicles, I look at why it's so important that software needs to run effectively on hardware. For this hardware, why is it important that it runs correctly on software? Then you can decide how to put together a new way to bring those things together. In the past, it was referred to as hardware/software co-design. We've made several attempts, and as mentioned earlier, other industries have made this shift as well. The unique thing about a car is that it's not just one transformation that needs to happen, it's hundreds or thousands. The ecosystem needs to change completely, and we're seeing that happening right now, and you need to bring all of that together. It's really a methodology, and you need the tools, the process, the thinking, the organization to make the change so that they can make that shift in a realistic way. SDV is a huge shift. It's a way for the automotive industry to be long-lived and able to meet customer expectations, which have been around for some time.

Serughetti: At the end of the day, if we look at it from a top-level perspective, SDV is a means to bring and enhance the automotive experience to the customer. It's the end result that OEMs are focused on, but they look at it in terms of how to improve OEM efficiency and how to create new business opportunities. The way we look at it, and what matters is its impact on the industry, the impact on processes, methods, people, ecosystems, and technology. It's really a transformation in the automotive market that is going to fundamentally change the way the industry evolves and bring OEMs into a world where they're really focused on how to deliver cars more efficiently, how they can bring new features, but at the same time, how they're also growing their businesses.

SE: As you described, SDV requires a lot of interdependencies, and the whole ecosystem has to understand the "why" and then develop a plan to get there. Where does the ecosystem currently sit in achieving SDV?

Fritz: OEMs have decided in the last few years that they have to take control of their own destiny. They can't simply accept what the supplier offers. They needed a methodology — like the whole SDV concept, and whatever tools needed to provide that concept — to deliver to their vendor, "This is what I need, and if you can't do it for me, I'm going to go to someone who will." "It's not an old ecosystem from IP to Tier 2, Tier 1, to OEM, which gives them limited options. So when I say "completely disrupt the ecosystem," that's what's happening. But each OEM has its own ecosystem, and they're not all in the same place. They can be very different even in different regions.

Delgado: It's a critical discussion, and one that the industry has to address ultimately. The extent of ecosystem transformation includes the role of technology in evolution. Over the next few years, chips in cars are expected to quadruple to define the in-car experience for end users. At the end of the day, the complexity of role shifting is so great that a proprietary, fragmented, and fragmented approach can't actually enable the industry to transform at the speed needed to deliver and meet demand. But most importantly, they won't address the actual technological changes needed to implement and allow this value delivery mechanism. At the end of the day, this is where Intel really believes collaboration is critical, and anyone who wants to participate in this ecosystem has to provide scalability—also known as top-down support for the different product lines of our OEMs and Tier 1 suppliers, and it's important to support these evolving higher performance and higher performance computing needs, rather than taking a decentralized approach. It has to be future-proof, because you're going to end up rolling out the car. Therefore, some hardware must be future-proof within a certain affordability, and there must be a strategy around that. Then the ecosystem and collaboration must be able to provide that aggregation. It has to be done with certain anchoring techniques that will allow us to deliver this performance. Collaboration is key because these technologies can't be owned alone, let alone owned, defined, developed, and integrated by OEMs in silos, with proprietary end-to-end architecture definitions. Obviously, there will be differences in implementation, but overall, the technology must be reusable, especially from other verticals that have done the software-defined transformation and then adapted the right way to meet the needs of the car.

Spadoni: There could be a variety of implementations. At Infineon, we work with OEMs and Tier 1 suppliers, and we see a different approach. General Motors, for example, has adopted a more modular approach to simulating what is happening in the field of mobile phones. Ford and Stellantis seem to be taking a more pragmatic approach, but they both face very similar challenges where affordability has become a big issue. There will be multiple generations of implementations, and you'll see how to pay for these extra hardware efforts. It leads to trade-offs when implementing other systems that must save money to be affordable. No one is going to walk into a dealership and say, "Give me a software-defined car." "Everybody is looking for value, and now with sales down, you can see that. High-priced buyers are saturated. OEMs want to get more sales, which means they have to move to lower-cost vehicles, which will impact electrical and electronic architectures as well as software-defined vehicles.

Clocher: I summarize what we're seeing as the impact on the ecosystem. We're moving to an OEM-centric ecosystem. One size does not fit all, which means OEMs will have different tastes and they want to have different levels of integration defined in a software-defined vehicle – especially considering the more complex tasks we all have to accomplish rather than the challenges we face that have to be solved because we are not talking about a universal umbrella for software-defined vehicles. But it does mean different implementations and different meanings for OEM A and OEM B. I totally agree with David and Steve that we don't have a consensus yet, at least on the market itself. That's good because it brings differentiation, and ultimately that's why the customer chooses A over B. That's what the industry wants to see – continue to differentiate and continue to add value to the end product.

Serughetti: Of course, the important thing about all of this is that you're breaking the mold that exists today. This is one of the biggest challenges. We used to have a level of responsibility for building boxes and delivering software. It's a complete black box. When it comes time to integrate, all sorts of problems arise. Are you going to break this now? The challenge for OEMs is how to do this. They want to control the software, but now do they have the ability to do that? Today, we're seeing some of the problems that traditional OEMs are having when building software organizations, the challenges faced by CARIAD, and all organizations that try to do so. It's not easy to change these companies. Of course, this problem doesn't exist for new entrants, as they have a completely new design rather than a traditional approach. So for OEMs, it's all about how to control the software. What does this mean for processes, agile development, digital twins, and all these technologies that everyone is talking about? The flip side is, "everything is fine with this software," but this software runs on all the companies that provide the hardware, and that's crucial for it. You can have the best software, but if your hardware can't support performance, power consumption, and all of these aspects, you won't succeed. As a result, the ecosystem is evolving the hardware, the software, and the way in which all of that is combined. OEMs want to be the central point. That's what we're talking about in terms of the process methodology that is driving this shift.

Gajendra: Where are we on this journey? How far have we come? Where are we going? Going back to the point I made earlier about the evolution of the supply chain, five years ago, if we were sitting in a panel like this and talking about software-defined vehicles, the conversation would be completely different. It's going to be stuck in the traditional supply chain that we've seen in the automotive industry for the last 35 or 40 years. There are basically two aspects here. The supply chain is constantly evolving, and we as a community, such as this team and many others in the community, working together to develop products will be key to partner satisfaction. Using virtual platforms in the cloud today to try to shift left and develop and validate some of these technologies and software didn't even exist five years ago, so we've come a long way. Together, we've made a lot of progress as an industry. Yes, we still have a long way to go before we can truly have a truly software-defined vehicle. We can go to the dealership and ask for a software-defined vehicle. But we're seeing various technology providers struggling to make sure that the technology that we end up having in the hardware is available in some kind of virtual form, whether it's a fast model or any form in the cloud, which is a huge change for the vast majority of software ecosystems in the automotive space. I'm in the embedded world, and the number of virtual platforms and demos that people are actually showing — like our chip partners here, Intel, Renesas, Infineon, EDA Corporation — shows a strong movement to let's build an infrastructure, we can build the infrastructure, and then provide the infrastructure to the OEMs, there's a lot of work going on. Together, we'll build a comprehensive infrastructure that's richer and more powerful, whether it's a virtual platform or something else.

Alpert: Of course, OEMs have to take their own destiny into their own hands. In the past, they would do this by differentiating, perhaps because they had better engine performance, or some other feature. But going forward, the differentiator will be in their software. Whoever develops software that provides additional value and builds a brand will stand out from the crowd, and that's the trend. Shared ecosystems are important in terms of how to achieve this. SOAFEE IS A POTENTIAL WAY THAT, ALONG WITH A VIRTUAL PLATFORM, YOU CAN PROVIDE A SHARED DEVELOPMENT ECOSYSTEM, BUT STILL ALLOW FOR DIFFERENTIATION AND PLUG-AND-PLAY FOR EVERYONE. That's one of the reasons why we've worked closely with Arm to try out a reference design specifically for this purpose. But again, we're not saying that's the design you're using. The point is, let's start somewhere, and then people can start exchanging pieces and doing different things. As long as OEMs can plug and play, they can still differentiate. But they don't have to invent everything themselves, otherwise the cost is too high.