Model-Based Systems Engineering

Systems Engineering (SE) is a cross-disciplinary and holistic approach that supports the development and management of all relevant life-cycle phases of complex products and services that meet the needs and constraints of various stakeholders (Friedenthal et al., Reference Friedenthal, Moore and Steiner2012; Walden, Reference Walden2023). SE includes systemic thinking and the systematic use of processes and methods for efficient and target-oriented product development (Walden et al., Reference Walden, Roedler, Forsberg, Hamelin and Shortell2015; Haberfellner et al., Reference Haberfellner, de Weck and Fricke2019).

MBSE is an extension of SE that uses models to represent or analyze information about the system under consideration [called the System of Interest (SOI)]. These models describe not only the system itself but also its surrounding context, such as environmental conditions or operational scenarios during the system life phases (Estefan, Reference Estefan2008; Husung et al., Reference Husung, Weber, Mahboob and Kleiner2021). Semi-formal, cross-disciplinary system models are particularly useful in the concept phase and at the mechatronic system level, as they allow for flexibility to handle frequent changes and iterations. In contrast, formal models are primarily used for the detailed specification and verification of product properties in later development phases in and across different domains (Hick et al., Reference Hick, Bajzek and Faustmann2019).

The Systems Modeling Language (SysML) is a widely used modeling language in MBSE (Friedenthal et al., Reference Friedenthal, Moore and Steiner2012; Dori, Reference Dori2016). The representation of the system and the context in MBSE (e.g., using SysML) is referred to as the system model. The system model is often organized hierarchically by specifying various aspects of the context (i.e., the use cases and the corresponding system environment) and the system with the mechatronic as well as (at least partially) electronic, software, and mechanical system elements. These elements include interfaces that describe interactions within the system and with external objects in the system context. It should be noted that system models today often include project- and product-specific content (Mandel et al., Reference Mandel, Schwarz, Brix, Albers and Husung2023), which restricts cross-project knowledge reuse. Cross-project descriptions are primarily found in models from modular systems (Hanna and Krause, Reference Hanna and Krause2017) or Product Line Engineering (ISO/IEC, 2021). However, the integration of empirical knowledge into SysML models remains a key challenge.

System models can be extended by specific definitions, depending on the modeling objective or methodology used. In particular, the Risk Analysis and Assessment Modeling Language should be mentioned in the context of Robust Design (Biggs et al., Reference Biggs, Juknevicius, Armonas and Post2018; OMG, 2022). These extensions enable the inclusion of robustness analyses, but systematic reuse of knowledge is still underdeveloped. It should be noted that, in addition to SysML, there are other modeling languages, such as the Object Process Methodology (OPM) in accordance with the ISO 19450 standard.

Robust design

The realization of required functions and further product properties within permissible (or acceptable) tolerances has been a central topic in engineering for more than a century. Early foundational work dates back to the nineteenth century (Redtenbacher, Reference Redtenbacher1859; Reuleaux, Reference Reuleaux1882) established the groundwork for understanding the relationship between design parameters, tolerances, and system performance.

Since the mid-twentieth century, several trends emerged in the field of Robust Design (RD). One of the best-known authors is Taguchi (Reference Taguchi1986), who introduced statistical methods to reduce variability in the context of Quality Management. To improve the robustness of precision engineering products, investigations were carried out by Hansen (Reference Hansen1970) and by Höhne et al. (Reference Höhne, Weber and Husung2024), among others, who applied systemic approaches to analyze the influences on function and thus also on system performance, as well as to determine necessary conceptual and design measures. Hansen systematically distinguished between intended and unintended input variables, including their deviations and deviations in the internal state variables (Z), which can lead to deviations in the intended or unintended output variables (see Fig. 1). Building on Hansen’s work, Brix et al. (Reference Brix, Husung and Döring2024) introduced a systematic categorization of failures. These failure categories form the foundation for RD analyses and the derivation of corrective measures (Brix et al., Reference Brix, Husung and Döring2024; Höhne et al., Reference Höhne, Brix and Sperlich2005).

Figure 1.

Function depending on the intended and unintended input variables and internal characteristics (Brix and Husung, Reference Brix and Husung2022; Brix et al., Reference Brix, Husung and Döring2024).

Figure 1. Long description

The diagram consists of a central rounded rectangular block representing the system state, with arrows entering from the left and exiting to the right.

At the center is the system block containing the blue variables Z sub i and Delta Z sub i.

To the left, two input arrows point into the block. The top arrow is labeled with orange variables E sub rel,i and Delta E sub rel,i. The bottom arrow is labeled with orange variables E sub n,i and Delta E sub n,i.

To the right, three output arrows point away from the block. The top arrow is labeled with red variables A sub rel,i and Delta A sub rel,i. The middle arrow is labeled with red variables (A sub n,i) sub u and (Delta A sub n,i) sub u. The bottom arrow is labeled with red variables (A sub n,i) sub h and (Delta A sub n,i) sub h.

The legend below defines the variables as follows.

* E sub rel,i is the ideal relevant input variable.

* Delta E sub rel,i is the disturbance in relevant input variables.

* E sub n,i and Delta E sub n,i are non-functional disturbance input variables.

* A sub rel,i is the relevant output variables.

* Delta A sub rel,i represents side effects.

* (A sub n,i) sub u and (Delta A sub n,i) sub u are unwanted side effects and their deviations.

* (A sub n,i) sub h and (Delta A sub n,i) sub h are harmless side effects and their deviations.

* Z sub i and Delta Z sub i are ideal system characteristics and their deviations.

With increasing digitalization, simulation-based and, in some cases, even AI-supported analysis and optimization approaches have emerged, particularly for geometric parameter analyses (Heling et al., Reference Heling, Schleich and Wartzack2018; Bode et al., Reference Bode, Goetz, Schleich and Wartzack2023; Steck and Husung, Reference Steck and Husung2024), among other things. Studies have shown that the requirements and boundary conditions in the context of RD vary greatly across different industrial sectors (Eifler et al., Reference Eifler, Campean, Husung and Schleich2023).

A key characteristic of RD methods is that they consist of three sequential steps: Analysis and evaluation of potential failures, as well as derivation of measures. For the analysis, among other things, methods based on empirical knowledge (e.g., checklists) (Welzbacher et al., Reference Welzbacher, Vorwerk-Handing and Kirchner2021) or cause-and-effect analyses [such as system analyses using FMEA (IEC, 2018), FTA, and their specific derivatives; empirical knowledge is also required here] are used. Measures can be taken in various development phases, whereby the early development phases (concept phase) are of particular importance due to the effectiveness of these measures (Andersson, Reference Andersson1997; Eifler et al., Reference Eifler, Mathias, Roland, Marion, Hermann, Birkhofer and Bohn2011). Deriving measures also requires empirical knowledge, for example, about known concepts. Recent advances have integrated RD principles with MBSE approaches. For instance, SysML modeling can be combined with system analyses (e.g., using FMEA) and integrated directly into the system model (Husung et al., Reference Husung, Weber, Mahboob and Kleiner2021; Lipšinić et al., Reference Lipšinić, Faheem, Husung and Pavković2025). For this purpose, the product properties relevant for the analyses are specifically added to the system model via profiles (Biggs et al., Reference Biggs, Juknevicius, Armonas and Post2018; Hecht et al., Reference Hecht, Chuidian, Tanaka and Raymond2020). These combinations enable direct analyses of the respective system model. However, empirical knowledge is still required.

The current state of the art indicates that, although numerous methods for combining RD with system models already exist, a major challenge remains: the availability and integration of empirical knowledge. RD methods rely heavily on knowledge from previous projects; however, systematic approaches to reuse and integrate this knowledge are still underdeveloped. Knowledge transfer between projects, particularly for complex systems, is limited, leaving a significant research gap in the use of empirical data for RD.

Knowledge management

Knowledge management is a systematic process of creating, sharing, storing, and managing knowledge to support stakeholders in accessing valid knowledge based on their particular needs (Beck et al., Reference Beck, Pahlke and Seebach2014). In technical product development, it is essential for decision-making and problem-solving throughout the technical development process. This section provides a state-of-the-art overview of knowledge management approaches in technical product development. Among the various approaches available, relational databases and knowledge graphs are highlighted as essential means for effectively storing and retrieving knowledge.

Knowledge utilization phase based on the SOI Model

This section provides a detailed explanation of the knowledge utilization phase of the proposed approach as illustrated in the right part of Figure 2 (cf., Section “Overall approach”). The primary objective is to analyze the defined SysML model of the SOI and extract information to formulate context-specific SPARQL queries. The SysML model of the SOI was specified based on the defined metamodel, as described in Section “Application example: Mobile robot system,” which explains how the model was defined and information was parsed. During the concept phase, engineers should create their SysML models based on this metamodel. This parsed information from SOI serves as a necessary input for formulating queries that facilitate the retrieval of robustness-related knowledge from the knowledge graph. The contents of SysML models vary depending on the project, product, modeling objective, and so forth. If the models are based on a specific metamodel, their underlying structure remains consistent. In this contribution, we use a limited set of parsing combinations, even though additional combinations are possible. Given the predictable structure of the information, a template-based approach is used for query generation. This contribution is based on a specific metamodel. If the metamodel is adapted, the specific parsing and the template may need to be adapted.

A discrete number of different combinations of parsed information from the SysML model are substituted individually into the template’s IRIs to formulate a different query at a time to retrieve relevant robustness-related knowledge from the knowledge graph. The SPARQL query template was developed based on the underlying structure and data distribution in the knowledge graph (see Fig. 5). The query template is composed of sections such as PREFIX declarations, SELECT DISTINCT, and WHERE clauses. PREFIXES declarations specify the shorthand notation of URIs. The SELECT clause defines the variables that store the retrieved query results, while the DISTINCT clause prevents duplicate results. The WHERE clause matches the results against the RDF datasets (i.e., RDF knowledge graph) to include in the query, based on the context-specific parsed SysML model information. This means that the WHERE clause is integrated with a discrete set of information at a time derived from the parsed SysML model to formulate the SPARQL query.

Figure 5.

Overview of the approach for identifying potential failures from the knowledge graph, based on the defined SysML model of SOI using the proposed SPARQL query template. The figure shows an excerpt of the knowledge graph for illustration. The numbered lines in the figure correspond to the steps described in the text, highlighting key parts of the SPARQL query execution.

Figure 5. Long description

The flowchart is organized into three vertical sections.

1. Top Section: S O I Sys M L Model. A block definition diagram shows a hierarchy starting from a Context block. Below it are blocks for Obstacle, Environment, Ground, and Mobile Robot. These connect to activity blocks like Detect Obstacle and Navigate, which are realized by hardware components including Sensor, C P U, and Actuation System. Blue arrows trace connections from these model elements down into the query template.

2. Middle Section: S P A R Q L Query Template. A text box contains code starting with a P R E F I X and a S E L E C T D I S T I N C T statement. The W H E R E clause lists eight numbered steps that define relationships between elements, parameters, functions, and contexts to identify failures. A downward arrow labeled S P A R Q L Query Execution on K G points to the bottom section.

3. Bottom Section: Knowledge Graph and Potential Failures. On the left, a circular network of nodes represents the Knowledge Graph. Nodes include Environment, Humidity, Navigate, Speed, and Interaction Context Context 3. These are linked by labeled edges such as element_participates_in and function_participates_in. On the right, the graph leads to a node labeled Failures List 3, which points to Path Planning Failure. A large upward arrow on the far right links these Potential Failures back to the Path Planning Problem at the top level.

The WHERE clause of the specified query template is defined to align with the structure of the defined RDF knowledge graph as described in the following section. Specifically, the WHERE clause verifies that the system element, the associated system element property, the relevant system element function, and the function property of the system element share a common interaction context within the knowledge graph. This interaction context preserves the common relation between the participating entities and supports the retrieval of associated potential failures, as further described in the next section of the knowledge enrichment phase. The name of this common interaction context is verified using a common relationship name entity (i.e., the parsed relationship between model elements, such as the system element, their associated function, and their relevant properties). This verification ensures that the participating model elements share the correct common relation within the knowledge graph.

Finally, the common interaction context entity, together with its associated name entity, leads to a distinct list entity, referred to as a common failure list (i.e., the unique intermediate entity that connects to subsequent known failure-related entities). Relevant failure-related entities are accessed through the common failure list and transferred into the SysML model. It is important to note that the RDF knowledge graph is structured based on a defined ontology (see Fig. 8), which specifies the semantic structure and relationships among entities. The ontology defines core classes such as Element, Function, Element_Parameter, Function_Parameter, InteractionContext, and Failures. These classes are interlinked through object properties such as has_function, has_element_parameter, has_function_parameter, element_participates_in, function_participates_in, and others. The ontology explicitly constrains these properties through domains and ranges (e.g., the relationship has_function has the domain Element and the range Function), thereby ensuring semantic consistency and preserving meaningful relationships among all entities in the graph. This verification process involves checking whether the parsed SysML elements correspond to entities in the knowledge graph, guaranteeing that queries return semantically relevant results. The queries formulated using the proposed query template enable context-specific knowledge retrieval.

To ensure clarity and simplicity, an example of context-specific parsing information from the SysML model of the robot is provided (i.e., one discrete set of parsed model information) that illustrates the formulation and execution of a SPARQL query to identify robustness-related knowledge from the knowledge graph (cf. Fig. 5). However, it is important to note that various SPARQL queries are formulated based on the different parsed information from the system model in a similar manner. For example, parsed information from the SOI model (i.e., Environmental Influence: Environment, Environmental Influence Parameter: Humidity, Function: Navigate, Function Parameter: Speed, and Relationship: hasFunctionalRelation) is integrated within the relevant IRIs of the query template (i.e., Element, Element_Parameter, Function, Function_Parameter, and contextRelationship).

This structured query formulation enables the context-specific retrieval of robustness-related knowledge from the knowledge graph, based on a discrete set of parsed information extracted from the SysML model.

The query starts its search within the knowledge graph by identifying that the entities “Environment,” “Humidity,” “Navigate,” and “Speed” share the common interaction context (i.e., Context3) through the contextual participation predicates (i.e., element_participates_in, function_participates_in, etc.) defined in the WHERE clause of the SPARQL query template (see lines 1–4 of the WHERE clause in the SPARQL query template). The query returns the output only when the condition is fully satisfied (e.g., all four entities share an exact common interaction context entity). Even if one entity does not share this common interaction context, the query produces no output. It is important to note that only a representative subset of the overall knowledge graph is presented in this contribution for illustrative purposes. However, in the graph, for example, “Environment” and other entities can have multiple common interaction contexts.

In addition, the query search that this common interaction context (i.e., Context3) is associated with the common relationship name entity, “hasFunctionalRelation.” Furthermore, the query verifies that the common interaction context, together with the corresponding common relationship name entity, is associated with a common list (i.e., List3 as illustrated in the knowledge graph) (see lines 5–7) that results in the retrieval of potential failures (see line 8). Finally, the identified failures (i.e., Path Planning Problem) are transferred to the SysML model, thereby addressing research question 3 by demonstrating how robustness-related knowledge can be retrieved in a context-specific manner based on the SOI system model. There are different ways to display the model in the SysML tool; in the prototypical implementation, standard output in the SysML tool was used.

Future work will focus on addressing inconsistencies between the naming conventions of SysML models and the knowledge graph.

Knowledge enrichment phase

This section presents a systematic approach for defining and structuring a knowledge graph (KG) that incorporates the RD knowledge from existing technical products, as illustrated on the left part of Figure 2 (cf. Section “Overall approach”). The KG comprises system elements, (partial) functions, robustness-related knowledge, and the relationships among them.

Various methods exist for creating knowledge graphs from structured, semi-structured, or unstructured data (Wu et al., Reference Wu, Qi, Li and Wang2018). Prior research (Sun et al., Reference Sun, Liu, Guo and Wang2016; Wang et al., Reference Wang, Ma, Chen and Chen2018; Dessì et al., Reference Dessì, Osborne, Reforgiato Recupero, Buscaldi and Motta2021) has examined the use of Natural Language Processing (NLP) and Machine Learning (ML) approaches to transform unstructured text into structured knowledge representations (i.e., knowledge graphs).

For instance, Liu et al. (Reference Liu, Yang, Li and Kolmanič2020) proposed a crawler-based framework that combines Deep Learning techniques with ontology extraction to build knowledge graphs from semi-structured and structured data sources. Similarly, Kumar et al. (Reference Kumar, Bharadwaj, Starly and Lynch2022) developed a knowledge graph from structured and unstructured data to support question-answering tasks.

While automated knowledge extraction methods offer valuable insights, the approach proposed in this contribution follows model-based knowledge representation to systematically create a semantically rich, scalable, and structured knowledge graph. Instead of relying on external data sources, this method extracts engineering-relevant knowledge directly from SysML models, supporting high accuracy based on the information described in a structured form in the model.

The creation of a knowledge graph incorporating RD knowledge from existing technical products is illustrated in Figures 6–10. This method follows a structured approach that begins with SysML models and results in a structured RDF-based knowledge graph.

Figure 6.

SysML model of the existing technical product based on a predefined metamodel (see Section “Application example: Mobile robot system”).

Figure 6. Long description

The diagram consists of four interconnected tan blocks.

At the top is a System Element block labeled Mobile Robot with a property of Speed.

A solid line with a diamond head connects the Mobile Robot down to a System Element block labeled Sensor, which has a property of Resolution.

A solid line with a circular cross symbol connects the Mobile Robot down to an activity block labeled Navigate, which has an attribute of Speed.

A dashed line labeled has Functional Relation connects the Navigate activity upward to the Sensor.

A dashed line labeled associated with connects the Navigate activity downward to a Failure block at the bottom labeled Inaccurate Obstacle Detection.

A second dashed line labeled associated with connects the Inaccurate Obstacle Detection failure block directly upward to the Sensor block.

Figure 7.

The relational database schema is derived from the predefined metamodel (cf. Section “Application example: Mobile robot system”). The metamodel elements are transformed into relational tables, which are interconnected through primary keys (PKs) and foreign keys (FKs). The 1–N notation represents one-to-many relationships (e.g., one element associated with multiple functions, among others).

Figure 7. Long description

The diagram consists of six tables organized into two columns.

On the left side, from top to bottom:

* Element table contains I D P K and Element_Name. It has a 1 to N relationship pointing to Function and Element_Parameter.

* Function table contains I D P K, Function_Name, and Element F K. It has a 1 to N relationship pointing to Function_Parameter and InteractionContext.

* InteractionContext table contains I D P K, Relationship_Name, Element F K, Element_Parameter F K, Function F K, and Function_Parameter F K.

On the right side, from top to bottom:

* Element_Parameter table contains I D P K, EParameter, and Element F K. It receives a 1 to N connection from Element and sends a 1 to N connection to InteractionContext.

* Function_Parameter table contains I D P K, FParameter, and Function F K. It receives a 1 to N connection from Function and sends a 1 to N connection to InteractionContext.

* Failures table contains I D P K, Leads_To, and InteractionContext F K. It receives a 1 to N connection from InteractionContext.

All connections use 1 to N notation, where the 1 is located at the source table and the N arrow points to the destination foreign key field.

Figure 8.

Excerpt of the ontology specification using RDF Schema, derived from the relational schema. The diagram illustrates the classes and their relationships, including domain, range, and type definitions. The full ontology is accessible via the GitHub link given in the Data Availability section.

Figure 9.

Relational database populated with the metadata from the SysML model of the existing technical product based on the designed relational schema.

Figure 9. Long description

The diagram consists of six tables connected by lines representing relational links.

Top Row:

- Element table: Columns for I D (Element1), Element_Name (Sensor), and Description (Subsystem).

- Element_Parameter table: Columns for I D (EParameter1), EParameter (Resolution), and Element (Element1).

Middle Row:

- Function table: Columns for I D (Function1), Function_Name (Navigate), and Element (Element1).

- Function_Parameter table: Columns for I D (FParameter1), FParameter (Speed), and Function (Function1).

Lower Middle:

- InteractionContext table: This central mapping table connects all previous entities. Columns include I D (Context1), Relationship_Name (isRealizedBy), Element (Element1), Element Parameter (EParameter1), Function (Function1), and Function_Parameter (FParameter1).

Bottom Row:

- Failures table: Columns for I D (List1), InteractionContext (Context1), and Leads_To (InaccurateObstacleDetection).

Lines connect the I D fields of the upper tables to the corresponding foreign key columns in the InteractionContext and Failures tables, illustrating the data flow from technical specifications to potential failure outcomes.

Figure 10.

Definition and structuring of RDF knowledge graph based on the specified relational database (cf. Fig. 9).

Figure 10. Long description

A directed graph with oval nodes and labeled arrows.

On the far left, the node Element forward slash Elemet1 serves as the primary anchor. It has four outgoing arrows.

1. ref underscore elementParameter points to Element underscore Parameter forward slash EParameter1 at the top left.

2. Element underscore Name points to Sensor.

3. ref underscore function points to Function forward slash Function1 at the bottom left.

4. ref underscore context is a long arc pointing to the central node InteractionContext forward slash Context1.

In the second column of nodes.

- Element underscore Parameter forward slash EParameter1 points to Resolution via EParameter and to InteractionContext forward slash Context1 via ref underscore context.

- Sensor points to Resolution via has underscore element underscore parameter and to Navigate via has underscore function.

- Function forward slash Function1 points to Navigate via Function underscore Name, to Function underscore Parameter forward slash FParameter1 via ref underscore functionParameter, and to InteractionContext forward slash Context1 via ref underscore context.

In the third column of nodes.

- Resolution points to InteractionContext forward slash Context1 via element underscore parameter underscore participates underscore in.

- Navigate points to InteractionContext forward slash Context1 via function underscore participates underscore in and to Speed via has underscore function underscore parameter.

- Function underscore Parameter forward slash FParameter1 points to Speed via FParameter and to InteractionContext forward slash Context1 via ref underscore context.

In the fourth column of nodes.

- Speed points to InteractionContext forward slash Context1 via function underscore parameter underscore participates underscore in.

- InteractionContext forward slash Context1 is the central hub. It points upward to Context via r d f colon type, downward to isRealizedBy via has underscore context underscore relationship, and rightward to Failures forward slash List1 via could underscore lead underscore to.

On the far right.

- Failures forward slash List1 points to InaccurateObstacleDetection via has underscore failure. It is also linked to isRealizedBy via associated underscore with. Two additional arrows point to nodes containing only dots, representing further list items.

The SysML model of existing technical products is created based on a specific metamodel (cf. Section “Application example: Mobile robot system”). It is important to note that the specified SysML model is further enhanced for the enrichment of the knowledge graph by incorporating associated robustness-related knowledge based on the predefined metamodel. This enhanced SysML model serves as the foundation for creating a relational database schema. The process of creating a relational database schema involves translating the meta-classes and meta-relationships of a defined SysML model into relational schema tables. The relationships between these schema tables are established by defining the primary and foreign keys so that the data are linked and organized in a structured manner. The schema serves as a base to define the ontology of the knowledge graph using RDF schema (cf. Section “Ontology specification using RDF schema (RDFS)”) by considering the schema’s tables and their interrelationships. By considering the tables and their interrelationships, the ontology provides a semantic structure that enables meaningful querying and reasoning over the knowledge graph (cf. Section “Knowledge utilization phase based on the SOI model”).

In addition, the relational schema supports the creation of a relational database by populating data from the specified SysML model in database tables. This relational database acts as an intermediate structured data representation, facilitating the systematic transformation of engineering knowledge into a knowledge graph. The final step involves mapping relational data into an RDF knowledge graph, where:

• • Table names are mapped to RDF classes (representing concepts in the knowledge graph)

• • Table rows are converted into RDF entities/nodes (instances of the respective classes)

• • Foreign key relationships are transformed into RDF edges, establishing semantic links between related entities.

This structure allows the knowledge graph and its ontology to enable context-specific retrieval and reasoning about robustness-related knowledge, thereby addressing research questions 1 and 2 (cf. Section “Research questions”). To enhance clarity and reader comprehension, a small portion of the SysML model of the existing technical product (cf. Figure 6) is used as an example. This model, based on a specific metamodel, demonstrates the systematic process of creating and structuring the knowledge graph.

The SysML model incorporates additional robustness-related knowledge, such as disturbing influencing factors and known failures, as additional model elements. These elements must adhere to the specific metamodel.

The selected SysML model focuses on a decomposed subsystem of a robot. It is important to note that the excerpt from the model shown here represents a different robot than the one in Section “Application example: Mobile robot system.” For the purposes of this contribution, the model, including the failures, was created based on fictitious data. In reality, this could be a previous robot generation or another existing robot. The model includes:

• • A system element (e.g., “Sensor”)

• • A partial function (e.g., “Navigate”)

• • Relevant properties (e.g., “Speed” and “Resolution”)

• • Defined relationships (e.g., “isRealizedBy”)

• • An associated failure (e.g., “InaccurateObstacleDetection”)

The model shows that the “Navigate” function with the property “Speed” (e.g., with the characteristic high speed) can influence the sensor with the property “Resolution,” since if the “Speed” is too high, the “Resolution” is insufficient to accurately detect obstacles. This can lead to failures (e.g., inaccurate detection of obstacles). It is important to note that only one failure is shown in Figure 6; however, failures related to this particular discrete combination are represented in the knowledge graph. Among the various sets of repetitive combinations (with varied content information) based on the specific metamodel, this model provides a discrete combination that serves as a base for designing a relational database schema.

In the next step, the specific metamodel elements of the SysML model (i.e., Element, Element Parameter, Function, Function Parameter, Relationship, and Failure Mode) are transformed into a relational database schema (cf. Fig. 7). The relationships between metamodel elements, such as the link between Element and Function, are captured via foreign keys, which reference the primary key in the corresponding schema tables, among others. This one-to-many (1 – N) relationship indicates that each element can be associated with multiple functions. The design of the relational schema facilitates the specific metamodel of the SysML model (cf. Fig. 6) into a structured format suitable for creating a relational database. This transformation supports the systematic integration of robustness-related knowledge in a structured database.

Following this, Figure 8 illustrates the definition of the knowledge graph ontology, represented using the RDF schema (cf. Section “Ontology specification using RDF schema (RDFS)”).

The relational schema structure is transformed into RDF classes and properties, enabling semantic reasoning and advanced querying:

• • Table names, such as Element, Element_Parameter, Function, and others, are mapped to RDF classes using rdf:type to classify them as rdfs:Class.

• • Properties, such as has_function, has_element_parameter, element_participates_in, and so forth, which define relationships between classes, are mapped to RDF properties using rdf:type to assign them as rdf:property.

For instance, the relationship between Function and Function_Parameter classes is specified via the property has_function_parameter using rdfs:domain and rdfs:range to enforce that:

• • The subject (i.e., any instance using has_function_parameter) must be an instance of Function.

• • The object (i.e., the value assigned via has_function_parameter) must be an instance of Function_Parameter.

The relational database shown in Figure 9 is built based on the designed relational schema and populated with one record based on the discrete combination derived from a specific metamodel of the defined SysML model (cf. Fig. 6). For example, the following entities from the SysML model are integrated into the corresponding database tables:

• • System element: “Sensor”

• • Function: “Navigate”

• • Properties: “Resolution” and “Speed”

• • Relationship: “isRealizedBy”

• • Failure: “InaccurateObstacleDetection”

The data entries in the relational tables are linked using primary and foreign keys, ensuring structured storage and supporting transformation from a semi-structured SysML model into a fully structured format. This structured database serves as a basis for constructing and enriching the knowledge graph, thereby ensuring scalable and robust knowledge representation.

The final step involves transforming the relational database into an RDF knowledge graph (Fig. 10). This process ensures that the structured engineering knowledge is machine-interpretable and queryable within a semantic framework. To create the RDF knowledge graph, the primary keys of the connected relational database tables are mapped to graph nodes, while customized foreign key relationships between the corresponding relational database entities establish associations between the transformed entities. Additionally, data values from the relational tables, such as entity names, are transformed into graph nodes, where semantic relationships among these entities are explicitly defined via object properties specified in the ontology (cf. Fig. 8). This supports the semantic representation of parsed SysML model information during the knowledge enrichment phase, as well as context-specific retrieval and semantic querying within the RDF knowledge graph during the knowledge utilization phase (cf. Section “Knowledge utilization phase based on the SOI Model”). Furthermore, intermediate contextual entities, such as InteractionContext, derived from the transformed primary keys of the relational database tables, are represented within the RDF knowledge graph to semantically connect the transformed entity names and their associated contextual information. This intermediate InteractionContext node ensures that discrete participating entity names and their associated relationship are grouped distinctly within the RDF knowledge graph. This facilitates distinguishing different participating entity names sharing similar relationship during SPARQL query traversal and supports retrieving the corresponding failure-related knowledge.

For instance, primary keys from tables such as Element and Element_Parameter (e.g., Element/Element1 and Element_Parameter/EParameter1) are transformed into graph nodes and connected through customized relationships, such as ref_elementParameter. Similarly, entity names such as Sensor and Resolution are transformed into graph nodes and semantically connected through ontology-defined object properties such as has_element_parameter. Furthermore, intermediate contextual entities, such as InteractionContext, are represented within the RDF knowledge graph to preserve contextual associations. Sensor and Resolution, among others, are connected to InteractionContext/Context1 through the ontology-defined predicates such as element_participates_in and element_parmaeter_participates_in among others. The transformed entities, such as primary keys, entity names, associated interaction contexts, and semantic relationships, ultimately converge into a centralized failure list, labeled Failures/List1, which stores failures, interference, and other factors.