Big Shift: Creating Automotive SW Without HW

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. To view part one, click here.

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

SE: What’s the best approach for developing a software-defined vehicle (SDV) platform?

Fritz:  It takes a multitude of companies committing to that. When we go into an automotive company and we start pitching SDV, the first sticking point is they need to change their whole internal IT infrastructure. If we’re running a virtual platform — or if we have some emulation that’s involved there, or whatever the solution is — it’s very different from their way of working, which is the hardware exists in a HIL (hardware-in-the-loop) rig. They do a little bit of modeling upfront, and then they hit the integration storm. So now we’re talking about continuous integration, continuous development, continuous verification, DevOps — all those types of changes that support Agile development. Agile development for many automotive companies is still a foreign concept. Agile development, in terms of the hardware and the software happening simultaneously, is about the only way to break this ‘Catch 22’ of writing software without the hardware. If my hardware depends on the software, as SDV implies, how do I build the hardware with no software? SDV is really about breaking that and providing the tooling and IT infrastructure to solve that problem.

Serughetti: A big part of SDV is infrastructure. All the companies here work on the infrastructure. That’s what we know. But there’s a piece that’s theoretical, too, which is the mindset of the OEMs. There are still a lot of people at the top of the OEMs who are mechanically oriented. They don’t understand how the whole software and electronics picture comes together. They have to change the way they think. Even today, when we talk about virtual platforms, there are still people coming from the hardware mindset, which is, ‘This is my hardware. The virtual prototype has to be exactly the same.’  No, you have to approach it from a software perspective, as well. When we talk about process, methodology, people, organizational aspects, these all need to change inside those companies. The technology will happen. We have a lot of very deep technology companies here. We know how to bring new technology together. That other part is something the OEMs have to do. They have to change, but it’s hard, because those are large companies and they have a business going. Everybody has the Kodak example in mind. Who will be the survivors? The survivors will be the ones who are able to adjust to those changes.

Delgado: I was on a couple of panels at SAE World Congress recently, and it was very interesting to see where we’re at and what it will take. The leadership was speaking to the problem statements of how the OEMs can survive and compete in this new landscape. There was an agreement about what it will take, that it’s hard, and there was a lot of the observation of the problem. If you think about Amazon and Netflix and Google, they all began delivering value on a software-defined architecture before they brought additional value on top of that. We’re almost there in automotive. We’re talking about infrastructure. But OEMs cannot own 100% of the software. It’s an insurmountable task. At the end of the day, you must allow the ecosystem to deliver differentiating skill sets and areas of expertise. So what is a software-defined vehicle? It’s a platform that requires an infrastructure, a culture, and different processes. The high-performance compute industry, already went through that infrastructure transformation of a layered redefinition of how you interoperate. Software-defined done right means an open architecture and open APIs to allow different ecosystem players to truly deliver value in the right spots. This allows for scale, for future-proofing, and then the ultimate element in compute, for performance. That is necessary for decoupling of Agile software functions to eventually be deployed in an effective way to the hardware assets — to the infrastructure. And correspondingly, it requires an infrastructure of virtualization enforced down to the silicon level. As well, it requires that ability to divide the roles and responsibilities across the industry. Historically, the industry has done this in a hardware fashion with many silos, but now we have to break it down to a horizontal perspective of the vehicle. That already occurred in the telco world, the networking world, the data center world. There was no other way to realize the value that had been software-defined, even in those industries, and allow the OEMs to focus on that differentiation. What’s required here are these layers, and a new perspective of the technology stack that has been brought to market.

Clocher: We all are talking to OEMs that are building product that can go as fast as 250 kilometers per hour on the Autobahn in Germany. One of the fundamental baselines they always will take seriously is safety and security. So all the things we have seen in other markets are certainly valid, as long as an ecosystem can take that to the next level with the right level of safety and security. We’re talking about platforms and systems that will range from quality management (QM) to ASIL-D. We all know how to spell ADAS. It is a great technology. But ultimately, on top of everything that has already been achieved in high-performance computing and various other markets, the complexity here is to do that with the right level of safety and security for automotive, and in an embedded system. We were talking about an embedded system — infrastructure, cloud, all the things that have to be deployed to make it happen. But ultimately, a car is an embedded system, and we need to do that with the level of complexity that combines embedded systems, low power, safety and security. And that’s really the challenge. It’s an exciting task, and something we always have to keep in mind.

Gajendra:  Fundamentally, this is about open standards — not having proprietary stacks, but having more standardization at the lower end. And then, yes, the OEMs will bring in the applications and other things. That’s what we’ve been trying to do, along with many people here, and others in the SOAFEE community. We believe that for a true software-defined vehicle ecosystem to thrive, there needs to be standardization of non-differentiating layers of the stack. I’m specifying non-differentiating layers, where the ecosystem and the partners can differentiate, but we don’t have to differentiate where we don’t have to. From a safety and security perspective, when Arm has some conversations with the OEMs about some of the foundational layers of system software, there are standards with respect to the Arm architecture, which can be followed and enabled so that a simple Linux boot can happen across the board for all Arm-based systems in a standard way. That is what we are pushing with all of the partners here, and especially in the Arm ecosystem. We drive power, performance, and area differentiation, specifically in terms of an AI workload, so let’s go race against each other and enable that. But let’s try to standardize some of the lower-level parts, because this is going to get harder when you think about mixed criticality.

Serughetti:  Mixed criticality is going to be a key aspect.

Gajendra: Yes. For example, I got a notification on my BMW app on my phone three or four months ago saying, ‘The RingGo parking app is available on your BMW console. You can download it so you don’t have to use your phone.’ You can use a parking app to pay for parking. Wherever your vehicle is, it will detect where you are, it will know the parking code of that particular location, and you just hit enter and the minutes that you want to park. But don’t get too excited. It’s been four months and I haven’t gotten it working yet. Nothing against RingGo or BMW. It’s just an example of the complexity. Again, the idea that the parking app has to be enabled and on only when the car is stationary. It can’t come on and interfere with any of the other safety critical applications when the car is running, when I drive it on the highway with basic autonomous features and situations like that. It’s complex, and mixed criticality is not easy. Hence, the foundations of standards that we drive as a community, which we’ve been vested in for the last four years as part of the SOAFEE initiative. And then, solving some of these mixed criticality problems is important. If we start differentiating up and down the stack and going crazy about it, the OEMs will not be able to even get close when these bigger problems come.

Read part one of the discussion:
Software-Defined Vehicle Momentum Grows
Challenges are massive and multi-faceted, but the auto industry recognizes the whole ecosystem needs to shift direction to remain viable.