Opinion: Can the Military Solve Aerospace’s Development Problem?

Credit: Boeing

It is no secret the aerospace industry has a design and development problem. Most new jetliner programs over the last 20 years, including the Airbus A380 and A350 as well as the Boeing 777X and 787, dramatically exceeded their development timeframes and budgets. Seven to nine years or more is standard for clean-sheet programs. This is a far cry from the 777, which took five years to develop and deliver on time in 1995. The situation in military aerospace, from the KC-46 to the F-35, is equally dismal.

Model-based systems engineering (MBSE) is emerging as a potential solution to aerospace’s development problem, with the promise of reducing development times and budgets by 30% or more. What is MBSE, where has it made a difference, and what are its prospects?

MBSE is a model-centric, front-loaded engineering methodology that replaces document-centric and test-based development approaches. It breaks down barriers between engineering functions and enables rapid evaluation of alternative designs, including their manufacturing and sustainment costs, through simulation with digital twins. It is a key element of Industry 4.0.

While MBSE is already making its mark in the automotive industry, there are relatively few examples in commercial aerospace. The 777X’s folding wingtips may be the best-known example, but the aircraft has yet to enter service. Airbus plans to utilize MBSE on its A321 XLR. Boeing planned to use it on the new midmarket airplane (NMA) until its cancellation. And Irkut is using MBSE for some systems on the MC-21.

Much of the early implementation of MBSE is in military aerospace. Boeing used the methodology with its “Black Diamond” approach in winning bids for the MQ-25 and T-7 trainer programs. The A-10 rewing and B-52 reengine retrofits will require MBSE, as do numerous black programs. 

Notably the U.S. Army’s Future Vertical Lift initiative will require MBSE. One of the first deliverables, in early 2024, will be a virtual prototype (VP) of the Future Long-Range Assault Aircraft. The Army will then be able to “fly” the aircraft on virtual missions to assess flight performance and analyze operations and sustainment costs. Mandating a VP deliverable is a new requirement for a U.S. military program.


Northrop Grumman may possess the most advanced MBSE capability of any major OEM. It leveraged MBSE to cut the development time and budget of the Omega solid rocket motor by 50% before the program’s cancellation and will apply it in the Ground-Based Strategic Deterrent program as well as the B-21 Raider stealth bomber. Early results for the B-21 are promising. Despite being one of the most complex aircraft ever, the program is on budget and only slightly behind schedule. 

Why is military aerospace leading the MBSE wave thus far? First, the customer is fully committed, willing to pay for it, and requiring it for new programs. With the U.S. pivoting to a near-peer threat environment laden with new technologies, increasing the pace of innovation while avoiding massive overruns is paramount. Former U.S. Assistant Secretary of the Air Force Will Roper was an outspoken advocate of MBSE. There are no equivalent customer advocates in commercial aerospace; no airline CEOs are demanding it. Second, military aerospace boasts a plethora of new programs to enable OEMs and suppliers to climb the learning curve. Finally, the risk of military development programs is usually backed by the taxpayer.

Is MBSE’s promise hype or reality? Industry opinions are split. Cynics point to the lack of tangible examples and the difficulty of implementation. Much like the lean and six-sigma movements of the past, successful implementation of MBSE requires changes not only to longstanding processes but also to company culture. That is very hard. Its supporters view it as an integral element of Industry 4.0 and the best way to tackle aerospace’s development problem. Former Boeing CEO Dennis Muilenburg called it “absolutely key” to cementing the case for the NMA. Current CEO Dave Calhoun recently said Boeing’s next aircraft will be more about changing business processes and cutting costs using MBSE and other enablers than developing a new propulsion package. 

We should know in the next five to seven years which side is right. The industry’s experience with high-profile programs like the B-21, FLRAA, A321 XLR and (hopefully) Boeing’s next jetliner program will determine if MBSE can address aerospace’s development problem. For the good of the industry, let us hope that its proponents are right.

Kevin Michaels

Contributing columnist Kevin Michaels is managing director of AeroDynamic Advisory in Ann Arbor, Michigan.


Instead of bla, bla, bla about MBSE, better have a close look to the way SpaceX operates.
MBSE is a buzzword for techniques that have been used by aerospace engineers for decades. The fact that the information is digital instead of on paper is irrelevant. Proper engineering still requires competent and experienced people to understand what they are looking at and to develop systems that satisfy the requirements. Unfortunately, MBSE has turned into a video game where people spend far too much time on the process and far too little on the product. The result is that MBSE enables new and creative ways to screw up. Engineers and designers spend way too much time making a model look pretty, including every single fastener implemented with precision to three significant figures, but they haven't even developed the lines of action and load paths first. The result is a huge and overly complex model that takes so long to load on a workstation that most users turn off layers that they don't think they need. This has resulted in further errors when they didn't realize that there were propellant lines in the way of the harness they just routed. Similarly, the time spent building these excruciatingly detailed models not only wastes manpower but lends an air of "reality" when in fact structural and dynamic analysis hasn't even been performed. The mass properties engineers release margin based on this "reality", and a year later the vehicle is over weight and the design won't close. How about we just get back to competent engineering?
The Skunkworks development paradigm is crazy fast, efficient, cheap and proven. We don’t use it because it doesn’t require a lot of management so management doesn’t like that.
It might be worth looking back a bit, to WW II. The industry produced new and/or revised airplanes in short order - B-29 troubles not withstanding. Lessons learned are often forgotten - sadly.
The comments to date, reflect the current condition of engineering with amazing accuracy. The designs come from rational thought by the engineers. Tools should aid the engineers in the capture and organization of their thought products. Instead, they concentrate upon looking pretty and eating resources like candy. In addition, this is a front loaded effort in that it has to proceed and direct discrete engineering, not happen in parallel with it. System engineering comes first and should never be relegated to simply being a design-knowledge-capture function. Another drawback is the advent of the Agile process. Defense is not a place where we can stand the-blue-screen-of-death in the middle of a battle. We have to get it right, we cannot afford multiple, error ridden generations. Thought processes and products do not happen in accordance with a two week schedule. I've seen this process consume 25% of a working schedule - can't help but wonder who sold management on the value of that approach! In conclusion, we know that the system engineering process is time proven and it is past time to get back to those proven processes.
MBSE is a tool to help visualize and analyze the systems engineering process. If you can't do systems engineering well, you won't do systems engineering using models well. Organizations who don't do root cause analysis of their SE issues will realize no benefit from a model based version of it since MBSE is only as good as the model design and inputs.

Making it a requirement for contracts only makes sense if the folks doing the SE inputs know what they are doing. This means every step of the systems engineering "V" still applies.