Defining the software-defined vehicle – On the Move S01E06 – Transcript
Software and electronics are drastically changing how vehicles are developed. To walk through how this is shift is impacting OEMs, suppliers, and the tools they use our host of On the Move – Nand Kochhar – sat down with Michael Munsey and David Fritz for a three part series. You can listen or read the first part of the conversation below.
Mike Severson
Welcome to On The Move, a Siemens automotive podcast where we explore the automotive industry, uncovering the trends, driving its evolution. I’m your host, Mike Severson, and as someone deeply passionate about automotive and the future of mobility, I’m thrilled to be here. I’m joined today by my co-host Nand Kochhar, VP of automotive and transportation, and we have some exciting guests. First, we have Michael Munsey, VP of Electronics and Semiconductor Industry. Also joining us today is David Fritz, VP of Virtual and Hybrid Systems. Very exciting. Today, we’re diving into the critical and rapidly expanding role of software and electronics in modern vehicles. In our three part series, we will explore how these technologies are reshaping everything from vehicle design to driving the customer experience itself. So, let’s get started. First question, software is and will be a key factor when it comes to competitive differentiation in the automotive market. Nand, how are automotive companies and the wider industry activities shifting to confront this change?
Nand Kochhar
Yeah, thank you, Michael, for introduction. As you mentioned, software-defined vehicle is one of the key initiatives at major OEMs and the entire ecosystem. And most automotive companies all over the globe are shifting their activities in all aspects. What I mean by all is organizational, how they work, how they work in their ecosystem. They are getting ready, getting prepared, and shifting to that at a very fast pace to confront these challenges.
Mike Severson
So as we talk about software-defined vehicles, we cannot forget about the impact on hardware. Michael, our electronics expert, how does this evolution of software impact hardware and electronics?
Michael Munsey
Well, it kind of turns everything upside down from the way things have traditionally been done. You know, when I was a semiconductor designer, you know, typically what would happen was I’d be given a spec and I would start designing my semiconductor. And then a couple of months down the road, I’d get a phone call or email from somebody in the software team starting to ask questions and, you know, software would start to be developed. That’s not the way things work anymore. Right. And what we’ve seen is the idea of, you know, common compute platforms that you build software on top of. All that’s going by the wayside because the fact that almost every single product out there is software defined. You know, whether you’re talking about your mobile phone, whether you’re talking about an automobile like we are today, that the way you interact with the product, the way you actually control the product is all through different software layers. And those software layers are so unique that it forces us to throw away the idea of the Common Compute platform and really focus in on developing a semiconductor platform that could support the software layer that needs to be run on it. And the key word there is support because you can’t think about designing something that ultimately is going to have a problem with the software workload. If your cell phone drops a call because somewhere there’s a software overload or you get the spinning wheel as your laptop starts to have to pause because it’s running so many applications, those are all inconveniences. But when you start to think about the world of automotive right now and actually designing the software-defined vehicle, if you have your processors lock up because of a software workload issue, then you find yourself in a position where you could kill people. So it’s critically important now that software take front and center and you design the software and you design the compute platforms all together to guarantee that you’re delivering something that could run the software, run the software in a way that’s safe and accounts for everything that needs to happen within the vehicles.
Nand Kochhar
Many of our customers who are working with their conclusion that software cannot be afterthought in the vehicle design. So, David, would you mind explaining why this shift is so important for SDVs?
David Fritz
Well, other markets have been through the similar transition that automotive is going through. And if you look at the lessons learned and best approaches that have been designed over time, the realization that it became very quick that you need to design the hardware and the software simultaneously. We like to say hardware and software are two sides to the same coin. They’re not two separate coins. And by that, I mean that the software workload will impact the hardware design and the hardware design itself will impact the software architecture and the workload that it can produce. There are many cases out there in the past from other industries. Mobile is a great example where large catastrophes have happened from the fact that hardware was developed separately from the software. The end result of not taking the approach, a new methodology called, in this case, software-defined vehicles, is that you end up having to design both the hardware and the software with technical margins to account for the unknowns that can’t be considered. And we have to break this whole concept of a catch-22, whereby how do you develop the software when there’s no hardware? And then how do you develop hardware to support the software and the software doesn’t exist yet? So SDVs is about bringing that together, breaking that cycle and allowing architectures and actual development methodologies to come together and address these issues, whereby you can determine very early on whether or not some of these margin requirements, time to break, for example, is a popular one, can be resolved very early in the process, and you know the impact of those design requirements on both the hardware and the software simultaneously. If you don’t do that, then you end up with a non-competitive product or lots of recalls, And that non-competitiveness can simply be you can’t meet a competitive price window or you’re missing features, so you’re not a differentiated producer or product anymore. Or in many cases we’re seeing these days, you’re not competitive either on price or features.
Mike Severson
Why can’t software features be designed independently of the hardware design process?
David Fritz
Well, it comes down to the fact, and this surprises us a lot as we engage with these automotive companies, it’s almost as though that there is a misnomer out there that if your software runs fine on your laptop or a server, it’s going to run fine in this highly time-critical, sensitive, embedded environment, which we call a vehicle. And that’s simply not true because as the hardware comes together, as we’re seeing consolidation between different ECUs, now we’re moving into the realm of these large systems on chip that could have 16, 32, 128 CPUs sharing multiple GPUs. You’re running hypervisors, running different operating systems with different levels of criticality support that needs to be there for safety and security. And all of those things at some point share resources. When you’re developing a software on, say, your laptop, whether it’s an algorithm or just a C++ application, you don’t have to deal with those contentions. And in a safety-critical environment like a vehicle, those contentions, those things that happen, the very slim margins that you have to break in time are critical. So having a hardware-software co-process from the very beginning is the only way that you can identify those issues and result in a much better product and get that product to market sooner and more reliably.
Mike Severson
Now, that’s really interesting. And this is really a big change from vehicle programs of the past. So Nand, how are automotive companies are adapting their mindsets, tool sets, and hiring to not only accommodate this influx of electronics, but truly leverage them for enhancing vehicle functionality and performance?
Nand Kochhar
Yeah, so very good point and the mindsets and the planning piece of it. So traditionally, automotive companies have been focused on vehicle architectures, right? Setting those up in a physical sense as a front wheel drive, rear wheel drive, what type of power trains, etc. But now in the software-defined world, they have to focus not only on the vehicle architecture, but also on the electrical, electronics architecture, and the software architectures. So you can see from the very onset of thinking through the process, you have to think all of these simultaneously. And you have to do the optimization of these at the architecture level up front so that you can make the right decisions while you move from architectures into detailed design modes, whether they are for electronics or whether they are for software. So I think you also mentioned in terms of the tool sets, as you know, auto industries, over 100 years old, has been some of those processes in the mechanical world have been set and streamlined, whereas bringing in software development methodologies, let me say agile software methods development, that’s new to many in the industry still. So the whole CI, CD, CC software flow of continuous integration, continuous deployment, continuous configuration. So you not only can develop the software mapped to the hardware, but also maintain that software and throughout the lifecycle beyond production and into the field. So you can see how the mindset becomes totally different of planning all that. Now, in order to do that, obviously, the hiring practices have been changing in the industry as well, trying to bring the software methodology, people not only from an educational perspective, but experience from the software industry into the traditional automotive industry, and then marrying those two together as neither one of them understand each other’s businesses that well. But now in the SDV world, electronics and the software and mechanical all need to come together from a cross-domain perspective. So it is a huge challenge and all of those being addressed in their respective areas.
Mike Severson
So, Michael, how does this semiconductor ecosystem interface with all these changes in automotive, the shift to SDV, etc.?
Michael Munsey
Yeah, so the change actually starts at the entire ecosystem level, right? And when we talk about the software-defined vehicle, fundamentally what that means is that we have to rethink the way that we do the entire system-level design. And at the system level, we need to really start to focus in on the requirements, but do it in such a way of optimizing the entire system. And then the idea is from there, we could start teeing up requirements for the software team, for the semiconductor team, for the ECAD team, the EE team, as well as the MCAD team for the entire product. But to make this work, we have to understand that we need to constantly refine those requirements as we start moving along. So when we’re looking at the system level and we then start to coalesce around what is this software defined definition, what does that look like, then we can start talking about software and semiconductor. And so the big change is we’re now doing software and semiconductor at the same time. You know, the software development isn’t following the semiconductor development. But in order to work, we need to continuously refine those requirements moving forward. And that also now requires that that semiconductor ecosystem is able to support the software development at the same time. And now we need to start looking at what we need to deliver to allow the software team to do that development. And that now means we need to create a virtual environment where the software team could start actually running the software long before there is anything tangible on the semiconductor side to start verifying against. So we have to set up an ecosystem where we deliver virtual models. And those virtual models need to evolve over time and increase in fidelity as we start doing more and more development. But keeping in mind in such a way that we still do the trade-offs that we need to at the requirements level and drive that throughout the whole development process.
David Fritz
Yeah, I’d like to add a little bit to what Michael just said. So when we talk about ecosystem here, we have to remember there’s several layers within an ecosystem. And every automotive OEM over the last 100 years has developed their own automotive ecosystem with their set of suppliers. And the way that these complex systems were divided out were through the tier ones and the tier twos. And they each developed a piece of the whole vehicle and they would all come together. And once they put it all together, nothing worked. We call that the integration storm. And that could account for as much as 50% of the total calendar time it takes to get an automotive car to market. And it is failures at those integration points that cause these recalls. So the whole idea is how do you make that transition that Michael was talking about? How do you change how these are all developed? How do you rework your ecosystem? How do you start bringing in other companies that have lots of experience in multi-billion gate systems on chip designs? And how does that fold its way into the automotive industry? So the automotive ecosystems themselves are turning upside down. And just recently, we’ve seen several announcements of tier one companies are struggling to figure out how they can remain a part of the whole solution. How do they find a way to take advantage of this new change that’s coming? we’re calling SDV. And the answer is they’re all gravitating to something that we at Siemens have been talking about for a long time, and that’s the digital twin. The digital twin is central to this. A holistic digital twin is critical. A not just holistic digital twin of the entire vehicle, but also one that is multi-fidelity. And by that, I mean that as your design of this next generation vehicle platform matures, the accuracy of the hardware modeling and the software workloads and all that mature together. And that goes back to what Nand mentioned earlier, CI, CD, CC flows are designed to iteratively improve that. And beneath all of that is your digital twin. Digital twin for managing the requirements across your suppliers and in your internal teams, But also running verification tests and showing failures, not just at, say, an ECU or a software functionality level, but across the entire system so that we can find those system level failures very early in the process. The ones that would actually cause recalls and other functionality problems much down the road once star production has begun. So digital twins are central to this. The realization of digital twins as being a functional methodology or central to a methodology for making this leap into a software-defined environment is now becoming reality. We had our Ford Mach-E, the PAVE 360 demonstrator at CES, and an executive from another company said, look at that. That’s the first digital twin I’ve ever seen. It actually does something. That might have been the only thing that he’s seen, but it really helped span that gap between what is a digital twin? How does it help me develop? How does it help me validate and verify? And how does it help me get away from these complex system and unit level problems that I have to deal with the old methodology? And that’s the core of SDV.
Mike Severson
Thank you David, Nand, and Michael. I think that summary of SDV is a perfect place to take a pause in our discussion. But there is still a lot we have to talk about on how companies are implementing SDV as well as what it means for the future of vehicle design, manufacturing, and service. We’ll be back soon to cover the role of transparency and the digital twin for On the Move. See you next time!
