Enhancing Ontological Metamodel Creation through Knowledge Extraction from Multidisciplinary Design and Optimization Frameworks

1. Introduction

The past few decades have seen a significant increase in the complexity of systems being developed, both in terms of the variety and number of system components and their interactions [1]. This trend is expected to continue as a result of current stakeholder demands and advancements in technology [1]. As the number of components and subsystems grows, the interactions between them become more intricate, necessitating extensive collaboration among diverse teams to manage both disciplinary interdependencies and information consistency. The growing complexity of systems being developed also presents integration challenges in multidisciplinary design efforts, making it difficult to accurately predict the behavior of systems, often leading to project outcomes that deviate from the designers’ intentions, and budget and schedule overruns [2].

With increasing complexity comes significant efforts in the design, modeling, analysis, and optimization of systems [3]. The iterative nature of engineering design studies in particular requires a comprehensive understanding of the various engineering disciplines involved. This in turn implies a reliance on the knowledge and expertise of disciplinary experts. The ability to build on previous and existing knowledge and expertise is critical to an organization’s ability to innovate [4]. Yet, knowledge within an organization is often unstructured, residing in the minds of its engineers and experts. For existing knowledge to be accessed and leveraged for future system design and development activities, it needs to be structured [5]. This in turn means that unstructured and tacit expert knowledge needs to be transformed into explicit forms [5]. Model-Based Systems Engineering (MBSE) provides a means to capture design knowledge and expertise in a centralized "authoritative source of truth" using ontologies and Semantic Web Technologies (SWT) [6,7]. In this context, ontology refers to the explicit representation of a shared understanding of the important concepts in a certain domain of interest [8]. While ontologies enable knowledge representation, SWT provides a common framework that allows data to be shared and reused across applications by providing common formats [8]. Hence, through the use of ontologies and SWT, MBSE facilitates the standardization of systems engineering knowledge and ensures interoperability among different engineering analyses.

The concept of an “authoritative source of truth”, defined by the Defense Acquisition University (DAU) as “the reference point for models and data across the system life cycle” [9], presents several advantages in systems engineering-enabled product design. In particular, it provides engineers with a foundation to reuse previous knowledge and engineering tools [10]. In engineering design, subsystem models are often developed independently and then integrated to create the overall system model [11]. However, the reuse of previously developed models can be costly and time-consuming when tool-to-tool integration is challenging. Model or tool-to-tool integration requires cross-domain interoperability and consistency management for the successful realization of multidisciplinary analyses and design space exploration studies. Indeed, by maintaining an authoritative, consistent database that facilitates communication between different disciplinary tools, designers can integrate the relevant components to address the design problem effectively. In addition, an “authoritative source of truth” aims to provide semantically consistent design knowledge to establish a shared understanding among disciplinary teams [10]. Throughout various design phases, different types of knowledge artifacts, such as charts, sketches, flowcharts, pseudocodes, ontologies, and mathematical calculations, are utilized [11]. If there is no agreement on how to interpret this knowledge among teams, computational assistance cannot be utilized efficiently and effectively. Therefore, formal conceptual modeling languages are necessary to ensure all engineers are aligned and to facilitate the integration of engineering domains in constructing the overall system model. This can be achieved through the use of semantically consistent information. In other words, a formal systems engineering language that describes engineering knowledge in a consistent manner provides a means to establish a common understanding among engineers working on a given project.

While MBSE methodologies aim to create a central data hub/medium for the integration of data and models from different disciplines and provide a holistic view of the system of interest, the sharing of underlying data and models has been lacking, because those data and models are traditionally siloed, i.e., residing within independent discipline-based activities [12]. Data exchange processes frequently rely on manually interpreting disconnected/siloed data and analyses. This is due to the progressive evolution of information technology within engineering fields, which has shifted from single-disciplinary to interdisciplinary frameworks. This shift has largely occurred in isolation within the engineering and product line management sectors, in contrast to the more integrated advancements seen in the software and data management communities. In addition, the resulting lack of seamless integration of data and models along with the manual approaches to connect interdisciplinary data and models result in poor performance of downstream tasks, such as trade-space exploration, cross-disciplinary impact identification and propagation, and decision-making. Overall, this hampers interdisciplinary responsiveness and iterative processes, resulting in inefficiency and a lack of holistic perspective.

Historically, Multidisciplinary Design and Optimization (MDO) activities are represented in quantitative frameworks using mathematical approaches [13]. If only MDO frameworks are used, results may be generated in isolation from the actual design [13]. MBSE provides a qualitative framework for design and development processes that enables one to see the big picture of the problem [13]. Existing frameworks for the MBSE-MDO connection do not provide any guidelines on how to represent an existing MDO workflow in a domain-specific language. The system model and multidisciplinary design optimization via MDO tools are not seamlessly integrated. In this context, the present work proposes to leverage existing engineering models to create a system model and capture the connections between independent, often siloed [12], discipline-based activities. In particular, it is hypothesized that if existing MDO data and knowledge are combined with MBSE processes, then a more complete semantic basis can be accomplished, which in turn can improve the connectivity between the disciplines and enable efficient reuse of the knowledge, data, and tools used during the system development.

The remainder of this paper is structured as follows. Section 2 presents background information and a comprehensive review of relevant literature. Section 3 describes the research methodology for leveraging existing engineering tools and extracting the physics information embedded within them to create a systems engineering knowledge base. Section 4 presents a detailed case study that demonstrates how the research methodology described in Section 3 is implemented. Finally, Section 5 presents the conclusions drawn from the research study, summarizes the key findings, and discusses potential avenues for future research.

2. Background and Literature Review

This section first discusses the different types of knowledge involved in complex system design. Next, the representation of this knowledge within systems engineering frameworks, along with current approaches, is examined. Finally, a literature review is provided on how multidisciplinary analyses are represented in MBSE frameworks, as well as the methods used to integrate MDO frameworks with system models.

2.1. Representation of Knowledge in Complex System Design (Physics-Based View)

The engineering design process comprises three phases: conceptual, preliminary, and detailed design [14]. Each phase requires specific types of knowledge to support its associated activities and analyses, as depicted in Figure 1. Integrating these diverse knowledge types is crucial to establishing a digital engineering platform that supports product design and development. This work specifically focuses on investigating the conceptual phase of the design process. The conceptual design aims to identify a feasible and viable design concept that will be further developed in the next phase [14]. This phase includes mathematical modeling that encompasses multiple disciplines that interact and communicate with each other. To capture the interdependencies among these disciplines and facilitate the overall analysis, MDO methods are commonly employed. The AIAA MDO Technical Committee defines MDO as “a methodology for the design of complex engineering systems and subsystems that coherently exploits the synergism of mutually interacting phenomena” [15].

MDO is a vital tool in aerospace engineering due to the complexity of aerospace systems, but several challenges limit its effectiveness: (1) reliance on traditional tools, restricting application to novel architectures [17]; (2) time-intensive setup processes consuming 60-80% of project time [17]; (3) limited reusability of architectures, reducing flexibility [18]; (4) opacity of black-box codes, hindering transparency and analysis [18]; (5) difficulty in understanding system behavior due to numerous variables and nonlinear relationships [18]; (6) inconsistent, ad hoc partitioning methods [18]; (7) data flow inconsistencies across multidisciplinary analyses [17]; and (8) lack of systematic cross-disciplinary constraint identification, focusing instead on tool integration by inputs and outputs [19]. These challenges emphasize the need for advancing MDO methodologies to better address complexity and improve multidisciplinary design. Integrating MBSE with MDO has gained traction, as both aim to support the product development process [13]. MBSE captures and manages system requirements, architecture, and behavior, providing a holistic system view and facilitating decision-making. MDO, in contrast, employs quantitative methods to optimize parameter values in complex systems. Their integration combines MBSE’s contextual understanding with MDO’s optimization capabilities, reducing development time and enhancing system design [13]. Viewing MDO within the broader context of MBSE enables a more holistic and effective approach to system development [20,21].

2.2. Systems Engineering View of Knowledge

The model-centric approach provided by MBSE allows for the exploration of system behavior from a dynamic perspective, making it easier to identify emergent behavior in the system design [22]. In addition, the integration of multiple views in an MBSE approach, as illustrated in Figure 2, enables the development of an integrated system model that can be connected to disciplinary engineering models [23]. The system model serves as an "authoritative source of truth" that captures shared aspects of the system, facilitating consistency across different engineering models [4]. It is typically stored in an MBSE repository and undergoes incremental refinement over time [4]. Overall, the concept of an authoritative source of truth is powerful in MBSE since it provides a shared knowledge base among the team. Its realization differs depending on the MBSE methodology implemented.

SE methodologies and architecture frameworks exist to orchestrate different models, tools, and environments in support of systems engineering processes and guide practitioners on utilizing the models and tools within an organization effectively. Table 1 lists available methodologies discussed in the literature. The selection of an appropriate methodology is crucial, as an inappropriate choice may lead to rework, inefficiencies, and cost overruns. Additionally, it is important to note that no single methodology can address every aspect of the entire lifecycle, as different methodologies may emphasize specific segments of the overall lifecycle. There are also architectural frameworks that define the “conventions, principles, and practices for the description of the architectures established within a specific domain of application and/or community of stakeholders” [24]. The available architectural frameworks in the literature include: (1) Zachman’s Framework [25], (2) IEEE 1471 [26], (3) DODAF [27], (4) MODAF [28], (5) NAF [29], (6) TOGAF [30], (7) UAF [31], (8) AGILE [32], (9) MagicGrid [33]. More information regarding these architectural frameworks can be found through the references indicated. Systems architecting in general is associated with qualitative estimations based on prior experiences and lessons learned, and it depends on the joint effort of system design and what requirements are imposed on the system [34]. Choosing a single architecture notation may overlook important details while employing multiple notations increases coordination efforts or becomes cumbersome [34].

2.3. Integration of MDO and MBSE

The lack of integration throughout the life cycle of a system leads to inefficiencies, rework, and unanticipated changes, resulting in cost overruns and schedule delays [4]. Several factors contribute to this issue: (1) Tool integration challenges: Discipline-specific engineering tools, developed for specific tasks and evolving with differing versions, often lack compatibility, impeding information exchange. Varying stakeholder needs further complicate tool execution sequences and data dependencies. (2) Communication barriers: While some vocabulary is shared across disciplines, discipline-specific terms hinder effective communication between teams. (3) Limited early-stage design control: Changes during design maturation require careful management, yet trade-off studies to assess design impacts are often delayed. (4) Limited design reuse: Despite the iterative nature of engineering design, artifacts are rarely created with reuse in mind, making adaptation for new problems difficult.

According to [47], there is little guidance on how to incorporate executable engineering models into SysML. Most SysML models include how to represent the system behavior, rather than explaining how the mathematical tools can be integrated to satisfy numerical-based requirements [47]. However, systems engineering practices include processes such as identification and definition of analyses based on the requirements, definition, execution, and analysis of trade space, which require the connection between SysML and the MDO tools. To address this, several approaches have been developed in the literature.

Georgia Tech Research Institute (GTRI) developed a framework that uses a Python programming language interface. It also uses OpenMDAO as the MDO tool and several open-source software for data transfer between the tools [47]. Although the GTRI framework provides a means to connect executable engineering models with a system model, it only covers a portion of the semantics offered by SysML. This implies that some aspects of the system representation may not be fully captured or supported by the framework. Furthermore, it is worth mentioning that the GTRI framework is not tied to a specific MBSE methodology or architecture framework. While this provides flexibility, it may make it challenging to establish connections between system elements in a complex system development process that follows a specific methodology or architecture framework.

Another framework that aims to combine MDO and MBSE is the AGILE Paradigm by EU Research project [48]. The aim of this framework is to be able to use MDO in collaborative engineering environments, where there are heterogeneous and diverse teams of experts [17]. In order to take advantage of MDO studies fully, the AGILE paradigm uses two fundamental pillars: (1) knowledge architecture, and (2) collaborative architecture [17]. Knowledge architecture aims to formulate a structured design process, including fully formalized MDO frameworks [17], whereas, collaborative architecture aims to find tools and methodologies to execute the formulated design process. According to [48], this framework allowed the early identification of potential inconsistencies in the MDO execution profile. However, one of the challenges encountered was the high amount of time dedicated to setting up the MDO model, and its interfaces between the heterogeneous disciplinary models. This is expected as initially a one-time effort is needed to implement all the available knowledge. A key component of their research is the reusability of the system model for future developments. The AGILE architectural framework has not been formalized; therefore, additional work is needed to build an entire system model with the guidance of their novel architectural framework.

NASA Jet Propulsion Laboratory (JPL) has also created a method, called Executable Systems Engineering Method (ESEM), to utilize OOSEM to show requirements traceability to design artifacts, how to define analyses within SysML, and how these defined analyses satisfy the design requirements [49]. In this approach, analyses are directly derived from the data model in SysML, so no external tools are used. One of the findings was that SysML provides limited resources to define analyses; therefore, it is not always possible to define engineering analysis using SysML. For example, finite element analysis, or computational fluid dynamics analyses are not suitable to be defined without any external tool.

Finally, the Systems Engineering Research Center (SERC) created a framework called Interoperability and Integration Framework to integrate SysML system models, OpenMBEE [50], ontologies, SWT, a decision framework, and visualizations for MDO [10]. The case study included an MDO formulation in ModelCenter for a UAV model. This framework does not include specific engineering tools but simple Python scripts to showcase the connection between the system model and the MDO workflow in ModelCenter.

Table 2 compares the frameworks, highlighting their strengths and limitations, particularly in integration complexity, tool interoperability, and efficiency. It shows that while MDO integrates multiple tools, representing them as black boxes in SysML fails to capture the complexities of physics-based models. Existing frameworks also lack guidelines for representing MDO workflows in domain-specific languages, resulting in poor integration of system models with MDO tools. As a result, the main research objective of this paper is to develop a systematic way to represent and integrate heterogeneous data and knowledge, which include semantic systems engineering models and physics-based engineering models. More specifically, to achieve this objective we developed a methodology that leverages an existing MDO tool to extract knowledge in support of constructing a system model from scratch.

3. Research Methodology: A Reverse Engineering Approach

In this work, an existing MDO tool is utilized as the source of knowledge. The knowledge obtained from the MDO tool is then translated into a formal modeling language, specifically SysML. In the process of knowledge translation, domain-specific entities and the relationships between them are defined within the SysML framework. This allows for the representation of the acquired knowledge in a structured and formal manner, enhancing its clarity and enabling its integration with other knowledge-based systems and tools. More information regarding the SE methodology and MDO framework chosen as well as details on the development of the semantic models are provided below.

3.1. SE Methodologies for Semantic Modeling

To create a semantic model, systems engineers require a systems engineering methodology and architectural framework. However, not all methodologies cover every stage of the lifecycle, so customization is necessary based on the specific design problem. The PMTE (Processes, Methods, Tools, and Environment) framework [51] is chosen as the mechanism to compare the existing systems engineering methodologies considered. PMTE is a framework developed to analyze, evaluate, and understand different aspects of systems, projects, or methodologies. It has been used to compare different systems engineering methodologies in the literature [37,52,53]. To facilitate the comparison, a standardized common basis in SE modeling is needed, which is where SE standards come into play [37]. However, these standards may not always align with each other. To address this, common lifecycle processes across major standards have been identified, including mission/purpose definition, requirements engineering, system architecting, system implementation, and verification and validation [54]. Additional supporting processes such as technical analysis, technical management/leadership, and scope management are also recognized. These common processes provide a unified view that serves as a basis for comparing systems engineering methodologies. By considering the PMTE framework and the common lifecycle processes, a comparison of methodologies can be conducted, helping guide the systems modeling process for the specific use case.

Utilizing the established criteria, common lifecycle processes, and the PMTE framework, the methodologies in Table 1 are compared against one another, leading to the selection of the OOSEM as the guiding methodology for the semantic modeling process. The reasons behind this selection include OOSEM’s (1) extensive documentation, (2) structured and comprehensive processes, (3) support for knowledge representation, (4) object-oriented approach, (5) information exchange support, (6) alignment with SE standards, and (7) adaptability to agile software development.

3.2. Software Frameworks for MDO

This section summarizes the frameworks commonly used in support of MDO, more specifically, (1) ModelCenter, (2) OpenMDAO, (3) GEMS, and (4) Design optimization with MATLAB/Simulink. ModelCenter [55] enables the integration of various analysis tools and software applications within a unified workflow. It does so by using wrappers, i.e., adapters that allow different software systems to communicate and operate together seamlessly, even if they were not originally designed to do so. The downside is that numerical methods used for converging MDO are not state-of-the-art models [13]. OpenMDAO, developed by NASA [56], is a Python library designed specifically for setting up, solving, and analyzing optimization problems across multiple disciplines. It includes several features that assist in the automation of gradient computation and the propagation of derivatives through the problem [57]. GEMS [58] is a Python library for programming MDO simulation processes. It supports the definition and execution of distributed and multi-level MDO architectures and integrates state-of-the-art numerical algorithms. The downside is that it is mostly focused on monolithic MDO architectures. MATLAB and Simulink provide toolboxes to evaluate design trade-offs and find optimal designs [59].

In addition, a number of MDO tools and frameworks exist that are specifically developed for aircraft design. This includes SUAVE, FAST-OAD, OpenConcept, CPACS, etc. SUAVE (Stanford University Aerospace Vehicle Environment) is a Python-based software framework specifically designed for the conceptual design and analysis of a variety of aircraft systems (commercial transport aircraft, eVTOL, regional jets, etc) [60]. It has extensive documentation through Doxygen and object-oriented architecture and allows for the use of different fidelity levels for disciplinary analyses. FAST-OAD (Framework for Aircraft Sizing and Trade-Off Analysis of Design) is an open-source, python-based aircraft sizing software developed by ONERA and ISAE-SUPAERO [61]. It provides tools for performance analysis throughout the aircraft’s mission profile, including fuel efficiency, range, payload capacity, and environmental impact [61]. It interfaces with other analysis and optimization tools, such as OpenMDAO to provide a more comprehensive exploration of design spaces. OpenConcept is an open-source software framework designed for preliminary aircraft design and analysis, with a specific focus on propulsion systems, including both conventional and unconventional configurations (e.g., electric propulsion) [62]. It is built on top of the Python-based OpenMDAO framework. CPACS (Common Parametric Aircraft Configuration Schema) is a data format and schema developed by the German Aerospace Center (DLR) [63]. It is used for defining and exchanging aircraft configuration data among different tools and disciplines, hence facilitating the interoperability and integration of various software tools used throughout the aircraft development process.

For this research, SUAVE is used as it is open-source, modular, and has an object-oriented architecture and available detailed documentation.

3.3. Ontology-Based Metamodeling Approach

The MBSE movement has been strengthened by the utilization of software engineering and modeling languages. General-purpose modeling languages such as UML offer the advantage of being applicable to a wide range of domains and knowledge types. They provide a standardized notation and syntax for representing knowledge, which promotes consistency and interoperability. However, one limitation of such languages is that they do not inherently guide individuals in the modeling process. Modeling complex systems requires a deep understanding of the domain, its concepts, and their relationships. Without proper guidance, it can be challenging to capture and communicate the intended meaning effectively. To address this limitation, specialized modeling methodologies such as OOSEM and Domain-Specific Languages (DSLs) such as SysML were developed. These methodologies and DSLs provide domain-specific guidance, conventions, and modeling patterns that assist individuals in correctly representing the concepts and relationships within a particular domain.

In this work, an ontology-based metamodeling approach is utilized, in which the domain knowledge is represented as an ontology, consisting of classes and relations. When a modeler creates a graphical model, they utilize this domain-specific guidance and generate instances of the ontology classes. In software engineering, the process of creating domain ontologies is commonly referred to as ontological metamodeling [64] Hence, the ontology serves as both the representation of the domain knowledge and the metamodel for a domain-specific modeling language. As a result, the ontology-based metamodeling approach achieves two main objectives: (1) the definition of domain-specific modeling languages with precise and well-defined formal semantics, making them consistent across different systems and by different users, and (2) the ability for both humans and machines to interpret the models, which eventually facilitates better collaboration, automation, and integration of tools.

Considering the elements of the research methodology described in the previous subsections, Figure 3 illustrates their interconnections. This methodology utilizes the selected MDO structure, SUAVE, as part of a reverse engineering process. Guided by the chosen systems engineering methodology, OOSEM, the MDO structure is depicted within a system model. Since this study focuses on the representation of an MDO, pertinent aspects of OOSEM are selected to guide the creation of the system model. As system elements are developed within the model, they are assigned specific stereotypes, which constitute the ontological metamodel of the MDO tool.

4. Implementation

This section goes into the details of the methodology shown in Figure 3 and its application to an aerospace case study.

4.1. OOSEM-Guided System Model Generation

The OOSEM methodology has been selected to guide the creation of the system model. A comprehensive overview of OOSEM can be found in the INCOSE SE Handbook [65], with detailed application insights provided by Friedenthal et al. [36]. The primary activities of OOSEM include: (1) analyzing stakeholder needs, (2) defining system requirements, (3) defining logical architecture, (4) synthesizing candidate allocated architectures, (5) optimizing and evaluating alternatives, and (6) validating and verifying the system [36]. According to ISO-15288 standards, the architectural design process involves converting system requirements into a physical architecture, while concurrently generating a logical architecture [66]. Both ISO-15288 and OOSEM emphasize the importance of creating diagrams and artifacts to represent the desired behavior and structure of the system. They also recognize the existence of two levels of abstraction in architectural descriptions: logical and physical. Abstraction in design helps manage complexity by revealing relevant information at different levels. In addition, since SUAVE provides information on the system’s logical and structural aspects, OOSEM’s architectural design is crucial for depicting the internal workings of SUAVE within a systems engineering framework. Therefore, this investigation focuses on two main OOSEM activities: (1) defining logical architecture and (2) synthesizing candidate allocated architectures. By systematically applying these OOSEM activities, the reverse engineering process establishes a solid foundation, enabling a thorough understanding of complex systems and contributing to the development of an "authoritative source of truth".

4.2. MDO Representation

SUAVE utilizes the core concepts of object-oriented programming such as inheritance, encapsulation, and abstraction to describe various aircraft and propulsion system topologies. It has several modules including analyses, attributes, components, core, inputs & outputs, methods, optimization, plots, plugins, and surrogates, as shown in Figure 4 [67].

Modules related to the execution and analysis of the MDO framework, such as core, inputs & outputs, optimization, plots, plugins, and surrogates, are excluded from this study. The reason is that current modeling languages such as SysML are limited in their execution capabilities and are not well-suited for efficiently handling complex physics-based interactions between components [68]. On the other hand, numerous analysis tools such as SUAVE have been developed over the years to design complex systems with efficient execution strategies [69]. As a result, practitioners typically use modeling languages to create a descriptive system representation and then ensure this model can interoperate with external engineering models for system analysis and design [70]. This descriptive system model is expected to represent product architectures in great detail, which is needed to create a consistent “authoritative source of truth” and enable other engineering tools to interoperate. Focusing on the descriptive representation of the MDO framework, which includes defining the system structure, data flows, and interfaces between disciplines, this work utilizes the following SUAVE components: analyses, attributes, components, and methods.

4.3. System Model Generation

Considering the OOSEM’s abstraction levels of depicting the system architecture and SUAVE’s internal structure, a system model is created that mirrors the physics information embedded in SUAVE. In the system model, SUAVE modules are represented as packages, in alignment with SUAVE’s organizational structure. Each module contains Python scripts that describe its classes, which are depicted as blocks in SysML. Using these Python scripts, the structural features of the blocks are defined by assigning properties that specify part, reference, and value properties. The composition hierarchy, as outlined in SUAVE’s Doxygen documentation, guides the creation of part properties in the system model. Additionally, the inheritance diagrams provided in the Doxygen documentation are used to create reference and value properties.

4.3.1. Logical Architecture

The OOSEM activities to define the logical architecture are (1) define logical decomposition, (2) define interaction between logical components to realize each system action and/or operation, (3) define logical internal block diagram, (4) specify logical components, and (5) define logical component state machine, as given in [36]. The first activity involves defining the logical decomposition, which is already available in the SUAVE modules of analyses and methods. The analyses module provides the analysis functions for each discipline at varying fidelity levels and their interactions. In contrast, the methods module details the methods used for the analyses provided in the analyses module. The decomposition of the analyses in the system model is illustrated in Figure 5. As mentioned, each disciplinary area has several types of analyses corresponding to different fidelity levels. An example of aerodynamics analyses is shown in Figure 6.

The second and third activities in the OOSEM’s definition of logical architecture are related to the interactions between the system elements to realize the system actions and/or operations. To realize this, each class in the SUAVE analyses module is represented as a block in SysML. In order to represent the functions in the classes, SysML operations are used. The inputs and outputs of the operations are also indicated based on the SUAVE implementation. An example of the fidelity zero aerodynamics analysis method is shown in Figure 7. This figure includes a block definition diagram showing the functions within the class of the corresponding analysis method. These functions are represented with blocks that have proxy ports to indicate the data flows. Each function has inputs and outputs and these are also represented using blocks and referenced to the analysis function blocks. This block definition diagram shows a high-level view of how the data flows in an analysis method. In order to represent the data flow better, internal block diagrams are utilized showing the analysis method functions and their proxy ports and what flows through the connections. The item flows are described by the function’s inputs and outputs, as shown in Figure 8. For each of the analysis method’s input and output sets, separate blocks are created. These blocks get their internal value properties from the components. Therefore, parametric diagrams are created to show that the value properties of the input and output blocks are connected to the value properties of the corresponding components. An example of a parametric diagram is shown in Figure 9. Here, only one function’s input parameters are represented for demonstration purposes. Binding connectors are used to match the inputs to the value properties of the corresponding components. The extent of information transformed into SysML encompassed inputs, outputs, and function behaviors, excluding detailed mathematical formulations to maintain a descriptive focus rather than execution specifics. Each function within a block corresponds to an operation, showcasing the behavioral aspects without delving into execution details. This approach ensures that the SysML model serves as a comprehensive descriptive representation of the MDO framework. Finally, as aforementioned, the last activity in the OOSEM guidelines is not considered as it is specific to the execution.

4.3.2. Physical Architecture

OOSEM’s guidelines indicate the following activities to form the physical architecture: (1) define partitioning criteria, (2) define logical node architecture, (3) define physical node architecture, (4) define software architecture, (5) define data architecture, (6) define hardware architecture, (7) define operational procedures, (8) specify component requirements, (9) conduct system design review, and (10) capture critical component properties as given in [36]. In this study, the physical architecture focuses primarily on the component decomposition and the connection between these components and the logical elements. Therefore, only the relevant parts of the guidelines, specifically the definition of the partitioning criteria and the definition of the physical architecture, will be used. The partitioning criteria for physical and logical components are already provided by SUAVE, so SUAVE’s implementation is followed. The specific module for the physical elements is the components module. Its structure is reflected in the system model, as shown in Figure 10. Additionally, SUAVE provides a module called attributes, which includes information about airports, atmospheres, constants, gases, propellants, solids, etc. These attributes are used as reference properties for other system elements, including analyses and mission elements. Each attribute is represented as a block, using an approach similar to that of the physical decomposition generation. Detailed information on SUAVE’s implementation can be found on their GitHub page. The SysML implementations are completed by examining the SUAVE Python scripts and translating the classes and class variables in SUAVE into blocks and value properties in the system model.

4.4. Ontological Metamodel Generation

So far, the OOSEM guidelines have been used to reflect the inner workings of SUAVE to create a system model, leveraging the already encoded MDO knowledge within SUAVE. During the construction of the system model, a UML profile is created to define the necessary semantics for the MDO framework. The stereotypes developed throughout the system model development process serve as the ontological metamodel, as shown in Figure 11. This metamodel acts as a bridge between the physics-based tool and the MBSE environment, providing a structured representation of how the MDO tool operates.

Generally, ontological metamodels are created by subject matter experts, and the system model is based on this metamodel. Throughout this process, iterations are necessary, as new stereotypes may need to be added later in the system model development. This iterative process requires additional effort to align the existing system model with the updated metamodel. However, in this study, our aim is to create this metamodel by reverse engineering an available MDO tool. This approach demonstrates that OOSEM guidelines can systematically transform an engineering tool into a system model, thereby deducing the ontological metamodel. It should be noted, however, that the transformation process is not one-to-one, and some details from the Python scripts are not directly representable in SysML. The goal is to capture the essential system structure and behavior in a way that is more abstract and focused on systems engineering rather than Python-specific implementation details.

Creating an ontological metamodel provides a better understanding of how the system elements interact and how to create use cases using the library of system elements. SUAVE includes tutorials for various types of aircraft, one of which is the mission analysis of the Boeing 737-800. By utilizing the ontological metamodel and the library of system elements, a high-level view of this mission analysis is created in SysML, as represented in Figure 12.

In scenarios where a new aircraft with enhanced capabilities is being designed, an updated MDO framework may be required. While some analyses from the SUAVE library can be reused, new or higher-fidelity analyses may also be needed, which may not currently be available. In such cases, the existing ontological metamodel can guide the integration of new analyses into the MDO workflow. By using the predefined structures in the metamodel, new analyses can be systematically added, ensuring compatibility with the existing framework. Additionally, traceability between existing and new analyses helps modelers understand how data flows within the MDO framework, ensuring smooth integration.

5. Discussion

In the methodology followed so far, OOSEM has been supplemented with an external engineering tool to acquire expert knowledge, thereby reducing the human effort needed to create a system model. The common practice is to manually create system models using expert knowledge, which is time-consuming. By integrating expertise from physics-based tools, the completeness and accuracy of the system model are expected to be enhanced. This approach leverages the assumption that the utilized engineering tool is complete and accurate, which is crucial for achieving a more realistic and reliable representation of the system. This study involves human efforts to transform expert knowledge into a system model. Additional research is needed to automatically transform models developed in different languages.

OOSEM is used in this research to build structured, standards-compliant system models. Its primary role is to guide the creation of SysML models by offering guidelines for organizing and transforming MDO knowledge, such as the expert insights embedded in SUAVE, into formal models. OOSEM’s focus on defining system behavior and structure through iterative steps aligns well with the process of capturing and organizing SUAVE’s embedded knowledge. By leveraging OOSEM, the MDO process can be effectively mapped to SysML diagrams, ensuring consistency, traceability, and structured system development. This approach not only captures detailed relationships between system elements but also improves the reusability and scalability of the system model for future use.

Transforming an engineering tool into a SysML model involves a shift in representation from code-centric details to a more abstract and visual representation used in system engineering. To analyze performance and critical aspects of a design, it is necessary to specify the behavior of the system or component using other analytical models. SysML can be used to integrate these analytical models with the system model. In cases where more precision is required for analysis, a portion of the system model in SysML needs to be expressed in a more detailed manner [36]. This is achieved by creating a domain-specific ontological metamodel, which includes extensions specified as profiles. These extensions allow for the inclusion of additional modeling elements and statements written in other languages, such as Python in this study, enhancing the precision and detail of the system model. By adopting this approach, systems engineers can benefit from the strengths of specialized analysis tools, while maintaining a clear connection to the system model [36]. It allows for a more comprehensive and detailed analysis without burdening the system model with unnecessary complexity and details.

During the implementation, a manual approach was used to understand SUAVE’s internal workings in order to deduce its ontological metamodel. This involved examining SUAVE’s Python scripts and converting its classes and variables into SysML constructs. The goal was not to capture every detail of the MDO framework in SysML, as the focus of this research is not on model transformation, but rather on capturing the high-level structure in an ontological metamodel. This metamodel serves as a foundation for future transformation efforts and guides the system model development process.

While SUAVE is the primary MDO framework used in this research, the approach is not limited to it. A key advantage of SUAVE is its open-source nature, allowing for transparency in modeling. This is essential because the proposed method relies on understanding the internal workings of the MDO framework. In contrast, MDO frameworks that involve proprietary information or operate as black box systems cannot be effectively used within this approach, as they do not reveal their internal processes. However, other frameworks that disclose their internal structures, such as SUAVE, can be adapted to this methodology. The feasibility of applying this approach depends on the openness of the system. Future work could explore its application in other transparent MDO frameworks to demonstrate versatility. In addition, it is possible to build an MDO formulation from the system model, and this is another area for future development. The system model establishes connections between MDO elements, and by using queries, it becomes possible to trace analyses, their inputs and outputs, and the exchanges of information between analyses. This traceability can support the creation of a formal MDO formulation.

6. Conclusions

This work aims to streamline the process of building system models from scratch by leveraging existing knowledge and utilizing an ontological metamodel as a modeling template. By leveraging the embedded expertise within SUAVE, the proposed approach aims to reduce the manual effort traditionally required to build system models, enhancing both the accuracy and completeness of these models. In addition, the ontological metamodel serves as a structured template that captures the concepts, relationships, and behaviors inherent to the MDO framework, thereby streamlining the model creation process.

More broadly, this study aims to establish a SysML metamodel as a foundation for formally representing complex MDO knowledge. As systems engineering initiatives become more complex, effective knowledge representation is needed to transform extensive data into machine-readable formats, aiding in complexity management. These representations support automated logical reasoning based on rules, enable knowledge reuse, and assist domain experts in drawing new inferences and making well-informed decisions [71]. Additionally, knowledge representations promote the integration of Artificial Intelligence (AI) tools and methodologies with contemporary MBSE and Digital Engineering (DE) practices, leading to significant reductions in both development times and costs. This research lays the groundwork for creating a comprehensive knowledge base, which is crucial for incorporating these advanced technologies.

Finally, the effectiveness of the approach relies on the level of details/embedded expert knowledge, accuracy, and completeness of the SUAVE tool itself. Any shortcomings within the tool can potentially compromise the reliability of the system models generated. This study assumes that the SUAVE tool’s knowledge is both accurate and complete. By doing so, we can ensure the system model is properly validated without the need for extensive manual effort. Furthermore, while the approach reduces manual effort, transforming expert knowledge into a comprehensive system model still requires significant human intervention. This process can be time-consuming and susceptible to errors, particularly when integrating complex analytical models or when detailed, precise analysis is needed. Therefore, future research should focus on the automation of model transformation, particularly the development of automated methods to transform the knowledge embedded in engineering models (often developed in a variety of languages) into SysML to reduce manual effort.