Auto Ecosystem Begins Shift To Software-First Transition

Experts at the Table: The automotive ecosystem is in the midst of an intense evolution as OEMs and tiered providers grapple with how to deal with legacy technology while incorporating ever-increasing levels of autonomy, electrification, and software-defined vehicle concepts. Semiconductor Engineering sat down to discuss these and other related issues with Wayne Lyons, senior director for the automotive market at AMD; Judy Curran, CTO for automotive at Ansys; Amit Kumar, product management director for Cadence’s Compute Solutions Group at Cadence; Adiel Bahrouch, director of business development for silicon IP at Rambus; and Marc Serughetti, vice president, product management and applications engineering at Synopsys. To view part one of this discussion, click here.

L to R: AMD’s Lyons, Ansys’ Curran, Cadence’s Kumar, Rambus’ Bahrouch; Synopsys’ Serughetti.

SE: With the future of vehicles centered around software, where do automotive OEMs stand today in their ability to be software-first versus hardware-first?

Serughetti: They’re still very much in a hardware-first mentality. They need to move to a software-first perspective. What does that mean? The hardware platform is critical, but the approach must change from, ‘I’m building a hardware platform, and hopefully I will run some software on it and things will work.’ The thinking must be, ‘Here is the software I’m going to run. What is the best hardware platform to run that software and offer all the services I need to have?’ We know today, for example, that one of the biggest issues traditional OEMs have with their architecture is over-the-air updates. They are not able to control how the over-the-air update is happening because it’s distributed all over the place. There are security issues to take care of. The architecture is just not scalable, and they will have to transition on that side.

Bahrouch: It comes down to a scalable hardware platform. The E/E architecture and scalable system is the baseline, and the wish is to have a software layer that is common for several brands/OEMs, because eventually it comes with a cost. It would be great if OEMs would collaborate to justify the investment, but also to accelerate the development. Once you have a baseline E/E architecture, baseline hardware and software, then every OEM could differentiate through the applications for, let’s say, the look and feel for every single OEM. That’s the goal of a number of those big players with a lot of brands — to make sure that when it comes to over-the-air updates, the underlying hardware is uniform, the software is uniform, so the over-the-air update would only focus on that application for any feature upgrade and so forth. It’s a dream, but that’s probably the strategy of a number of those OEMs.

Serughetti: We talk about how the hardware must evolve, but the software must evolve as well. Even today, there is a lot of [software] like AUTOSAR, but we’re starting to see that market transition as well, as far as the operating system being used. On top of this, it’s about hardware, software, but also the way they develop those systems must completely evolve. We’re seeing all these OEMs have created their software/hardware internal team, like the Cariads of this world, and the Toyota Woven at some point. They created teams that are struggling today to figure out how they going to do that.

Curran: One opportunity for the industry is that currently everybody is doing their own architecture. I looked at our customer base, and I’m probably supporting 50 OEMs. I can’t even believe there are 50 OEMs now, but it keeps growing. Every OEM is thinking through their own architecture, but the industry really counts on the supply base. You guys who are in the supply base already know that, and it’s a weave of OEMs and supply base. It’s much more cost-efficient for the supply base if the OEMs would have some common pieces of the architecture, and that also would add robustness to the selected architecture. And if we really believe that the DNA of our vehicles will be in these software features, there should be a common part of the hardware architecture that we all can agree on so the OEMs could focus more on their unique features. That would be a giant step forward from the chaos we’re seeing, since it is an industry that in general doesn’t really get together for commonality. There are a whole bunch of consortiums that have tried to do that, but no luck so far.

Lyons: I agree. We do see common themes, though, in hardware. In hardware, we’ve got to implement high levels of safety in the next-generation platform. That goes without saying. ASIL B through to ASIL D on our next-generation platform is like table stakes. Table stakes now also includes ISO 21434 from the security perspective. We’re implementing application security units, as well, to enable this layering of the software. So there are some standards out there on the security side, which help. On the security side it’s starting to catch up with the safety side. And it does help to have these standards there, from a hardware manufacturer perspective. But you’re right, it doesn’t go all the way up to the software layers. We’re enabling hypervisors now, like Xen, the open-source hypervisor, to enable this kind of sandbox of virtualization for software between software boxes. But today there’s very little standardization in the way that will be implemented from one carmaker to another one.

SE: How do we move the standardization forward especially when most everyone recognizes the benefit of it?

Kumar: Regulation.

Curran: I didn’t want to say that, but that does seem to be the one carrot that makes us all behave the same.

Kumar: Unless it’s a regulatory chair or a committee that’s driving standardization, everybody would like to provide their own value, and for good reasons. Whether that value is good from an industry standpoint, or a unification of the architecture standpoint, we can all take our common guesses. But regulation is of top importance.

Bahrouch: This is a very strong point. When I was part of the evaluation lab and security, we did a lot of statistics and assessments, and it comes down that 85% of the industry would only go for security because it’s regulated. It’s regulated, it’s mandatory, and if you don’t comply, there is no market entrance. If there is no market interest, there is no business, so it’s a very straightforward business case. No compliance, no business. You still might go for security because of due diligence or to differentiate, but regulation is key here. If things can be regulated, then things will be accelerated.

SE: How are OEMs grappling with the transition from hardware-driven vehicle architectures to software-driven vehicles?

Serughetti: That’s one of the problems. They’re grappling with it, but they’re having quite a hard time on that side. The pendulum is still swinging. Two years ago, OEMs were saying, ‘I’m going to do everything. I’m going to do semiconductors. I’m going to do software. I need to own the software.’ What we’re seeing now is maybe that pendulum swinging back a little bit the other way, and the OEMs are now asking, ‘How am I going to do this? What needs to change?’ It’s really a digital transformation that needs to happen for them. It just doesn’t happen in one day. Of course, as you think about this, you need SoCs that are more powerful and that have more capabilities. We talked about AI and all those things coming in. You need a software development infrastructure that is in place. There are a lot of technology aspects, but there are also methodology aspects and organizational aspects. All of those need to evolve. The tooling that goes with that asks, ‘How do you start integrating all that enterprise software?’ We’re still in an embedded world within the car. How do you start looking at the embedded aspect and the enterprise software development aspect, and bring those things together? These are things that have been solved in other industries. We just must figure out how to apply this to a specific domain of the car — an embedded system that’s distributed, that has safety and security requirements all together.

Kumar: The level of inputs that a car company wants the consumer or third parties to access in their vehicle is also different. A lot of traditional companies would not give you access to the depth of your vehicle’s software architecture, so you would probably stay at a layer. Maybe there are some car companies that are giving access to a lot deeper layers of software so that you can tweak things and install things that are helpful?

Serughetti: It’s really a mindset to add on the mindset. It’s how the industry transforms. We talked about standards being one way, but there is also collaboration. Before, it was very siloed. Where are the parts where the industry should differentiate? Where are the parts where they should collaborate? That model must change, as well.

Curran: As far as my experience working with the OEMs, now as part of Ansys, they are stepping back and looking at their distributed architectures. We have some tools that they use — MBSE type tools– to help them decide what their next architecture will be. I don’t see them jumping from this very distributed architecture to this complete zonal architecture. It is too big of a jump for a lot of the traditional OEMs, so I see some stepping stones. I also see the conversation that someone mentioned, where they are starting to realize they can’t do it all themselves. OEMs, in general, can never do it all themselves, and that’s why there’s this giant supply base, and there is a lot of discussion of what we will do inside the OEM, and who we will partner with, and if you’re going to partner now with these Tier One suppliers, you would need to give them more access than you might have had in the past if you have a more zonal architecture, because they will have to be more aware of the full system than just their little component that they’re used to being a part of. We help a lot of suppliers now with encrypted models of their hardware so the OEM can do the software they’ve decided to do in-house using these encrypted models. That’s one example of how they’re working better together. There’s also now a marketplace, because if you’re going to have these larger supercomputers/zonal computers, you need all the software from those distributed modules. So there are now marketplaces being developed, like SDVerse and others, where I’ve heard a large Tier One say, ‘I’m willing to sell my software.’ In the past, they would sell the module with the software. Now they’re willing to sell their software. So there are different business models that must be developed that include copies of the software, encrypted models, tighter NDAs than ever before, bigger partnerships than ever before to make that work.

Lyons: You’re right. This software market is the one that will probably emerge over time. We see that with Tier Ones today. Tier Ones that we’ve worked with over the last 15 years on ADAS are looking to modularize that software now and sell it as a component within a larger high-performance computer in the vehicle. And there are initiatives. We’re a part of one called SOAFEE, where that consortium is focused on modularizing and delivering microservices running on the edge so they will be containerized. That would lead to the kind of marketplace that Judy mentioned. SOAFEE 2.0 then expands that concept to enhance the cloud side, so it can be emulated and have a digital twin in the cloud, as well. So there are initiatives, but none of them is legislative. They’re all consortium-driven today.