Shifting Left with the Comprehensive Digital Twin with Doug Burcicki and Scot Morrison – Part 3 – 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 the third installment, Dale shifts the conversation to focus on how companies are approaching software maintenance – especially in products of varying ages, how new business models are contributing to the shift, and some key takeaways from the entire conversation.
You can listen to the episode through the player, or read a transcript of the discussion below.
Conor Peick
Hello and welcome in to the Industry Forward Podcast with Dale Tutt. My name is Conor Peick and I am a writer for Siemens Digital Industries Software’s Thought Leadership team and your host for today’s podcast.
Dale Tutt
And I’m Dale Tutt, Vice President of the Industry Strategy Team at Siemens Digital Industries Software.
Conor Peick
So it’s a new season of the Industry Forward Podcast. In this new series, we are going to be exploring the idea of shifting left with comprehensive digital twin and doing so with the help of several experts with decades of combined experience in automotive, aerospace, semiconductors, software and more. Today Dale and I will be talking with 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. We invited Doug and Scot on to give us each of their unique perspectives on their transition towards software defined products, promoting new collaboration among engineering and product teams, virtual testing and verification methods, and much more. Thanks so much for tuning in and we hope you enjoy the episode.
Dale Tutt
But you now want to shift just a little bit. You know, Doug, you were talking earlier about the changing business models and you know how they have a different revenue stream. And so when we start and talk about shift left, you know we’re talking about code designing code. You know, hardware, software, code design. And that’s really in some level based on well, what’s available today. But when we think about future software updates to the products of varying ages and different hardware configurations that are going to be out there and and you know what’s the art of the possible in the future, how are companies really taking a look at that and driving those type of requirements? Into their into their design of their hardware as well as their software. So how are they starting to plan for this? I’d like to think about that because we’re talking about these long 20-30 year revenue streams. How are we pulling that in so we can actually execute on that and have something that’s a viable product for many years to come?
Doug Burcicki
Yeah, well. As we know or as I said, right, this evolving business models are driven by incremental revenue opportunities, right? And I don’t think it’s any secret. There’s several large OEM’s that have stated that, you know, by 2030 to 2035, they plan on generating 20 billion plus in incremental revenue. Solely from software that they don’t sell today on these vehicles. So. That’s a big motivator for these companies to do things differently, right. And start to approach historical methodologies from a different perspective. So you know, as we said, software is driving many aspects of the vehicle designs and architecture considerations. It’s well known that the intent is to have that software. Be flexible and agile and able to be updated, upgraded, improved over the life of the vehicle and then you know maybe provide features and functionality that we don’t even know about or talk about today 10 years down the road.
So I think from the very early onset of requirement definition that they’re already thinking about the long term deployability of the vehicle, as Scott said earlier, in the past you have been involved with programs where they spec out a chip and then they basically say you know the software code. And use up to a certain percentage of the headroom, and they leave themselves a buffer to add some features or additional software to improve performance later on in the program. But you’re talking about. Vehicle development life cycles over a few years, right? And then that software is essentially done at that point. But now we’re talking about it never being done it, it never it’s going to continuously be designed, validated and integrated and deployed over the life of that vehicle. So I think there’s. More focused around long term performance requirements and how to provide this upgrade not upgrade ability but extended usability. Via over the air updates to the vehicle and also there’s a desire to have a certain amount of flexibility, flexibility where they can literally move features and functions around in different modules on the vehicle.
It’s not like it used to be where there were hundreds of electronic modules on a vehicle. Each one had its specific purpose. And most of the designers and developers associated with that module didn’t really know what was going on. The rest of the vehicle and didn’t need to or didn’t care. And now it’s a much more holistic vehicle level assessment, which is, you know, to Scott’s point that’s driving the desire to have virtual environments, whether it’s at a chip level or at a holistic subsystem level or a vehicle level as early in the process and doing it in the cloud as a way to. And do it in a light mode if that is possible, simulating an entire vehicle calling that a light model, but it it’s. It’s required going forward, right?
But then the other thing is through this virtual simulation validation, they’re able to establish and identify, identify essentially reusable components of their architectures, right. And they’re the, the desire. Is to build scalable architectures that you can build on in the future, not generating a new architecture every five or six years and optimizing or improving it through an iterative process. These are meant to be fundamental platforms that they build on going forward, and when I say build on it, you could be building on increased levels of automation or autonomy as Scott’s referenced. Or maybe you just provide additional levels of functionality that don’t exist today.
So you know there’s. Again, it’s a business model and there’s, you know, there’s a lot of different ways to approach the automotive market historically. You try to limit giveaways on vehicles right, and maximize your profit. And the last thing you want to do is put content in a car that’s not utilized by a consumer. But these software defined products are taking a much different approach where there’s a lot of hardware in the vehicle that only gets turned on if you decide to turn on and. Certain features or functions are a pain. For that, and that’s a much different business model. And I think that’s another area that the legacy OEMs are really trying to get their heads wrapped around because that has not been how they’ve done their run their business for decades. But if you’re truly going to leverage a scalable architecture, that’s a different approach that you need to be looking at so. Yeah, I don’t know if I directly answered your question, Dale, but those are some thoughts on the more holistic perspective these companies are taking.
Scot Morrison
Yeah, I could add something to what Doug said as well. He brings in this concept. We’re hearing more and more about shift right. People talk a lot about shift left software and we talked about some of the reasons for doing that earlier, but. This concept of shifting right as well-being able to change software, you know post release of a product and that not only it kind of extends the software defined vehicle concept to the software maintained vehicle and the software enhanced. And you know, for maintenance for instance, I mean obviously it’s very expensive for automotive companies to have recalls, but if there’s an issue in the software and they can patch that in the vehicle after it went out the door, that saves them a tremendous amount of money and it’s not necessarily just in the software, right. They can oftentimes work around hardware issues. They’re discovered later as well. Which are even more expensive. To fix and then the software enhanced, I think Doug spoke about that very well. It’s like it can drive that additional revenue stream, but it also keeps the company competitive because honestly if a company is shipping a static vehicle in the future, they are just not going to be competitive. I think because their competitors are going to be releasing new and new. Capabilities, you know as things change and there’s new devices that people want to bring to their car, new capabilities, you know, different types of infrastructure that the vehicle can interface with and integrate with. You have to be able to update the software just to kind of extend the eventual. Utility of the vehicle and defer the obsolete. You know when it becomes obsolete as well.
Dale Tutt
Yeah, I like the whole thought process around shifting, right. Yeah. You know, it’s The funny thing is, is now we have to shift right even further than we used to because used to it used to be is like, how do we get it delivered? And then it’s, you know, it’s out there and then we’ll do with all that. But now you have to shift those. You have to shift 10 years into the future of how you might want that car to operate and envision that capabilities that would need to be available to it. So I really like that notion of shifting right because it does. It’s a different mindset as part of the. Whole. Paradigm shift.
Conor Peick
So Doug and Scott, thank you guys again for joining us today. I think it’s been a really, really interesting. Conversation so far. Uhm, I was just, you know, typically when we when we end these podcasts, we like to just give you guys a minute or two just to kind of freestyle and you know, think about anything that that you want the listeners to leave sort of the episode with. So Scott, I don’t know if you want to start but yeah maybe just a few thoughts of about where we’re headed, maybe some of the big challenges up ahead, anything like that.
Scot Morrison
Yeah, I mean, just to kind of summarize briefly what we talked about right, because my title is shift left software enablement, right? That’s what I do day in and day out. And we talked about all the value during the development process, early, mid and late in the development process of how shifting realistic software workloads left and using these virtual platforms and digital twins adds value. And then we talked about how shifting right is really driving a whole different set of additional. Values that customers you know need to realize to be competitive. So from a software standpoint, which is what I really focus on kind of the software enablement at various levels of development that kind of covers everything. Although as Dale said, you know the horizons on the. Things keep changing. You know, I like what you said there.
You know, people want to shift further left very, very early. Even pre development, pre hardware development and as far right as possible. So I think you know in terms of the overall challenge our customers are facing and kind of the software defined vehicle or software defined product or software defined world. That we live in today. It’s really the broad, broad spectrum of different capabilities that there. They’re challenged with right now and it’s impacting from the earliest to the latest aspects of their design and their maintenance, you know, and their development processes. So it’s kind of ubiquitous, you know, and it permeates all aspects of the design. It’s not just, you know, moving into one particular phase or a handset of phases. It’s really throughout the entire complete kind of cradle to grave development process for these vehicles or any type of software defined device and that’s what our customers need and that’s what we’re trying to focus on enabling.
Doug Burcicki
From my perspective, I’ll go back to one of the earlier points I made about you know, we’re just embarking on this journey. There’s a couple OEMs that may be a little bit further along right now, you could argue, but for the most part, there’s not a software defined vehicle on the road today and a lot of that is because of the challenges. The. Realized in regards to the software development and the software deployment, I mean some very large, powerful, impressive companies have failed miserably trying to launch their first generation of product in this space. And you know, it doesn’t bode well for the bottom line. For an automotive manufacturing company, so they’re trying to learn, they’re trying to learn fast, there’s different approaches. Some are taking a more vertically integrated approach. Some are looking to a supplier ecosystem to support them more.
Which is the right answer and you know is yet to be determined, but I don’t see anyone succeeding without collaboration and partnerships, and it’s actually been kind of surprising to me if you look at. Companies that are actually collaborating and partnering with each other in this space, it’s very small. There’s only a couple that I’ve really I’m aware of. Volvo and Daimler, Truck and commercial vehicle have actually opened up a facility in Europe and they’re. They’re partnering on a software defined architecture for their commercial vehicle platforms. They felt it would be more competitive for them to work together in common software development as opposed to competing with each other and duplicating efforts. Similar type of relationship between VW and RIVIAN. Rivian has developed a very state-of-the-art architecture that VW wants to take advantage of as they deploy some global platforms.
So they didn’t see value in developing their own capabilities for something that doesn’t drive the differentiation at a user level. So they’re focused on the app side, they want to focus on your user experience with the vehicle, not the underlying software that supports it. So it’s a different approach. Again, we’re early on, so who knows. The broad or successful approach would be, I think we all know there’ll be different solutions that are correct in different situations or different regions and we’ll see how that pans out. But we, Siemens, we don’t have all the answers either, but we sure do have a lot of them and we have a very big network of partners. As well, and we’re pretty well positioned to help these companies on this journey on this Advent. And I think we have a lot of existing capabilities and know how that we can bring to bear. And again determining what those priority gaps are in any solution space you know are critical and we look forward to working with our customers and making progress in that space and enabling their success in the future as they try to realize. Software defined products.
Dale Tutt Being able to shift left is going to be so critical for these companies to manage their risk and actually define these high performing products as a as they you know, really look to the future with their customers as they shift left shift, right. I mean as well. But really, having that multi domain mindset and the ability to collaborate on a strong peeling platform, I think Doug, many of your comments, I agree with it’s you know we we’re very lucky to be able to partner with so many of our customers on these on helping them with these solutions. And so it really has been a great experiences. So I thank you guys for. Being here today.
Conor Peick
Hi there this is your host Conor. One more time just to say thank you so much for listening to the Industry Forward Podcast with Dale Tutt. If you enjoyed the show, please consider subscribing on Spotify or Apple Podcasts and if you really enjoyed the show, maybe throwing us a rating and a review. Next time on the Industry Forward Podcast, we will continue our conversation with Doug and Scot, focusing on how companies are placing greater emphasis on early selection of chips, how they can foster collaboration among engineering disciplines, and how the move towards software defined products is affecting product strategy. Thanks again for listening and we’ll see you next time.
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.
