The Greatest Challenge in Collaborative Design

Wikipedia ¹ defines complex system as a system composed of many components which may interact with each other. By extension, teams from different disciplines must work closely together during complex system development, relying on each other’s expertise and input.

However, even in small companies, different teams can sometimes operate with distinct procedures, or interpret the same company process in contrasting ways. It’s also common to see completely disparate organisation of documents and engineering artefacts across different teams.

Without proper means to collaborate, teams struggle to work together effectively, making it challenging to produce feasible designs, let alone optimal ones.

This is a challenge I’ve encountered many times in my own work as a Systems Engineer. I’m Joy, the founder of OptimiSE, and in this article I’ll share a step-by-step methodology I developed to help engineering teams collaborate more effectively — even when they work with different tools, processes, or models.

Daily Struggle as a Systems Engineer

In one of my previous roles as a Systems Engineer, I faced a particularly challenging situation. My team and our directly interfacing team operated in entirely different ways and used completely different engineering toolsets.

While we conducted all our evaluations and analyses using Python, the other team relied exclusively on MATLAB. Data transfer between us was done using zip files, and every time there was a design change, the back-and-forth updates of our respective models took at least a week to finalise. By the time we settled on the updates, the next design change was already imminent.

To address this challenge, some companies may mandate that all teams use the same engineering tool, under the guise of unifying the organisation. However, this approach can be counterproductive.

Not only might the chosen common software be unsuitable for all system teams, but it also undermines the principle of giving teams the autonomy they need to perform their jobs effectively. Additionally, it may require discarding perfectly functional legacy models and creating new ones, adding unnecessary overhead.

How to Implement MDO Using MBSE: Step-by-Step Guide

Since the start of my career in Systems Engineering, I have been a strong advocate for Model-Based Systems Engineering (MBSE). I believed that the solution to the nuanced problem of collaborative design lies in MBSE. Over half a decade ago, while working with the Research and Technology team at Airbus, I developed a workflow ² that began to bridge the gap in collaborative design using MBSE.

Since then, I have refined and implemented this methodology across various engineering organisations. The paradigm shift in technology towards more openness, especially with the advent of APIs, has enabled a seamless integration of various disciplines. This transformation has allowed for a more cohesive and efficient design process, described in these five steps.

Step 1: Formulate MDO Problem

The first step in designing a system is to formulate and define the design problem. A design problem is sufficiently defined when the following elements are understood:

• Objective — the ultimate goal of the design, distilled into a quantitative metric
• Mathematical functions of each disciplines — the dynamics and interdependencies between multiple components
• Design variables — independent aspects in the system that can be freely modified
• Constraints (if any) — physical or engineering limits that must be met for a feasible design

With these information, we can formulate the Multidisciplinary Design optimisation (MDO) problem as follows:

The above represents a generic MDO problem with an objective $f$, design variables $x$, $z$, intermediate state variable $y$, and a constraint $g$.

Want to learn more about what MDO is? Check out our latest article here!

Step 2: Create System Model

Next, a system model should be developed focusing on both its form and function. This system model should be no different than any ordinary model created as part of an MBSE workflow. However, any variables or parameters that appear in the MDO problem should be included in the system model, and their relationships clearly defined.

In SysML, this information is expressed in the Parametric Diagram, Internal Block Diagram, Block Definition Diagram, and possibly also State Machine Diagram too. On the other hand, using Object Process Methodology (OPM), our preferred MBSE methodology, both the structure and behaviour of the system can be captured using the same kind of diagram. Structure is described using objects and structural links, and behaviour is described using processes and procedural links with the objects.

Step 3: Connect Domain Models to System Model

Once the system model is in place, domain models can be connected. Domain models here refer to the various analytical models from each individual system or design domain. These could be MATLAB files computing the planform of the wing or Python scripts calculating the weight of the landing gear.

Integrating domain models with the system model is analogous to a microservice architecture, known for its modularity and scalability. Design teams enjoy the autonomy to develop and deploy their domain models independently, using the engineering tools most suitable for their task.

Connections between these models are facilitated through an API. In an OPM model, the process that computes the landing gear weight is linked to a Python kernel running the corresponding script via API. The result is then passed back to the system model. Similarly, this setup can be achieved with SysML using the standardised API introduced in SysML v2.

Step 4: Orchestrate MDO Using System Model

The system model is created to orchestrate design optimisation involving multiple disciplines that do not naturally communicate easily. By using the system model as a mediator, data transfer between different platforms such as MATLAB, Python or CAD software can be facilitated easily, allowing MDO to be performed holistically while domain models are developed by experts with full autonomy in a distributed manner.

In practice, the MDO process starts by executing the system model with some initial values for the design variables. Following a predefined sequence based on the problem formulation, the system model queries the connected domain models and solves intermediate state variables to compute the objective and constraint(s). This process iterates, with the system model continually refining the design variables until the optimal value for the objective is achieved.

(Bonus) Step 5: Use System Model for MBSE Activities

Ultimately, design is just one part of system development. Leveraging MBSE, design optimisation can be seamlessly integrated into systems engineering in just four steps. The same system model can then be used for requirements management, validation, and verification activities as well.

Furthermore, the availability of design data enables more informed decisions during trade studies. For instance, in one of our use cases, the payload of an aircraft was traded against its range. Initially, the system model orchestrated the MDO to maximise the range for a set of fixed payloads. The resulting family of optimal designs was then synced to a PowerBI dashboard, allowing company executives to make business decisions about which combination of payload and range best aligns with their target market. This vertical flow of information from design to business significantly enhances the efficiency of system development.

Final Thoughts

In this article, we explored one of the core problems encountered in engineering organisations: the lack of an effective collaboration means for diverse design teams. By leveraging MBSE principles, we can bridge the gap between them, achieving optimal system design even if they use completely different engineering toolsets.

Although implementing MBSE is already a significant feat, the benefits of integrating MDO should not be overlooked. MDO can be implemented as early as the conceptual design phase, with domain models maturing alongside further system development. If your organisation could benefit from MDO and MBSE, don’t hesitate and seize the opportunity today by booking your free initial consultation with us here.

¹ Wikipedia Contributors (2019). Complex system. [online] Wikipedia. Available at: https://en.wikipedia.org/wiki/Complex_system.

² Au, J. and Ravindranath, R. (2020). Bridging the Gap Between Architects, Engineers and Other Stakeholders in Complex and Multidisciplinary Systems – a Holistic, Inclusive and Interactive Design Approach. INCOSE International Symposium, 30(1), pp.153–167. doi:https://doi.org/10.1002/j.2334-5837.2020.00714.x.