Managing Legacy In Automotive

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, software defined vehicle concepts, just to name a few. 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.

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

SE: A lot of technology development for the automotive industry is overlapping and interdependent. How are automakers and the semiconductor ecosystem that serves the automotive industry addressing legacy?

Lyons: What is legacy? What will be supported? What will be carried forward? Today we’re seeing baseline features in ADAS, airbag deployment, and on forward-looking cameras. Automatic emergency braking is a function that’s mandated by legal regulations, and lane departure warning, as well. When you look at some of the higher-end ADAS features around things like changing lanes, there are additional features that carmakers can implement and add in. But there are some baseline features, as well as a lot of body control features and convenience features they want to bring in and continue, without having to reinvent the wheel there. So legacy remains important. I’ll call it mature software rather than legacy, because a lot of the time it’s based upon software that’s been certified. Here, it’s the ISO 26262 safety certification level. They don’t want to get rid of that in some cases. And so there is a lot of need to bring that forward. But a lot of OEMs are looking to reinvent and redesign their platforms, as well.

Curran: In thinking about the life of a vehicle — and the average age of a vehicle now is 11 or 12 years — customers are purchasing this for 20 years. As an industry, we want to do over-the-air software drops. Everything we design from a hardware perspective and a software perspective needs to have a long life — longer than what we’re probably used to in other consumer electronics. So that’s a challenge. As a result, the industry is having to upsize their architectures and their hardware, which in the past was also unusual. As a vehicle line director, you try to get the last penny out of a car before you send it out. Now, you’re thinking through what you’re going to need for 10 or 20 years. That thought process is much different, and they’re going to have to trust that they’re going to be able to get payback from upsizing their software. Then, as far as what they’ve released in the past, that’s going to be a huge burden on the resources, because even with the distributed architectures they have today in the software they released, and the fact that they can do some over-the-air software, that is going to take too much time. I’ve already heard some OEMs are giving payments to customers in exchange for not updating something any further, because they can’t continue in the past that long and at the same time plan too far in the future.

Serughetti: There’s another part to look at in the market, which is the segmentation of the automotive companies. The people that are going to have the power now, the traditional OEMs, the people that are building new architectures, they are building architectures and vehicles to sustain that software and all those things. They don’t deal with the legacy. So this is a big challenge for the existing OEMs. It’s how they want to deal with the transformation they have to go through now to stay competitive and set a path forward that keeps them relevant. How do they keep track of all that legacy they have? Today they are having major issues in that transition, because they are trying somehow to bring legacy and new things together, which makes the problem much harder than looking for new things and starting from a blank sheet sometimes. It’s an integration problem at the end of the day. It’s how to bring the old stuff together with the new, and how to validate all this together. That’s where the problem is for a lot of those companies.

Bahrouch: The majority of vehicles nowadays still rely on the traditional distributed and domain-based E/E architecture, which is designed to optimize costs, with cost as the driving factor. This includes the selection of the sensor sets, the selection of compute performance, the memory storage. Everything is selected in a way to have a cost-effective solution, where the hardware and the software are very tightly coupled. So it’s about a cost-effective strategy, but it’s almost impossible for any updates or upgrades. It’s definitely not for in-field vehicles on post-production. Now, we see the move to the next-generation centralized E/E architecture, where the focus is to decouple the hardware and software. That allows feature upgrades and so forth. It will come with some challenges, and obviously the cost will increase. To make it happen, the underlying hardware must be oversized in a way — over-specified. But since 60% or 70% of vehicles nowadays still rely on the traditional, distributed and maybe even domain-based E/E architecture, this legacy is always there. It’s going to be tough to make that transition to the architecture, where the hardware and software are decoupled, and software updates will be easy to manage throughout the lifecycle of the vehicle.

Lyons: Adiel makes a good point there. There’s this whole inflection point with electrification and autonomy. New car companies are coming in that can build a whole new platform from the ground up. You’ve got the existing carmakers that need to compete, and are taking control of this, bringing the development in from the Tier 1s. But they don’t have an infinite amount of time. They’re on a very strict regimen of delivering car model years one after the other. So in a lot of cases, they must make these tradeoffs and choose which features to redesign and which ones to bring through with them to hit these annual model year deadlines. They would like to re-architect the whole system, but in some cases it’s not feasible or practical given the timeline.

Curran: We used to have a very strict regimen when vehicles would be launched. It was rare as a vehicle line director or chief in the industry that you would not launch your vehicle close to when you told your board you would. I just recently read that close to 50% of vehicle programs today are missing their launch date. So even though we haven’t fully re-architected everything, just the current churn we’re in, whether it’s the new employees, the new processes, they’re unable to launch on time. That is really impacting the financials of the OEMs, as well as the suppliers. So that regimen we used to have is not being hit, and it might get worse before it gets better.

SE: How does legacy impact the software?

Kumar: The dependence of the current software with whatever existing hardware has been deployed in the legacy systems is another consideration. The data formats could be different when it comes to software implementation on the newer architectures. The second thing is that the diagnostics that were there in traditional cars where you need to put in your OBD2 to get the data, you can get that data now from a connected vehicle. However, I think you still need that OBD2 port as a backup, as a part of your car, in case the telematics unit goes down, or if your vehicle needs some kind of a repair to extract that data. So, even though we are moving toward software defined vehicles, there are some basic legacy components that the OEMs might still say, “This is how I perceive it,” and the transition from the software that’s running on the legacy hardware that was 15 years old, 20 years old, things have changed. A lot of computations today are based on AI-based or dealer network-based models, and it takes time for everything to migrate from one platform to another.  I’m not sure the traditional automotive guys, especially those companies who have been there forever, can move that fast compared to the newer companies that we see mostly in the Bay Area.

Lyons: What’s interesting is that’s influencing the hardware design, as well, from a device/chip/semiconductor perspective. Our latest product has 10 times the processing performance of the previous generation because of this migration toward software-defined vehicles. But we were implementing cores there like Cortex R52s, which have hardware virtualization, because you still need to bring with it these kinds of sand-boxed legacy or mature operating systems, or software blocks, in with it even though you want to lay a lot more software into the overall platform. So I completely agree. They must make these tradeoffs in terms of delivery of the platform.

Bahrouch: When it comes to the combination of advanced SoCs with multi-core CPUs, NPUs, AI capabilities, and so forth, and at the same time leveraging the legacy, there is still this cybersecurity issue that comes with it. In Europe, there is the UNR 155 cybersecurity regulation, along with ISO 21434, which will hold the OEMs responsible for cybersecurity postures. So now you will see a number of OEMs that have difficulty in maintaining the cybersecurity posture of those legacy OSes, legacy components, or even legacy product lines of certain brands because of the legacy issues. There are tough decisions made to stop a product line and start a completely new product line just because of the cyber security regulations and compliance.

SE: What else besides on-board diagnostic ports need to be maintained over time?

Curran: The goal of a software-defined vehicle is very much needed, and it fits the vision of where the customer would like the vehicle, as well as where OEMs would like to make incremental money after they sell the vehicle. Getting from where they are today to that goal is going to require a lot of different changes. One change would be determining what would stay and what would go. Another one of the changes will have to be the complexity. When I think back on the complexity of the offerings we would have on a vehicle, from a low- to a mid-range, to a mid-high, to a high series, with all the different features, all the different combinations, there would be 100,000 combinations of vehicles we could build on one vehicle. To validate all that is a lot of work, and it’s not clear that the customer would appreciate all that complexity. We spend quite a bit of time with OEMs going through architecture choices, and once they have their architecture, getting through their feature offerings. But how are they going to offer their features so they can minimize how many variants that they would need? Then, somebody mentioned regulation. The industry continues to sell in 100 to 200 countries around the world, in which there are different regulations, and there is homologation required of that software and hardware. Again, if you can get to a lineup that is reasonable, and then virtually be able to homologate, that would help the end goal. Those are all big changes in the way they currently do their business, but I think those are steps that need to happen for this all to be realizable.

Lyons: I agree. And when you talk to different carmakers, they have different care-abouts, as well. Every OEM has signature features or capability. It could be the comfort and convenience features they offer. If it’s more of a sports car, it could be the handling, the drive experience, or it could just be that they deliver class-leading safety features and best-in-class safety features for the driver. They are all influencing which features they want to focus on, and what drives that software development. But absolutely, they also need to simplify this platform. Otherwise, they’re not going to be able to deliver the number of SKUs that they previously did.

Related Reading
Balancing Programmability And Performance In Cars
Customization and adaptability are essential for software-defined vehicles, but there’s a price to pay for that flexibility.
Pressure Builds To Adopt Virtual Prototypes
Creating complex multi-chiplet systems is no longer a back-of-the-envelope diagram, but viable methodologies are still in short supply.
Legacy Process Nodes Going Strong
The critical, and growing, significance of mature node chips and processes.