Shifting Left with the Comprehensive Digital Twin with Doug Burcicki and Scot Morrison – Part 2 – Transcript
The Industry Forward Podcast recently featured a series of discussions focused on the concept of the “shift-left” and how it is supported by the comprehensive Digital Twin. The series features Doug Burcicki, Senior Director of Automotive and Heavy Equipment Industries for the Lifecycle Collaboration Software Product Team at Siemens Digital Industries Software and Scot Morrison, Vice President of Shift Left Software Product Management in the Hardware Assisted Verification group at Siemens EDA.
In part two, the conversation turned to focus on how companies are prioritizing software development and chip specification early in the overall design process. Other topics included how this shift in priorities affects inter-disciplinary collaboration and how software tools can help encourage collaboration.
You can listen to the episode through the player, or read a transcript of the discussion below.
Dale Tutt
You know, both of you guys have touched on a couple of topics with the shifting left and you mentioned the hardware, software, code design elements. And Doug, I really liked what you said about changing business models and you even touched on a little bit about the fact that it takes an ecosystem and we, you know, I had an opportunity to chat with Michaela a few weeks. Back on what we’re doing with being able to develop semiconductors and we talked a lot about the comprehensive Digital Twin and the fact that you now have to be able to. Collaborate much greater between the different engineering domains, the software, the electronics, the hardware that’s on the card and hardware and sense of the sensors and the systems that are on the car, not necessarily the hardware that’s in the semiconductor as well as you know the mechanical and electrical, I’m sorry, electrical system design, so really being able to work collaboratively with an ecosystem of partners and how do you do that with a Digital Twin? And so, yeah.
But let’s now maybe not so much on the technology, you know right away. But you know, how do companies in this new environment, how do they reconcile these cultural and technical difficult differences to ensure that both efficiency and a pleasant working environment? I mean, I think it’s very you’re what you’re describing very fast pace undergoing a lot of change, new business models. The organizational requirements I got to imagine this is pretty challenging stuff. You know for a company and both culturally and technically. So you know, Scot, what are you, what are your thoughts on that?
Scot Morrison
Yeah, I mean it’s it is quite a challenge for them, you know, especially the larger companies, as Doug said, you know, they tend to be more siloed and. And historically have always worked that way and you know a lot of times that they have dealt with each other. These different domains, you know, whether it be, you know, chassis versus powertrain, you know or software versus the hardware subsystem providers. And this is even just within a major OEM, right? I mean you talked about the partner. And then the multiple tiers of suppliers that they have as well, it’s a very, very complex set of not only groups and sites, you know and cultures, but you know, different companies, geographies, et cetera. They have to pull together for these very, very complex vehicles.
So one of the things you know that we are focused on is not just the ability to have this scalable Digital Twin capability that I mentioned earlier anywhere from a chip all the way up through a subsystem to a. Vehicle, but also we’re working on technologies to be able to kind of thread requirements through these as well. So that some of the higher level discussions and decisions that get made at kind of the functional and the feature level that those can be traced down through the design phase and we have the classical V development. Michael, for instance, and people have used kind of specifications that they pass between the different groups historically and interface definitions and things like that.
But what we find is could be much more effective, you know, we’re working with some lead customers on this, is actually within the development tools themselves is to be able to have kind of integration and traceability, so you’re not passing documents around, you know, or spreadsheets, you know, interface descriptions, things like that. But you can actually more seamlessly transition from one tool into the next tool and you get that kind of innate. Traceability, and not just down through the development process, but also as you’re doing verification, you have test results and things like that to be able to trace results back up through the integration phase as well. And honestly, given the complexity of each of the subsystems and the components. It seems to me to be the only kind of realistic way that we can do this and make it much less, much less manual and much more integrated from a tool flow and development standpoint.
Doug Burcicki
Yeah. So again, I’m going to use the word collaboration. You know, we talked about the complexity of the development activities, but the inherent collaboration that’s required across multiple domains and skill sets that in the past, quite honestly, didn’t have to do that, and here’s an example. It’s a small example, but it’s kind of fundamental to this whole discussion. In the past, an automotive software developer was typically given a piece of hardware and told this is the chipset your code is going to be running on. In a lot of cases, that was a limiting factor in how they wanted to architect their software or maybe even architect the entire E/E architecture of the vehicle itself. And it’s almost flipped 180° these days, where the software is providing a fundamental differentiating value to the vehicles. It’s no longer just things like design and styling, the user interface of a vehicle has just as much brand recognition and satisfaction to a customer or consumer as you know the sound of the exhaust or the rev of an engine.
You know, there’s different factors that are compelling consumers to make purchasing decisions around these vehicles and. And so that for that very reason, the software is also becoming a differentiator. You know, Tesla is a perfect example, right? There’s all sorts of features and notoriety that they’ve gotten over the years simply because of software additions. Nothing impacted hardware whatsoever. It was all software. Many times it was delivered after a vehicle was already sold. So software is now dictating what hardware is being used, and that’s why you’re seeing OEMs get into chip specification and determining, I mean, you know what the requirements are for foundries. They’re basically designing chips and then going out and finding a manufacturer to build it for them. And that was never the case before.
But that’s because the software is what’s defining that product and the software is driving the hardware implementation. And I find that absolutely miraculous. But that also goes back to the point I made before about why our legacy customers are struggling with this transition so much because that is not the way they operated for the better part of a century. So, I think that’s one of the areas that is the biggest challenge for them.
And then the other thing is, I mentioned multiple times about your partner and network. Well, we all know we all speak a different language, right? We all have thousands of acronyms we use. We might use the same word and have two or three different meanings, like “architecture”. If you ask the software engineer how to define architecture and then you ask the electrical engineer how to define architecture or the platform engineer how to define architecture, they’re all going to have a different answer for you and a different view of the world. And that’s one of the biggest challenges with these cross-discipline development activities is getting everyone on the same page.
So now your requirements and specifications are more important than ever, right? The ability to trace those requirements and validate them and demonstrate that they’ve been implemented and documented in certain cases, I mean that’s, that all hinges on one coherent data set, you know, comprehensive Digital Twin as we say. So the earlier you can bring those elements together in the process, the better you understand the design decisions and the associated tradeoffs you’re making, and you’re also able to validate or invalidate different approaches so that that’s again another reason why we’re seeing everyone push to move left as fast and as early in the process.
Dale Tutt
Like the you know, as the example of the paradigm shift that you’re, you know, you were sharing there and. And having seen that before as well with that the chip, you would pick a chip and then the software would be limited by which, what was available. And I was using the analogy that by the time we selected a chip and then went through the development of their new aircraft, now the chips that we were using were already 7, 8, 10 years old before we, before we even delivered to our first customer. I mean, we’re already starting to talk about parts obsolescence. And so I think this is really that, that to me is part of the benefit of what we’re doing here, that the tools are now able to take the risk of that development. And so that you can develop the software and the chips and you have more up-to-date hardware on the on the car, if you will, so or the airplane or the tractor doesn’t matter.
But you’re it’s you’re really changing. So we’ve talked about this a lot. So I’m not sure how much there is to add yet but you know given the growing emphasis on software, let’s dive into just a little more on the details there. And so as we think about how their companies are shifting, with the development of software in conjunction with the development of other systems like the semiconductor chips themselves or custom, you know, SoCs, you know the system on chip in particular, which I know is you’re really gaining a lot of attention now as well. Well, or the electrical system. So as we think about the software development, is there anything else that we really need to add that we haven’t covered already on some of the details of really what does it mean to start developing the software before you even have a car?
Scot Morrison
Yeah. Are you or you’ve even picked your chip yet, right? I mean, a lot of our customers are doing is they want to shift left onto a virtual platform to just even pick the right chip, right, even if they’re not going to design an SoC. If you look at the SoCs that are being designed in the automotive market as an example, right, a lot of them tend to be around autonomous driving, maybe because of kind of the mix of safety criticality that they have in those applications. Maybe in vehicle infotainment you know because as several people said already, right, the vehicle experience to the driver is really defined by the software and therefore by the displays that they see in the cockpit and we see more and more of those displays. So you know sometimes. What we’re seeing is this interest in specification SoC, but just the selection of off the shelf as well because not all the ICs are going to be. They basically can take the software workload which you know in the case of a custom SoC, is going to basically specify or almost design drive the design of the ICs.
But people want to do architectural analysis because you know the automotive, in particular the volumes were so high that, you know, purchasing really drives a lot of these decisions. And they want to look at two or three different vendors and you know, you can only really pick the right chip, so to speak. If you can run a realistic software workload and that’s what you mean by shift-left, of course, is taking that realistic software workload that maybe typically would come in towards the end of development process and pull it forward and be able to use that during the chip design or the chip selection process and. You know, I’ve seen programs too, where purchasing, you know, since they were mentioned, they will actually switch a chip part way through a development process just because they can save a certain amount of money. And we all know how purchasing can help drive the strategy in terms of vehicle development.
So you have to have that agility as well to be able to evaluate different ICs, different SoCs early in the design, even midway through the. 9 and so that you know, being able to do that before you even think necessarily about what you know, whether you’re going to have a custom SoC, you got to pull software development with realistic workloads, it’s far less possible. And that’s just in kind of the architectural design and kind of chip selection or chip design, but also for verification. I don’t think we really touched on that right, but that’s one of the biggest cost savings and basically accelerators that people can have for their programs is by having these Digital Twins, virtual platforms is that they can pull realistic verification efforts left in the development.
Another aspect of shift left, and that can be, you know, at the unit testing level, it can be at system testing you know, but you can also have this concept that has been emerging in the marketplace in automotive and aerospace applications of this virtual hardware in the loop. It used to be that you really only pulled the subsystems together when you built a HiL rig very late in the development. But now that you have these kind of component level subsystem level Digital Twins, you can pull them together into what’s called the HiL, virtual hardware in the loop, and you can start pulling together multiple subsystems, entire vehicles. And not only that, you know pulling together basically the components of a vehicle, but you can drive them, you know, either with captured data or with these kind of three-dimensional virtual reality, different methodologies and you know paradigms that people have now so that they can actually have realistic test cases.
But they can also drive corner cases, right? Things that it’s very hard if not impossible. To test against in the real world, but you can shift that type of testing left as well into the virtual domain into the vehicle. Domain and you can start to really explore, especially for autonomous driving and things like that. Kind of the safety capabilities of the system that you’re developing. So you don’t get surprises later when you get into actual vehicle testing.
Dale Tutt
I know. That’s. Thank you, Scot. And that’s you know. You know, it is really changing how I, you know, I love the fact that you talked about, you know, the hardware-in-the-loop testing the virtual hardware-in-the-loop testing and being able to plan, you know, and be able to test for all of these, you know, for all these changes.
Siemens Digital Industries Software helps organizations of all sizes digitally transform using software, hardware and services from the Siemens Xcelerator business platform. Siemens’ software and the comprehensive digital twin enable companies to optimize their design, engineering and manufacturing processes to turn today’s ideas into the sustainable products of the future. From chips to entire systems, from product to process, across all industries. Siemens Digital Industries Software – Accelerating transformation.
