Nothing Special   »   [go: up one dir, main page]
Next Article in Journal
Identifying the Characteristics of Sustainable Design System: A Survey Study
Previous Article in Journal
Only Platformization? No, Community First!
You seem to have javascript disabled. Please note that many of the page functionalities won't work as expected without javascript enabled.
 
 
Search for Articles:
Title / Keyword
Author / Affiliation / Email
Journal
Article Type
 
 
Advanced Search
 
Section
Special Issue
Volume
Issue
Number
Page
 
Journals
Systems
Volume 12
Issue 12
10.3390/systems12120555
systems-logo
Submit to this Journal Review for this Journal Propose a Special Issue
► Article Menu

Article Menu

share Share announcement Help format_quote Cite question_answer Discuss in SciProfiles
first_page
settings
Order Article Reprints
Font Type:
Arial Georgia Verdana
Font Size:
Aa Aa Aa
Line Spacing:
Column Width:
Background:
Article

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

by
Esma Karagoz
1,*,
Olivia J. Pinon Fischer
2 and
Dimitri N. Mavris
2
1
Mechanical, Materials, and Aerospace Engineering, Illinois Institute of Technology, Chicago, IL 60616, USA
2
Aerospace Systems Design Laboratory, School of Aerospace Engineering, Georgia Institute of Technology, Atlanta, GA 30332, USA
*
Author to whom correspondence should be addressed.
Systems 2024, 12(12), 555; https://doi.org/10.3390/systems12120555
Submission received: 9 September 2024 / Revised: 16 November 2024 / Accepted: 25 November 2024 / Published: 12 December 2024
(This article belongs to the Section Systems Engineering)
Browse Figures
Figure 1
<p>Knowledge types in engineering design [<a href="#B14-systems-12-00555" class="html-bibr">14</a>,<a href="#B16-systems-12-00555" class="html-bibr">16</a>].</p> "> Figure 2
<p>Projections of knowledge on to the system model [<a href="#B23-systems-12-00555" class="html-bibr">23</a>].</p> "> Figure 3
<p>Research methodology.</p> "> Figure 4
<p>Structure of SUAVE.</p> "> Figure 5
<p>Logical decomposition: In the system model, the logical components are represented by disciplinary analyses within SUAVE.</p> "> Figure 6
<p>SUAVE—aerodynamics analyses: The decomposition of aerodynamics analyses involves different levels of fidelity.</p> "> Figure 7
<p>Fidelity zero aerodynamics method.</p> "> Figure 8
<p>Data flow between the analysis method functions.</p> "> Figure 9
<p>Parametric diagram showing the relation between the components and inputs/outputs.</p> "> Figure 10
<p>Physical decomposition: This decomposition reflects the structure of SUAVE. It is important to note that this figure provides a high-level view of the physical decomposition to avoid overcrowded representations.</p> "> Figure 11
<p>Ontological metamodel.</p> "> Figure 12
<p>A high-level representation of the mission analysis for a Boeing 737-800, including the required analyses and the physical components whose values serve as input for the analysis.</p> ">
Versions Notes

Abstract

:
The design of complex aerospace systems requires a broad multidisciplinary knowledge base and an iterative approach to accommodate changes effectively. Engineering knowledge is commonly represented through engineering analyses and descriptive models with underlying semantics. While guidelines from systems engineering methodologies exist to guide the development of system models, creating a system model from scratch with every new application/system requires research into more adaptable and reusable modeling frameworks. In this context, this research demonstrates how a physics-based multidisciplinary analysis and optimization tool, SUAVE, can be leveraged to develop a system model. By leveraging the existing physics-based knowledge captured within SUAVE, the process benefits from the expertise embedded in the tool. To facilitate the systematic creation of the system model, an ontological metamodel is created in SysML. This metamodel is designed to capture the inner workings of the SUAVE tool, representing its concepts, relationships, and behaviors. By using this ontological metamodel as a modeling template, the process of creating the system model becomes more structured and organized. Overall, this research aims to streamline the process of building system models from scratch by leveraging existing knowledge and utilizing an ontological metamodel as a modeling template. This approach enhances formal knowledge representation and its consistency, and promotes reusability in multidisciplinary design problems.

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 the systems being developed also presents integration challenges in multidisciplinary design efforts, making it difficult to accurately predict the behavior of the 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 (SWTs) [6,7]. In this context, ontology refers to the explicit representation of a shared understanding of important concepts in a certain domain of interest [8]. While ontologies enable knowledge representation, SWTs provide 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 SWTs, 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 leveraging 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 the 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 its 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 in 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], and (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 experience 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 lifecycle 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 system behavior, rather than explaining how mathematical tools can be integrated to satisfy numerically-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 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 [48] as the MDO tool and various 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 [49]. 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 [49], 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 was 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 the Executable Systems Engineering Method (ESEM), to utilize OOSEM to show requirement traceability in designing artifacts, how to define analyses within SysML, and how these defined analyses satisfy the design requirements [50]. 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 the Interoperability and Integration Framework to integrate SysML system models, OpenMBEE [51], 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 on the chosen SE methodology and MDO framework, 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 depending on the specific design problem. The PMTE (Processes, Methods, Tools, and Environment) framework [52] 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,53,54]. 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 [55]. 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 [56] enables the integration of various analysis tools and software applications within a unified workflow. It achieves this by using wrappers, i.e., adapters that allow different software systems to communicate and operate together seamlessly, even if they were not originally designed for this. The downside is that the numerical methods used for converging MDO are not state-of-the-art models [13]. OpenMDAO, developed by NASA [48], 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. These include 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 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 was 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 and 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 and 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 flow 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 receive 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, showing 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 are required to form the physical architecture, as given in [36]: (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. 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 the 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 was 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 flow 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 effort 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, standard-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 systems 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]. This 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. In this way, 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.

Author Contributions

Conceptualization, E.K., D.N.M. and O.J.P.F.; methodology, E.K.; validation, E.K.; formal analysis, E.K.; investigation, E.K.; data curation, E.K.; writing—original draft preparation, E.K.; writing—review and editing, O.J.P.F. and D.N.M.; visualization, E.K.; supervision, O.J.P.F. and D.N.M. All authors have read and agreed to the published version of the manuscript.

Funding

This research received no external funding.

Data Availability Statement

Dataset available on request from the authors.

Conflicts of Interest

The authors declare no conflicts of interest.

Abbreviations

The following abbreviations are used in this manuscript:
AIArtificial intelligence
CPACSCommon Parametric Aircraft Configuration Schema
DAUDefense Acquisition University
DEDigital engineering
DODAFDepartment of Defense Architecture Framework
DSLDomain-specific language
FAST-OADFramework for Aircraft Sizing and Trade-Off Analysis of Design
MBSEModel-based systems engineering
MDOMultidisciplinary design and optimization
MODAFThe British Ministry of Defence Architecture Framework
NAFNATO Architecture Framework
PMTEProcesses, Methods, Tools, and Environment
SESystems engineering
SUAVEStanford University Aerospace Vehicle Environment
SWTsSemantic Web technologies
SysMLSystems Modeling Language
TOGAFThe Open Group Architecture Framework
UAFUnified Architecture Framework

References

  1. INCOSE. SE Vision 2025; INCOSE: San Diego, CA, USA, 2014. [Google Scholar]
  2. Jaifer, R.; Beauregard, Y.; Bhuiyan, N. Reimagining uncertainty and complexity evaluation in aerospace new product development-time and cost planning perspective. In Proceedings of the International Annual Conference of the American Society for Engineering Management, Huntsville, AL, USA, 18–21 October 2017; American Society for Engineering Management (ASEM): Huntsville, AL, USA, 2017; pp. 1–10. [Google Scholar]
  3. Tamaskar, S.; Neema, K.; DeLaurentis, D. Framework for measuring complexity of aerospace systems. Res. Eng. Des. 2014, 25, 125–137. [Google Scholar] [CrossRef]
  4. Friedenthal, S. Future Directions for Product Lifecycle Management (PLM) and Model-Based Systems Engineering (MBSE). Available online: https://www.aras.com/-/media/files/resources/whitepapers/white-paper-future-directions-for-product-lifecycle-management.ashx (accessed on 11 December 2023).
  5. Ameri, F.; Dutta, D. Product Lifecycle Management: Closing the Knowledge Loops. Comput.-Aided Des. Appl. 2005, 2, 577–590. [Google Scholar] [CrossRef]
  6. Lin, C.; Verma, D. Semantic Technologies Foundation Initiative for Systems Engineering; Jet Propulsion Laboratory, National Aeronautics and Space Administration: Pasadena, CA, USA, 2017.
  7. Hagedorn, T.; Bone, M.; Kruse, B.; Grosse, I.; Blackburn, M. Knowledge Representation with Ontologies and Semantic Web Technologies to Promote Augmented and Artificial Intelligence in Systems Engineering. Insight 2020, 23, 15–20. [Google Scholar] [CrossRef]
  8. Gaševic, D.; Djuric, D.; Devedžic, V. Model Driven Engineering and Ontology Development; Springer Science & Business Media: Berlin/Heidelberg, Germany, 2009. [Google Scholar]
  9. Authoritative Source of Truth. Available online: https://www.dau.edu/glossary/authoritative-source-truth#:~:text=The%20reference%20point%20for%20models,versions%20of%20models%20and%20data (accessed on 28 August 2024).
  10. Blackburn, M.; Verma, D.; Dillon-Merrill, R.; Blake, R.; Bone, M.; Chell, B.; Dove, R.; Dzielski, J.; Grogan, P.; Hoffenson, S.; et al. Transforming Systems Engineering Through Model Centric Engineering; Technical Report; Stevens Institute of Technology Hoboken United States: Hoboken, NJ, USA, 2018. [Google Scholar]
  11. Fujimoto, R.; Bock, C.; Chen, W.; Page, E.; Panchal, J.H. Research Challenges in Modeling and Simulation for Engineering Complex Systems; Springer: Cham, Switzerland, 2017. [Google Scholar]
  12. Karban, R.; Ardito, S.; Lattimore, M.; Bayer, T.; Quadrelli, M.; Black, A.; Hang, T.; Altenbuchner, C.; Delp, C. Towards a model-based product development process from early concepts to engineering implementation. In Proceedings of the 2023 IEEE Aerospace Conference, Big Sky, MT, USA, 4–11 March 2023; pp. 1–18. [Google Scholar]
  13. van Tooren, M.; La Rocca, G. Systems engineering and multi-disciplinary design optimization. In Collaborative Product and Service Life Cycle Management for a Sustainable World, Proceedings of the 15th ISPE International Conference on Concurrent Engineering (CE2008), Belfast, Northern Ireland, 17–21 August 2008; Springer: London, UK, 2008; pp. 401–415. [Google Scholar]
  14. Mavris, D.N.; Pinon, O.J. An Overview of Design Challenges and Methods in Aerospace Engineering. In Complex Systems Design & Management; Springer: Berlin/Heidelberg, Germany, 2011; pp. 1–25. [Google Scholar]
  15. Giesing, J.; Barthelemy, J.F. A summary of industry MDO applications and needs. In Proceedings of the 7th AIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimization, St. Louis, MO, USA, 2–4 September 1998; p. 4737. [Google Scholar]
  16. Chandrasegaran, S.K.; Ramani, K.; Sriram, R.D.; Horváth, I.; Bernard, A.; Harik, R.F.; Gao, W. The evolution, challenges, and future of knowledge representation in product design systems. Comput.-Aided Des. 2013, 45, 204–228. [Google Scholar] [CrossRef]
  17. van Gent, I.; Aigner, B.; Beijer, B.; Jepsen, J.; La Rocca, G. Knowledge architecture supporting the next generation of MDO in the AGILE paradigm. Prog. Aerosp. Sci. 2020, 119, 100642. [Google Scholar] [CrossRef]
  18. German, B. Lecture Notes in Optimization for the Design of Engineered Systems—Multidisciplinary Design Optimization (MDO); Georgia Institute of Technology: Atlanta, GA, USA, 2016. [Google Scholar]
  19. Ciampa, P.D.; Nagel, B. Towards the 3rd generation MDO collaborative environment. In Proceedings of the 30th ICAS, Daejeon, Republic of Korea, 25–30 September 2016; pp. 1–12. [Google Scholar]
  20. Kuelper, N.; Bielsky, T.; Broehan, J.; Thielecke, F. Model-Based Framework for Data and Knowledge-Driven Systems Architecting Demonstrated on a Hydrogen-Powered Concept Aircraft. Insight 2024, 27, 47–60. [Google Scholar] [CrossRef]
  21. Page Risueno, J.; Nagel, B. Development of a knowledge-based engineering framework for modeling aircraft production. In Proceedings of the AIAA Aviation 2019 Forum, Dallas, TX, USA, 17–21 June 2019; p. 2889. [Google Scholar]
  22. Vaneman, W.K. Evolving Model-Based Systems Engineering Ontologies and Structures. In Proceedings of the INCOSE International Symposium, Washington, DC, USA, 7–12 July 2018; Wiley Online Library: New York, NY, USA, 2018; Volume 28, pp. 1027–1036. [Google Scholar]
  23. Fosse, E. Model-Based Systems Engineering (MBSE) 101. 2016. Available online: https://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:2016_iw-mbse_101.pdf (accessed on 10 August 2024).
  24. ISO/IEC/IEEE 42010; Systems and Software Engineering—Architecture Description. International Organization for Standardization: Geneva, Switzerland, 2011.
  25. Zachman, J.A. A framework for information systems architecture. IBM Syst. J. 1987, 26, 276–292. [Google Scholar] [CrossRef]
  26. Maier, M.W.; Emery, D.; Hilliard, R. Software architecture: Introducing IEEE standard 1471. Computer 2001, 34, 107–109. [Google Scholar] [CrossRef]
  27. The DoDAF Architecture Framework Version 2.02. Available online: https://dodcio.defense.gov/Library/DoD-Architecture-Framework/ (accessed on 29 September 2022).
  28. UK Ministry of Defence, MOD Architecture Framework. Available online: https://www.gov.uk/guidance/mod-architecture-framework (accessed on 29 September 2022).
  29. Architecture Capability Team. NATO Architecture Framework. Version 4. 2018. Available online: https://www.nato.int/nato_static_fl2014/assets/pdf/2021/1/pdf/NAFv4_2020.09.pdf (accessed on 1 November 2024).
  30. The Open Group, The TOGAF Standard, Version 9.2. Available online: https://www.opengroup.org/togaf (accessed on 29 September 2022).
  31. Hause, M.; Bleakley, G.; Morkevicius, A. Technology update on the unified architecture framework (UAF). Insight 2017, 20, 71–78. [Google Scholar] [CrossRef]
  32. Boggero, L.; Ciampa, P.D.; Nagel, B. An MBSE Architectural Framework for the Agile Definition of System Stakeholders, Needs and Requirements. In Proceedings of the AIAA AVIATION 2021 FORUM, Virtual, 2–6 August 2021; p. 3076. [Google Scholar]
  33. Plattsmier, G. NASA MBSE Implementation; Technical Report; 2019. Available online: https://ntrs.nasa.gov/api/citations/20190032390/downloads/20190032390.pdf (accessed on 29 September 2022).
  34. Reichwein, A.; Paredis, C. Overview of architecture frameworks and modeling languages for model-based systems engineering. In Proceedings of the ASME, Denver, CO, USA, 12–14 July 2011; Volume 1275. [Google Scholar]
  35. Hoffmann, H.P. Harmony-SE/SysML Deskbook: Model-Based Systems Engineering with Rhapsody; Rev. 1.51; Telelogic AB: Malmö, Sweden, 2006. [Google Scholar]
  36. Friedenthal, S.; Moore, A.; Steiner, R. A Practical Guide to SysML: The Systems Modeling Language; Morgan Kaufmann: San Francisco, CA, USA, 2014. [Google Scholar]
  37. Estefan, J.A. Survey of model-based systems engineering (MBSE) methodologies. Incose MBSE Focus Group 2007, 25, 1–12. [Google Scholar]
  38. Childers, S.R.; Long, J.E. A concurrent methodology for the system engineering design process. In Proceedings of the INCOSE International Symposium, San Jose, CA, USA, 10–12 August 1994; Wiley Online Library: New York, NY, USA, 1994; Volume 4, pp. 226–231. [Google Scholar]
  39. Ingham, M.D.; Rasmussen, R.D.; Bennett, M.B.; Moncada, A.C. Generating requirements for complex embedded systems using State Analysis. Acta Astronaut. 2006, 58, 648–661. [Google Scholar] [CrossRef]
  40. Dori, D.; Reinhartz-Berger, I.; Sturm, A. OPCAT-A Bimodal Case Tool for Object-Process Based System Development. In Proceedings of the ICEIS (3), Angers, France, 22–26 April 2003; pp. 286–291. [Google Scholar]
  41. Weilkiens, T. Systems Engineering with SysML/UML: Modeling, Analysis, Design; Elsevier: Amsterdam, The Netherlands, 2011. [Google Scholar]
  42. Holt, J.; Perry, S.; Payne, R.; Bryans, J.; Hallerstede, S.; Hansen, F.O. A model-based approach for requirements engineering for systems of systems. IEEE Syst. J. 2014, 9, 252–262. [Google Scholar] [CrossRef]
  43. Bussemaker, J.; Boggero, L.; Ciampa, P.D. From System Architecting to System Design and Optimization: A Link Between MBSE and MDAO. In Proceedings of the 32nd Annual INCOSE International Symposium, Detroit, MI, USA, 25–30 June 2022. [Google Scholar]
  44. Let Yourself Be Guided with Arcadia, Capella MBSE Tool—Arcadia. Available online: https://www.eclipse.org/capella/arcadia.html (accessed on 29 September 2022).
  45. Li, T.; Lockett, H.; Lawson, C. Using requirement-functional-logical-physical models to support early assembly process planning for complex aircraft systems integration. J. Manuf. Syst. 2020, 54, 242–257. [Google Scholar] [CrossRef]
  46. Micouin, P. Model Based Systems Engineering: Fundamentals and Methods; John Wiley & Sons: Hoboken, NJ, USA, 2014. [Google Scholar]
  47. Balestrini-Robinson, S.; Freeman, D.F.; Browne, D.C. An object-oriented and executable SysML framework for rapid model development. Procedia Comput. Sci. 2015, 44, 423–432. [Google Scholar] [CrossRef]
  48. OpenMDAO. Available online: https://openmdao.org/ (accessed on 21 February 2021).
  49. Ciampa, P.D.; Nagel, B. AGILE Paradigm: The next generation collaborative MDO for the development of aeronautical systems. Prog. Aerosp. Sci. 2020, 119, 100643. [Google Scholar] [CrossRef]
  50. Karban, R.; Jankevičius, N.; Elaasar, M. Esem: Automated systems analysis using executable sysml modeling patterns. In Proceedings of the INCOSE International Symposium, Edinburgh, Scotland, UK, 18–21 July 2016; Wiley Online Library: New York, NY, USA, 2016; Volume 26, pp. 1–24. [Google Scholar]
  51. OpenMBEE. Available online: https://www.openmbee.org/index.html (accessed on 21 February 2021).
  52. Martin, J.N. The PMTE Paradigm: Exploring the Relationship Between Systems Engineering Process and Tools. In Proceedings of the INCOSE International Symposium, San Jose, CA, USA, 9–11 August 1994; Wiley Online Library: New York, NY, USA, 1994; Volume 4, pp. 176–183. [Google Scholar]
  53. Hussein, O.E.M.A.I. Object Process Methodology: An Evaluation Using the Framework for the Evaluation of Model-Based Systems Engineering Methodologies for Practitioners. Ph.D. Thesis, Technische Hochschule Ingolstadt, Ingolstadt, Germany, 2020. [Google Scholar]
  54. Aboushama, M.A.M.M.A. ViTech Model Based Systems Engineering: Methodology Assessment Using the FEMMP Framework. Ph.D. Thesis, Technische Hochschule Ingolstadt, Ingolstadt, Germany, 2020. [Google Scholar]
  55. Honour, E.C.; Valerdi, R. Advancing an Ontology for Systems Engineering to Allow Consistent Measurement; Technical Report; 2006; Available online: https://dspace.mit.edu/bitstream/handle/1721.1/84432/CP_060407_Honour%2cValerdi_CSER.pdf?sequence=1&isAllowed=y (accessed on 1 November 2024).
  56. ModelCenter by Phoenix Integration. Available online: https://www.phoenix-int.com/ (accessed on 21 February 2021).
  57. Gray, J.S.; Hwang, J.T.; Martins, J.R.; Moore, K.T.; Naylor, B.A. OpenMDAO: An open-source framework for multidisciplinary design, analysis, and optimization. Struct. Multidiscip. Optim. 2019, 59, 1075–1104. [Google Scholar] [CrossRef]
  58. Gallard, F.; Vanaret, C.; Guénot, D.; Gachelin, V.; Lafage, R.; Pauwels, B.; Barjhoux, P.J.; Gazaix, A. GEMS: A Python library for automation of multidisciplinary design optimization process generation. In Proceedings of the 2018 AIAA/ASCE/AHS/ASC Structures, Structural Dynamics, and Materials Conference, Kissimmee, FL, USA, 8–12 January 2018; p. 0657. [Google Scholar]
  59. Design Optimization with MATLAB and Simulink. Available online: https://www.mathworks.com/discovery/design-optimization.html (accessed on 21 February 2021).
  60. Botero, E.M.; Wendorff, A.; MacDonald, T.; Variyar, A.; Vegh, J.M.; Lukaczyk, T.W.; Alonso, J.J.; Orra, T.H.; Ilario da Silva, C. Suave: An open-source environment for conceptual vehicle design and optimization. In Proceedings of the 54th AIAA Aerospace Sciences Meeting, San Diego, CA, USA, 4–8 January 2016; p. 1275. [Google Scholar]
  61. David, C.; Delbecq, S.; Defoort, S.; Schmollgruber, P.; Benard, E.; Pommier-Budinger, V. From FAST to FAST-OAD An open source framework for rapid Overall Aircraft Design. In Proceedings of the IOP Conference Series Materials Science and Engineering, Suzhou, China, 17–19 March 2021; IOP Publishing: Bristol, UK, 2021; Volume 1024, p. 012062. [Google Scholar]
  62. Brelje, B.J.; Martins, J.R. Development of a conceptual design model for aircraft electric propulsion with efficient gradients. In Proceedings of the 2018 AIAA/IEEE Electric Aircraft Technologies Symposium (EATS), Cincinnati, OH, USA, 12–14 July 2018; IEEE: Piscataway, NJ, USA, 2018; pp. 1–25. [Google Scholar]
  63. Alder, M.; Moerland, E.; Jepsen, J.; Nagel, B. Recent advances in establishing a common language for aircraft design with CPACS. In Proceedings of the Aerospace Europe Conference 2020, Bordeaux, France, 25–28 February 2020. [Google Scholar]
  64. Eriksson, O.; Henderson-Sellers, B.; Ågerfalk, P.J. Ontological and linguistic metamodelling revisited: A language use approach. Inf. Softw. Technol. 2013, 55, 2099–2124. [Google Scholar] [CrossRef]
  65. Shortell, T.M. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities; John Wiley & Sons: Hoboken, NJ, USA, 2015. [Google Scholar]
  66. Pearce, P.; Hause, M. ISO-15288, OOSEM and Model-Based Submarine Design; SETE/APCOSE: Brisbane, Australia, 2012. [Google Scholar]
  67. Lukaczyk, T.W.; Wendorff, A.D.; Colonno, M.; Economon, T.D.; Alonso, J.J.; Orra, T.H.; Ilario, C. SUAVE: An open-source environment for multi-fidelity conceptual vehicle design. In Proceedings of the 16th AIAA/ISSMO Multidisciplinary Analysis and Optimization Conference, Dallas, TX, USA, 22–26 June 2015; p. 3087. [Google Scholar]
  68. Ramos, A.L.; Ferreira, J.V.; Barceló, J. Model-based systems engineering: An emerging approach for modern systems. IEEE Trans. Syst. Man Cybern. Part C (Appl. Rev.) 2011, 42, 101–111. [Google Scholar] [CrossRef]
  69. Cao, Y.; Liu, Y.; Paredis, C.J. System-level model integration of design and simulation for mechatronic systems based on SysML. Mechatronics 2011, 21, 1063–1075. [Google Scholar] [CrossRef]
  70. Bajaj, M.; Zwemer, D.; Peak, R.; Phung, A.; Scott, A.G.; Wilson, M. Slim: Collaborative model-based systems engineering workspace for next-generation complex systems. In Proceedings of the 2011 Aerospace Conference, Big Sky, MT, USA, 5–12 March 2011; IEEE: Piscataway, NJ, USA, 2011; pp. 1–15. [Google Scholar]
  71. Kannan, H. Formal reasoning of knowledge in systems engineering through epistemic modal logic. Syst. Eng. 2021, 24, 3–16. [Google Scholar] [CrossRef]
Systems 12 00555 g001
Figure 1. Knowledge types in engineering design [14,16].
Figure 1. Knowledge types in engineering design [14,16].
Systems 12 00555 g001
Systems 12 00555 g002
Figure 2. Projections of knowledge on to the system model [23].
Figure 2. Projections of knowledge on to the system model [23].
Systems 12 00555 g002
Systems 12 00555 g003
Figure 3. Research methodology.
Figure 3. Research methodology.
Systems 12 00555 g003
Systems 12 00555 g004
Figure 4. Structure of SUAVE.
Figure 4. Structure of SUAVE.
Systems 12 00555 g004
Systems 12 00555 g005
Figure 5. Logical decomposition: In the system model, the logical components are represented by disciplinary analyses within SUAVE.
Figure 5. Logical decomposition: In the system model, the logical components are represented by disciplinary analyses within SUAVE.
Systems 12 00555 g005
Systems 12 00555 g006
Figure 6. SUAVE—aerodynamics analyses: The decomposition of aerodynamics analyses involves different levels of fidelity.
Figure 6. SUAVE—aerodynamics analyses: The decomposition of aerodynamics analyses involves different levels of fidelity.
Systems 12 00555 g006
Systems 12 00555 g007
Figure 7. Fidelity zero aerodynamics method.
Figure 7. Fidelity zero aerodynamics method.
Systems 12 00555 g007
Systems 12 00555 g008
Figure 8. Data flow between the analysis method functions.
Figure 8. Data flow between the analysis method functions.
Systems 12 00555 g008
Systems 12 00555 g009
Figure 9. Parametric diagram showing the relation between the components and inputs/outputs.
Figure 9. Parametric diagram showing the relation between the components and inputs/outputs.
Systems 12 00555 g009
Systems 12 00555 g010
Figure 10. Physical decomposition: This decomposition reflects the structure of SUAVE. It is important to note that this figure provides a high-level view of the physical decomposition to avoid overcrowded representations.
Figure 10. Physical decomposition: This decomposition reflects the structure of SUAVE. It is important to note that this figure provides a high-level view of the physical decomposition to avoid overcrowded representations.
Systems 12 00555 g010
Systems 12 00555 g011
Figure 11. Ontological metamodel.
Figure 11. Ontological metamodel.
Systems 12 00555 g011
Systems 12 00555 g012
Figure 12. A high-level representation of the mission analysis for a Boeing 737-800, including the required analyses and the physical components whose values serve as input for the analysis.
Figure 12. A high-level representation of the mission analysis for a Boeing 737-800, including the required analyses and the physical components whose values serve as input for the analysis.
Systems 12 00555 g012
Table 1. Systems engineering methodologies.
Table 1. Systems engineering methodologies.
NameAbbreviationSource
HarmonyHarmony SEIBM Telelogic [35]
Object Oriented Systems Engineering
Method		OOSEMINCOSE [36]
Rational Unified Process for Systems
Engineering for Model-Driven Systems
Development		RUP SE MDSDIBM [37]
Vitech Model-Based Systems
Engineering Method		Vitech MBSEVitech [38]
State AnalysisSAJet Propulsion
Laboratory [39]
Object Process MethodologyOPMDori [40]
The Systems Modeling ToolboxSYSMODWeilkiens [41]
Approach for Context Based
Requirements Engineering		ACREHolt [42]
Aircraft 3rd Generation MDO For
Innovative Collaboration of
Heterogeneous Teams of Experts		Agile 4.0European Union’s Horizon
2020 research and innovation
framework program [43]
ARChitecture Analysis and Design
Integrated Approach		ARCADIAThales [44]
Requirements, Functional, Logical,
and Physical		RFLPDassault Systems [45]
Property Model MethodologyPMMMicoin [46]
Table 2. Comparison of MDO and MBSE integration approaches.
Table 2. Comparison of MDO and MBSE integration approaches.
ApproachAdvantagesDisadvantages
GTRI FrameworkFlexible; uses open-source tools. Connects engineering and system models.Limited SysML semantics. Not tied to specific methodologies, complicating integration for complex processes.
AGILE ParadigmEarly inconsistency detection; promotes model reusability. Supports collaborative environments.High initial setup time. Lacks formalized framework for full-system model implementation.
NASA JPL ESEMDirect analysis derivation in SysML; no external tools needed for basic tasks.Cannot define complex analyses (e.g., CFD, FEA) without external tools due to SysML limitations.
SERC Interoperability and Integration FrameworkIntegrates SysML with ontologies and visualizations. Demonstrates MDO in a UAV case study.Relies on basic Python scripts; lacks integration with advanced domain-specific engineering tools.
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Share and Cite

MDPI and ACS Style

Karagoz, E.; Pinon Fischer, O.J.; Mavris, D.N. Enhancing Ontological Metamodel Creation Through Knowledge Extraction from Multidisciplinary Design and Optimization Frameworks. Systems 2024, 12, 555. https://doi.org/10.3390/systems12120555

AMA Style

Karagoz E, Pinon Fischer OJ, Mavris DN. Enhancing Ontological Metamodel Creation Through Knowledge Extraction from Multidisciplinary Design and Optimization Frameworks. Systems. 2024; 12(12):555. https://doi.org/10.3390/systems12120555

Chicago/Turabian Style

Karagoz, Esma, Olivia J. Pinon Fischer, and Dimitri N. Mavris. 2024. "Enhancing Ontological Metamodel Creation Through Knowledge Extraction from Multidisciplinary Design and Optimization Frameworks" Systems 12, no. 12: 555. https://doi.org/10.3390/systems12120555

APA Style

Karagoz, E., Pinon Fischer, O. J., & Mavris, D. N. (2024). Enhancing Ontological Metamodel Creation Through Knowledge Extraction from Multidisciplinary Design and Optimization Frameworks. Systems, 12(12), 555. https://doi.org/10.3390/systems12120555

Note that from the first issue of 2016, this journal uses article numbers instead of page numbers. See further details here.

Article Metrics

Back to TopTop