With the advancement of computational power and physical solvers, the complexity of coupled systems in the aerospace domain will continue to grow. Currently, engineers often model such systems from scratch or reuse local files, despite the potential to formalize, store, and share expert knowledge for broader reuse. In this work, we focus on the open-source software KRATOS Multiphysics, which supports coupled simulations through its CoSimulationApplication. The input JSON files for KRATOS describe deeply nested and interconnected structures, making them dificult to interpret and reuse. To enhance the FAIRness (Findability, Accessibility, Interoperability, and Reusability) of this data, we leverage RDF and OWL standards of the Semantic Web. However, manually constructing semantic graphs and ontologies from such lfies is both labor-intensive and prone to human error. To address this, we propose an automated procedure for extracting reusable knowledge from coupled simulation data and storing it in a centralized, human- and machine-interpretable knowledge base. Our contribution includes an algorithm that automatically translates KRATOS CoSimulationApplication JSON input files into RDF graphs and derives OWL ontologies from them, capturing generalizable patterns of coupled systems. We validate this approach through a proof-of-concept implementation applied to two representative use cases. Our results demonstrate that the extracted knowledge can be visualized and queried, ofering capabilities that were previously achievable only through manual inspection and analysis of JSON files.
To advance and explore new aerospace technologies, it is essential to model and solve increasingly
complex problems that span multiple disciplines. With ongoing improvements in computational power
and advanced physical solvers, the complexity of multidisciplinary models and their analysis is expected
to grow significantly. As a result, tools and support systems are needed to help future engineers better
understand, visualize, and manage the data generated by their models and simulations [
Moreover, the FAIR principles emphasize the need for computational systems to Find, Access,
Interoperate, and Reuse data with minimal human intervention [
We focus on the open-source software KRATOS Multiphysics [9, 10], which provides a flexible framework for developing multidisciplinary solvers. Coupled simulations within KRATOS are handled by the CoSimulationApplication [11], which relies on JSON files as input. These JSON configurations are typically created manually by engineers, embedding expert knowledge that could otherwise be formalized, stored, and reused to define new problems more eficiently. The JSON files often contain deeply nested, interconnected structures that are dificult for new users to interpret, yet include a significant amount of reusable components and recurring patterns. Thus, applying RDF and OWL standards can help align the data with FAIR principles and enhance its machine readability and interoperability.
To enhance accessibility and reuse, we propose a centralized knowledge base that is both humanand machine-interpretable for storing data from coupled simulations. However, manually designing and populating such a knowledge base is time-consuming and prone to human error. To address this, we develop an automated approach for extracting reusable knowledge from previously implemented coupled systems. Specifically, we present an algorithm that converts input JSON files from the KRATOS CoSimulationApplication into RDF format and derives OWL axioms to describe unique classes of coupled systems. We validate this algorithm through a proof of concept, applying it to two distinct use cases, and demonstrate how the proposed approach improves the accessibility and reusability of data in coupled modeling.
The paper is organized as follows: section 2 reviews related work; section 3 provides background on the KRATOS CoSimulationApplication; section 4 describes the proposed method; section 5 presents its application to two use cases; section 6 discusses the results; and finally, section 7 concludes the paper.
Aerospace engineering makes use of various data models, languages, and ontologies, with XML being the most widely adopted. Vargas-Hernandez et al. [12] employed bond graphs to develop a CAD tool for designing complex electromechanical systems using a standardized taxonomy of elements. Agrawal et al. [13] developed a platform-independent visualization framework for solving multidisciplinary design optimization (MDO) problems. Jackson and Hildreth [14] proposed a flight dynamics model exchange standard. Nagel et al. [15] introduced the Common Parametric Aircraft Configuration Scheme (CPACS), a unified XML-based data model for interfacing between various MDO systems. Munjulury [ 16] presented RAPID, a relational-based tool for aircraft geometry design. Van Gent [17] introduced the Common MDO Workflow Schema (CMDOWS), a graph-based, application-agnostic formalization of multidisciplinary design analysis and optimization (MDAO) workflows.
Another widely adopted approach is the use of Unified Modeling Language (UML). Lu [ 18] applied an object-oriented framework to model data for aircraft conceptual design. Oh et al. [19] proposed a mapping methodology to facilitate the exchange of product structure data between CAD and product data management systems. Böhnke [20] compared CPACS [15], STEP1, and UML in terms of their suitability for data integration in preliminary aircraft design, concluding that a combination of UML or SysML with XML ofers the most benefits.
Researchers have also developed specialized software tools to model knowledge in aerospace engineering. Sung & Park [21] introduced a component-based product data management system implemented in Java. Haney [22] developed a data engineering system using Microsoft Access to support aerospace design and forecasting tasks. Herbst [23] presented ADDAM, an object-oriented aircraft design environment implemented in MATLAB. The Python implementation of CMDOWS, known as Knowledgeand Graph-based Agile Design for Multidisciplinary Optimization System (KADMOS), was introduced by Van Gent [17]. Similarly, Risueño et al. [24] developed the MDAO Workflow Design Accelerator (MDAx) in Python, extending the XDSM format with additional design rules.
In this work, we focus on knowledge representation methods with embedded semantics. Using RDF, Bang et al [25] developed Daphne, an intelligent assistant designed to support the architecture of Earth-observing satellite systems. Herrero [26] proposed a Digital Thread for airplane design, modeled as a knowledge graph to enable seamless data integration across the design process.
Studies utilizing OWL predominantly rely on manual modeling using the Protégé tool. Curran et
al. [27] proposed the Knowledge Optimized Manufacture and Design (KNOMAD) ontology. Kuofie [ 28]
introduced the Rationale-based Design Explanation (RaDEX) framework. Verhagen & Curran [29]
developed an ontology for the aerospace composite manufacturing domain. Zhao et al. [30] constructed
a knowledge base for spacecraft overall design. More recently, Franzén et al. [
Some studies go a step further by incorporating rule-based reasoning using SWRL. Hoogreef et
al. [
The most relevant related work includes methods that incorporate automated knowledge extraction workflows. Dadzie et al. [ 33] introduced a methodology for extracting knowledge from textual and multimedia documents in the aeronautics domain, using both manual and automated techniques, and representing the information with RDF and OWL DL. Khilwani & Harding [34] developed a framework for managing corporate memory by extracting information from documents, converting it into RDF resources, and identifying relationships using Latent Semantic Analysis. Ezhilarasu & Jennions [35] proposed the Framework for Aerospace Vehicle Reasoning (FAVER), which combines an Adaptive Neuro-Fuzzy Inference System (ANFIS) with causal reasoning. Berquand [36] applied natural language processing (NLP) techniques to extract an ontology of domain-specific models and rules from documents, storing the results in TypeDB2. De Leon [37] proposed an approach to enhance association rule mining for Entry, Descent, and Landing datasets by leveraging a user-defined knowledge graph implemented using SysML and Neo4j. However, automated knowledge extraction specifically from coupled systems remains an open and underexplored area.
This section provides background on the coupled modeling software that forms the focus of our work. Coupled problems are often addressed using black-box solvers. However, solving multidisciplinary and mixed-fidelity problems through co-simulation requires software that supports eficient coupling strategies, manages the complexity of data exchange between heterogeneous solvers and models, and ensures proper synchronization across multiple processes. KRATOS Multiphysics [9, 10] is a free, open-source framework for the development of multidisciplinary simulation software. It is particularly well-suited to our study, as it has been designed to support complex, coupled simulation scenarios and emphasizes generality, reusability, and extensibility, ofering a wide range of tools for implementing finite element applications. It also provides a unified interface for interaction between internal applications and externally controlled solvers, thereby reducing implementation overhead and simplifying data synchronization, especially when compared to traditional distributed data exchange approaches where individual solvers are connected directly to one another.
Co-simulation capabilities in KRATOS are provided by the CoSimulationApplication [11], which manages data exchange and process coordination in coupled simulation environments. This application relies on a JSON file with a specific structure as its input. The core component of the file is the solver_settings section, which defines the configuration of the coupled system. Its main elements include: • type: Specifies the coupling method, such as weak or strong coupling using Gauss-Seidel or
Jacobi strategies. • num_coupling_iterations: Sets the maximum number of coupling iterations allowed. • data_transfer_operators: Defines how data is transferred between solvers or codes, either through direct copying or using KRATOS mapping. • convergence_accelerators: Used to accelerate convergence in strongly coupled simulations.
Available only for strongly coupled solvers. • convergence_criteria: Specifies the criteria for determining when the coupled problem is considered solved. Also only applicable for strongly coupled solvers. • coupling_sequence: Describes the sequence in which disciplines are solved and data is synchronized, establishing the order for initializing and executing the coupling process. • input_data_list: Defines the input data flow. For example, “Discipline 1” receives “data 1” from “Discipline 2”, stores it as “data 1”, and applies “operation 1”. • output_data_list: Specifies the output data flow in a manner similar to the input configuration. • solvers: Lists all solvers or external codes involved in the co-simulation, describing shared meshes, coupled variables or data fields, and communication methods for data exchange. • solver_wrapper_settings: Contains solver-specific parameters, including settings for I/O communication and mesh/data synchronization.
Listing 1 presents a fragment of a typical KRATOS CoSimulation JSON configuration. As shown, the structure is deeply nested and consists of numerous interconnected components. In JSON format, this complexity can be challenging for new users to comprehend. Moreover, the configuration includes a significant amount of reusable structural patterns and recurring entities. Therefore, we propose that a graph-based representation of this data could ofer a more intuitive and accessible way to understand and interact with the configuration. { "data_transfer_operators": {
"operation 1": {...} }, "coupling_sequence": [ { "name": "Displine 1", "input_data_list": [
{ }, { }
} ], ...
"name": "Displine 2", ... ], "solvers": { "Displine 1": { "data": {
"data 1": {...}, ...
}, ...
}, ... } } "data": "data 1", "from_solver": "Displine 2", "from_solver_data": "data 1", "data_transfer_operator": "operation 1"
Listing 1: A fragment of the KRATOS CoSimulation configuration in JSON
Currently, aerospace engineers typically model coupled systems either from scratch or by reusing locally available files. Our goal is to streamline this process by developing a centralized knowledge base with structured representations, thereby making knowledge from prior coupled simulations more FAIR. This knowledge base includes semantic representations of coupled simulation data in RDF, enhancing interoperability, as well as general knowledge encoded as OWL axioms, which supports human understanding in the formulation and validation of new coupled systems.
Since manual ontology development and knowledge base population are time-consuming and dificult to maintain, our approach is data-driven. While existing tools such as JSON2RDF3 can convert JSON into RDF, preliminary experiments revealed that these tools fail to accurately capture the underlying data model of the KRATOS CoSimulationApplication and do not support the extraction of generalized knowledge from the data. To address this limitation, we develop an automated workflow that extracts both information and reusable knowledge from KRATOS input JSON files and consistently imports it into the knowledge base. For shortness, we refer to this algorithm as CoSim2OWL. This process consists of two main steps: 1) Populating the knowledge base with coupled simulation data extracted from a JSON file and translating it into RDF, and 2) Deriving OWL class axioms that semantically describe the RDF data.
Figure 1 illustrates our proposed approach. On the left, the diagram depicts the current multidisciplinary analysis (MDA) workflow, where aerospace engineers typically model coupled systems from scratch. On the right is the enhanced workflow we propose, which incorporates a knowledge base to support reuse and automation. In our approach, JSON files containing data from previous experiments are processed by a Python module implementing the CoSim2OWL algorithm. This module extracts relevant information and stores it in an OWL-based knowledge base. In subsequent experiments, knowledge at various levels of granularity can be retrieved from the knowledge base via SPARQL queries to support the formulation of new coupled systems. Looking ahead, we plan to further streamline knowledge retrieval by developing an API for the knowledge base and integrating it with existing graphical user interfaces for KRATOS, such as FlowGraph4. In the diagram, components highlighted in green represent elements implemented in this work, while dotted elements indicate planned future developments.
This subsection describes the first stage of the CoSim2OWL workflow — translating coupled system data into RDF format. The knowledge base, denoted as , is initialized with a single predefined class, coupled_system (we use teletype font to denote knowledge base objects). This class serves as the superclass for all coupled systems extracted from the CoSimApp JSON files. For each coupled system, the algorithm begins by instantiating the coupled_system class with a named individual , which corresponds to a specific coupled system described in the input JSON. The algorithm then recursively parses the JSON structure, generating RDF triples and populating accordingly. At each iteration, the algorithm constructs an RDF triple using the RDF resource created in the previous step as the subject , a key from the current JSON object as the predicate name , and the corresponding value as the object . The resulting triple (, , ) is then added to the knowledge base. This recursive traversal continues until the entire JSON structure has been processed and fully represented in RDF.
The object value in a JSON key-value pair can be one of three types: 1) a JSON object, 2) an array, or 3) a literal. Depending on the type, the CoSim2OWL algorithm generates the corresponding RDF triple using diferent procedures. For clarity and precision, this part of the algorithm is described formally in Algorithm 1. If is a JSON object, it is converted into an owl:NamedIndividual using Algorithm 2. This sub-algorithm also assigns the newly created individual to a specific OWL class , determined based on the predicate name that links to the subject . The algorithm then
Manual formulation of MDA tasks from scratch
Reusing previously solved MDA tasks done not yet Actor
CoSimApp input JSON
KRATOS Multiphysics MDA solver
CoSim2OWL
Python Graphic user interface
KRATOS FlowGraph Actor
MDA problems knowledge base
OWL Python API recursively calls Algorithm 1, treating as the new subject, to process any nested structure and add further RDF triples to the knowledge base. If is a literal, the algorithm either finds or creates an owl:DataProperty using the predicate name , and adds the triple (, , ) to . If is an array, the algorithm iterates over each element in the array. For each item, it checks whether is a JSON object or a literal and applies the corresponding procedure as described above. Finally, the algorithm returns the current subject , which can be reused in subsequent iterations or higher-level operations.
Algorithm 1 Triples generation from KRATOS CoSimulation configuration Require: Knowledge base , subject , predicate name , object value if is a JSON object then
Apply Algorithm 2 to , , , , owl:Thing else if is an array then for ∈ do if is a JSON object then
Get/create an owl:Class by
Apply Algorithm 2 to , , , , else
Get/create an owl:DataProperty by
Add (, , ) to end if end for else
Get/create an owl:DataProperty by
Add (, , ) to end if return
Algorithm 2 describes the translation of a JSON object value into an owl:Named-Individual . It is invoked from Algorithm 1 and receives the following inputs: the current knowledge base , an existing subject individual , the object value , the predicate name connecting to , and a superclass that serves as a parent for any class created for the individual . Within the algorithm, a class is either retrieved or created as a subclass of , based on the predicate name . The object value is then instantiated as an individual of class . Using the same predicate name , an owl:ObjectProperty is retrieved or created to represent the relationship between and . The triple (, , ) is then added to the knowledge base . Afterward, the algorithm iterates over each key-value pair (, ) within the JSON object , and recursively calls Algorithm 1 with the updated parameters: the knowledge base , the new subject , key , and value . This recursive traversal continues to generate additional RDF triples for the nested structure of .
Algorithm 2 Translating JSON object of KRATOS CoSimulation configuration into named individual Require: knowledge base , subject , predicate name , object value , object superclass Get/create an owl:Class by as an Get/create an owl:ObjectProperty by owl:SubClassOf Instantiate with for (, ) ∈ do
Apply Algorithm 1 to , , ,
Add (, , ) to end for 4.2. Describing classes of coupled systems with OWL axioms Once a specific coupled system is represented in the knowledge base , we derive general knowledge from it by generating OWL axioms that capture recurring structural patterns as class restrictions. This process is described in Algorithm 3. The algorithm iterates over each individual ∈ . For each individual, we compute the set of predicates for which is the subject: () = { : ∃(, )}.
For each predicate ∈ , we collect the set of individuals such that (, ) holds, i.e., the set of objects connected to via . We then determine the set of classes to which the individuals in belong:
(()) = { : ∃(, ), ∈ }.
For each class ∈ , we count the number of individuals in that belong to . Then, for each class that is an instance of, we generate OWL class axioms as follows: if = 1, we add an existential restriction: otherwise, we add a cardinality restriction: ⊑ ∃., ⊑= ..
To summarize, for each key-value pair (, ) in the JSON object extracted from the input file of the KRATOS CoSimulationApplication, we create an individual in the knowledge base to represent the coupled system under consideration. The key and value are then passed to Algorithm 1, which recursively traverses the structure of and adds corresponding RDF triples to . Finally, we apply Algorithm 3 to in order to enrich the knowledge base with OWL axioms that capture generalizable patterns and semantic constraints. These axioms generalize the observed patterns in the RDF data into reusable, machine-interpretable OWL semantics, thereby enriching the knowledge base with domain-level conceptual knowledge. The described CoSim2OWL algorithm has been implemented in Python using the Owlready2 library [38]. The implementation is publicly available on GitHub5. 5https://anonymous.4open.science/r/coupled_modelling-3909/ Algorithm 3 Generation of OWL axioms describing classes of coupled systems Require: for ∈ do = () = () for ∈ do = (()) for ∈ do = (, (()) for ∈ do if == 1 then
⊑ ∃. else
⊑= . end if end for end for end for end for
To validate the proposed workflow, we examine two case studies of coupled systems from the aerospace engineering domain. Both cases involve fluid-structure interaction (FSI) problems but difer in the type of models used: 1) analytical functions and 2) finite element-based physical models (FEM). The developed prototype is applied to extract a knowledge base from each of these coupled systems.
The first use case involves a simplified aero-structural system consisting of a two-dimensional airfoil mounted on a spring. This airfoil–spring system is modeled using an analytical approach originally developed by Sobieszczanski-Sobieski in [39], see Figure 2.
The analytical model consists of two coupled disciplines: 1) the fluid dynamics around the airfoil and 2) the structural behavior of the supporting spring system. These disciplines are coupled through two shared variables: the elastic support pitch angle of the airfoil (Φ ) and the resulting lift force (). The model operates according to the following process: 1. The lift force acting on the airfoil is computed using aerodynamic equations and is directly transferred to the structural model by simple data copying. 2. The deformation of the spring system caused by the applied lift force alters the elastic support pitch angle Φ , which is then passed back to the aerodynamic model. This updated pitch angle is used to recompute the lift force.
3. The process repeats iteratively until a stationary point is reached.
Due to the assumed nonlinear relationship between the lift coeficient and the pitch angle, the solution cannot be obtained analytically in a single step. Instead, it requires iterative resolution using a strong coupling strategy.
The second use case is based on a finite element model of an aeroelastic ONERA M6 wing, see Figure 3. The ONERA M6 wing is a well-established benchmark case for validating computational fluid dynamics (CFD) methods in external aerodynamic flows. Its relatively simple geometry, combined with the presence of complex transonic phenomena, such as local supersonic regions, shock waves, and turbulent boundary layer separation, makes it particularly suitable for such evaluations. Due to its extensive use in the literature as a reference case [40], the ONERA M6 wing has become a de facto standard for assessing the accuracy and performance of CFD codes.
(a) photo from [40] (b) numerical CFD mesh
The open-source SU2 solver [41] is used to solve the steady 3D Euler equations and compute the aerodynamic forces of the CFD model. The structural mechanics (SM) model shares the same geometry as the ONERA M6 wing and is discretized using solid tetrahedral finite elements. It is solved using the KRATOS StructuralMechanicsApplication. The FE-based coupled model can be described as follows: 1. The coupled problem is solved using the KRATOS CoSimulationApplication, which employs a strong Gauss–Seidel coupling strategy as specified in the type property of the input JSON file. To accelerate convergence and reduce computational cost, convergence acceleration methods are defined in the convergence_accelerators section. 2. The CFD and SM models are remotely orchestrated by the CoSimulationApplication and executed sequentially according to the order specified in coupling_sequence. 3. The SU2 solver, defined in the solvers section, computes the aerodynamic solution and outputs the lift force. 4. The lift force is transferred from the CFD model to the SM model using a mapping strategy provided by the KRATOS MappingApplication, as specified in the data_transfer_operators property, see Figure 4a. 5. The KRATOS StructuralMechanicsApplication, also defined in solvers, computes the resulting structural displacements in response to the transferred aerodynamic loads, see Figure 4b. 6. This process is repeated iteratively until convergence is reached, as defined by the criteria specified in convergence_criteria.
(a) lift force (b) structural displacements
To extract a knowledge base from the described coupled systems, we process the input JSON files corresponding to each case and create an instance of the coupled_system class for each. The instance for the first use case is labeled low_fid_models, while the second use case is represented by the instance Onera_FSI. We then run our prototype to translate the JSON data into a graph-based representation and to derive semantic knowledge from it. The resulting knowledge base contains 549 axioms, 41 classes, 41 individuals, 32 data properties, and 13 object properties. Figure 5 visualizes the part of the knowledge base corresponding to the low_fid_models coupled system.
As an example of the generated axioms, Figure 6a illustrates the properties of the solvers_1 class, which represents both the low_fid_fluid and spring_structure solver instances. This class is a subclass of solvers and is required to be connected to two instances of the data_1 class, one instance of io_settings_1, and one instance of solver_wrapper_settings_1. Additionally, it possesses a string value for the has_type property. Figure 6b shows the properties of the low_fid_fluid individual.
(b) Properties of a generated instance (a) Properties of a generated class
As an example of how the knowledge base can be utilized, Listing 2 demonstrates a SPARQL query that retrieves all solvers used in previous experiments. This query returns solvers such as low_fid_fluid and spring_structure from the first coupled system, as well as SM and CFD from the second coupled system. This information previously could only be obtained by manually collecting and inspecting local JSON files.
SELECT DISTINCT ?solver WHERE { ?solver rdf:type ?solvers .
?solvers rdfs:subClassOf kb:solvers . } -------------------------------------------------------spring_structure low_fid_fluid SM CFD Listing 2: SPARQL query for retrieving solver instances across all coupled systems in the knowledge base
In this subsection, we demonstrate that existing tools for converting JSON data into RDF are not suficient for our goals. Listing 3 shows RDF in TTL format generated by the JSON2RDF tool based on the airfoil–spring system, while Listing 4 presents RDF generated by our approach using the same content. The two outputs difer in both structure and semantic expressiveness. The RDF generated by JSON2RDF contains blank nodes, which require deep path traversal when querying. In contrast, our tool creates named individuals, giving each resource an identifiable IRI. The output from JSON2RDF is also harder to maintain and reuse, as it is less modular. Finally, the RDF produced by our approach explicitly employs OWL classes and properties, enabling more advanced semantic modeling. ... :solver_settings [ :convergence_accelerators [ :data_name "pitch_angle"; :solver "low_fid_fluid" ; :type "aitken" ] ; :data_transfer_operators [ : direct_transfer [ :mapper_settings [ :mapper_type "
nearest_neighbor" ; :echo_level "3"^^xsd:int ] ; :type "kratos_mapping" ] ] ; :echo_level "3"^^xsd:int ; :num_coupling_iterations "20"^^xsd:
int ; :type "coupled_solvers.
gauss_seidel_strong" ; ...
Listing 3: RDF generated by JSON2RDF ... :instance_3 rdf:type owl:NamedIndividual ,
:solver_settings_1 ; :has_convergence_accelerators :instance_6 ; ... :has_data_transfer_operators :instance_4 ; ... :has_echo_level 3 ; :has_num_coupling_iterations 20 ; :has_type "coupled_solvers.
gauss_seidel_strong" . ... :instance_6 rdf:type owl:NamedIndividual ,
:convergence_accelerators_1 ; :has_data_name "pitch_angle" ; :has_solver "low_fid_fluid" ; :has_type "aitken" . ... :instance_4 rdf:type owl:NamedIndividual ,
:data_transfer_operators_1 ; :has_mapper_settings :instance_5 ; :has_type "kratos_mapping" ; rdfs:label "direct_transfer" . ...
6.2. Advancing FAIRness of coupled simulation data In the current state of our approach, we do not perform a user evaluation, as we do not expect aerospace engineers to interact directly with Semantic Web tools such as Protégé. We plan to conduct a user study after integrating our approach with user-friendly interfaces like FlowGraph. In the meantime, we provide an analysis of the FAIRness of the generated representation in comparison to the source JSON data (see Table 1). This comparison shows that transforming coupled simulation configurations from JSON into an ontology-based RDF representation makes a significant advancement in terms of FAIR compliance. Whereas the original JSON files are functional only within their specific software ecosystem and serve as siloed containers with implicit semantics, our approach transforms the configuration data into a FAIR digital object. Each piece of information is assigned a unique identifier, embedded within a formal, machine-interpretable schema, and linked through explicit, typed relationships. Moreover, the proposed approach enhances data reusability and interoperability by reusing previously generated classes and properties when modeling new coupled systems. For example, see Listing 5 and Listing 6, which describe two instances, one from the low_fid_fluid model and the other from the Onera_FSI model. Both instances belong to the same class, problem_data_1, as they share the exact same set of properties and difer only in their echo level value. This ensures structural consistency and results in a unified MDA knowledge base. :instance_2 rdf:type owl:NamedIndividual ,
:problem_data_1 ; :has_parallel_type "OpenMP" ; :has_echo_level 0 ; :has_end_time 1.0 ; :has_print_colors "true"^^xsd:boolean ; :has_start_time 0.0 . :instance_44 rdf:type owl:NamedIndividual ,
:problem_data_1 ; :has_parallel_type "OpenMP" ; :has_echo_level 2 ; :has_end_time 1.0 ; :has_print_colors "true"^^xsd:boolean ; :has_start_time 0.0 .
Listing (5) An instance of problem data from the
low_fid_fluid model Onera_FSI model
In this research, we addressed the challenge of enabling the reuse of expert knowledge for modeling coupled systems by representing it using RDF and OWL languages. We developed an automated workflow to extract knowledge from KRATOS CoSimulationApplication input JSON files and store it in a centralized knowledge base. As a result, our approach enhances the accessibility and interoperability of MDA data and enables the extraction of unique, human- and machine-interpretable general patterns of coupled systems. We validated our method through two use cases and demonstrated how the extracted knowledge can be efectively visualized and queried, while previously accessing such knowledge required manual collection and analysis of JSON files.
Although our work represents only an initial step toward data FAIRification in the aerospace engineering domain, addressing this challenge is essential to manage the imminent overflow of technical data that can no longer be handled manually. In future work, we will validate the scalability of our approach and further enhance the FAIRness of the data and knowledge stored in our knowledge base. Specifically, we plan to further increase its FAIRness by synchronizing our resources with established knowledge bases such as Wikidata and DBpedia. Additionally, we aim to extend the knowledge base with a Python API to facilitate knowledge retrieval and integrate it with existing graphical user interfaces.
We would like to acknowledge the funding by the Deutsche Forschungsgemeinschaft (DFG, German Research Foundation) under Germany´s Excellence Strategy – EXC 2163/1 - Sustainable and Energy Eficient Aviation – Project-ID 390881007 and the German Ministry of Education and Research (BmBF) for the project KISSKI AI Service Center (01IS22093C).
During the preparation of this work, the author(s) used ChatGPT in order to: Grammar and spelling check. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content. [8] T. Wittenborg, I. Baimuratov, L. K. Franzén, I. Staack, U. Römer, S. Auer, Knowledge-based aerospace engineering–a systematic literature review, arXiv preprint arXiv:2505.10142 (2025).
URL: https://doi.org/10.48550/arXiv.2505.10142. doi:10.48550/arXiv.2505.10142. [9] P. Dadvand, R. Rossi, E. Oñate, An Object-oriented Environment for Developing Finite Element Codes for Multi-disciplinary Applications, Archives of Computational Methods in Engineering 17 (2010) 253–297. URL: http://link.springer.com/10.1007/s11831-010-9045-2. doi:10.1007/ s11831-010-9045-2. [10] V. M. Ferrándiz, P. Bucher, R. Zorrilla, R. Rossi, A. Cornejo, Jcotela, M. A. Celigueta, J. Maria, Tteschemacher, C. Roig, M. Masó, Suneth Warnakulasuriya, G. Casas, M. Núñez, P. Dadvand, S. Latorre, I. De Pouplana, J. I. González, F. Arrufat, Riccardotosi, AFranci, A. Ghantasala, P. Wilson, Dbaumgaertner, Bodhinanda Chandra, A. Geiser, K. B. Sautter, Inigo Lopez, Lluís, Javi Gárate, KratosMultiphysics/Kratos: Release 9.3, 2023. URL: https://zenodo.org/record/3234644. doi:10. 5281/ZENODO.3234644, language: en. [11] P. Bucher, A. Ghantasala, P. Dadvand, R. Wüchner, K.-U. Bletzinger, Realizing cosimulation in and with a multiphysics framework, 2021. doi:10.23967/coupled.2021.048. [12] N. Vargas-Hernandez, J. Shah, Z. Lacroix, Development of a computer aided conceptual design tool for complex electromechanical systems, in: Computational Synthesis: From Basic Building Blocks to High Level Functionality, Papers from the 2003 AAAI Symposium Technical Report SS-03-02, 2003, pp. 255–261. [13] G. Agrawal, S. Parashar, K. W. English, C. L. Bloebaum, Web-based visualization framework for decision-making in multidisciplinary design optimization, in: 45th AIAA/ASME Conference, Citeseer, 2004, pp. 19–22. URL: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi= e94eda1e9ac59fb4202d213685594c903e7910d7. [14] E. B. Jackson, B. L. Hildreth, Progress Toward a Format Standard for Flight Dynamics Models, 2006. URL: https://ntrs.nasa.gov/citations/20060048508. [15] B. Nagel, D. Böhnke, V. Gollnick, P. Schmollgruber, A. Rizzi, G. La Rocca, J. J. Alonso, Communication in aircraft design: Can we establish a common language, in: 28th International Congress of the Aeronautical Sciences, volume 201, 2012. URL: https://www.icas.org/ICAS_ARCHIVE/ICAS2012/ PAPERS/201.PDF, issue: 2. [16] V. R. C. Munjulury, Knowledge based integrated multidisciplinary aircraft conceptual design, PhD Thesis, Linköping University Electronic Press, 2014. URL: https://www.diva-portal.org/smash/ record.jsf?pid=diva2:719775. [17] I. van Gent, Agile MDAO systems: a graph-based methodology to enhance collaborative multidisciplinary design, 2019. URL: https://research.tudelft.nl/en/publications/ agile-mdao-systems-a-graph-based-methodology-to-enhance-collabora. [18] Z. Lu, Data management in an object-oriented distributed aircraft conceptual design environment, PhD Thesis, Citeseer, 2005. URL: https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf& doi=dca1203c612b3e35449e180cb605431b8b627511. [19] Y. Oh, S.-h. Han, H. Suh, Mapping product structures between cad and pdm systems using uml,
Computer-aided design 33 (2001) 521–529. [20] D. Böhnke, Data integration in preliminary airplane design, PhD Thesis, 2009. URL: https://elib.dlr.
de/59735/. [21] C. S. Sung, S. J. Park, A component-based product data management system, The International
Journal of Advanced Manufacturing Technology 33 (2007) 614–626. [22] E. Haney, Data Engineering in Aerospace Systems Design & Forecasting, PhD Thesis, 2016. URL: https://rc.library.uta.edu/uta-ir/handle/10106/25877. [23] S. Herbst, Development of an aircraft design environment using an object-oriented data model in MATLAB, PhD Thesis, Technische Universität München, 2018. URL: https://mediatum.ub.tum.de/ 1431402. [24] R. A.P, B. J.H, C. P.D, N. B, MDAx: Agile Generation of Collaborative MDAO Workflows for
Complex Systems, 2020. URL: https://zenodo.org/record/4672051. doi:10.2514/6.2020-3133.