Faster Time-to-Market with Lower Costs: How Digital Twin and Model Based Systems Engineering Delivers Both

Jim Anderton: Hello everyone and welcome to Designing the Future. You know, today’s automotive industry, it’s undergoing a revolution as significant as the birth of mass production over a century ago. Electrification and self-driving once considered science fiction, well their rapidly advancing, and there’s real promise that a large portion of the global light vehicle fleet will be substantially automated and driven by electricity in years, rather than decades. Now, the price of progress, however, is complexity, and complexity is the enemy of reliability in engineering. How can the industry cope with the inevitable challenges of designing more complex automotive systems and manage programs in the automotive industry that still hit cost and time to market objectives? Well to help answer that question, I’m speaking with Dassault Systems, Senior Director of Transportation Mobility, Rick Sturgeon. Rick, welcome to the show.

Rick Sturgeon: Thank you, Jim.

Jim Anderton: Rick, it’s, it’s, let’s dive right into this. This subject is, it’s very timely. Everyone’s talking about automated driving electrification at the same time. No one talks about sort of the complexity that sort of comes with it, with that kind of progress. Can you tell me what types of data should be included in digital threads of connected car and connected car services? I mean, we talk about the digital twin, for example, model based systems engineering, it’s a hot topic as well, but when we think of the data stream, what do we mean in the automotive context?

Rick Sturgeon: Well, it depends on where you are in the program. When you start out, you really need to think about the requirements. Not really as we have in the past, rather not just the vehicle, but the environment the vehicle’s going to be driving in, because with the advent of smart cities and the infrastructure, communications, et cetera, and really the expectation of the people using the vehicles that it’s more than just driving. Think of the smartphone as a car and in essence, to do that, you really start out with the concept of what we call model-based systems engineering, and what that really means is you start out with all the stakeholders. You start out with the vehicle requirements as we always know them, how it’s going to be used, the city, et cetera, and you build a high-level model, and then you start working down through that. Now, when you first start out, that’s really all you have, but you simulate it and you begin to develop your vehicle. But as you go through the flow, you collect more and more information clear through the time when you actually start taking data from the car and adding that to your models. Long-winded answer, I know, but a lot of complexity to deal with in a change.

Jim Anderton: Let’s define that complexity a little bit. What do we mean by complexity? I come from the automotive industry at a time when electronic fuel injection was considered an impossible hurdle to overcome. I mean, the wiring harnesses began to become as thick as your wrist and there were predictions even then that this will lead to reliability problems. Now in the analog world, we overcame that, but now, automotive systems are largely digital, and this is an entirely new world. I mean, analog signals, we can trace, we can track, but we seem to be as much about software as hardware now. Is that a factor?

Rick Sturgeon: Few years ago, people were saying there’s more software lines in an automobile than a 747, for example, but that’s gone exponential. Another way to look at it is the autos that we drive today have probably up to 200 computers in them, which sounds like a lot, but they’re sort of all independent now and each supplier develops their own, and they verify it and the OEMs put it in. But with the advent of some of the EV companies, Tesla really driving it, they’ve gone to more of a, not quite there yet, but one computer for control and one computer for entertainment, which really makes the car a huge computer. And it really requires the coordination of all that software and if you add to that the integration that’s happening from vehicle-to-vehicle communications, ADAS, which is really automated driving at different levels, I’m on the SAE committee that’s been working on validating that, and in my past life at Johnson Controls at that time, I was head of engineering operations, and we designed and developed about a third of the automotive seats in the world and we had to validate them.

Well, that’s pretty important because you want your seat to work when you’re in a crash and that’s really what we would validate. I think we did a great job. Now, the number of requirements to really do that are about 200. To do that for an automated vehicle or an ADAS vehicle it’s, I don’t know, 10, 20 times that, so really the complexity that’s hitting the auto industry, there’s never been anything like it. I don’t know if it’s as much as an aircraft, but it’s right in that area and it’s a change we all have to deal with.

Jim Anderton: What is the reliability environment and you think of it, I know that when we think of the aerospace industry, many systems are safety critical, and they’re engineered with that in mind, so reliability is a factor. But the automotive industry, although they’re not safety critical, they’re certainly customer satisfaction critical, and in a mass production environment, of course, if we’re using statistical process control and we’re not at 100% inspecting everything. Is there a natural conflict there? Highly complex automotive systems on the one hand and the need for high reliability, but the need for high volume too.

Rick Sturgeon: Well, if you go to the automotive industry years ago, when I was at a company called AlliedSignal, now Honeywell, I had the opportunity to go and try to take aerospace parts and use them in automotive. This is like 20 years ago, and it sounded like it would be easy, but it wasn’t, and the interesting twist to it was obviously they cost a lot more. The American soldier, if they need gold contacts, you give them gold contacts. In automotive we try not to use metal, you know. We try to make it as cheap as possible. However, there was another subtlety and it was early in the specification requirement. An automotive spec is typically the same spec that they require to go up into space. Much more severe than what the aircraft industry uses for their aircraft, because we have a hundred miles, hundred miles of, with salt hitting it, and extremely hard requirements for the parts.

Now move to the software. Again, in my past life, we did a large part of the automotive electronics in the vehicle. And there, people would, we did a lot of the tape players or not tape players, but the CDs in my time, and what would happen is when people would analyze the vehicle from one of the big OEMs and they had our stuff in it, the consumer would come back, when I press five buttons in this unknown way, the tape player doesn’t do what I expect it to do, or the CD, therefore I’m never going to buy this car again. And of course, that would drive the OEMs crazy. Well, we’re going into that problem unbelievably and the consumer electronics people never wanted to deal with us because the consumers of automobiles are so much more critical than we are with our PCs or our phones or anything else. So it’s a huge challenge, but there are tools developing now to, to deal with that, that are much more capable of looking at, and we have them here at Dassault Systems, at the millions of use cases that you can’t even think of testing them and validating.

Jim Anderton: I’m glad you brought up a critical point here. What are the challenges or the issues when creating digital threads for the connected auto environment versus say other connected consumer goods? We all carry a smartphone now, they’re heavily connected, cloud connected laptops, personal devices like pads, tablets, and automobiles now are in that space, but it’s still a different industry.

Rick Sturgeon: Well, it’s really different because if you think of the iPhone, which we all, most of us anyway, carry, we really decide what we’re going to pull from the internet, when we’re going to pull it, how we’re going to use it. But now you throw into that a vehicle moving through the environment that obviously is very safety critical, and what you have to do is you have to take all the other vehicles into account. You have to take the infrastructure into account, and you have to take into account what we’re doing as we always do, hopefully not looking at our smartphone when we’re driving. For example, there was, I went to what, this MIT sort of lab that’s been monitoring people in their vehicles for many years, and it really changed my behavior because it turns out, now I have to admit occasionally I’ve looked at my iPhone when I’m in the car and I’m trying to, you know give it up, but occasionally it happens.

And what they had studied really by watching drivers for many years is when you look down at your phone, maybe for a second, maybe two, maybe for three, maybe more, and when you look back up, it takes you that many seconds to regain control of the car, to get a sense of where it is, and if you look down more than, I don’t know the number, eight or 10 seconds, you’ve totally lost control of this huge vehicle. Now that’s something that we need to address, and we can address right now by monitoring. But if, I just tried to give you an example of the difference between the phone and the car in this case, I’m just using my phone while I’m driving the car, but the car is not driving. You know, it’s just going. Anyway, that’s the difference?

Jim Anderton: When I was in the industry, sounds like roughly the same timeline you were. I mean, SAJ standards, FMVSS, you had handbooks, they’re literally paper handbooks, and you sort of engineered to the book or to the standard in there. But we’re talking about a level of complexity. Can you still do it that way now? Or is the technology racing past the regulatory regime?

Rick Sturgeon: Well, actually in the automotive industry they are exceptions, but it’s still running that way. But really it started a thing called model-based systems engineering. And we actually have a product called No Magic, which is very dominant in that space, but it started out with NASA. There’s actually a huge handbook that defined it, and the concept is that you look from everybody’s viewpoint, not just the car, but the customer, the owner, the government, whatever, and you start at a top level and you start creating a model, a live model really, of the requirements. And that really has totally permeated aerospace, it’s used everywhere. But one of our big OEM customers did a vehicle and they did it the old way, and they ended up, because really in an automobile, what we try to do is we try to reuse everything and we try to take the body and we try to take the chassis, et cetera, the internal combustion engine (ICE) structure, and every OEM has a set of those and a set of the main structure. And when you’re going to do a new vehicle, they say, “Okay, do whatever the customer needs, but you’ve got to pick one of these and one of those and then build your vehicle around it. And don’t change too much.” That’s the way the auto industry has run for many, many years.

Well, they tried to do that. And of course, with the electric motor, the whole power train, it just gets torn apart. And then you have to package the battery and that gets torn apart. And so they ended up spending about two and a half times the amount of money they normally would to develop a vehicle, because now rather than changing five, 10% of the parts you were changing it all.

So they looked to say, “Who does that well?” And it turns out it’s aerospace, it’s NASA. And this tool, No Magic in our case, or MBSE is the way they manage all of that complexity, software, electronics and hardware. Most of the OEMs, they’re going forward with that in the new vehicles and that’s really the answer to this.

And I think when we do a seat and we go back to the old way, one time in my past life, I had the engineering people, the requirements people, the testing people and the simulation people. And I said, “You’ve got to coordinate yourselves. If we do something up front, the customer tells you, ‘I want to see how that ends up in testing.'” Well, it turns out that we start a seat anyway, or an interior, is we started out with about 200 requirements.

By the time you’re testing, it’s like 10,000. And if you would fail one down in testing and try to figure out what that affects up the line, it was very difficult. With model-based systems engineering, it blows all the way out. Every requirement in that model knows what it effects and what it’s affected by. So it’s a way to really keep everybody in tune, even out to the user base.

So that is the answer. That’s what automotive’s going. It’s early penetration, but it’ll be a great future because it’ll make better vehicles, safer vehicles.

Jim Anderton: Well, Rick, that’s an interesting point. I think what we’re talking about it here is a migration from document-based systems engineering to model-based systems engineering. In the document-based world that it sounds like you were involved in as I was, a relatively minor engineering change would have a ripple effect in that parallel flow of documentation and certification that ran through an entire system with cost building each step of the way to the point where in some cases, some of our OEM customers, they would acknowledge that an engineering change would be beneficial or it might improve reliability or even lower cost. But the cost of implementing it through the engineering change system made it cost prohibitive for that model year or that platform. So you deferred it to a time when you were scheduling a redesign anyway, for example. So you lost something in the process, the paperwork, there was a tyranny of documentation and with every engineer in a silo working on their bracket or their fastener or their widget, and really not being able to, throwing their design over the wall and hoping that it works further down the line.

With model-based, are we talking about a democratization of the engineering process inside the workplace? I mean, is every engineer going to know where their widget fits in the larger assembly?

Rick Sturgeon: Well, they will. And obviously, people like you and I have to stay current. So a couple years ago, I took a set of four courses from MIT in complex systems development, which is really what we’ve been talking about here. And during that course, MIT obviously really studies things at a deep level, and they had actually studied one of the $6 billion oil rigs. And they had gone through and analyzed all the engineering changes that happened. And I believe they did it with MBSE, but in any case, obviously engineering changes slow you down. They change the vehicle, they cost, et cetera. And the sum of that was that if you use MBSE, you spend about 20% more up front, which the finance people hate, but you massively reduce the engineering changes and you save about half the cost of what you would spend otherwise.

So, it’s something that we need to get some experience with. Obviously we need to learn to deal with it, but it is the answer. And it does, well, give you an example of how it works. We did a study at one point of an emergency vehicle moving through a smart city. Okay? And you start out with the government, the person in the vehicle, the driver of the vehicle, the environment, et cetera, very high level. And then you keep blowing it out as you would with requirements. If you get down into the ambulance, what are all of its critical parts to moving through the city, all the sensors. But once you go about maybe four to six levels down, you’re talking about the communication protocols that the car will talk to with the stoplight.

And that level of connection between what you’re trying to accomplish and at the low level, all the things that need to be orchestrated, you just can’t do that in the world that we’re living in today. And this world really requires it, and it’s really exciting to be a part of it. And obviously as we work through it, hopefully one day I’ll be sitting in that autonomous vehicle and I’ll be going to visit my daughters out in Seattle, which I did recently. And rather than paying that thousand dollars for the vehicle, I’ll just call up my autonomous vehicle. It’ll come to the airport, pick me up. It’ll take me up into the mountains. When we need food, I’ll tell it to go get me some food and it will. So I have dreams.

Jim Anderton: Yeah, I’m looking forward to that vehicle myself. Rick, thinking about MBSE, one factor in a document-based system, in most project management system in my experience at automotive, I’ve seen it in aerospace, is that we tend to cost projects early, of course, at the pre-design phase, if we can, but certainly during the design phase. Then engineering changes that might result in costs later in production or even rework, if we need to do that, it’s difficult to predict what those costs are. And of course, inevitably there can be cost overruns, program delays. You see that in aerospace a lot. I mean, it’s difficult to recall the last time I heard of a large aerospace project that actually arrived according to the plan, time and budget. And then in the things like defense, we get some unusual contractual arrangements, cost plus contracts, contracts that are not fixed price that are unusual accounting stuff, to try and work around this. Can we take the simulation function and that sort of compressed documentation that MBSE gives us and get a little bit more certainty into what these things are going to cost?

Rick Sturgeon: Well, certainly the way automotive works and the way aerospace works is totally different. Obviously, we’re driven by what the consumer will pay. We’re driven to a deadline to hit it. But I’ll delve into another important piece of this, and you started to hit on it in simulation. When MBSE is just the first part of this, it’s really a model of a requirement. But as you build the vehicle out, you start making your CAD models. You start simulating. In our current process, you start making early prototypes and testing them and as you say, decide what you can afford and does it work. And then, and clear through maybe at the end you have made a mistake and didn’t simulate well and you didn’t catch it earlier. You have this half a million dollar tool cut and you realize it’s not going to work and it slows things down. And that’s the world we live in.

Well, what you really do in this new, if I’ll just walk through it with you, environment, you do this MBSE work. You simulate. You get the customers and you do the best you can. Then you start developing the vehicle. Now, a subtlety at Dassault, we’ve moved it all to the cloud. Same thing, you could do an Airbus or a Boeing 747 plane now in the cloud; it’s now available and it’s been used by some of the new EVs to actually create their vehicles, starting out with just three people and then growing to hundreds. But what it has in it, it doesn’t use CAD files. And that’s a big difference. It uses data as Google uses data. Today, the way engineering works typically is these huge files and people work in their silos. And at the end, as you said, they realize, “Did it work or not?”

Well, once it’s all cloud data, as you develop, you can start integrating the real parts and simulations of the real parts that replace some of the maybe assumptions you’ve made in the MBSE models. And in turn, even out to the point where we’ve made an investment with a company called AV Simulation, which is a leader in actually simulating the city, simulating the vehicle in the city. And so as you’re in those early development phases and you get some of the early models, you can literally see how your vehicle as it exists at that point is going to perform in the city, and you find things. You find that consumers really don’t like the way you’ve done it. You find safety issues.

And so the environment really goes back to the way people did the vehicles the best in the past, where like Henry Ford would sit in a room and he would just tell people what to do. And if he didn’t like it, they would fix it. And if you think of the way some of the really World War II best aircrafts were done, they were done in a hangar with everybody in there. Well, today we don’t work like that. Everybody’s in silos. The more we make it complex, the more silos there are, et cetera. And people are less and less together. I think the Japanese have always called the “obeya” room, where everybody is together.

Well, in our world today, it’s so complex and people are all over the world. To be together is not so easy. But using MBSE, using the cloud platforms without files and data, you can literally create a virtual twin as we call it, so that as somebody in India or China or Detroit makes a change, everybody in the world sees the change they made, which might be a good thing. Or they might say, “How could you do that, Rick? Fix it.” But anyway, a very different of working, really, going back to the past and recreating the room, the Henry Ford room, where everybody works together as they build, rather than everybody working and then handing in their homework, so to speak, and then seeing if it coordinates. And that’s our view at Dassault and our dream and we’re well on the way to making it happen.

Jim Anderton: Rick, that connectivity in the industry, today we talk about cloud connectivity. When I was just starting as a young graduate… In fact, I recall once visiting a plant of one of your competitors in the seat business, a company that was a division of a firm that made private jets, in fact, and they had a large satellite dish on the roof of the works. And of course, it was satellite-connected on a dedicated channel to the large OEMs in Detroit, at huge cost. And of course, there’s limited bandwidth.

Today, we use the cloud because internet is ubiquitous, and OEMs are asking for continuous data flows of increasing sophistication from their tier one and even tier two suppliers; so we have that data stream. At the same, the vehicles, the products themselves. Are cloud-connected and they are feeding information back to the OEM, who may then feed that performance data back through that stream to the tier one, the tier two.

So we’ve got a lot of information flying around in multiple directions up and down, right down to the consumer down there. We have to ask the question: What about security? I mean, there’s information embedded in those data streams that’s highly proprietary, might be safety critical. It’s personal. What do we do about that?

Rick Sturgeon: Well, obviously, as you look in the news, IT security… I was a CIO a bunch of times. And at one time, well, not supposed to use… Cummins Engine, I was an early CIO. And when I went there, they had had a breach and of course the FBI was there and everybody else, and they assumed it was IT.

Jim Anderton: I recall that. Yeah.

Rick Sturgeon: Cummins is a great company, and we went and benchmarked a whole bunch of other companies, IBM, et cetera, and IBM was so far ahead of everybody else that it was ridiculous. And they had this guy, Phil Dolan, who was retiring, he was the father of IT security. And I’m this young guy in there and everybody’s coming to my office, “What are you going to do?” And I said, “Phil, how would you like to consult?” “No, going to go fish. I’m too old, whatever. This has been a hard life.”

And I kept ratcheting the number up in the deal, and finally I put him in the corner of my office two days every two weeks, and he could talk to the FBI and make it okay. And he helped us recover from that and obviously the company did well later, as it would. But he told me that what IT security was about is really focus on what you really need to protect, not everything. Obviously, protect everything, but really protect the important stuff, number one. And number two, make sure you can monitor so that even when they do get through that, you can identify them, prosecute them, and send them to jail. So that was the old knowledge, so to speak.

We aren’t doing well with that old knowledge today. But in automotive, we’re certainly putting layers of security in, certainly on the key control information and especially what’s downloaded for the updates. There’re all kinds of standards. There’s all kinds of testing. I think the more loose part of it is during the design phase. And that’s something that if you do go to a cloud platform like ours, you actually pick up security because you really have the security of all the big internet providers protecting you.

I had IT security at GM and, obviously, as a CIO I had it. And one of my friends asked me one time… He’d been CIO of Microsoft. He said, “Well, how many IT security people did you have at X company?” And I came up with the number, it was very small, and he pointed out to me that cloud providers sometimes have a thousand people working in IT security, and they often have three or four groups of penetration people, checking constantly.

And in turn, if there is a penetration, a small army, like the S.E.A.L.S., so to speak, come and protect you. So our move to the cloud, to these cloud systems with the layers of security, will make us very safe, safer than we are today, number one. And number two, we just have to monitor and work at it. But I haven’t heard a lot of security breaches for the autos at this point. So, so far I think we’re safe.

Jim Anderton: Rick, there are a lot of stakeholders in many of these systems. I’m thinking about vehicle sensors in particular, in that there are many firms that are very interested in the outputs of those sensors, even the raw outputs of those sensors. As tier one ourselves, we were very interested in how the things that our wiring harness is plugged into performed and would’ve loved to have a system where we could get real-time data about what those sensors were doing, even before the analog to digital conversion phase of the process. API layers. I mean, a lot of people are trying to get at or would like to get access to information. I mean, what role do they play in creating these threads?

Rick Sturgeon: Well, obviously standards and APIs are being worked on all over the place: the vehicle to the vehicle standard, there is one, and other people are trying different ones. Standards are very, very important. Openness, as we’ve gone with at Dassault, is very, very important.

That said, the amount of information flowing is unbelievable. And so we’ve been involved in a more infrastructure business with some of the cities and the phone companies, et cetera, to really figure out how to process that information in the vehicle, as it comes to the towers, as it flows through the network. And really, there’s a whole tier of taking that raw data and turning it into information.

So to your point: will an individual, let’s say sensor provider, be able to get access to his sensors? Probably, if he makes the right deal with both the OEM and the phone company, really, most likely that’s collecting it. I don’t know that that level of information in the future will flow up to the cloud.

But what we’ve been doing with Dassault is really working across that continuum and really, with one of our products, Exalead, it’s really… used to be AltaVista, one of the really famous search engines. And what was unique about it, it’s buried in our platform now, it really wasn’t character-based, it was mathematically-based, which really has made it quite powerful for today’s world because a lot of this is mathematics; it’s faces like yours and mine, it’s relationships between information, and really being able to collect that, turn it into information, but then be able to search it and hopefully use it in your simulations or, as you pointed out, your statistical analysis of your performance. That will continue.

And what we’d like to think of our platform… because we aren’t necessarily focused today, with some exceptions with some of the things we do to optimize routings of delivery trucks and so forth and ships, et cetera, most of what we do is help people invent. So what we’re doing, if you think about this new environment, it’s constantly changing, it’s not like a vehicle where you push it out the door and you’re done, as we see with some of the EV companies; they update every day or every night, their software.

So there’s constant innovation. And by having a virtual twin that’s always current, you can actually try out your innovations, see how they work, and very quickly invent. And this information you asked about, “How are your sensors performing?” maybe the invention is it’s not working very well. So how do we fix it, make it better, make it more unique? So this continuous invention is our dream. We call it PIP: Product Innovation Platform.

Jim Anderton: Edge cloud systems. There was a time in, I’m thinking probably way back to the 1960’s, before my time, when this kind of technology was developed in-house by major OEMs. CAD systems, for example, early mainframe CAD system was developed by people within the automotive companies themselves. Automation, industrial automation, for example, famously, it didn’t exist in the market so they had to start companies or invest in companies that would do that.

But we’re talking about a world now with edge and cloud-based systems where this is probably beyond the cost-effective ability of even a large automotive OEM to play in that world. So they’re purchasing systems or they’re working with companies like yours to do this.

We talked about security, but how do the OEMs play in that world? I mean, I recall one of the first things I did in this business was I had to go to a large Dearborn-based maker of American cars and light trucks. And the IP was in the form of blueprints and we had to physically hand-carry them back to the plant because we’re looking at something which has… from industrial espionage perspective, that IP was really, really valuable.

And now we’ve got a world in which these companies feel comfortable pushing a button and then beaming sort of a digital twin, a model, perhaps of a substantial part of a vehicle system or a whole vehicle, and send it to the cloud, and it just sort of disappears into the ether, and do that with the knowledge that their IP is secure.

So is this part of this outsourcing trend, do you think? I mean, Boeing, with the Dreamliner program, basically is a final assembler of components that are made all over the world. Is this going to be the same thing with engineering design? Are they going to sort of push that out, using the cloud, to the whole planet?

Rick Sturgeon: Actually, there are two things going on in the auto industry and it really comes down to some of the new OEMs are trying to do almost all of it themselves: build their own computers, build their own parts, et cetera.

Well. The traditional OEMs, however, optimize by using sometimes tens of thousands of suppliers, each validating their part, certifying it, and finding a way to fit it in the vehicle. Certainly those 200 processors in a car today are examples of that: Here’s my processor. I guarantee that it’ll work.

But I’ve talked to some of the leaders of engineering at the OEMs and what they see is the use of suppliers is very, very important because innovation is so strong there. And so, really what it likely will be, and I don’t know for sure, but certainly some people believe that there’ll be a computer in the car. And then, every supplier will be able to validate within a framework as they do today mechanically, their capabilities within that, in that big computer.

And a lot of the… Let’s say smarts, will come out of those 200 parts, and go to that central place where it’s easy to update, it’s easy to move. But the points you hit, the suppliers are actually very concerned about their IP being exposed to the OEMs. And so, we’ve worked on that, that whole structure of allowing everybody to collaborate together in a Cloud, on the one hand.

On the other hand, only exposing the outside of the black box, so to speak, that’s necessary, as they used to do by shipping a part today, still in that integrated environment. MBSE, you absolutely have to have. You have to have no files, but models, so everybody can simulate together. Those are really the keys to making that happen.

And the other complexity that you get into, right now, if we think of a vehicle, that’s part of it, but the extended mobility applications… What I like to think about is, when the smartphone came out, I don’t know, there were what? Probably 12 apps on it? And people said, “This will be wonderful for you”. Now, there’s several million in the app store anyway, and that’s the way it’s going to happen.

Right now, people think about a handheld that’s integrated to the car to help you find a… Or, help the car help you find a parking space, or parallel park you, park. There’ll probably be a million. I don’t know if it’ll be a million, but many, many applications, mobility applications, that integrate the car to the city, and to your life. And the amount of money that’s there is probably beyond what the auto makers are going to make on their vehicles. So, and again, you need all of this new, let’s say, innovation capability, to execute that strategy.

Jim Anderton: Rick, from a product lifecycle perspective, there was a time when an OEM basically built a product as a consumer good. They sold it through the dealer network. They threw it out there. It went off warranty. Eventually, it went into the used market. It’s gone. And we move on, and we sell a consumer the next new vehicle. Now, we’re looking at a world now, and Europe is leading the way in this I think, where manufacturers are responsible for the entire lifecycle of their product, including its disposal at the end of life.

Famously, BMW has a plant that disassembles their cars, and that’s sort of feeding information back to design phase, where they’re incented to minimize the number of different plastics, for example, they use, to make that recycling part easier.

So, you many look at that as the future, but that has PLM implications as well. Are there special PLM features going to be needed in the future, to make a sensible digital thread for cars that are connected?

Rick Sturgeon: Well, actually, I spoke, or led a panel at the battery show last week, and … That’s a broad question you asked me, but let’s take batteries as an example, because obviously, that’s probably the hottest topic right now, and the one that hasn’t really been dealt with. I had on the panel with me, some of the CEOs, and one of the main head of the battery society, whatever it’s called. And there was an agreement that we haven’t yet dealt with disposing of batteries, okay? The whole life cycle… It’s not done. People keep saying, “Well, we have seven years left. We’ll figure it out”, which probably is not a good answer.

Now, in my past life at Johnson Controls, we had about an 89% market share of the lead acid battery system, and I had some involvement in that. And I think when I started out there, and I was there quite a while, I don’t know what happened to the old batteries. I’m sure they went somewhere, but I don’t think we really knew. And that’s probably not fair, but that’s probably wide of the truth.

By the time I left, we had smelters that we owned, in China, and almost every region. And according to the battery guy that was there, we were into the high 90 percentiles of recycling batteries. Now, batteries is a poison. So, that’s a really good thing. It’s very, very effective. And now, to do that, we really did it through financial incentives. But to your point, with the advent of the Cloud, with everything being tracked, we ought to be able to track every material that’s in that vehicle. We ought to be able to recycle it, reuse it,, and obviously sustainability is a huge focus, and the vehicles are being monitored for that.

I learned a fact… Sometimes you don’t learn a fact in a panel, especially when you’re facilitating. Hopefully, you learn something today, Jim, but during that panel, we talk about CO2, the amount of CO2 it takes to create a battery, which is a lot, which really puts into question somewhat, how much CO2 we’re saving when we do an EV. But, what I had never thought about is, once you extend all that, or expend all that CO2 to make the battery, to recycle the battery is hardly any. So, in some respects, once we get enough batteries out there, if we get that high 90 percentile, which I understand is possible recycling, we actually will not spend nearly the CO2 we are today, to create it.

And that probably applies to many of the many of the materials. So, I think monitoring through the life cycle, monitoring through the service, keeping the MBSE models live as things change, because they will, but maybe more importantly, keeping all the data in the Cloud, and tied, will be a whole different… Let’s say, I don’t want to say control, but, opportunity for society.

Jim Anderton: Rick. I’m glad you brought that up. I have one last question for you, and it’s a broad one again. You mentioned batteries, for example, and in my experience in the industry, often it would come up that, “Well, at least we don’t make batteries”. Because we regarded the lead acid battery industry as, this is one of the most difficult, from a tier one perspective. You got a product which has a liquid inside, which can harm or kill you. It uses a toxic metal inside the case. It involves hydrogen gas when you charge it, which has its own safety issue. If you drop it on your foot, it’ll break your toes. And it’s a commodity business with tough margins.

So, it’s sort of like it encapsulates the whole automotive industry, or the supply chain in a nutshell. But, who owns the thread? Who owns the model? We’re talking about a world now, where we’re cloud connecting things. We’re talking about edge cases. Everything is about pushing the design, pushing the concept out, into the cloud there. Do we have a sense that it resides anywhere anymore?

Rick Sturgeon: Well, Jim, I never thought about that. So, we can think about that together. Well, certainly the way that the lead acid problem was solved, was making each OEM responsible, and maybe they grouped to be responsible, to get the batteries recycled. More or less, as you sold a new one, you had to get the old one, as I recall. I’m not that close to it. But in this world, I’m sure the government will have something to say about it, for sure. But it’s certainly possible to track it all. I mean, God, you and I are probably tracked by 10,000 different companies every time we use our phone, so I don’t think it’s a technical issue.

It certainly is a privacy issue, a huge privacy issue, and if we think of some of the European requirements… But, on the other hand, for the good of mankind, certainly tracking things that maybe don’t affect you personally, but affect the environment? I don’t have an answer for that, but I think it’s a really, really good question.

And I will challenge, actually, as I did at the battery show, figuring out how to recycle batteries, or with Jim’s broader question, on who controls all that, that needs a young person to really hear this presentation, and say, “I could really make a lot of money with that”, or an older person that wants to change the world. They ought to get involved, because that’s really something that I think, by figuring out how to make money doing that, in our world, seems to be the way to fix these kinds of problems.

Jim Anderton: That’s a terrific conclusion. Rick Sturgeon, Senior Director of Transportation Mobility for Dassault Systems, thanks for joining me on the show.

Rick Sturgeon: Well, thank you, Jim. And you’ll have to come join me in Ann Arbor, and drink some of the Dassault wine that’s showing behind me, and we can continue this discussion.

Jim Anderton: Count on it. And thank you for joining me on Designing the Future. See you again next time.

Learn more about designing EV technology in the 3DEXPERIENCE platform.