Automotive software delivers vehicle functionality, changing vehicle development – The Future Car on E/E Systems – ep. 5 Transcript
In our fifth episode of the Automotive E/E Future Car podcast series we continue conversations around the evolution of vehicle architectures, electrification and the challenges of bringing them to life.
We are privileged again to speak with our experts, Doug Burcicki, Automotive Market Director for the IES team at Siemens, and Dan Scott, Marketing Director for Integrated Electrical Systems at Siemens Digital Industries Software. In this final episode of the Automotive E/E series we wrap up our discussion on the future of automotive E/E architectures, E/E systems development and the automotive industry. We talk about the growing role of software to deliver vehicle functionality, and how this change may affect vehicle development. We hope you enjoy it!
Check out the transcript below or listen to the audio podcast.
Read the transcript:
Conor Peick: Throughout this conversation, we’ve been talking a lot about the evolution of the E/E architecture and the rise of software. And there’s this concept of the software-defined vehicle that I was hoping to get your perspective on. Just as an intro I wanted to say I found a definition of it on an active blog, and their definition says, “A software-defined vehicle is a term that describes a vehicle whose features and functions are primarily enabled through software, a result of the ongoing transformation of the automobile from a product that is mainly hardware-based to a software-centric electronic device on wheels.” So, from that definition, maybe just in broad strokes at first, do you agree with the definition? Are there points that you feel are, if not inaccurate, may be incomplete?
Doug Burcicki: In general, I agree with it. I don’t think anyone can refute that more content is being provided by means of software as opposed to an electromechanical or hydraulic type of functionality in the vehicle. In some cases, content already exists but is not being used. But when an OEM decides to use it, they can turn it on with software. A good example of that is Tesla recently activating the driver monitoring systems in their vehicles. So, there’s been a camera in the vehicle from the time the vehicles were purchased, but it wasn’t activated or used – the interfaced subsystem was not activated. Tesla knew they would have that functionality down the road, and when their software was ready, they would activate it. So, that’s just one example. But I think it’s indisputable that more of the functionality of the vehicles that we drive is provided almost exclusively via software.
Dan Scott: They had hardware that took up space and weight in the vehicle that they didn’t immediately use, but they still put it in the vehicle, going through all theextra work, the cost, the homologation, the testing – they put it out into the market and fingers crossed, knowing they will find a use for it later. I think that’s interesting. Again, back to the culture thing, it’s an interesting approach from a company, which is not like a traditional OEM, getting back to that inverted commas traditional OEM. That is quite a different approach, isn’t it? To be able to do that with some things like cameras and stuff, those are not necessarily super cheap components. But yeah, I agree with their definition, you read, Conor, in terms of it being a software-centric electronic device on wheels. It sounds super futuristic, and there’s still a box of that software and electronics it has to kind of sit in. I’m sure all the body in white engineers and the interior guys, and everything like that will be shouting at the podcast at this moment, of how important their bits are, but yeah, just like Doug said, there’s that inevitable trend, isn’t there? It’s that increase of the software defining much of the functionality that customers care about, whether that’s talk maps in an engine, obviously, it’s not just the software, it’s the whole system that we kind of keep coming back to. It’s like that double EE system or even that wider mechanical integration. The electronics and their hardware. And you must have all of that working together. That’s the optimal way you deliver those features. But undeniably software and electronics is an increasingly important part of a vehicle.
Doug Burcicki: To your point, Dan, it’s interesting to see a company put content, especially content that is not as cheap as a camera into a vehicle with anticipation that it might be used down the road, and not with it being activated and used from the first day that the vehicle is purchased. And, as you said, traditional OEMs are very averse to putting any giveaway content in a vehicle for obvious reasons. You’re giving away cost that you’re not recurring. And the only time they do that is because economies of scale justify it, you know, the investments that produce the greater volume of parts offset the incremental cost, and they do it and it eases their complexity, and they give away that content. At the end of the day, that same decision had to be made about the camera from Tesla. And in their minds, they have a business case that justifies giving away their content, knowing that they would get a return on that investment down the road when they activate the feature and initiate it via the software. So, my expectation is that you’re going to see a package, if they haven’t announced it already, of some sort of driver awareness, or driver monitoring system that you can subscribe to or turn on via a lump sum fee. And it’s a different feature than you were paying for, enabled by software, maybe years after the vehicle purchase. So, that’s a perfect example of the giveaway strategy, maybe changing because of the software. If you think about a complex sensor, like a camera, and putting one of those for free in a vehicle, it seems like an exorbitant amount of money. But if you have the scale to do it across the board, and you only have one design that’s going into these vehicles, as a result, maybe that enables that type of approach, as opposed to having 15 variants in your design with various combinations of sensors within the vehicle.
So, there’s many trade-offs associated with the design process, the suppliers’ cost back to you, as well as the end-vehicle manufacturing assembly process that can be impacted by software. I think one thing that’s important to note is we call them software-defined vehicles because so much of the content is provided via software. An underlying aspect of that, though, is inherently having the over-the-air capabilities because of having more software, which means the more bugs you’re going to have to address – it just goes without saying. And you’re going to have to patch and fix those bugs. The more data you have flying around these vehicles, the more data coming in and out of the vehicles and traveling around within the vehicles, especially when it comes to the availability to make purchases, you’re providing financial transactions over these networks. There are many privacy issues, so security is clearly a number one concern for the OEMs. And they’re constantly going to be monitoring these vehicles and providing updates and security patches as a result. So, it’s never-ending. These are living entities. And as a result, I kind of refer to the software-defined vehicle as a fine line, if you would, in the sense that it’s not like the vehicle of old where the finest day it ever saw was the day you drove it off the lot. And from that point on it slowly erodes over its lifecycle. You have the ability now with over-the-air updates to improve vehicle performance, improve vehicle quality, as that car ages on the road, that’s something that you never would have thought of, at least, what I never would have thought of any other vehicle that I have bought previously. So, it’s very exciting to see this scenario. But then that’s just ongoing customer satisfaction and quality of the product that has nothing to do with additional revenue or the business model. So, with that same over-the-air updates capability, you can turn on these features, or turn off these features, allow people to buy a feature or functionality for a set period. If I want to take my family camping and my EV pickup truck for the weekend, and I want a three-inch suspension lift, and I want to have different torque capability so I can go climbing on rugged terrain, I can pay for that functionality via software updates for a week or a month.
Dan Scott: Yeah, that’s right. I mean, it really does open quite different business models and a lot more of the stuff we see in terms of subscription models and Software as a Service type things that we see on kind of internet services and those sorts of things being rolled out into vehicles exactly like you say, you just buy a feature for a couple of weeks, and it’s time-bound and switches off after that time. I think that’s extremely interesting.
Doug Burcicki: Yes, but some of these packages can be bought annually, or monthly, or you can pay one lump sum and have a feature reside in your vehicle from that point forward, then the OEMs are going to do what the OEMs do, right? Well, when you buy the vehicle, you get a discount, but if you decide to buy it six months later, it’s going to cost a bit more. If you do it on a subscription, it’s going to be a little bit more as well. And they’re going to placate those desired purchase models. The great thing is the consumer has the flexibility to do whatever they want – they can purchase it for a month, they can purchase it for a year, or the entire life of the vehicle. And then even if you go to sell that vehicle, you can turn features on or off and the person who buys that vehicle can then modify it as well, which you could never do in the past if you bought a used car. So, it’s just a very different dynamic to the decision-making process.
Dan Scott: Yes, very interesting, isn’t it? In that sort of like resale, you can imagine selling the same vehicle, being worth different amounts, because it’s got nine months left on its subscription. In the same way, you have an MOT or whatever it’s called. You know, you get a little bit more money for that, “Oh, well, I’ve still got six months left of the altering feature on this vehicle. So, that’s worth more than the equivalent.”
Conor Peick: Earlier we were talking about EVs, and how it kind of frees up the design space or the packaging, if you will, for the designer. Can software do something similar in terms of how the vehicle is designed and packaged, and then, of course, sold?
Dan Scott: So, it drives you down to more of this sort of modular approach to the hardware, where it’s slightly more interchangeable. Yes, you’re able to get software from multiple sources. Can you imagine even having like an app store for the vehicle, where it’s like an equivalent to Apple where they kind of validate every bit of functionality that’s described, and actually your kind of “open-sourcing” your vehicle functionality, where enthusiasts can kind of write code for a particular feature which they know about, because the hardware is there but your engineers happen to not have thought of it. And so maybe you end up with some of these secondary type markets as well.
Conor Peick: There could be almost a resurgence, or maybe not a resurgence, but it’s a new take on the aftermarket vehicle customization, whereas instead of buying a spoiler, or whatever you want, it would be like a software package.
Doug Burcicki: Back to your fundamental question or the base question about the software impact on the physical structure of the vehicle? Yes, it absolutely does have that capability. If you think about it, most vehicles today are a series of thousands of discrete wires connecting modules, and switches, and sensors to each other, with the software functioning along with a combination of hardware and electronics. But you can eliminate large chunks of that wiring and send the same signal on communications back and forth between those modules over multiplexed networks, thereby eliminating huge pieces of the wiring. And then you can distribute your functionality, moving these modules around to the loads that they’re located by and then do your hardwiring from those distributed modules to the respective devices or loads. And that will eliminate a large amount of weight mass associated with the traditional wire harness. The problem is that the vehicle architecture, and the vehicle development cycle, at best case is a two to three-year activity. It’s not done in six or 12 months. And we all know the consumer electronics and features and functionality associated with it move at a much faster pace.
So, I envision a future where you’re going to have these distributed architectures with potentially very little core wiring from module to module that takes care of base functionality on a vehicle but much additional feature content – that next generation of high-tech functionality and devices that will be integrated into a vehicle that will be connected through these dedicated wiring systems until the next generation where they’re further integrated into the overall vehicle architecture. So, it will be a constant evolution of incorporating the latest features with a more traditional commodity, cost-effective type of wiring solution, as opposed to a full vehicle solution. And I think there will be a balance between those two going forward. However, there’s always the price point trade-off: at what point is that multiplexed system that’s predicated on software, hardware and electronics cheaper than a simple copper circuit to connect those devices with the same level of functionality; that’s the trade-off that the OEMs are always trying to make. Furthermore, when you see these architectures that are software enabled, it’s not just a cost assessment that they’re doing. It’s an assessment about the whole vehicle structure, the design complexity and even down to the impact of the manufacturability of the vehicle because that’s such a huge aspect of concern for any OEM. Even at Tesla, their relative complexity for an OEM in comparison to a GM or Ford is minuscule, yet their biggest single challenge in launching was building vehicles. It’s kind of hard to build vehicles, it’s not something you should take for granted.
Conor Peick: Absolutely. The manufacturing aspect is so huge, and just hitting the scale you need to make a lot of these things economical for the company.
Doug Burcicki: We tend to talk about technology and capabilities, which is great. But a lot of the capabilities we’re talking about have technically existed for 15, 20, and 25 years in some cases, but they weren’t cost-justifiable; so there was never a motivating need that would cause you to spend as much as it would cost to eliminate or simplify your architectures. But now we’re getting to a point where there is a compelling reason to reevaluate and recreate your architecture because of the business changes that are going on. Like I’ve come back to multiple times, at the end of the day it’s not the technology that’s driving these changes, but the technology that enables these changes, and the business models that are driving these changes.
Dan Scott: I have to say one thing that we haven’t really touched on as well is kind of things like legislative drivers. I’m thinking about autonomy and electrification, as they’re going to be some of the big drivers for vehicle development and probably EE systems and the redundancy that is required legislatively or level of functionality to be provided. So, we know where and when you can incrementally turn on various levels of autonomous functionality. I think governments just have a massive part to play, obviously, in driving all these things forward because the OEMs and car companies respond to those big drivers and they’re obviously large global companies. So, what happens in China is just as important as what happens in the US or Europe. And changes in one place have a big impact on vehicle design. And that’s historically always been the case, whether it’s ensuring kind of crash safety zones. So you end up with bonnets, that kind of all look pretty similar, because of certain constraints and areas where you can’t package things and stuff like that. They’re just quite unknown. I think, particularly around the autonomous it feels more so than electrification because it feels like there’s a gradual trend and just an increasing desire to reduce emissions, reduced CO2, all those sorts of things. And the pace of that, I guess, it’s a little unknown. But the autonomy feels like is the one way. It’s the legislation side of it is just a lot less developed and there’s a lot more risk, I guess, for companies in terms of how that is going to develop, which will obviously drive business models and technology development team.
Doug Burcicki: That’s a good point, Dan, the legislation piece because there are so many unknowns. And quite honestly, it’s like some of the governments, particularly in North America, seem to be of the mindset that it’s not at a scale that it needs to be addressed by the federal government at this point. So, instead of getting ahead of the curve, and defining regulations and guidelines that drive the industry, waiting for industry to figure it out amongst themselves. And historically, in the automotive industry, that’s a slow road to progress.
Dan Scott: Rather than being forced.
Doug Burcicki: Yeah, I mean, I don’t want to oversimplify, but I would say that German OEMs, when it comes to areas of standardization that helps speed development or common critical requirements that impact the common supply base, they tend to do a better job of getting aligned and driving those requirements as opposed to in North America where it seems like they tend to focus on their more immediate needs and what’s best for their current business, as opposed to broader industry standardization and commonality. And I mean, it makes sense, everyone’s got to focus on their current profits, and what’s driving their development priorities and standardization with industry players is rarely at the top of the list.
Conor Peick: So maybe just to kind of wrap up the conversation for today, I wanted to ask about just the pace of development overall, and how it’s going to change over the next ten years. I think a common trend has been that it’s accelerating, but is there a limit to how fast can it move between developing the product and getting it out to market?
Doug Burcicki: There’s always going to be a limit. Time is a limited commodity, so we can’t keep reducing to the point of it taking no time. But there’s always going to be marginal gains at a minimum. You’ll always be able to improve some percentage. But I don’t think we’re there yet. We are still in the phase of rapid improvements. We have customer testimonials that, through process, reinvention, tool implementation and automation have been able to reduce certain development phases by as much as 50 percent. And these aren’t hours or days, but weeks’ long activities. So, there’s significant opportunity out there. And I believe we’ve just started to tap into some of the areas where we can reduce development life cycles. There are certain areas that people have not focused on as much because it has been perceived as not having as much of an impact to the total lifecycle improvement, but all of those areas will get flushed out in time. Even when I started in the industry, people talked about four to five-year vehicle life cycles, but now you’re looking at two to three-year life cycles. So, I’d like to think by the time I’m retired in 10 years or so, that we’re talking about an 18-month life cycle on vehicle development.
Dan Scott: Yeah, I think exactly like you say, Doug. I mean, we haven’t even touched on the whole impact of things like AI and other real machine learning and assistance, and how that might impact development. So maybe that is one for another podcast, but yeah, I think even in automation, there’s so much in the industry where there’s still huge gains to be made in terms of automating processes and using people where they can add the most value, whether that’s creative or innovative. There’s still so much manual development that happens in engineering, whether it’s on the documentation side, in the design, or the testing, there are lots of manual steps in those processes. So, we still have a ways to go in terms of accelerating these areas. And whether they use that to reduce the time for vehicle programs to get to market, or whether they use it to add more features and functionality into a vehicle, I guess different OEMs will have different answers to these issues.
Conor Peick: This seems to tie into the whole idea of the software-defined vehicle, because we talked about building content into a vehicle that you might not enable until sometime down the road. How does that play into this change in development cycles?
Dan Scott: Because you are decoupling the feature completion from startup of production. You can have like a large backlog of features to implement; but you can’t get those implemented in the next two or three years of this vehicle program. So, maybe you’ve got six years’ worth of features to do, using software, and half of them are going to come out afterwards. However, you know those features will be release some time in the future. I think that decoupling of hardware and software will have a radical shift, changing customer’s expectations. Because again, if your car can’t have all these updates, that’s going be looked on negatively, I would expect, by customers as well.
Doug Burcicki: The only other thing I’d throw in there about the software-defined vehicle, is the software that’s resident or running on the vehicle and defining its functions. The software helps define the vehicle, right? Helps define, design anddevelop that vehicle. I think that the software impact of development tools, or the impact of software-driven development tools, is far more substantial and going to have a much broader impact on the design process and result in timing associated with it for these OEMs. So, we talked about the cultural change in the past, and it drives business decisions, but it also drives the way you develop your product as well, and that’s going to be a very big challenge for some of the legacy OEMs. It’s not there right now. They don’t lack technology. They don’t lack capability. And clearly, they’re way ahead of the new entrants regarding quality assembly at scale, especially on a global footprint, for most of them, but they don’t have that mindset that some of the startups do and the willingness to tear up a process that’s existed and served them for decades.
And where they have committed to doing that and committed to changing and improving themselves, they’re not sticking their head in the sand; however, it just takes time. So, where they are committed to doing it, they acknowledge it’s going to take more time than these startups for obvious reasons. But that doesn’t mean that they don’t realize it needs to be accomplished and that they are moving down that path. But my point is, when I hear software-defined vehicle, I look at it from not just the features that the consumer buys, but the ability to develop that vehicle.
Conor Peick: Yes, it involves the underlying process as well.
Doug Burcicki: Absolutely.
Dan Scott: That’s a very good observation, Doug, in terms of that software-defined vehicle, because it is these kinds of tools and pieces of software that I’ve enabled so many advances in terms of being able to perform simulations, or the analysis, or the design work or automating so much of that stuff. And I think, there is that aspect that the tools must develop, must advance and must continually progress for OEMs and organizations to make these technologies work and to develop the technologies as quickly as they can to make this software-defined vehicle a reality.
Doug Burcicki: Yes, and again, that goes back to where we started this whole discussion about the workforce, the skill sets and the people. Quite honestly, you mentioned automation, and there’s tools that are automated to do simple tasks, and that you wouldn’t necessarily want your skilled workforce spending their time on if they don’t need to do it, because it’s not adding value or creativity to the work product. So, when you’re running those engineering teams, you want your engineers to be maximizing creativity and optimizing aspects of the design, not pushing buttons on the computer entering data or making sure it’s accurate. The whole development process is becoming more software-driven, not just the vehicle product itself.
Dan Scott: Yes, that is changing the nature of skills, isn’t it? Because even in the electrical and harness industry, it is being able to shift from engineers needing to be great at drawing out massive, big harnesses to being able to manage data. And the design rule sets to support some of these automated tasks that change the nature of this process with the skill sets and the way, as an engineer, you must think about your role and what you’re doing and how you develop it. And that’s just one simple example, but you can see that replicated across various other domains as well, where the nature of what you’re doing as an engineer is changing slightly, and it’s much more about you interacting with the software tools and using them to best augment your abilities.
Conor Peick: Awesome. Thank you, guys, very much for the discussion today.
Dan Scott: Thanks, Conor. That was fun.
Doug Burcicki: Thank you, Conor. Thank you, Dan.
Conor Peick: So, the software-defined vehicle is an important trend in today’s automotive industry, not separate from, but intertwined with the other megatrends of electrification, autonomy, connectivity, and shared mobility. The technologies underlying these trends all rely on sophisticated software applications to enable both basic and advanced vehicle features and functionality. For example, electric vehicles need battery management software to maximize range and optimize the charging and discharging of the battery. Even cars that you can go buy today contain over a hundred million lines of software code, managing everything from the powertrain to your heated seats and smartphone connectivity.
Automotive companies are responding at all levels, from increasing their in-house software development capabilities, to developing closer partnerships with suppliers and integrating software development more tightly with other engineering domains while also decoupling its implementation from the hardware. How are they doing it? Digitalization. Digitalization across the enterprise is allowing these companies to manage complexity, accelerate development and monetize innovative technologies and products.
Thanks again for joining us for our deep dive on automotive E/E systems. If you’d like to learn more about our electrical systems solutions, please visit siemens.com/ee-systems. I am Conor Peick, thanks for listening.
Siemens Digital Industries Software is driving transformation to enable a digital enterprise where engineering, manufacturing, and electronics design meet tomorrow.
Xcelerator, the comprehensive and integrated portfolio of software and services from Siemens Digital Industries Software, helps companies of all sizes create and leverage a comprehensive digital twin that provides organizations with new insights, opportunities and levels of automation to drive innovation.
For more information on Siemens Digital Industries Software products and services, visit siemens.com/software or follow us on LinkedIn, Twitter, Facebook and Instagram. Siemens Digital Industries Software – Where today meets tomorrow
