Optimizing systems engineering begins with digital transformation – Transcript
In this episode of Talking Aerospace Today, Todd Tuthill and Dale Tutt discuss why companies need to build a foundation in digital transformation and the comprehensive digital twin to build a holistic approach to systems engineering with return-on-investment.
Patty Russo: Greetings, and welcome to Talking Aerospace Today podcast from Siemens Digital Industries Software. I’m Patty Russo and I’m responsible for global marketing in A&D for Siemens Digital Industries Software. Thank you for joining us today. We’ll be wrapping up our discussion with our Vice President of Aerospace, Defense, and Marine, Todd Tuthill, and our Vice President of Industry Strategy, Dale Tutt. We’ve been talking about the future of systems engineering in aerospace and defense. In our previous episodes, we talked about the importance of collaboration and connectivity across domains and the entire product ecosystems when it comes to systems engineering. We also covered the importance of recent technology advances such as SysML v2 and artificial intelligence. Let’s jump right back in and I’m going to start with a question for Todd.
Patty Russo: So earlier we talked about the naming criteria for SysML v1 versus v2 and earlier we talked about, Todd, you commented on the name of this discipline, model-based systems engineering, and it almost seems like from our conversation and then just from, you know, working in this area, that today, because of the advances in technology and the development software technology that’s available for engineers, that we’re finally able to deliver on the promise of, and the vision for, MBSE from way back when. And I say that because what seems to be true in some pockets is that model-based systems engineering or MBSE in some areas, companies in some regards have been slow to adopt it or it’s been difficult to adopt. Is that a fair statement and is this kind of the next evolution of systems engineering because of the convergence of all of these advances in software? And Todd, I’ll point that question first to you and then Dale, if you want to comment.
Todd Tuthill: Okay, so lots of levels of that question. I’ll start with what you said. Have companies been slow to adopt it? I’ll say yes, I’ll say companies, I’ll maybe be more specific. I think companies who have adopted it, SysML v1 in many cases, have invested a lot in it and then said, “Where’s the beef? Where’s the ROI?” And I’ve talked to so many companies in various levels. I’ve been to INCOSE conferences and heard the discussion. Okay, we kind of created what SysML v1 did, in Todd’s opinion, what SysML v1 did and those tools created a cottage industry of people who are really, really good at creating these really sophisticated model. And I’ve seen things modeled in SysML v1 that were down to the transistor level of a circuit. And I had an engineer who worked for me once in a company I won’t name who said, “Gee, Todd. I designed a whole power system in SysML v1.”
Todd Tuthill: And that was a horrible thing to do because he designed down to the transistor. I said, “Yeah, that’s the wrong tool for the job.” And SysML v1 created this cottage industry of these models that only systems engineers could use. They were silos. And I think that a lot of companies went down that route and then said, “Okay, I invested all this money. What did I get for it?” And I think that’s the thing that we’re trying to solve with SysML v2 with it, not just being a modeling ability, but really look at, like Dale said, what’s the output of it is. Is it just a nice looking model or is it a tool that I can use for analysis and integration and really a framework? I’ve heard it described as you know, I want to build a machine that lets me build all the machines I want to deliver, and I really think of where we want to go with SysML v2 in modern day systems engineering as building the platform in my company, to be able to build the products I want to build more efficiently.
Todd Tuthill: And that’s where I think we want to go. I think we’ve yet really in many cases to realize that vision of systems engineering because of the cottage industry we created with SysML v1 and this idea of pretty pictures.
Dale Tutt: Yeah, I have to add on to what Todd was saying. I was, SysML v1, creating that cottage industry, what a great characterization because it was, really, it became the realm of highly specialized engineers and so they, because they were creating these models, and so to do it right, you had to really have pretty specialized knowledge. And then sometimes it’s where do you find the balance of complexity in your system models and actually getting ROI for the company. So there’s a lot of investment and they’re like, “Okay, so what did we get out of this? Did it actually prevent us from having a problem once we got down into the field? What did it give us?”
Dale Tutt: And so when companies are slow to adopt it because of that, I think, because of some of the challenges they’re having, I believe it’s fair to say that there’s companies that are doing it because their government, their DoD or NASA customer required them to do it, and so they do it, but it’s really not they’re not using that information to actually drive a lot of their downstream function to really develop their products more efficiently and then build them more efficiently and get through their test program. So, to me, the complexity of SysML v1 makes it hard to adopt and really hard to show any ROI. And then sometimes when they do start to adopt it, then they don’t adopt it completely. And so then again, it really just becomes, I almost hate to say the word, kind of feels like busy work. We’re doing it because we have to, but we’re not really seeing the value out of it. So we just want to kind of, we’re going to get through this step and then we’re going to move on.
Dale Tutt: And I know that’s maybe a bit of an oversimplification of the challenge, but companies, if they don’t see value of it, they’re just going to do what they need to do to move on. And so I think this is where we’re starting to see now, when you start to think about SysML v2 that it’s about developing the architectures, and it’s about a process and methodology to get you the architecture. And that, companies will see value in and that will make it easier to adopt. And so I think that’s really what’s going to be the change here. And I’ll just add to that that systems engineering is not something you do in the early parts of the program and then you stop and then you move on to other activities. And certainly in some of my past lives, that’s how we did it.
Dale Tutt: And systems engineering is across the lifecycle. So you have to have it on a good PLM foundation that allows you to take the outputs of those early systems engineering activities, those architectures, the requirements that flow down the requirements for verification testing, all of those activities that come out of the early systems engineering phase, they need to be used to drive the design. They need to drive the manufacturing processes. And so you have to have that tie in to the downstream functions in order for your upstream functions of systems engineering to be truly helpful. And so I think that’s really where you going to start to see the difference in the value, is that you’re actually taking those outputs. You’re not just creating a bunch of diagrams because you had a requirement to do it, but you’re taking the architectures that come out of that process and you’re actually using that to go faster and take risk out of the rest of your program.
Patty Russo: So speaking of risk, Dale, what is the risk? I think you read my mind because you touched on a couple of the things that I was thinking about for this next question is, what is the risk, Dale, if the systems aren’t optimized or considered, or that interoperability isn’t managed early and often through the process? What are the risks in the developed product development process or once you get to manufacturing, if companies aren’t adopting some of these new technologies? What’s the risk?
Dale Tutt: Yeah, great question. And this can apply to just about every industry by the way. So if you are, as you’re developing a new product and if you haven’t fully optimized those systems or at least make sure that they’re interoperable and that you’ve addressed all the requirements, the risk is generally a couple things. One is you’re going to get into your test program and that’s when you realize something doesn’t work. And sometimes it might just be, well, it didn’t work and so now we have to go back and do a bunch of new engineering, new testing. And oh, by the way, we’re already building our, we’ve already started our production lineup, so now we got to go back and make changes to our production line. That’s what drives cost and schedule.
Dale Tutt: And so when you look at aerospace programs, sometimes the biggest source of the delays of the program is because we found something in the test program, and not only did we have to go in and change our prototypes, but we also have to go change the 30 aircraft that are already in production. That is costly. It adds weight to an aircraft because you suboptimize the system. You now are adding more to the airplane and so it’s a tremendous cost and schedule impact. But beyond that, you run into problems when you’re manufacturing that because you maybe did not incorporate the right requirements into the production line.
Dale Tutt: Now it becomes harder to do your functional testing of your aircraft or your car, or your whatever system that you’re building, whatever product that you’re building now you’re having manufacturing problems, you’re having quality problems. And then, we’ve already talked about some of the maintenance issues downstream that we’ve seen with recalls. And so it’s all of these things. At best it’s a cost and schedule impact, at worst it’s something catastrophic and that’s I think that’s what we really want to try to avoid with that and make sure you have a good systems engineering approach to take care of that.
Patty Russo: Todd, do you want to add anything to what Dale just shared in terms of the potential risks if you’re not considering this upfront?
Todd Tuthill: You know, I’ll just amplify things Dale said. There are simple impacts, cost and schedule. It takes me longer to get the product out. If you think we talked about shifting left, certainly we want to find all the problems we can find with our product as soon as we can find them in the digital realm before we build it physically. But if we’re not going to find it there, we certainly want to find it in test. The last place we want to find a problem is in practice, and we’ve all seen catastrophic failures of aerospace things, aircraft or spacecraft, that have caused people to die. And that’s the ultimate cost from a lack of systems engineering.
Todd Tuthill: You know, a problem with a tile on the spacecraft to a satellite that I couldn’t deorbit because it ran out of fuel before I tried to deorbit it, to a scooter that caught on, my seven-year-old’s scooter, they caught on fire in my garage. Those were all, at their heart, systems engineering problems that we need good fundamental systems engineering to solve.
Patty Russo: Yep. So my summary oversimplifying is that regardless, you know, we’ve started talking and focused on space relative to systems engineering, but obviously this conversation applies across many industries. And if I oversimplify, I apologize, but it sounds like the key is planning early, designing, and having a view and collaboration in context, you know, the system and context of other systems and the whole product versus just looking at one system in isolation and being able to iterate and develop that throughout the entire life cycle in context.
Patty Russo: So it, you know, and again I mentioned before, it sounds like the convergence and the development of technology today the advance are finally helping customers realize that that vision of what was MBSE but now we’re looking at just a more holistic approach to systems engineering. So we’re reaching our time, and I wanted to ask a question or two just to wrap things up. Is there anything that we haven’t touched on, Dale, I’ll ask you first, is there anything we haven’t touched on that you feel like would be beneficial to cover related to the look back and then the look forward on systems engineering development, in particular for the space industry?
Dale Tutt: Yeah, I just have a couple of thoughts. It’s been great being on the show here and having this conversation today and I really appreciate the opportunity. We’ve talked a lot about systems engineering, but I will just say we really we need to also mention the fact that good systems engineering practices in the future are going to be really about being part of a strong digital transformation program, that you need the comprehensive digital twin in order to really make a lot of these new approaches around systems engineering to really be effective.
Dale Tutt: You know, model-based systems engineering around system modeling, but when you start looking at it holistically and you start talking about the fact that you want to incorporate your systems, your simulation models, that you want to be multi-domain with electrical electronics, software, mechanical, and then you want to start to automate some of these processes and bring in AI so you can start to accelerate some of your development. You got to build that on the foundation of the comprehensive digital twin to really be successful with this.
Dale Tutt: And so I think that’s an important thing to mention. And then just, we’ve talked about a little bit, but really being within an open environment and open ecosystem, to be able to bring these tools together in a way that’s actually meaningful for companies to help them get return on investment is a critical part of that digital transformation as well. So I think that when companies really start to do this, the impact that they’re going to have in order to go faster, to be more innovative, I mean, we talk about faster and innovative. Why do they need to do that? Well, because there’s someone else that’s out there trying to be faster and more innovative than you are. So you got to stay competitive and I think this is the key tools for doing that.
Patty Russo: Todd, anything to add?
Todd Tuthill: I think this this would be the summary. If you think about, you know, before the Apollo program, there were no systems engineers. The Apollo program kicked off systems engineering and we talked about the path through SysML v1 where systems engineering kind of became a cottage industry. If I could paint my picture of Nirvana in aerospace engineering, it’s that everyone is a systems engineer. There are systems engineering aspects that are part of all aspects of engineering now. And Dale talked about the comprehensive digital twin, talked about digital tools, and I think really the advance in digital tools and things like that really allow all engineers to have access to be systems engineers, to, in other words to think broader, than just, I’m not just designing a part, I’m designing an aircraft.
Todd Tuthill: And digital tools give that all those engineers access to broader information, to simulation, to a broader understanding of how will the part I’m designing affect the whole? And I really think that’s to me, and what are the requirements I’m satisfying? How does what I’m doing affect their worthiness and safety? And I think engineers at every level need to consider that as opposed to just, I’m designing a part I’m designing a thing that’s going to carry people, that’s going to solve a problem. And to me everyone’s a systems engineer and I think digital tools really enable all engineers to think that way.
Patty Russo: It was a great conversation today and that’s a great summary. Todd, thank you. And Dale, thank you for joining us. My takeaway from the conversation is regardless of a company’s maturity level, regardless of a company’s industry, it’s time to rethink the approach to systems engineering full stop. So I’ll leave it there. I think there’s some opportunity in the future to talk about whether it’s isolated conversations or perhaps another podcast is, you know, where do companies start and where do they go from where they currently are? But topic for a different day. We’re at our time limit and I want to thank both Todd and Dale for contributions for the conversation today. Thank you to our listeners for joining us.
Patty Russo: Discussions like these just show us how quickly technology changes, how important it is for the industry to, you know, we need to listen to what’s happening not just in our own industry but other industries. Be ready to be flexible and adaptable, and the good news is that technology today is allowing us to do that. We hope that you’ve learned, taking away something today that you can apply in your organization. We’ll be back soon with more episodes on systems engineering in A&D. I’m Patty Russo. And we’ll see you next time on Talking Aerospace Today.
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.
