“Productivity” podcast series (Ep. #2): Orchestrate your technical program with Model Based Systems Engineering

Systems engineering is not a new approach – many companies have been using it for years. But what’s happening today is we’ve entered a period of intense innovation and we are under tremendous pressure to reduce program costs. OEMs are dealing with increased product complexity, more electrification to deliver new mission capabilities and there are more interactions between the thousands of systems, interfaces and components on a single aircraft.

As a result, OEMs are rethinking their current systems engineering approach.

This is episode #2 in a five-part series.

Podcast Transcript:

Scott Salzwedel: Hello, this is Talking Aerospace Today – a podcast for the Aerospace and Defense industry, a place that brings the promise of tomorrow’s technology to the ears of our listeners today. I’m your host, Scott Salzwedel. Welcome to episode two of our five-part series “Accelerating Productivity through Digital Transformation.”

Now, as you might imagine, maximizing productivity throughout the A&D product lifecycle is key to success and significant profits. Today, in our second podcast, we’ll be discussing ways to orchestrate your technical program with Model Based Systems Engineering, or MBSE for short. Before we get started, to recap our last episode, we talked about the trends in the A&D industry and how these trends are forcing companies to embark on their own digital transformation. There are so many exciting opportunities and ways to achieve new levels of productivity. If you missed it, I urge you to take a listen!

So, in this podcast, we’ll be discussing MBSE and the role it plays in the A&D industry. Systems engineering is so much more than simply replacing a paper-based system, as you will soon find out. I’m pleased to introduce my special guest, Dale Tutt, who is the Vice President of Aerospace and Defense at Siemens Digital Industries Software. Welcome, Dale! Thanks for stopping by! Before we dive in, could you please share with our listeners your background and your role at Siemens?

Dale Tutt: Hi, Scott. I’m very happy to be here today and thank you for having me. So, before I joined Siemens, I worked in the aerospace and defense industry for about 30 years in various engineering and program leadership roles. In my most recent position, I was the Vice President of Engineering at The Spaceship Company, and we were working with Virgin Galactic in developing spaceships for commercial space tourism. Before that, I was at Textron Aviation – or Cessna Aircraft Company – for about 18 years, and a number of engineering and program management roles there as well. In my last real big program, before I left there, I was the Chief Engineering and Program Director for this Textron AirLand Scorpion Jet. We went from a concept sketch to the first flight of an all-new tactical aircraft in about 23 months, which was pretty fast for the industry. And before that, I had some time as well at Bombardier Learjet and General Dynamics Space Systems Division – so a mix of space and aircraft in my career. But now, at Siemens, I’m the Vice President of the Aerospace and Defense Industry. And we do a lot of the industry strategy development and work on developing product solutions for the aerospace and defense industry and for our customers in the industry so that we can provide solutions that meet our customer’s needs. So, I get to work with all of our product lines and our global sales teams and it’s a lot of fun in this role, so thank you for having me!

Scott: Sure. Since this podcast series is on productivity, why don’t we first take a minute and discuss the many ways in which an OEM or a supplier can increase productivity?

Dale: We’re focusing on four topics right now. The first is Model Based Systems Engineering, which is really kind of at the heart of any new program, and it’s about orchestrating your technical program – and we’re going to talk a lot about that today. And then, our next episode will be around accelerating product design and agile product development, the tools and methods that you’re using for your design, and analysis, and certification of your product. Improving your program management with our integrated program planning and execution solution it’s really about bringing together all of the aspects of your program and effectively managing them. And then, finally, moving into manufacturing, being able to accelerate your production ramp-up very quickly so that you can start delivering products to your customers – and this is bringing in intelligent manufacturing or flexible manufacturing processes so that companies can be a little bit more agile in how they establish their production lines.

Scott: This episode is on MBSE and it’s gaining in popularity. So what is systems engineering? How would you define it?

Dale: Systems engineering is an approach where a lot of companies are using it, but it adds a little bit of discipline to the design process and you get customer requirements, and how you fold that out in your design, and then how do you verify that you actually satisfy those requirements. So that’s systems engineering. The thing that we’re seeing is – and why it’s becoming so popular – is with this increasing product complexity with electrification and with more and more software and autonomy, and all these vehicles, you have thousands of interfaces and interactions between all these systems and components that are, say, on a new airplane. This is a very big process. When you think about thousands of interfaces companies need different skill sets to manage all of these complexities and all these multi-domain challenges because everything’s so integrated.

And then, integration of these complex systems and the supplier relationships also increase the risk and cost of schedule overruns. So with all these challenges a lot of companies have been doing systems engineering in a document-based system for decades, but now they’re moving to Model Based Systems Engineering to be more effective and do a better job with their traceability. So that’s kind of in a nutshell why they’re doing it.

Scott: And I know the Department of Defense is very active in this area, so could you explain to our listeners a little bit more about what the DOD is doing?

Dale: Absolutely. The DOD, they’ve been maybe at the forefront of recognizing the need for systems engineering. NASA, also, was an early leader in this. But the systems, again, are so complex – if you think about the F-35 and how complex it is, as an aircraft, how much capability it has. And so the DOD recognized the need for systems engineering to be able to communicate the requirements better to the OEMs that were going to build the airplanes, and then having a process to check that all those requirements were satisfied, and all these interfaces are done. And when you think about what Dr. Will Roper has been saying – and he’s been advocating this digital transformation within the Air Force for the last couple of years – he recognizes that they need a better process. It’s much faster, much more agile. And he talks about the digital holy trinity of digital engineering, agile development, and open architecture. And, to be able to satisfy these needs, really, MBSE is the key to this as we move forward on that.

Scott: Okay, and then, with the civil aircraft, do we want to touch on that as well?

Dale: Yeah, we should. The FAA, and the EASA, and other regulators, also have started requiring more systems engineering as part of the certification process now. So, it’s always been part of the process, but probably in the last six to eight years has really increased in awareness. It was in ARP4754A – which is the standard that’s used for defining systems engineering – and that’s been out for, I don’t know, eight or nine years now. But it’s very comprehensive and it really defines the process and the rigor that you need to use to manage these complex systems and the safety of those systems. And so, it plays a very big role in all civil aircraft as well.

Scott: Okay, so, let’s try and define systems engineering. What are the key elements or the domains that go into systems engineering?

Dale: I started to talk about this a little bit earlier, but I’m going into a little bit more detail now. So, your systems engineering process really starts with requirements. So, you get a set of requirements from your customer, and then you might have those at an aircraft level, and then you have to then flow those down into your different systems. So, your flight controls, your landing gear system, your electrical system – all have to meet different requirements. And then, those flow down in individual components so that when you start to design, say, an electrical box, or the software that’s in the box, you have a set of requirements that you’re designing to. So, it’s all about requirements management. And then you have system modeling – so, it’s about taking those requirements, turning that into a functional definition to your system architecture, so the schematics of what your systems might look like. And then, to be able to link those to the physical design and be able to link that design back to those requirements.

System safety, which I touched on a little bit, is a key part of this process and it’s about defining requirements for your components, but also about verifying that you’ve satisfied the safety intent of this product. And then, you go through your software design and verification. And then, finally, just verification management which takes you through the process of moving from requirements into your verification plan. This is how we’re going to test and show that we can certify the product, and then into your actual testing, your test results, and showing final compliance. So, a process, really, to close the loop on all of the verification, show that you’ve met all the requirements. Simply stated, it’s about requirements management, system modeling, and verifying that you’ve satisfied your requirements.

Scott: Wow! That certainly covers a lot of ground. I mean, we’re talking about managing all requirements, the consistent and constant verification throughout the entire process; also includes software design and verification, and of course, adhering to system safety requirements from start to finish. It sounds too good to be true! I’m sure there are some challenges when it comes to system engineering. So Dale, what are some of the challenges in implementing something like this?

Dale: It’s too good to be true! But it is very challenging to go through the whole process, if you just think about the complexity of some of these products that we’re designing and you think about a new air taxi and everything that’s going on in that. The biggest challenge with systems engineering kind of comes in two different phases: in the early design phases, when you’re in this conceptual design phase, you have to be able to optimize these multi-domain architectures. What I mean by that is you’re looking at your structure, your hydraulic system, your pneumatic system, your electrical system – all the systems on the airplane – and even just sometimes the basic configuration of the airplane, and you might be looking at hundreds of options and tradeoffs. And you have to be able to keep track of all of this.

And so, it’s very important to get it right the first time because the decisions that you make early will drive the costs that you have later when you’re going through your certification process or even when you’re moving into manufacturing. You rely a lot on simulation and analysis to virtually verify that the concept design will meet the product requirements. And this is usually done a small team. I mean, I joke that sometimes, during these phases we might have 30 or 40 people working on a program. And then you bring in the rest of your product team, and sometimes its suppliers and partners. And all of a sudden, now you have four or five, 600 people working on this program. Now it’s a big task. And you need to be able to execute the design through the rest of the process. So you make decisions early in the design, in the conceptual design process, and you need to be able to carry those through to the end of the program and make sure that you get it right the first time because you don’t want to start over. You have to manage all of these people and all the partners and the functional teams, and you do this with good interface management, you’ve got to be able to manage the integration of all these partners, both on a business process as well as on the technical side. And then, you have to be able to do your design and verification oversight to make sure that everything’s getting done and that you have good visibility into the whole program.

Scott: So much going on here. Pretty complex stuff… And to manage all this, to get it all to work together, how does a company do that? What’s the answer?

Dale: Yeah, it’s a great question! And to be honest companies have been doing this for decades but they’ve been doing it in a lot of document-based systems. And so, you have information, you might have your requirements in one database and you have your system modeling in Microsoft Visio, and then your verification, your test data might be in Excel. Everything’s disconnected. So to manage it now, you have to have a digital thread for your Model Based Systems Engineering, your MBSE process that connects all of your engineering, your manufacturing, your supply chain, your program management activities – you’ve got to connect everything together. And you’ve got to be able to do this across all of your functional areas and all of your suppliers. You’ve got to be able to track your requirements and the architecture implementations throughout the entire lifecycle process. You want to be able to capture those design decisions as your product matures, why did you make a decision?

Dale: So, as I said earlier, you’re looking at hundreds of options and tradeoffs and you make a decision and then five years later, as you’re going through your design or you’re maybe finishing up your certification, someone says “Why did you do that?” You have to have that information available. It’s important to capture that knowledge so that you can use it again. And then, you have to be able to integrate these complex supply chain and product interfaces. You might have multiple suppliers working inside your wing and you have to be able to manage all of these interfaces between all the suppliers and make sure that everything comes out right. And then, finally, you want to really be able to do this in a flexible and open multi-tool solution. You have to be able to work with anything that’s out there because your suppliers might be working in different tools than you are, and you’ve got to be able to communicate. You’ve got to have this flexible and open environment.

Scott: I do believe this is where Siemens comes in. I know we have a robust and proven MBSE digital thread. So, could you tell our listeners a little bit more about the MBSE digital thread that Siemens offers?

Dale: Yeah. So this comprehensive digital thread that Siemens offers, it really enables companies and programs to orchestrate their technical program, and to be able to manage all of their technical scopes throughout the entire lifecycle of the product – and that’s important because these products might take several years to develop and you need to have that continuity throughout. From conceptual design until you go into service, you want to have that information being covered. And that’s what we talk about when we talk about this comprehensive digital thread. It works with everybody. So, again, as I mentioned, it’s flexible and open for any tools for requirements or system modeling, is going to ensure that you’ve been able to carry your architecture. When you make those design decisions upfront, you know that you can carry those architecture and the requirements throughout the design, all the way to the end of certification and have complete traceability. And then, finally, just to be able to manage the complex product and all these integrations with this seamless data sharing between your functional areas as well as with your partners.

Scott: I’m sure you’ve been on location and witnessed how the MBSE thread delivers for our customers. What have you seen along the lines of some tangible benefits?

Dale: Companies that are implementing this today, they are accelerating our product development, they are moving faster than everyone else and they’re becoming a lot more agile in their execution and their decision-making. Because of this thread, they have that traceability, that continuity, they have information. When there’s a change that happens, they can do a better job of understanding the impact of that change. They’re seeing dramatic results. They’re reducing their product development time, by maybe 20 to 30%. And that’s huge! And when you think about it, if you do a couple of programs, if you would reduce 30% each time, after a couple of programs, you’ve really made a big dent in your product development lifecycle, in your development costs.

And also, these companies are seeing 90% first-pass yield on their design and manufacturing. So, when they do their design, they’re getting it right the first time, they hand it off to manufacturing, and they’re able to build it the first time. And, if you think about it, just the cost savings that come from that. And so, I think it’s just, you know, as we look at some of the different programs, even that I’ve worked on in the past – when we’ve had good requirements, we’ve always been able to go through these programs very effectively. I had an experience, and I don’t want to mention the company, but we didn’t have a good set of requirements. So, then, the system came in, and then, we all started arguing about what we were expected to do. And so, we didn’t do the work up front, but then we had time to really debate and argue about it later on, but it just added a lot of costs. And so, when we switched over and started having good, robust requirements we just started going through the processes so much easier.

Scott: Wow! That’s really exciting stuff… It’s just amazing, the times we’re living in. Unfortunately, we’re nearing the end of this episode. I can’t believe it’s gone so fast. But there are many more episodes to come in this Productivity series. So, Dale, what can our listeners expect in our next episode?

Dale: Yeah, it is kind of hard to believe that we’re done. In the next episode, we’ll talk about accelerating your product design. And, as I said, this is a topic I really enjoy talking about. We’re going to talk a lot about agile product development, how are companies going faster as they go through their development processes and getting it right the first time – so it should be a fun discussion!

Scott: Okay, great! Thank you, Dale for this engaging discussion on MBSE, and the role it plays in aerospace productivity.

Dale: No problem, Scott. And thanks again for having me.

Scott Salzwedel: Yes. And we’ll be talking again, soon. And of course, I’d like to extend my many thanks to our listeners. I’m glad you tuned in to this podcast. Thank you, listeners. Remember at the top of the show I mentioned Dale and I will be doing a five-part series on A&D productivity. So check back here for more information on our next podcast. Also, in the meantime, you can visit us online at siemens.com/PLM/aerospacedefense.

This is Talking Aerospace Today and I hope you’ll join us again for our next podcast. Until then, bye for now…

---

---