In this eighth episode of the Model-Based Matters podcast series, our experts discuss how electrification is the most significant trend in the automotive and transportation industry, including trucking.
We are speaking again with Tim Kinman, vice president of Trending Solutions and Global Program Lead for Systems Digitalization at Siemens Digital Industries Software. In addition, we are privileged to talk with Nand Kochar, Matt Bromley and Doug Burcicki, also from Siemens Digital Industries Software, each providing their expertise on this subject. Join us as we discuss the future of MBSE and the role of ever-increasing complexity in electronics.
Check out the transcript (below) or listen to the audio podcast.
Read the transcript
Nicholas Finberg: Thanks, everyone, for joining us. We’ve covered a lot of definitions with our previous guests and podcast. And we just finished up an episode on continuous verification, specifically for the automotive market. We’ve talked about some of the trends in the past on this show, but there are some interesting things unfolding right now. Electric trucks are rolling off the lines, and it seems likemight even be the fastest-growing category in the coming years. There’s a lot of change happening in the automotive and transportation markets, and we’ve discussed a handful of these drivers. But what are you seeing as the trends right now?
Nand Kochhar: Good afternoon, thanks for having us. What we clearly see in electrification, by and large, is the biggest change of the trend going on in the automotive and transportation industry. A lot of different factors is driving that, both from a business perspective and in a technological and sustainability perspective. And that’s transforming the entire transportation system. It’s not only the automotive OEMs, but it’s the entire ecosystem and the supply chains that are being impacted. And, it’s not merely the automobile, but the trucking business as well, or in the heavy equipment arena. So, the electrification is touching all different modes of transportation, including aerospace and electric planes. So, you can see a big shift in the electrification arena.
Matt Bromley: I think it’s interesting to dwell on what Nand just said, and what that means from an electronics perspective. I think when we think of electrification, we always think of battery, motor – that clearly creates a focus on high power electronics. And that goes all the way back to novel silicon or novel semiconductor technologies – so, sort of gallium arsenide for high-power electronics. But we shouldn’t forget also that high-power electronics must extend outside of the vehicle. There is an impact on charging networks, for example, not only the ability to charge a car, but then the whole infrastructure that’s necessary to support it from a design perspective, and then as Nand was saying, that introduces a lot of business challenges to ensure those networks are in place. So, on the electrification side, from the electronics perspective, we see certainly a very large growing trend in high-power electronics. What’s interesting is to tie it back maybe a little bit into the MBSE side, initial design phase; how can I get accurate estimates of battery capacity versus motor power so that I can meet my target range? Range would be a classic example that is early in the design cycle. I want to be able to get range as a marketing condition, and so how can I get stimulation estimates based on some early estimates of battery and motor? We are beginning to see those conversations happen a lot more often.
Doug Burcicki: Something interesting that is going on in the industry, the auto industry in particular, but others as non-references; is the business models are changing. It used to be that the OEMs would sell a car and make profit on that car, and then they try to sell as many cars as possible. Currently, they’re monetizing the vehicles after the point of sale, generating an entirely different revenue stream. They can’t do that without a new EE architecture. And that EE architectures, as Matt’s was saying, has many finite pieces to it that contribute to many different trends in the industry; one being electrification; another being increasing levels of autonomy. But all of them are predicated around different ways for the OEMs to monetize the traditional business model a bit differently. And when you talk about companies that are having an impact on the industry, Nand mentioned the supply ecosystem, as opposed to what we used to refer to as a supply chain, and that’s because there’s more collaboration and partnerships.
This is another massive change in the industry. The pace of the technology implementations drives it. It’s much faster than you’ve ever seen in the industry before. So, many things occur that come into play but at different factors or different speeds. So, it’s an enjoyable time to be in the industry. I also think Siemens is uniquely positioned because there are many different facets to the changes taking place, and we can facilitate and provide experience to various areas. Many other companies don’t have as broad a vision or scope. There is a business change in the industry (just like Tesla, which was the first to monetize over-the-air) that is hugely foundational to the changes taking place because it drives new architectures, like EV, which impact the most change across the broadest categories – infrastructure, government and municipalities. So, companies must approach the vehicle design differently. So MBSE methodology is necessary because design complexity far outpaces what humans can keep up with, and you must take a more foundational approach.
Nicholas Finberg: So, software features are kind of the new flashy thing that gets buyer’s attention, but those require not only the high-power electronic systems that Matt was talking about, but the relatively low-power electronics to run all of the software capabilities to create what is essentially a mobile computer. And these changes start to alter the business context of what a transportation business provides.
Tim Kinman: I guess, to chime in, the computational demands of the vehicle is going up. And this is what’s leading to the consolidation of the location of the controllers, and the virtualizing of software to hardware on the PCVs. It is trying to make some separation between how do I move the computational emphasis to its point of decision – this is where we get into the whole sensor synthesis. And then you get the 5G onslaught going on in terms of connectivity and things I’m reading and watching – I’m hearing people say that once the 5G really started rolling out, we’re going to have connectivity: between the vehicle, your home, and your calendar, so the car knows where you’re going, because it knows which calendar it’s connected to. The car tells your home when you’re coming home, and it changes your lighting and your thermostats. It’s like a motion sensor in your life, where your vehicle is the driver. It’s one of the center points of that scenario. But then the demands of all this, what are you doing? How are you going to consolidate that computational power, create another energy consumption drain on the vehicle, create another weight element to the vehicle? There are all these dynamics of the competing requirements to the design and what it means, not just to the experience, but what it means to the other performance elements of the vehicle.
Matt Bromley: Yes, the complexity vector in the vehicle is exponential. Historically, when you looked at the complexity increase, you can almost view it within a domain in a linear fashion. I mean, I’ve got to use a faster processor, so what do I need to do that? Or I must use a different material, so what’s the impact of using that material? But now, in these instances, the complexity is so inter-domain, intertwined that you can almost view it as an exponential increase in complexity. And I think, as Doug said, that’s what stops it being tractable without having methodology built around that like MBSE to help manage that complexity. We have just touched on it – it has to take into account additional complexities. In automotive and anything that’s an over-the-air update, you’ve got this security concern; it must be secure at how it operates. When you look at all the sensor placements within a car, that Tim was just talking about in 5G, and we all know they have LiDAR and RADAR and visual cameras, etc. What’s the impact of the placement of those sensors based on the high-power electronics we were referencing? And when you’ve got magnets and motors spinning, what’s the impact on sensitive electronics next to that? It’s an ever-increasing challenge that must be managed. And as Doug mentioned, the old timeframes of car development in the last seven to 10 years, just shrinks and shrinks so that they must get them out in shorter timeframes.
Nand Kochhar: That’s a very key challenge Matt has highlighted. Complexity is a huge challenge for the industry, whether it’s automobile or any other transportation system. And what’s driving this is the trends we just touched on. These are consumer trends or societal trends, and they’re going to continue. We just touched on electrification, but it’s connected – just having smart products, whether it’s a car or your iPhone or anything else, like a home thermostat. This whole smart products connectedness, and we haven’t even touched on autonomy, and autonomy not only in the vehicle, but even in your factories – factories running autonomously and things of that nature. So, what all this is doing is adding, in one way, the complexity, and that becomes a huge challenge. And that’s where I think most of us have touched on the approaches like MBSE (Model-Based Systems Engineering) as it becomes necessary to solve this huge challenge of complexity. One of my favorites is in systems engineering, where you first must define your system. So, when we talk about autonomous and the connectedness, your system is not only just a vehicle, but also the entire environment: it could be a city infrastructure, it could be the buildings itself, and that becomes your definition of a system. So, how do you approach this to solve that problem? Or you could go in a traditional way, like the last 20 years in my experience of MBSE on a vehicle, where we treat body, chassis, electrical and electronics as a system – that was the definition of systems. Then we use MBSE methodology across the silos to solve problems. But guess what? Now with all the trends we talked about, those silos are becoming even broader, because they are going outside of the vehicle, connected to the city, connected to the building. So, that’s why I think, to Doug’s point, you need some methodologies. Without MBSE, you can’t solve these problems, or you can’t even comprehend how to approach them. So, you’d need a structured approach.
Nicholas Finberg: Yes, you need it In the mechanical, the electronic, the electrical and the software domains within automotive manufacturing and development. But you’re bringing in city planners, you’re bringing in the technology companies for consumers – that’s one of the really big trends that I’ve been seeing, too, of companies partnering to work on these new vehicles. You’ve got your Apples and your Googles working on getting the infotainment systems to connect people’s phones to their cars. But you’ve got other software companies and technology companies hopping into the automotive market. How is that mixing or picking up the industry, getting into this very new space for them?
Doug Burcicki: I think it goes back to that business model. That business model has changed so much and now the automotive market has a much larger capital value associated with it, because there’s a software revenue machine, so to speak. So, the OEMs, obviously, would like to retain that all to themselves, but when you have an attractive or growing market like that, there’s always going to be new entrants. Many of those new entrants are coming in from a much more agile background. There are tech companies, there are consumer electronics companies, or they have that development culture within their operations or their DevOps activities. And they move at a much quicker pace than the OEMs do. And then you also can’t diminish the fact that the traditional OEMs, not the stars, but the traditional OEMs, they’ve been historically mechanical companies for decades – their development process, organizational structures, their validation activities are all around mechanical-centric systems. The electrical systems have been kind of an afterthought, so if you think about it, 15-10 years ago, when you had a system or a function, you had an ECU to a car. They’re developing brand new architectures to capture this new revenue opportunity, but they’re trying to go electric at the same time, and they’re trying to keep up with the ability to deliver features and functionality or software. These mechanical companies are trying to become software factories at the same time. So, it’s a monumental challenge, and you’re not going to do that on your own; you need partners, you need a collaborative network. Some of your partners may have been your former competitors, or maybe you’re willing to collaborate with certain areas, maybe you’re going to collaborate on a common skateboard powertrain. But everything aside from that, in your vehicle application, it is “Game on.” There are different business models as a result. You see a company like Tesla, and they want to vertically integrate everything that’s substantially important to their IP, and design it in-house, and give very little outsourcing in that regard. Or, then you look at a company like a Fisker, who basically is a designer of a vehicle and a badge, but they’re outsourcing software development, vehicle integration, manufacturing, and their dealership network. So, it’s an entirely different business model. But they wouldn’t even be there if there wasn’t this growth in the market, based on the software business and the software revenue stream that’s been generated.
Nand Kochhar: That is a very interesting point that Doug has brought up a couple of times around business models. So, even the financial markets are rewarding the technology companies when they’re getting into this kind of business, because the automotive business is still very strong. And then traditional OEMs see that, and as you touched on in the opening, cars are becoming software on wheels. So, now you see an amalgamation of these two industries coming together from that perspective. And again, the customer is traditionally used to looking at an automobile in terms of horsepower, performance, zero to 60, and things of that metric nature. Today, new consumers are also looking at the human-machine interface, what kind of experience they get out of this and at many other factors, which kind of translate into they’re looking for features, functions, and being willing to pay for those features. In case of autonomous driving, it just starts with, “Hey, I’m going to give you adaptive cruise control, so you could have a really comfortable experience driving on the highway under that adaptive cruise control.” And that’s a feature. Now, the carmakers can sell that as a feature and generate revenue. So, you see, things are changing. And that’s the example, that many things are heavily driven by electronics and software and the control systems. So, suddenly, the paradigm shift from getting a better suspension system or just getting a better body structure, has also shifted into “Hey, to deliver these features, what else is needed?” And that is the software and electronics.
Tim Kinman: Nand, I’m glad you said that because I was sitting here thinking exactly what you were saying, that many analyze information, but technology is not necessarily going to be the differentiator. Technology still can differentiate, but largely experience is going to be the differentiator. And that’s where the Googles and the software companies are coming in. It’s almost like an iOS for the vehicle. They’re going to come in and say, “I want to install my iOS.” It will be a Google or an Android versus iOS type of battle. They will be fighting for the experience. And then when you get into that, of course, software is the big player. And virtualizing software so I can have those rapid updates, or run that software at a fast cycle, and have it on a vehicle. The hardware elements: the battery electrification, the wiring, runs at kind of a different development trend. I saw another one that said 90 percent of auto innovation is now coming through software. So, when you think about what’s coming, it’s going to be driven through software. And to drive that software, the computational power is going to directly affect what happens in the whole electrical architecture, and the distribution of the computational, as well as the distribution of the actuation of the vehicle. So, a lot of stuff is going on. But you hit it spot on – it’s going to be driven by experience and software.
Matt Bromley: I think there’s some good corollary to that, and what is an incredibly robust product lifecycle management. Because now when I’m doing over-the-air updates of software into a vehicle, I have to be 100 percent certain that I know the configuration of the vehicle that I’m doing the update. And I must be incredibly sure that I know if there’s been any aftermarket update performed to that vehicle that might compromise that over-the-air update. And that’s a very complex product lifecycle management challenge. And the other is, as everyone has said, the ecosystem is broadening and there is a much broader ecosystem of participants – maintaining the development phase, the digital thread of the vehicle and the digital model so that you can get the necessary verifications. This is another area where a good modeling solution is required. Therefore, if I’m working with an outsource partner that may be developing software, they need to know, not only the requirements, but must have a very fluid communication that what they’re developing is going to be compatible with the multidomain ECU capabilities. And, as Tim said, the multidomain ECU capabilities don’t only impact what’s running on that software, it impacts the entire vehicle because now I’ve got trade-offs going on that I’m trying to manage between multiple software elements that are running on a multidomain ECU at the same time. And that level of complexity requires a continuous digital thread and continuous check on architecture that you can validate against. I think that’s one of the key areas where MBSE can come in and play an important role, not only in a vertically integrated solution like a Tesla, but one that’s more horizontally pulling in OEMs and Tier-1s, and other partners, who are all contributing to that vehicle at the same time.
Nicholas Finberg: Exactly. How do you ensure they’re talking within the right context and doing so consistently? How does a tiny change make its way through the development processes in case it has ramifications on another process or system?
Tim Kinman: But you’re driven by safety-oriented features and more of the experience. So, there are certain things that we’re dealing with that are all about societal things. We want to drive down the number of deaths and injuries; therefore, having assisted driving is a good thing. And that’s where we bring on the sensor technology and sensor fusion and how it helps us deal with these kinds of fatalities and injuries. So, that’s all-good stuff. Then there’s the other element that says it’s the experience. I get in the vehicle, and today, simple things like my Bluetooth connects my phone and everything is in my configuration. Today, in a very limited way, my configuration is going to be that my song list is available. But what they’re heading to is that it could be different – your lighting could change because you like blue rather than red. It could be that what you see in the dash is completely different because I chose configuration X for my dashboard. Just like you know another simple thing about my seat button. For me, I push the number two and it goes to my seat position. But now it’s going to be automated, it’s going to know that it’s me, it’s going to put the seat in the position I want, and it’s going to bring up the dashboard in my configuration. And if I want the water pressure to be in the display, it doesn’t matter, because it’s all electronics anyway. I can have any configuration in dash that I want. And it’s going to know it’s you and it’s going to automatically configure that with the lighting and everything that you want. And I think the only way you can get there is, of course, to marry those things between the experience that you see and the safety elements that you don’t see, but you expect to work for you. And that ties all this stuff together that we’re talking about because it gets very complex between all the sensor information that is trying to ensure the vehicle is safe as it drives, and all the other elements of connectivity that you want that’s also putting all this experience around you in the way that you participate in that environment.
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.