Tackling smart aircraft with connected solutions
Smart, connected, and sustainable products – with increasingly more complex multi-domain integration between embedded software, microprocessor-based controls, and electronics – present greater and greater product development, validation, and certification/compliance challenges for our customers across all industries, but especially for those in Aerospace & Defense and Automotive. Sustainability is now a key requirement across all industries. Increased electrification is driving need for more integration with software. New configurations require faster simulation, testing, validation. And these are just a few of the considerations our customers face. Customers need the ability for a broader impact of systems integration on product development processes, organizational complexity, and on the overall business.
We know we are not alone in thinking about these obstacles that continue to steepen. We hear our customers talk about these issues on a daily basis.
We recently caught up with Brett Hillhouse from IBM and Todd Tuthill from Siemens Digital Industries Software and asked them a few questions about their insights on where MBSE is today and where we need to take it tomorrow.
What follows is the transcript of that discussion:
Question: What is MBSE today, and why is there a need for a new approach?
Todd: Today I see MBSE as the beginning of the digital transformation of systems engineering. We are just at the cusp of what’s next. There’s a long way for us to go and lots of opportunities for us to grow, especially considering the demands for integration of systems and software that we never could have imagined even 5 years ago. Customers are at a tipping point, risking missed targets and costs that will drive them out of business. We in the industry have an opportunity to help them leverage digital transformation in the area of MBSE.
Brett: When we talk about MBSE, I think we’re talking about digital engineering, which has an implication of the full digital thread. I think we still do a lot of throwing stuff over the wall, which doesn’t work anymore. We need to get to a point where models have seamless traceability across disciplines and across what are traditionally developed in very different and very separate tool sets.
Question: What kind of interconnection do customers in the Aerospace & Defense and Automotive industry need in the future?
Brett: You can look at it in two different ways. One is certainly looking at the tools. But we also need to consider the process. For example, we have to engage with EEs who are doing wiring diagrams and network design. Then we need to look at how we integrate that with the system model and how to apply that down to the software and deployment. All elements of the product need to be tied together. That’s a really good lesson learned from the process and personas work we’ve been doing to figure out how to advance the entire toolchain.
Todd: I agree. We talk about tools a lot, but the problem we need to solve is the tools and more. In addition to the tools, it’s about connecting processes and people. It has to be holistic. It’s the combination of all of these things. And, if you lack any one of those three in transforming your company’s approach to interoperability, you won’t go very far.
Question: What do you say to someone who says, “Look, at our company we have people trained in MBSE and we’ve been doing lots of models let’s say in SQL. Where should we be looking for the benefits of MBSE? Is it just some kind of secret sauce like if we just do a bunch of MBSE models then good things will just start to happen somehow?” …What is it that makes MBSE effective or not in a given situation?
Todd: If you think of MBSE as a silo thing and you just do ABC and life’s going to get better, I think you’re going to be disappointed. What’s key is the connection with the other aspects of engineering and manufacturing and product support and the whole life cycle of your program. In a sense, the future of MBSE is simply the digital transformation of system engineering. In my 30 years of systems engineering, I wasn’t just thinking about systems engineering. I was thinking about how I could guide and work with the design engineers, with manufacturing engineers’ office, and others across the product and program lifecycle. When you work in a silo, you see that won’t help you that much. When you can achieve the connection to the whole lifecycle of your program and your product development, you will see the benefit of that broader connection.
Brett: Another thing we have to keep in mind is that this is an iterative process. We need to realize that you have to go back and forth between an MBSE model, keeping it current, keeping it under configuration control, as well as keeping it linked to those other disciplines with some level of configuration between them. It’s a challenge for most industries, but this is a lot of the work that I see in aerospace and automotive where we’re trying to help them keep everything linked and interoperable. That includes the obvious domains, but also things like functional safety and cyber – it’s all these different elements that they’re using MBSE models for. They’re not specifically called out as multi-disciplinary today. We’ve jointly been [doing] a lot of work on this and we’re not done.
Question: What’s the purpose of doing a model at all, how are we trying to use it? As we look to the future, how much does this impact how we actually use these models?
Todd: Let’s look at bringing environmentally compliant products to market. These require a sustainability framework that can provide full transparency across the product or asset lifecycle, starting at the earliest concept stage. A true multi-domain model can do that. It is a framework like this that will link the front-end concept development within the four key domains and remain connected and traceable through the entire product lifecycle.
Question: Can you share a story where you were able to use an MBSE model successfully and how it was used more successfully than for the initial intent.
Todd: I was working for an aerospace company a few years ago and we were talking about some of the areas where we invested a lot of time money. We were looking at our testing process and we noticed we spent a whole lot of time just writing a paper document of the test and converting that a test script, then running a test script, getting results, putting the results together, creating a report. This was testing of a commercial flight control system in an Iron Bird. This testing was a key part of the commercial certification of that flight control system, and the aircraft it would fly on.
I challenged the team to use a model. I asked if we could we model the test process and the test. And could that model create the test script. Then, as the test script ran, could the test script document the results so basically we would be doing all this through a model. When we proposed it to the customer, the customer said they still wanted to see the test procedures in a paper document. So, we actually had the model create the paper document, too. All the work was done through model!
You go into a large test program thinking that you’ll run it once or twice. But we ran these tests 10 to 12 times before we were done. The automation came from the model. The model was able to do a lot of the mundane tasks that engineers would typically do. This really saved us on that program and allowed us to deliver it on time and fly the aircraft.
A lot of what we did with that model we automated a lot of mundane tasks that engineers didn’t want to do. Instead, they did the interesting creative stuff working with the model creating this whole test process and automated fashion that we used to certify commercial aircraft.
Brett: So, here’s one from an automotive OEM global company that we’ve learned a lot from, especially in this project. It was really rolling out the functional decomposition of their vehicles and on a global basis. They had not been able to do this effectively with just systems engineering guidance. So, first, we adapted it to support automotive ASPICE from a best practice perspective. We then leveraged everything from the cyber and functional safety standards that were applicable. This is an example of the level of support needed for industries to fully adopt systems engineering tools and practices – it has to be adapted for that industry’s specific requirements and standards.
However, even after all of this work, we found we were missing the specific guidance on how this applies to the AUTOSAR standard. We had guidance on AUTOSAR for Software, but not how to bridge from this functional work breakdown structure. But in working with the client, it was clear that this AUTOSAR specific work needed to be done early in the design stage. Being able to adopt it and change it and put in the methodology, while helping them understand how the tools can support that, was an additional set of work. I think it relates to us being able to better communicate to the domains that we’re talking to and by that I mean both industries as well as engineering domains.
Question: How do we convince senior level executives that a plan for MBSE is critical for the future? What do they need to make this a priority?
Todd: There was a real angst when we started with our MBSE initiative because we had never done this before. This was a risk, and I was to an extent risking my career as leader of this process. But, when we had tackled a similar task before, the method was a giant army of engineers doing all the scripting. I didn’t want to do that anymore because it was wasting resources. Instead, it made sense to let the computers do that. This approach was very successful, and It became the model for how we did all future programs. While there was risk in the beginning, I’m quite certain we would not have delivered that control system on time without this model-based process. That one example of success was enough to convince executives to do all future programs using the MBSE model.
Brett: There’s another element related to this that I’ve seen especially in automotive. The whole MBSE process has helped automotive manufacturers think about the functions on their vehicles instead of thinking about the mechanical systems behind it. For example, it’s this ECU or it’s this computer. Instead, they’re doing a functional work breakdown structure just having MBSE as a part of that. They’re looking at the vehicle in a very different way and starting to think of it more along the lines of what Tesla did to the industry and many years ago. They introduced a truly software defined vehicle and then over the course of their updates they offered continuous improvement. It’s a very different way of thinking for the automotive industry. I mean you know there has been reorganization in some of our industries where they actually called their reorganization Project Conway. Which implies Conway’s Law – your product will reflect your organization structure.
Another one I’m seeing right now is using MBSE downstream on the software side. This is because they’re seeing orders of magnitude of increased productivity and developing code by utilizing the SysML V1 down to the software level, transforming it to UML, and then allowing the tools to automatically generate the code without the engineering even needing to be a C or C++ expert. That’s been an ongoing change in the industry, as well.
Question: Look out five to 10 years. What do you think systems engineering and MBSE will look like, assuming we even use that term in five years?
Todd: When we talk about MBSE and systems modeling, and related topics, to a large extent I think we’re still in the mode of just gated models to convey information in better ways than paper documents. There’s a lot of value in that. That’s a good thing. But I hope MBSE progresses to the point where the models really do significant things such as analysis to help us make decisions and help us write code.
Another example of what I hope for in the future in the aerospace industry is that MBSE – or whatever it will be called – can provide the level of modeling and automating the mundane needed to make up for the shortage of engineers.
I’ve seen studies suggesting that in the aerospace industry, we are 30,000 engineers short right now. I’ve seen projections that show by 2030 this number will be 70,000+ engineers. This is unsustainable. This shortage will mean we’re not going to have the resources needed to design sustainable aircraft, that we’re not going to advance commercial space, that we won’t be able to design the systems we need to protect ourselves – because we won’t have the engineers!
Brett: There are two things I’d like to see developed. I want to see us continue to grow industry specificity. If we want aerospace to use this, we need to make it real for commercial aircraft. We need to make it real for defense systems. As a larger system of systems, I think we’ve done some of that, but we’re not nearly specific enough for medical devices and for other industries to be able to do that.
The second piece is looking at it down to the domain level. We are trying to understand the applicability with SysML V2. We can make it a lot more customizable and more adaptable. This is a good start, but I think we still need to [standardize] it and make it more out-of-the-box for specific industries. For example, how do you do that for a semiconductor company? How do you do that for a company mainly doing printed circuit boards? It’s a different discipline and I think we need to be more specific to that in the future.
Question: What is the role of standards? Do we need a standard language that most people have align to?
Brett: Some of those standards are there, but we could be leveraging some key standards more. However, we’re just not adopting them from the industries even though the industries have been the ones driving them.
I’ll also hit on the AI thing just a little bit. What is the right algorithm? There’s no AI expert who knows all these algorithms, nor is there anyone who is an expert in all of them. They have to specialize in certain areas. So being able to help people pick them I think that’s part of what we need to think through. I also think some of the MBSE thought process should be how we go about doing the engineering, and how this could be leveraged to understand the role of AI in the system, how you think through where you’re going to apply it, and where it makes sense.
Question: Any closing comments about the future of MBSE?
Todd: I am really bullish on MBSE and very excited to be part of this industry at this time. As we move forward, we are going to be part of something that will outlive all of us. I feel like what we’ve done with respect to model based systems engineering and digital transformation is just scratching the surface. There’s so much opportunity, I think we’ve really created a foundation to be built on the next two or three for decades to help solve so many issues – from staffing to climate change to these things that are greater than any one of us.
Brett Hillhouse is a global leader for IBM sustainability software. His responsibility to IBM includes industry and technology strategy as well as customer success for automotive companies around the world. Brett has 25+ years of industry experience including transformation engagements at global automotive and aerospace OEMs, at tier one suppliers. Previously Brett held several industry leadership positions at IBM and Siemens formerly SDRC. He holds a BS in mechanical and aerospace engineering from Cornell.
Todd Tuthill is the Vice President for Aerospace and Defense Strategy and Marketing at Siemens Digital Industries Software. Todd’s engineering background is in systems design with functional engineering and program leadership roles and a strong vision for digital transformation. His 30+ aerospace leadership career spans McDonnell Douglas/Boeing, Moog, Raytheon, and Siemens. His experience encompasses all aspects of A&D programs, including design, model-based systems engineering, software engineering, lean product development, supplier/partner management and program management. In his new role at Siemens, he is a passionate advocate for the advancement of digital transformation across the A&D industry.
