Moving Software-Defined Vehicles Forward

Experts at the Table: The automotive ecosystem is undergoing a transformation toward software-defined vehicles, spurring new architectures with more software. Semiconductor Engineering sat down to discuss the impact of these changes with Suraj Gajendra, vice president of products and solutions in Arm’s automotive line of business; Chuck Alpert, R&D automotive fellow at Cadence; Steve Spadoni, zone controller and power distribution application manager at Infineon; Rebeca Delgado, chief technology officer and principal AI engineer at Intel Automotive; Cyril Clocher, senior director in the automotive product line for high-performance computing at Renesas; David Fritz, vice president, hybrid and virtual systems at Siemens EDA; and Marc Serughetti, senior director, systems design group at Synopsys. What follows are excerpts of that discussion. Part one of this discussion is here. Part two is here.

L-R: Arm’s Gajendra, Cadence’s Alpert, Infineon’s Spadoni, Intel’s Delgado, Renesas’ Clocher, Siemens’ Fritz, Synopsys’ Serughetti.

SE: A very important aspect of an SDV architecture is safety and security. How will this be included with SDVs?

Serughetti: Safety and security are two critical elements. Safety is obvious. We’re talking about people’s lives. How do you bring this into the car? How do you validate it, and verify it along the way? How do you enable the hardware to do that? The other part is security. When you think SDV, it also means the architecture will have a massive consolidation around the ECU and the chips that are being used. That has a direct impact on the security, because now you have more software, you have more attack points on that software. There’s more surface on which you have security concerns. Those aspects are absolutely critical in the development of SDV. I use the word ‘development’ because that’s also something important to look at in the context of SDV. You have the development part, which happens before the vehicle is shipped. But this is just one piece of it. As the vehicle is being maintained, what we’re starting to see on the software side, and that’s one of the mindset changes. How do you start detaching the software development from necessarily being attached to a specific standard operating procedure on the OEM side? Those are pieces that come together — safety and security — which are very critical parts of the SDV development and deployment process.

Spadoni: The challenges in the implementation of software-defined vehicles are really on the software side and the DNA of the companies trying to do it. These OEMs are mechanical-centric, and they’re also vehicle-centric. They think in vehicle milestones instead of software developments. I see that some of them are starting to decouple that so they have software milestones that are decoupled from vehicle milestones. Their prototypes are starting to become more like a phone would be, like the iPhone, but that’s in the beginning stage so it’s not universal. Everyone’s at different stages, and it’s very interesting to watch, but it’s also causing a lot of delays. There are a lot of programs that have been delayed because of software development.

Delgado: One panelist at the recent SAE World Congress said the amount of vehicle recalls has gone up since the software complexity has risen. I agree 100% that safety and security are absolute musts in automotive use cases. We can separate a little bit on the context of mixed criticality, and the very tight deterministic workloads. There’s an element of software-defined that speaks to having the right workload in the right socket. Then there are going to be areas of high-performance compute necessary to deliver to the user experience. And in this evolution of centralization, everybody’s talking software-defined. Everybody’s talking about central compute, about safety and security. The reality is there is a variable of time in terms of where we are at today, in levels of centralization versus where the industry needs to move to — slowly but surely, and painfully, maybe. But some of the technologies that exist as part of the software-defined requirements around virtualization are necessary to be enforced down to the hardware level to ensure that partitioning, to ensure the mixed criticality is preserved. And when you can trust how the operation is going to happen, then you can focus on efficiencies, which are paramount to this scaling across all vehicle levels, and then to manage the lifecycle of these technologies. So all of these are very traditional IT concepts, and these comments I’m making in the sense of mixed criticality is the only way to go in centralization. But it requires foundational silicon-level enforcement that a car is not a tablet. A car is absolutely a machine that’s delivering experiences, but more than anything, the main use case is transportation in a safe and secure manner.

Alpert: One thing I haven’t heard yet is the word chiplet, which I’m surprised about. Without chiplets, SDV doesn’t become a reality. And the reason is because it allows people to plug and play. I want to have a low-end chiplet for a low-end vehicle, or higher-end one for a high-end vehicle. It also allows different vendors to compete. But the key thing there is you have to be able to plug and play. You have to have common interfaces like UCIe and standards, which will define that you really can plug and play and things will just work. I thought about this whole chiplet idea that you decompose the problem. We used to have another term for that many years ago — chips. And then we said, ‘Let’s do SoCs. We can combine all of it.’ Now we’re basically going back in the other direction. What’s enabled that are advances in packaging and 3D so that you can improve the interfaces between the chiplets now and you can go back to this decomposition model just in time. The second thing to mention in terms of software-defined architectures is that nobody here wants to see car vendors pay for lots of copper. We’d rather them spend their money on silicon than copper. A zonal architecture allows you to save a lot of the wiring. Plus, copper is really heavy. The final area is safety. That’s an interesting problem, because we want to keep the costs down, and for those of you who are at ASIL-D, which is in the ISO 26262 standard everybody is applying, the easiest way to achieve it is redundancy. Instead of one chip, you have two chips. But two chips or two cores is very expensive. It doubles the area. The key is how to use tools and technology to achieve ASIL-D with much less area and power and cost savings. In our functional safety solutions we’re definitely eager to put together a way for companies that are building silicon to achieve that cheaper.

SE: What needs to happen in the short term to move SDV forward?

Fritz: Cultural mindset was brought up earlier. These companies still have model years they have to generate revenue from, and the skill set to deploy SDV is very different from the conventional approach of electro-mechanical. The OEMs need to get to the point very quickly where they say, ‘We have two paths, and at some time they will converge.’ Until then, they are very different. They are organized differently — different operational procedures, everything is very different. Otherwise, it’s not going to happen. If they go incrementally they are going to continue to have more and more recalls, because they’re trying to stretch beyond what the hardware or software can do. So they need to adopt that approach. and we’re seeing some that are thinking about it.

Delgado: The most immediate goals here are to truly collaborate with the right ecosystem partners to deliver solutions to the OEMs so they can evolve in a multi-generation approach. This is where it’s critical. And this has always been Intel’s approach. We helped other industries participate with an open approach, open compute APIs, and then scalability to the chiplet offerings that were mentioned. Intel is the first company to announce an open platform where the ecosystem can bring chiplets ahead of all standards being defined. This collaboration is key to truly delivering the efficiencies necessary in the technologies that already exist in the marketplace.

Gajendra: Standards and collaboration, that’s really key. Short-term, we’ll have to align on this. We have to then build the higher-level infrastructures across the board based on that.

Serughetti: I agree with what has been said about standard collaboration. You look at everybody on this roundtable and we’ve done collaborations. We compete, but we work together, as well, to serve the industry. That collaboration needs to continue and needs to serve the market. And I agree with David — all this can be very nice, but if you don’t have the change happening on the other side, nobody is going to take it in. There needs to be an evolution in those OEM companies. At the end of the day, it will happen because if they do not change, there are other people who are making the change. Just look at what’s happening in China. That will be forced on the industry, and it will be survival mode at that point. So yes, the mindset of some of those companies has to evolve, and for some of them it has to evolve very fast.

Clocher: In this panel, there are a bunch of partners of Renesas, and we cannot build our product if we don’t get the right IPs from Synopsys on time on top of what we are developing. And then, on the other side, we are evolving and changing the way we are developing software in hardcore silicon companies. So that’s also part of the transformations of a company that used to develop chips, develop SoCs, now working on chiplets. For all of the industry, it will be a success if we all either lease or buy those objects for a bunch of money. It can be SDV, or another technology that has value. With all the technology we are developing together, from the software and hardware, the OEMs have to open their minds and bring value for you and me when we go to the dealership and spend $20k, $30k, $40k on those vehicles. That’s not our job. But together we need to deliver this technology so the OEMs can do a better job and simply leverage this future SDV platform and turn that into new features and new user experiences.

Spadoni: From an Infineon perspective, the most pressing thing that was mentioned is mindset. And it’s not just mindset from the OEM perspective or even the Tiers. Their organizational structure has to match that. It doesn’t at this point, and in order for SDVs to become a reality faster, that has to change. There are a lot of competitors doing that in different parts of the world, and everyone’s noticing that.

Alpert: The mindset is a great point, and it will happen. For the companies where it doesn’t happen, they won’t be around in 5 or 10 years. But it’s also about the speed. How long does it take to design if it’s a 5- to 7-year lifecycle to build it. This whole shift left and virtual platforms must happen, which means collaboration standards have to happen. The company that tries to do everything themself will not survive. They have to be able to collaborate, but then figure out the ways that they can differentiate. Whoever figures that out will win.