Strategies for bringing software-defined vehicles to market – On the Move S01E08 – Transcript
Below is the complete transcript of season one, episode 8 of On the Move: A Siemens Automotive Podcast. It wraps up a three part discussion on the role of software and electronics in modern vehicle development. Read the whole conversation or listen below.
Mike Severson
It’s time for another episode of On the Move, a Siemens podcast for the automotive and transportation industry. I’m Mike Severson, joined by my co-host Nand Kochhar, This is the last episode of our three part series on software defined vehicles and autonomy. We’re joined by Michael Munsey and David Fritz for our conversation on electronics, software, and the SDV.
As autonomous vehicles encounter the many edge cases in the real world, what are OEMs doing to incorporate unpredictable road situations? Dave, maybe you could start with this one.
David Fritz
Sure. Several years ago, the hype curve on autonomous driving was very interesting, where the hype was very high on the scale and the ability to deliver was very low. And we’ve seen that in electrical industries for quite some time. Any technology tends to go through that hype curve where the early adopters want to get out there early and some companies get out there with solutions. And it takes time to work through all those issues. And, you know, Tesla is known for that being a first adopt, a first driver of the industry for electric vehicles and for their autopilot. as a primary example. So what we’ve seen lately, however, is that there’s this sort of glitch in that process whereby the ability to deliver hasn’t really kept up at all with expectations. Instead of the curve coming down precipitously, as often is the case, it’s kind of stretched out and skewed a bit more right. So the belief and the understanding that, quote unquote, autonomous driving as a consumer would see it seems to be further and further away. But what we’re seeing is those companies that are really dedicated to delivering a high level of autonomy have stopped talking about it, stopped hyping on the curve, and instead of taking things internally and got really focused on engineering. And as you mentioned, one of the things that they’re concerned about are all these corner cases and the impact of liability on not being able to meet those corner cases. So again, SDV as a methodology and digital twin as a technology under SDV is the ideal solution for that. The concept is if you can use some high fidelity simulation, not only of the vehicle and the components of the vehicle running real software loads and running that in a realistic environment, which is virtual, primarily in the cloud for scalability. And it is that scalability that’s required here. And that’s why you’re seeing announcements with multiple cloud platform partners to implement and deploy this. But with that level of scalability, then instead of having a dozen cars on the road, driving 90% the same routes every day, collecting data, hoping to encounter corner cases, we can now use tools and run many hundreds of thousands of scenarios overnight in a short period of time in that scalable cloud environment with a high-fidelity digital twin. So we can encounter those complexities much earlier and those failures. And not only that, using a lot of our software-defined system-aware technology, we can identify where the failures happen, which requirements have failed. And then when the engineer comes in the next morning, they can start working on how to resolve those corner cases. All that happens long before any vehicle is on the road. But then you’ve spent a lot of time, effort, and money working in the digital twin, the virtual environment. How do you convince yourself that all of those tests provide a lot of confidence that the physical vehicle itself is going to perform similarly in a real situation? So the latest phase that we have been announcing, and we saw some of this at CES just in January of this year, was we could actually take the digital twin running in the cloud, running real scenarios, and then sending all of the control signals to the physical vehicle. So it is a half step towards the correlation between the virtual world and the physical world. And then the last step is we’re taking all of the hardware that’s been designed in that environment, all the software that runs in the digital twin environment, and putting it in a vehicle and running the vehicle through the very same scenarios, particularly the corner case scenarios, that we have been running that vehicle through virtually for quite some time. And we put that vehicle on the track, we instrument its behavior, and we correlate the behavior of the physical vehicle against the digital twin, and either the digital twin or the physical vehicle changes. So this whole step of prototyping and driving millions and millions of miles on the road turns out with this SDV digital twin environment to not be necessary to the same degree. You can start thinking about best case, worst case, nominal case on the road instead of trying to find every case and using Monte Carlo-like simulation capabilities and hoping that your vehicles encounter those corner cases. It becomes an engineering problem and not a statistical problem.
Michael Munsey
And it doesn’t even have to be limited to things like autonomous driving, right? The whole idea here now is that you could catch a failure in the field, right? If it happens once, it’s a nomonaly. Sorry, an anomaly. But if it starts to happen a couple of times, there could be an underlying issue in the engineering somewhere, right? But the fact that if you start catching these issues early, bringing them back, writing a fix for it, simulating in the cloud, as David just said, You could actually head off a costly recall by proactively fixing it and pushing these fixes to the field and catching these edge cases early, right? So I think the important thing here is that it could be an edge case not only for ADAS, but it could also be an edge case for normal operation and just start to eliminate some of these costly recalls due to software errors or software interacting with hardware and proactively fix them based on real-time data coming from the field.
David Fritz
Yeah, that’s a really good point, Michael, because what we have actually seen is if you’ve used this digital twin methodology to define the entire car, then you have a digital version of what is actually in the field. So there are many times there’s a failure in the field that it’s almost impossible to debug exactly what went wrong, but you can take the instrumentation data from the field and play that back in a digital twin where you have a lot more visibility, a lot more flexibility, and then it’s much easier to diagnose problems in that environment than it is in the actual field. And like Michael said, it doesn’t have to be autonomy. That could be just general operation or an over-the-air update that’s gone out and only a few vehicles have failed. Why? And with a digital twin and instrumentation and a physical brought into the digital twin, you can figure that out much easier.
Nand Kochhar
A very important point, and it goes beyond autonomy, going back to recalls, which is very important to avoid for automotive companies. Looking at the NHTSA data from 2023, about 18% of the, and also 2024, 18% of the recalls were software related. So in 2024 in the U.S. alone, there’s 27 million units recalled. And you can imagine it’s a big number. And average repair cost is anywhere from $300 to $500. And you can see how it adds up to millions of dollars, avoidance, cost avoidance, and also the quality improvement and the customer satisfaction. So those are all the opportunities possible through SDV, digital twin technologies going across not only just autonomy, but other failure types as well.
Mike Severson
Is it fair to say that this digital twin can both accelerate the fixes out in the field and also the development of autonomous like we were talking about earlier? So is it accelerating these fixes?
David Fritz
Yes. The real question is the rate of adoption of the methodology. Again, like we said earlier, that is regional at this point, and we’d love to see it be accelerated elsewhere. I think there’s no other way to compete globally than adopting this type of technology.
Michael Munsey
I agree.
Mike Severson
And has this led to a shift in just-in-time manufacturing with OEM starting to take into account the possibility of supply chain disruption in electronics manufacturing?
David Fritz
My view on that, and I’d love to hear everyone else’s view as well, is that when you have the digital twin capable of modeling all this, you also have the ability to say, if I have a supply chain crunch in one area, what are my alternatives and what are the impacts of those alternatives on the functionality of the vehicle as a whole, as well as the individual ECUs? Which is a critical question because then you know what your second and third level supplier possibilities are, and they may have different levels of availability. And because of that, then you can make an early decision who your primary and secondary suppliers are going to be long before you actually have to have those parts in hand.
Nand Kochhar
Yeah, Michael, building on David’s response, in addition to that, having a library of those parts, including the performance characteristics, allows when those disruptions happen, what are the alternatives? So I think having this digital twin technologies helps link the parts and the performance characteristics in your database, and then you can make those trade-offs and make those decisions fast.
Mike Severson
is this leading to a shift in how companies manage the electronics and software from a service perspective. there’s a legal requirement that oems have to make parts available for a number of years after job last. is is there a shift here? and if so what is the shift how are they handling this for software and electronics.
Nand Kochhar
Yeah, in today’s requirement, as you know, there’s a sort of legal requirement to maintain 15 years or sometimes longer, depending on the country, parts and service. That’s on the pure mechanical parts. Somebody has to track physical storage of different model years, these parts. But now it becomes even more important. That’s what companies need to think. having this twin technology will be the only way to prove that because now you need also the software versions of what are out there, different model years. So it’s the length, how long you keep the parts, but now you have to maintain what software versions were on those parts. And within the softwares, when they’re working on electronics, there might be a bunch of other things needed from a middleware perspective and other technologies which enable that. And now, David mentioned in one of his answers, you want to make sure when you do these updates down the road that they work on all of the units, not just they fix part of the problem and other vehicles are still having problems. So now you imagine it’s tracking of the software versions over multi-years, mapping of that to the hardware, which physical parts you still need to retain, And when it comes to software, also the cybersecurity side of keeping track of that on the different versions, all those things become important to meet this requirement, which today is basically on the mechanical parts only. In the SDV world, it opens up even much bigger than that. So that’s what is changing and shifting. Automakers have to think through, plan, and adapt digital twin technology so they can adapt these changes both on the software and hardware side.
Mike Severson
And lastly, is there anything that interests you about the convergence of automotive electronics and software that we haven’t covered? Or is there something else that our audience should know about developing software-defined vehicles?
Michael Munsey
One of the things that jumps out to me is, first of all, the notion of software actually defining the value of the automobile that you’re buying. And this is true of most software-defined products, but the notion of unlocking future value through software. One of the things that’s probably easiest to do first is that instead of developing, let’s say, three or four different semiconductor devices that all do various different things, it’s a lot cheaper for these companies to develop one semiconductor device and manufacture one semiconductor device, but then unlock different features and functionality through a software layer at first. So that becomes a way of simplifying the number of parts and the number of configurations that you have to worry about and then adding that software layer to actually unlock value later on. But then there’s the whole notion of upgrading functionality in the future strictly through software and actually driving new value into an older platform through new software functionality that could come later on. You know, I liken it to having your cell phone. And when you do an upgrade, you actually have a better cell phone later on, not just because of the software layer, but because of the way the software interacts with the hardware, where you could do an upgrade and have a better noise cancellation capability on the microphone that’s in the phone or take better pictures because of better DSP algorithms. You know, just being able to deliver increased value and increased functionality through a software platform is going to be a huge shift for the entire industry.
David Fritz
I completely agree with Michael on that. But going just a little bit deeper, why is that the case? It’s not just because of smartphone technology and that’s driving the expectations of consumers. But it’s also as a result of some reports that I’ve seen that they’re projecting that around 2030, the vast majority of profits in an automobile are going to go to the chip developers, not the OEMs. So they have to find new business models. There’s no way around it. And what we talked about earlier about custom SOCs and for chiplets, packages, 3DIC, that sort of thing, is there a way to get back into margins that they can take advantage of on the hardware side, but software is going to be the big differentiator there. And therefore, if you’re going to differentiate with software, then in reality, you’re going to have to differentiate into hardware to match that. And that’s really what’s driving the direction things are headed.
Nand Kochhar
Yep, I agree with both the comments. So the convergence is coming. Looking at some of the latest publications from Deloitte, they’re requesting automotive OEMs who are not considering this change going on in the industry, but get on that path for a five to 10-year journey, because it’s not something you just get it done in two months, two quarters, that have plans for that kind of shift, which is happening in the industry, bringing together of these three industries talked about.
Mike Severson
Big thanks to you Nand, David and Michael for taking the time to have this discussion.
And thank you for listening. we hope you enjoyed the conversation. You can find other great conversations our back catalogue. Don’t forget to subscribe to get new episodes when they are added. We hope to have you back soon for more great automotive conversations.
