Digital Engineering: Why every engineer should be part of the MDO process

Big changes in aircraft development are coming. The COVID-19 pandemic is having massive implications on commercial aviation. With the entire industry coming to a grinding halt, state governments have acted quickly to protect the A&D industries that are so critical for the economy and national security. France for example has issued a €15bn rescue package to Airbus and Air France. But countries are seeing these rescue packages also as an opportunity to address climate change, supported by societal trends such as “flight shaming”; as part of the French bailout, Airbus will have to ramp up investment in alternative technologies such as hydrogen and electric airplanes.

On the defense side, radical change was already on its way. Prior to the pandemic, the US Air Force issued a plan to develop a future fighter in five years or less, in what’s become known as the “Digital Century Series.” Three industrial technologies will be key to reach this goal: agile software development, open architecture, and digital engineering, with the latter being the most relevant to the modeling & simulation community.

A big component of digital engineering is multidisciplinary design optimization (MDO). It is key to develop disruptive and alternative concepts much faster and keep costs under control. Since MDO brings tools, processes, and people together, it is the only available method to fully explore and understand the entire design space, balance competing objectives and constraints, and ultimately find the optimal solution - all driven by intelligent computer algorithms.

Given this notion, one would think that MDO is already prevalent in any organization. We can note however that in many instances, especially in the conservative A&D community, MDO is still being practiced by only a relatively small subset of engineers - if done at all. Sometimes a dedicated MDO team is set up in a conceptual design environment, and in some cases, an MDO framework is exercised by domain engineers to run single-disciplinary optimization scenarios. Large scale implementation across all disciplines is rare, however.

MDO is often seen as an ‘expert-only’ application, feared by the inexperienced. In this article, I will try to make a case as to why, with the right technology, every engineer can and should be part of the MDO process, much to the benefit of the digital transformation of the entire organization.

Democratization of optimization

One can observe that in many large A&D organizations departmental silos exist. These silos are great for building domain-specific expertise, but consequently, the walls that get built between them might hurt cross-collaboration. For example, when domain-specific models are required to set up an MDO workflow, an MDO expert often has to collect and integrate all the relevant models and start the optimization process. However, it is not uncommon to face reluctance from domain experts to share their data, simply because they fear misuse and losing control. “It is not ready for sharing yet” or “What are you planning to do with it?” are a common reply when asking for data. Models are never ready and never perfect though, yet these less-than-perfect models may already provide valuable insights.

It is human nature for individuals to want to develop something to the best of their abilities which will put them in a positive light. Asking them to make a change that will hurt their performance in order to achieve gains elsewhere might lead to friction - especially if the big picture is not visible to them.

By being protective of domain knowledge and aiming for the best domain-specific performance however, opportunities for true innovation and revolutionary designs that can only come as a result of collaboration can be missed out on. Instead, if all engineers become part of the MDO process, they will immediately see the broader picture and become more open to sharing and contributing. As quoted in the book “Countdown 1945: The Extraordinary Story of the Atomic Bomb and the 116 Days that changed the World” by Chris Wallace: “And Los Alamos was a security nightmare. Too many people worked together in one place, toward a common goal. To prevent espionage, General Groves insisted the project scientists keep their work compartmentalized, limiting the number of people who knew the overall scope and progress of the effort. But Oppenheimer took the opposite track. He encouraged scientists from different departments to meet, share their work, and cooperate. Oppie often moderated these discussions himself. It fostered creativity, efficiency, and teamwork.”

Given the academic nature of MDO, engineers who don’t have deep knowledge of optimization often incorrectly think that this is not for them. While it’s true that a large organization should always have a team of MDO experts who can develop best practices and oversee the entire process, MDO doesn’t have to be limited to them and the larger modeling & simulation teams; if a test engineer has valuable experimental test data he should be able to share that in the same MDO framework, even if he would never run any simulations or exercise MDO himself.

MDO is agnostic and can be applied to any discipline. Structures, airfoils, electrical systems, hydraulic systems, fuel systems, environmental control systems - all these systems require domain-specific simulation tools, but they can all be integrated and optimized in the same MDO framework.

By institutionalizing MDO a culture of sharing and collaborating can be fostered, and MDO can be scaled up across the entire organization much to everyone’s benefit. In this case, however, properly managing the simulation and process data (SPDM) is of utmost importance. Data needs to be version controlled, accessed by authorized users only, and permissions regarding running, editing, viewing, and contributing need to be properly managed.

This leads obviously to the question of which framework(s) can enable such a culture shift. Requirements for such a framework include ease of use, ease of installation and maintenance, ease of integration of existing internal tools, ease of access across every geographic location, ease of connecting to execution machines, and security.

Commercial versus open-source

When deciding on an MDO framework, there are quite a few choices. It is tempting to look at cost only and decide on open-source (nothing beats free) but such a tool will not drive an enterprise-wide digital transformation.

Open-source tools are typically developed by experts in academia, government laboratories, and research institutes. They might work very well for the specific application they’ve been intended for (usually focused around the two dominant domains in aerospace, i.e. structures and aerodynamics) but as with anything free, there is a hidden cost.

A lack of a sophisticated user interface, third-party tool integration issues, potential security threats, and no dedicated support and maintenance infrastructure won’t convince the non-expert from industry, where deadlines and deliverables are real, to come on board. “I spend more time coding, hacking and scripting than running optimization” - a comment from an aerospace engineer working at one of those government labs. Make no mistake though, these open-source frameworks can do a great job in research, where experts continue to push the boundaries and develop techniques or algorithms that may eventually show up in a commercial framework. But relying on them for a large scale deployment in an industrial environment with many casual users would be advised against.

So commercial it is. Over the past 2 decades, a dozen or so commercial MDO platforms have been developed, each with their own strengths and weaknesses. The majority of them are desktop clients however, which have their own significant limitations regarding collaboration and SPDM.

Server-based versus desktop

In a prior article, I already elaborated on the benefits of a server-based approach. As stated then, desktop tools will continue to be relevant for certain scenarios. However, if the goal is to shift cultures and scale-up MDO across the organization, streamline work and collaborate, and manage data and processes, only a server-based framework with a web interface can do so efficiently - especially when geographically dispersed teams need to be brought together. Think Google Drive for MDO.

While quite a few desktop frameworks exist, there are only a handful of commercial server-based frameworks currently available. VOLTA from ESTECO, which was highly praised by Lockheed Martin in the context of the AFRL EXPEDITE program, especially regarding ease of internal tool integration, flexibility regarding distributed execution, and modeling lifecycle management, is one of them. You can read more on that in the paper “Expanded MDO for Effectiveness Based Design Technologies: The EXPEDITE Program and Successes with ESTECO Technologies”.

Cost and ROI

Of course, at the end of the day, a check has to be written and returns on the investment are expected. While every customer deployment is unique, and most software vendors don’t publish their price list, a decent order of magnitude for enterprise-wide installations in large A&D organizations would be $1-5MM annually. Not cheap, but having to make changes late in the design process or missing out on new sales is far more expensive though. One can look at software as an expense, one can see it as a saving. So while it is true that a digital engineering transformation will require an upfront investment in software and labor, done right it pays back for itself quickly.

How quickly? A good example of the benefits of MDO was recently published by Embraer in a paper titled “A case of success: MDO applied on the development of the Embraer 175 enhanced wingtip” where Embraer discussed the optimization of a new winglet using ESTECO MDO technology. This new winglet resulted in a fuel burn improvement of 6.4% and led to a market share increase from ~40% to ~80% compared to the CRJ 900 - a 100% increase!

All this was achieved in under 2 years from receiving the market request to product certification. How’s that for an ROI?

Societal changes with the flying public becoming more concerned about the environment, governments acting as change agents and rising geopolitical tensions are driving the need for faster development in both commercial and military aviation. This can only be achieved by embracing digital engineering at an enterprise level, of which MDO is a critical component. It is clear that democratization of MDO and company-wide collaboration can only happen with a friendly-to-use modern commercial server-based framework that integrates any existing tool, manages the simulation and process data, and offers flexibility regarding distributed execution.

VOLTA is a good option to consider. Oppenheimer would approve.

Digital engineering, digital transformation, digital twin, model-based engineering, and similar terms have become popular buzzwords over the past few years. There are many aspects to digital engineering beyond the development of an aircraft, such as manufacturing, maintenance, operations, etc, all fields of expertise of which I have no knowledge. In the context of this article, digital engineering refers to modeling & simulation in the development of an aircraft.