FMEA integration within systems engineering: A review of methods and challenges

FMEA, one of the most widely recognized methods for reliability and safety, is a proactive tool developed to identify, evaluate, and prevent potential failures in products and processes. It aims to improve product and system design outcomes by enhancing reliability, reducing environmental impact, and achieving cost savings (Wu et al., Reference Wu, Liu and Nie2021). FMEA has been widely adopted across industries like aerospace, nuclear, and automotive, following established methodologies (e.g., SAE-J1739, 2009]), with its versatile framework applicable to hardware, software, processes, human actions, and their interactions (IEC-60812, 2018), ultimately evolving into specialized variants, such as design, process, and system FMEA, to address specific process and system aspects (AIAG and VDA, 2019). Historically, FMEA has been approached from two perspectives:

1. i. Bottom-up approach: This approach, rooted in military standards like IEC-60812 (2018), starts at the component level, identifying failure modes and propagating their effects up the system hierarchy. This reactive approach can lead to significant design changes and increased costs.

2. ii. Top-down approach: The AIAG and VDA (2019) approach aligns FMEA with product development, adopting a top-down approach. It focuses on identifying potential failure modes at the system level, cascading them down to component levels, and defining countermeasures to mitigate critical risks.

On the other hand, integrating FMEA effectively within the systems engineering process is essential to ensure coherence between design decisions and risk identification, enhancing the reliability and robustness of complex systems, thereby minimizing late-stage errors and reducing overall system development time (Baklouti et al., Reference Baklouti, Nguyen, Mhenni, Choley and Mlika2019). Campean et al. (Reference Campean, Henshall and Rutter2013) explored the integration of FMEA into system engineering processes and, subsequently, Campean et al. (Reference Campean, Henshall and Rutter2014) proposed an integrated framework for aligning FMEA processes with systems engineering models for complex multidisciplinary systems. Their framework leverages a function-driven methodology, providing a coherent flow of information based on the analysis and cascading of functional requirements, failure modes, and design verification activities.

Several earlier efforts have similarly aimed to enhance the FMEA process through integration with system modelling frameworks. Research by Huang et al. (Reference Huang, Hansen and Huang2018, Reference Huang, Swalgen, Davidz and Murray2017) focused on representing FMEA within MBSE models but faced challenges regarding automation capabilities. Hecht et al. (Reference Hecht, Dimpfl and Pinchak2014) and Girard et al. (Reference Girard, Baeriswyl, Hendriks, Scherwey, Müller, Hönig and Lunde2020) presented MBSE-based FMEA generation approaches. However, their scope was often limited in terms of semantic depth and extensibility, as they do not incorporate a formal ontology or support integration with external knowledge repositories for reuse and reasoning. Ontology-based approaches, such as those presented by Day et al. (Reference Day, Donahue, Ingham, Kadesch, Kennedy and Post2012), sought to formally structure risk information but encountered scalability and deployment challenges. These limitations align with broader findings by Campean et al. (Reference Campean, Henshall and Rutter2013, Campean et al. Reference Campean, Henshall and Rutter2014), who noted the ineffective deployment of FMEA within systems engineering contexts across various Original Equipment Manufacturers (OEMs).

In addition, various research efforts have proposed different strategies to support the integration of risk identification and assessment within system design activities.

Table 1 provides a comparative overview of five distinct methodologies, each demonstrating diverse approaches for embedding risk assessment or functional failure reasoning at early stages of the design process.

Table 1.

Comparative review of methods integrating risk analysis within the design process

Sierla et al. (Reference Sierla, Tumer, Papakonstantinou, Koskinen and Jensen2012) introduced the Functional Failure Identification and Propagation framework, facilitating early hazard identification using minimal design information, although subsequent quantitative analysis using traditional methods such as fault tree analysis (FTA) or probabilistic risk assessment (PRA) remains necessary. Mansoor et al. (Reference Mansoor, Diao and Smidts2023) proposed a backward failure propagation methodology to strengthen conceptual design robustness by tracing causes of failure. However, its reliance on abstract models may limit fidelity without detailed system representations. Russomanno et al. (Reference Russomanno, Bonnell and Bowles1993) embedded functional FMEA reasoning within an expert system (An Expert System for Failure Mode and Effects Analysis (XFMEA)), providing a structured simulation of system failure modes, albeit with ongoing challenges in knowledge formalization and intelligent system extension. Tumer and Stone (Reference Tumer and Stone2003) presented a matrix-based method linking component functionality to failure modes, offering analytical support for design improvements but limited by its focus on functional relationships alone. Finally, Stone et al. (Reference Stone, Tumer and Van Wie2005) developed the Function–Failure Design Method, enabling FMEA-style analysis during conceptual design stages, although additional operational and maintenance aspects may require separate treatment.

These comparisons highlight that although significant progress has been made in integrating risk assessment analysis into system design, critical challenges persist. In particular, the complexity of modern automotive systems, the integration of diverse data sources, and multidisciplinary coordination continue to pose major hurdles that must be addressed to fully realize reliable, efficient system development.

The primary technical challenges in complex automotive systems include:

• • High system complexity: Dealing with a large number of interconnected components and subsystems (Haytham et al., Reference Haytham, Doikin, Campean, Kabir, Abdullatif, Delaux and Bonnaud2024).

• • Data integration challenges: Integrating data from various sources (e.g., Computer-Aided Design (CAD), simulation, and testing) into the FMEA process (Filz et al., Reference Filz, Langner, Herrmann and Thiede2021).

• • Multidisciplinary integration: Coordinating efforts across different engineering disciplines (e.g., mechanical, electrical, and software) (Jiménez López et al., Reference Jiménez López, Cuenca Jiménez, Luna Sandoval, Ochoa Estrella, Maciel Monteón, Muñoz and Limón Leyva2022).

• • Managing interfaces: Effectively managing the interfaces between different subsystems and components (Campean et al., Reference Campean, Henshall and Rutter2014).

Overcoming these challenges requires a multipronged approach, including the development of more robust MBSE frameworks, leveraging Artificial Intelligence / Machine Learning (AI/ML) for automation and knowledge discovery, and improving knowledge sharing and collaboration among engineering teams.

Function modeling and its integration with FMEA

The cascade of functional requirements, from customer to shop floor, underpins systems engineering design by ensuring robust and reliable delivery of customer needs. However, within complex systems-of-systems, integrating FMEA into this functional cascade remains a significant challenge (Campean et al., Reference Campean, Henshall and Rutter2013).

Function reasoning (FR) provides a structured approach to analyzing and representing complex systems. Hamraz et al. (Reference Hamraz, Caldwell, Ridgman and Clarkson2015) highlighted that various groups have developed FR schemes, typically structured around three domains: function, behavior, and structure (or state). These schemes offer systematic approaches for representing and analyzing system complexity. Extending the verb–noun approach, Tomiyama et al. (Reference Tomiyama, Van Beek, Cabrera, Komoto and D’Amelio2013) introduce the transformation method, which emphasizes functional transformation processes, while Borgo et al. (Reference Borgo, Carrara, Garbacz and Vermaas2009) developed the physical behavior approach, integrating function–behavior–state relationships. Similarly, the FBS approach was introduced by Gero (Reference Gero1990), Gero and Kannengiesser (Reference Gero and Kannengiesser2007b), and Qian and Gero (Reference Qian and Gero1996). The FBS framework provides a comprehensive understanding of the interplay between functions and behaviors, essential for systematic design processes. Central to the FBS ontology is the clear delineation of key concepts: a “system” as an entity interacting with its environment with defined boundaries (Avizienis et al., Reference Avizienis, Laprie, Randell and Landwehr2004); “function” as the intended purpose or fundamental role of the system (Gero and Kannengiesser, Reference Gero and Kannengiesser2007a); “behavior” as the actions performed to fulfil the system’s function; and “structure” as the components and their configuration that enable the system’s behavior. Gero’s FBS ontology outlines an eight-step design process that begins with translating design requirements into functions, transforming these into expected behaviors, synthesizing solution structures, and iteratively refining the structure, behavior, and functions based on evaluations. This structured methodology ensures that the designed structure effectively implements the desired functions, addressing potential gaps between expected and actual behaviors.

The systematic guidance provided by the FBS framework ensures alignment between functions, behaviors, and structures, facilitating continuous refinement that enhances system performance and reliability. This alignment is particularly relevant when integrating reliability analysis techniques, such as FMEA, into a system model represented as an FBS ontology. Furthermore, FMEA evolves to incorporate more sophisticated knowledge representation methodologies to handle system complexity; the FBS framework benefits from ontological enhancements to address real-world performance challenges. Frameworks such as FBS and the five-key-terms approach (Vermaas, Reference Vermaas2013) exhibit limitations, particularly in explicitly addressing the system’s actual behavior based on its real-world performance. This gap highlights the necessity of integrating ontological approaches to enrich the FBS framework, thereby complementing methodologies like FMEA that also seek to enhance reliability through structured knowledge representation.

Recent research efforts have explored the integration of the FBS framework into ontological models, each adopting distinct strategies to formalize, structure, and enhance design knowledge representation. Cebrian-Tarrason et al. (Reference Cebrian-Tarrason, Lopez-Montero and Vidal2008) introduced OntoFaBeS, an ontology built upon the Behaviour-driven Function-Environment-Structure framework and the Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) upper ontology, aiming to formalize product knowledge and infer structures directly from user-defined functional requirements. This work addresses the lack of unified criteria in existing FBS-based methodologies, although it notes that many current engineering ontologies remain predominantly taxonomic. Wang and Wang (Reference Wang and Wang2014) developed a product design ontology system by linking geometry application programming interfaces and surface behaviors to FBS elements, thereby strengthening the semantic connection among functions, behaviors, and structures. While this approach improves knowledge sharing and quantization, it faces challenges regarding instance creation, artificial support for function mapping, and the absence of unified standards for functional vocabulary and behavioral classification. Meanwhile, Galle (Reference Galle2009) critically reexamined the conceptual foundations of the FBS model itself, proposing two revised ontological models, the nominalist and the realist versions, focused on improving logical coherence and temporal clarity. Although the work by Galle (Reference Galle2009) does not target immediate practical application, it provides a more reliable conceptual infrastructure for future research and tool development in design theory. Together, these contributions demonstrate the diverse directions taken to advance FBS-based knowledge modeling, each addressing different aspects of conceptual rigor, semantic interoperability, and systematization challenges.

Beyond FBS-based frameworks, recent work has focused more specifically on integrating ontological approaches with function-based perspectives of failure and reliability analysis. Safont-Andreu et al. (Reference Safont-Andreu, Burmer and Schekotihin2021) proposed a logic-based ontology for the FA domain, aiming to standardize terminology across engineers and software systems to enhance documentation clarity, information retrieval, and workflow verification. This ontology addresses the knowledge-intensiveness and ambiguity challenges inherent in fault analysis by offering a structured semantic framework, with further extensions envisioned for predictive task recommendation, causal relation mining, and ontology alignment with FMEA systems. Meanwhile, Kitamura et al. (Reference Kitamura, Takafuji and Mizoguchi2007) developed a middle-level reference ontology for functional knowledge interoperability, based on a generalized input–output model. His work categorizes functions to enable the mapping between different functional models and to facilitate the automatic generation and transformation of FMEA documents. Although both approaches show significant potential in advancing function-oriented reliability analysis, practical implementation challenges remain. The Safont-Andreu et al. (Reference Safont-Andreu, Burmer and Schekotihin2021) approach requires further development to realize predictive capabilities and ontology alignment, while the Kitamura et al. (Reference Kitamura, Takafuji and Mizoguchi2007) model, although conceptually robust, demands careful mapping and categorization to ensure accurate integration across diverse engineering domains. Collectively, these contributions demonstrate the critical role of ontologies in bridging functional modeling and FA to support more consistent, interoperable, and automated system design practices.

Formal ontological approaches to function and failure

Several methodological frameworks have been proposed within the ontology engineering community. Prominent among these are NeOn (Suárez et al., Reference Suárez-Figueroa, Gómez-Pérez and Fernández-López2011), Methontology (Poveda-Villalón et al., Reference Poveda-Villalón, Fernández-Izquierdo, Fernández-López and García-Castro2022), and DILIGENT (Pinto et al., Reference Pinto, Staab and Tempich2004), each providing tools for ontology development and reuse. The NeOn methodology, in particular, offers guidance for nine distinct development scenarios, including ontology merging, reengineering, and alignment with external vocabularies, each of which is relevant for engineering domains involving both design and risk artefacts. Ontologies significantly enhance engineering and design by providing structured knowledge representations that improve machine comprehension and support complex system design (Ebrahimipour et al., Reference Ebrahimipour, Rezaie and Shokravi2010; Mikos et al., Reference Mikos, Ferreira, Botura and Freitas2011; Rehman and Kifor, Reference Rehman and Kifor2016; Hodkiewicz et al., Reference Hodkiewicz, Klüwer, Woods, Smoker and Low2021). In computer science, ontologies serve as formal specifications that define a common understanding of a domain, encompassing concepts, relationships, and attributes (Kumar, Reference Kumar2008; da Silva and Pereira, Reference da Silva and Pereira2014). Unlike simple taxonomic hierarchies, ontologies offer rich definitions and elucidate intricate inter-concept relationships, enabling more profound and nuanced knowledge representation (Kumar, Reference Kumar2008). Tools like Protégé (Musen, Reference Musen2015) have revolutionized ontology development by making it accessible and integral to advancements in engineering design. Protégé supports various ontology formats, including the Web Ontology Language (OWL), facilitating interoperability and integration with diverse systems. In engineering contexts, ontologies enable the formalization of design knowledge, supporting tasks such as function modeling, requirement analysis, and system synthesis (Dermeval et al., Reference Dermeval, Vilela, Bittencourt, Castro, Isotani, Brito and Silva2016). This formalization is particularly beneficial for enhancing FMEA processes, as ontological representations can improve the consistency, reusability, and integration of failure mode data within broader design and reliability frameworks.

In parallel, several top-level ontologies offer differing interpretations of “function” and its relation to behavior and failure, contributing valuable insights for structured engineering representations. DOLCE does not formally define function within its core ontology, but it has been extended in related work to represent functions as types of “perdurants,” while roles are treated as anti-rigid concepts classified over endurants and perdurants (Borgo et al., Reference Borgo, Ferrario, Gangemi, Guarino, Masolo, Porello, Sanfilippo and Vieu2022). It is therefore important to clarify these ontological categories. Endurants are entities that are wholly present at any given point in time, such as a person, a component, or a vehicle, whereas perdurants, in contrast, are entities that unfold over time and are only partially present at any moment, such as a manufacturing process, a failure event, or a design meeting. The distinction reflects the philosophical differentiation between static entities and dynamic processes, which is fundamental in modeling behaviors and functions within engineered systems (Borgo et al., Reference Borgo, Ferrario, Gangemi, Guarino, Masolo, Porello, Sanfilippo and Vieu2022). Meanwhile, Basic Formal Ontology (BFO) (Otte et al., Reference Otte, Beverley and Ruttenberg2022) functions are defined as a subclass of dispositions, realizable entities inherent in material objects such as organs or components, which manifest through specific processes like pumping or vision (Spear et al., Reference Spear, Ceusters and Smith2016). In the General Formal Ontology (Herre, Reference Herre, Poli, Healy and Kameas2010), functions are treated as attributives, defined as roles played by entities in the context of achieving a goal. This interpretation frames functions within a teleological structure based on the role–goal relationship (Loebe et al., Reference Loebe, Burek and Herre2022). More recently, in the MALFunction Ontology (MALFO) (Compagno and Borgo, Reference Compagno and Borgo2024) designed to address the need to structure maintenance-related knowledge, functions are modeled as DOLCE-aligned concepts classifying certain classes of perdurants, enabling them to exist independently of execution. The ontology distinguishes between systemic and ontological functions based on the abstraction level and further separates engineering methods from proper functions to clarify functional ambiguity. While these ontologies do not always directly formalize failure or dynamic system behaviors, their treatment of functional roles and realizable processes provides foundational scaffolding for modeling causality, state change, and failure propagation within engineered systems.

Integrating the FBS ontology with ontological approaches provides a robust framework for engineering and design knowledge representation, enhancing systematic function modeling, supporting comprehensive design processes, and addressing critical limitations related to actual behavior. Ontologies offer the necessary structure to formalize the FBS concept’s function, behavior, and structure, enabling sophisticated KM and automated reasoning. By leveraging ontologies, the FBS framework achieves greater precision and adaptability, providing clear guidelines for describing the actual behavior and aligning design processes with broader system goals. Furthermore, ontological approaches mitigate conceptual bypassing by ensuring that all relevant conceptual layers are adequately addressed, thereby enriching function-based reasoning during the design process (Eisenbart and Gericke, Reference Eisenbart, Gericke, Michelfelder and Doorn2020). This synergy fosters a more comprehensive and flexible design methodology, supporting iterative refinements and ensuring that systems meet both functional requirements and real-world performance expectations. Additionally, such an integrated approach is essential for advancing FMEA methodologies, where detailed and structured knowledge representation is crucial for identifying and mitigating potential failure modes effectively. This integration not only advances the FBS methodology itself but also complements and enhances reliability analysis techniques, such as FMEA, highlighting the interconnectedness of structured knowledge representation in modern engineering practices.

The Knowledge Representation and Semantic Web communities have collaborated to standardize widely used knowledge representation languages, such as Resource Description Framework(RDF) and OWL (Pan et al., Reference Pan, Razniewski, Kalo, Singhania, Chen, Dietze, Jabeen, Omeliyanenko, Zhang and Lissandrini2023). In this context, researchers argue that augmenting Large Language Models (LLMs) with ontologies offers several advantages (Yang et al., Reference Yang, Chen, Li, Ding and Wu2023) such as Knowledge Representation and Reasoning, High-Precision Methods, Long-tail Knowledge, and Explainability and Interpretability (Pan et al., Reference Pan, Razniewski, Kalo, Singhania, Chen, Dietze, Jabeen, Omeliyanenko, Zhang and Lissandrini2023). Nevertheless, the development of Ontologies and Knowledge Graphs (KGs) heavily relies on human domain experts to define entities and relationships, establish hierarchies, and maintain domain relevance (Kommineni et al., Reference Kommineni, König-Ries and Samuel2024). A KG is a graph-based data model designed to accumulate and convey real-world knowledge. Its nodes represent entities of interest, while edges represent relationships between these entities. KGs are employed in applications requiring the integration, management, and extraction of value from diverse, large-scale data sources (Hogan et al., Reference Hogan, Blomqvist, Cochez, D’amato, Melo, Gutierrez, Kirrane, Gayo, Navigli, Neumaier, Ngomo, Polleres, Rashid, Rula, Schmelzeisen, Sequeda, Staab and Zimmermann2021).

Building upon these findings, it is evident that while integrating FMEA with MBSE shows significant promise, substantial challenges remain in effectively capturing and utilizing complex system behaviors within FMEA processes. The integration between risk analysis, represented by FMEA, and system design is crucial for ensuring robust product development and system reliability. However, the lack of a structured data representation continues to hinder efficient data sharing, reuse, and interoperability between different system models and analysis frameworks. To address these gaps, this research proposes the development of a novel framework that integrates FMEA within system models through ontological representations. The objective is to enhance the capture and utilization of system elements and behaviors within risk assessments, thereby enabling a more efficient and effective FMEA process, improving overall system reliability, and strengthening decision-making capabilities throughout complex systems engineering projects.

Methodology overview

The review of the literature showed that significant challenges persist in the integration of FMEA with MBSE and ontological frameworks. Existing FMEA-MBSE integration efforts lack robust automation and scalability, limiting their practical deployment in complex systems. While frameworks such as the FBS ontology offer structured design approaches, they often fail to explicitly represent real-world system behavior, leading to a disconnect between theoretical modeling and actual system operation. Moreover, data integration challenges and multidisciplinary inconsistencies further complicate the application of FMEA in engineering design. Ontology-based methods, despite offering structured knowledge representation, face scalability issues and are heavily reliant on human expertise for their development and maintenance.

In light of these gaps, this research is driven by the following central question:

The work aims to develop a structured, scalable, and integrative framework that bridges the gap between system design models and risk analysis through ontological knowledge representations.

The ontological framework put forward in this work is theoretically grounded in the FBS ontology, which is a well-established conceptual model for representing design knowledge. The proposed framework, henceforth referred to as FBSFM, extends the FBS model to include consideration of failure modes associated with the system functions and behavior. While leveraging the strengths of FBS in capturing the intended functional requirements, expected behaviors, and physical structure of a system, the FBSFM framework explicitly addresses the limitation of conventional FBS models, related to the inadequate capture and representation of the actual behavior of the system, particularly under faulty or failed conditions. Standard FBS primarily focuses on the intended behavior derived from function, often neglecting the actual behavior that manifests during operation, including deviations and failures.

The FBSFM framework extends the FBS model by incorporating a dedicated FMEA ontology layer and establishing explicit semantic links between the intended design representation (FBS layer) and the potential failure characteristics (FMEA layer). This integration introduces the concept of “actual behavior” as a bridge between intended function and observed failure modes. By formally mapping functions to both intended and actual (potentially faulty or failed) behaviors, and subsequently linking these behaviors to specific failure modes, causes, and effects, the FBSFM framework provides a more comprehensive theoretical model. Thus, FBSFM moves beyond representing just the “as-designed” system to encompass the “as-is” or “as-failed” system behavior, thereby offering a richer, more realistic foundation for integrating design synthesis with reliability analysis and risk assessment within a single, coherent ontological structure.

The key objectives of the proposed ontological framework, along with anticipated quantifiable contributions, are as follows:

1. 1. To create a unified knowledge repository: This repository will integrate design data (functions, behaviors, and structures) and risk data (failure modes, causes, and effects) for systems.

2. 2. To facilitate automated knowledge retrieval and reuse: The framework aims to reduce the time required for engineers to retrieve relevant design and risk information.

3. 3. To support early-stage FA by explicitly linking intended functions to potential failure modes via behavior representations.

4. 4. To improve decision-making: The framework will enable semantic analysis and automated reasoning, potentially leading reduction in design changes related to previously unidentified risks and improving the effectiveness of risk mitigation strategies through more informed decision support.

The overall methodology for developing the integrated FBSFM Ontological Framework is supported by the conceptual structure illustrated in Figure 1. This figure presents the key components and their interactions, starting with the independent development of the FBS ontology (representing system design knowledge) and the FMEA ontology (capturing failure knowledge) from the design phase domain. These ontologies are then semantically integrated into a unified FBSFM ontology, which consolidates system functions, behaviors, structures, and failure data within a coherent formal representation. The resulting FBSFM ontology is subsequently deployed into a system repository to enable structured querying, reasoning, and validation. The implementation of this framework involves three main tasks: constructing the individual ontologies, establishing semantic mappings to integrate them, and deploying the combined ontology into a knowledge repository that supports enhanced traceability, knowledge reuse, and decision support.

Figure 1.

Methodology roadmap for developing and implementing the integrated FBSFM ontological framework.

The development of the FBSFM ontology followed established ontology engineering practices, specifically drawing on the NeOn methodology (Suárez et al., Reference Suárez-Figueroa, Gómez-Pérez and Fernández-López2011). NeOn defines nine distinct scenarios for building ontologies and ontology networks, accommodating diverse development contexts such as creating new ontologies from scratch, reusing existing ontological or non-ontological resources, and merging or restructuring them. The construction of FBSFM applied a combination of Scenario 4 (reusing and reengineering ontological resources) and Scenario 5 (reusing and merging ontological resources). Scenario 4 was applied to extend the existing FBS ontology by reengineering its behavioral layer to include the concept of actual behavior represented as function failure modes. Scenario 5 was employed to merge the reengineered FBS ontology with a domain-specific FMEA ontology, forming an integrated framework that semantically aligns system design concepts with FA artifacts. Additionally, elements of Scenario 2 (reusing and reengineering non-ontological resources) were involved, particularly in the transformation of FMEA tables and functional requirement documents into structured ontology instances. These scenarios collectively enabled the systematic integration of both structured and semi-structured engineering knowledge into a coherent, formal ontology, ensuring consistency, extensibility, and reuse.

The roadmap emphasizes the structured flow of knowledge from distinct sources into a consolidated framework, culminating in an implemented system ready for advanced KM, cross-domain analysis, and decision support.

Ontological framework development

Figure 2 shows an FMEA extract from the AIAG and VDA (2019) standard, which illustrates a case for a window lifter system. It presents only a single row from the example to demonstrate the Design FMEA steps, beginning with step 2: structural analysis. However, it does not include the initial step of the FMEA process, “planning and preparation,” which encompasses critical information regarding the organization, product/system, and the FMEA team.

Figure 2.

Example of a design FMEA table for a window lifter system (AIAG-VDA, 2019).

The AIAG/VDA FMEA procedure establishes a linkage between system models through structure analysis, function analysis, and failure mode analysis as part of risk assessment. In structural analysis, the system is decomposed into three levels: (1) next higher level, (2) focus element, and (3) next lower level. Each level undergoes its corresponding function decomposition in step 3, that is, function analysis.

However, functional analysis remains a recognized weakness in current systems engineering practices, as it often relies heavily on brainstorming techniques (Campean and Henshall, Reference Campean and Henshall2012). Once functional requirements are identified, functional failure mode analysis follows to address potential design risks. Additionally, nonfunctional requirements (NFRs) represent the intended behaviors that support the fulfilment of these functional requirements (Eckhardt et al., Reference Eckhardt, Vogelsang and Fernández2016).

Despite the AIAG/VDA framework’s strengths, its integration of behavior analysis with functional and risk analyses is limited. Although it incorporates P-diagrams to characterize system output behaviors (Su et al., Reference Su, Lin, Teng and Yang2014), a comprehensive behavioral modeling approach linking design intent to observed failure remains absent. Within this framework, failure modes are defined as deviations in system behaviors from intended outputs, while error states categorize these failure modes as unintended behaviors (Goktas et al., Reference Goktas, Hu and Yellamati2024).

FA, the fourth step in conducting FMEA, investigates failure modes, their effects, and causes in relation to their corresponding functional and behavioral elements. Thus, the FMEA analytical sequence progresses logically from system structure to functional requirements, to NFRs (intended behaviors), and finally to failure modes (unintended behaviors), as summarized in Table 2.

Table 2.

Mapping sequence analysis of system structure, functional requirements, nonfunctional requirements, and failure modes

The FBSFM Ontology is developed by extending the foundational FBS ontology introduced by Gero (Reference Gero1990) and Gero and Kannengiesser (Reference Gero and Kannengiesser2007a, Reference Gero and Kannengiesser2007b), which describes the relationships among system entities during the design phase. In the standard FBS ontology, system behavior is categorized into two types: expected behavior (Be), which represents the intended functionality derived from requirements, and structural behavior (Bs), which describes how the implemented design performs. The design process ideally concludes when structural behavior closely matches expected behavior. However, in current industry practice, as discussed by Campean et al. (Reference Campean, Henshall and Rutter2013), Campean et al., Reference Campean, Henshall and Rutter2014), early consideration of design risks is mandated to identify potential behaviors and integration requirements that need to be considered within the conceptual design iteration, to avoid costly downstream engineering change iterations, associated with the post-design risk evaluations. Thus, the FBS extension to explicitly include consideration of failure modes, that is, FBSFM, is coherent with the current design practice.

The proposed FBSFM Ontological Framework comprehensively unifies system design knowledge and risk analysis within a single ontological structure. Unlike the methodologies discussed earlier, which either treat design and risk assessment as separate activities or do not explicitly provide adequate representation of knowledge from both domains, the proposed framework creates formal semantic bridges between them, thereby enabling unprecedented integration across system levels.

The FBSFM framework, shown in Figure 3, represented as a KG, introduces a critical distinction in behavior types after structure determination. Specifically, the established structure “Delivers” both intended behavior (aligned with expected behavior) and unintended behavior (representing potential deviations or failures). The intended behavior “Fulfils” the system’s function, which in turn “Achieves” the user’s goals, while unintended behavior forms the foundation for systematic risk analysis.

Figure 3.

The knowledge graph of the FBSFM ontology for the system level.

The FBSFM ontology, illustrated in Figure 3, extends the FBS ontology framework by explicitly incorporating unintended behavior alongside intended behavior. This represents a fundamental advancement over existing approaches. The framework establishes formal semantic connections between design elements (functions, behaviors, and structures) and risk elements (failure modes, effects, and causes), creating a goal-oriented traceability from user needs through to potential system failures. By combining the extended system ontology concepts shown in Figure 2 (upper side) with FMEA knowledge shown in Figure 3 (lower side), the framework enables cross-domain knowledge representation and reasoning, overcoming the limitations of conventional, siloed approaches to engineering design and risk management.

Identification of classes and relations within the framework

The proposed FBSFM can be deployed across multiple system levels, as illustrated in Figure 2, which shows the system structure divided into higher, focus, and lower levels. Within this framework, the focus level structure “is a part of” the higher-level structure, and similarly, the focus level function “is a part of” the higher-level function. Regarding failure modes and their consequences across multiple system levels, this can be demonstrated through the cause-and-effect chain shown in Figure 4, introduced in the AIAG/VDA standard. In this chain, the failure cause of a system’s top level “is a” failure mode for system’s lower level. With this explanation, the FBSFM ontology can be deployed to any number of system-level decompositions.

Figure 4.

Failure modes and cause relation at different level.

Central to the FBSFM ontology, as shown in Figure 3, is the concept of failure modes as “Unintended Behaviors.” These unintended behaviors disrupt the performance in achievement of the system functions, resulting in potential failure modes defined as states in which the system fails to deliver the expected or specified performance. Within this work, reflecting our focus on early system design analysis, and coherent with the AIAG and VDA standard, we are concentrating on function failure modes, which are explicitly conceptualized in relation to the functional specifications. While related, this approach is distinctly different from other prominent recent ontological approaches focused on failure mode knowledge representation, such as Compagno (Reference Compagno2025), Compagno and Borgo (Reference Compagno and Borgo2024), and Hodkiewicz et al. (Reference Hodkiewicz, Klüwer, Woods, Smoker and Low2021), which focused on a bottom-up approach, starting with the failure mechanism leading to component failure modes. While similar in the objective of formalizing knowledge representation for future design tasks, the approaching viewpoints and the requirements of the domain experts are fundamentally different. Specifically, systems engineering designers are expected to provide solution-agnostic system models in the early stages of the design, which need to be evaluated using function failure frameworks.

The proposed ontological framework provides a structured representation of the classes and their relationships within the FMEA and system model for the system’s focus elements. These classes and relationships are outlined in Table 3. Specifically, the parameters governing FMEA-related relationships were adopted from the AIAG and VDA (2019) standard, while the parameters defining system design relationships were derived from established FBS ontology frameworks. This dual sourcing ensures that the framework accurately reflects both risk assessment standards and design modeling principles.

Table 3.

Classes and their relationships in FBSFM ontology

Since the FBSFM ontology is built upon the top-level FBS and FMEA ontologies, both of which align with the definition provided by Ye et al. (Reference Ye, Stevenson and Dobson2011), describing a top-level ontology as one that captures common semantics across dimensions of information, it inherently integrates the semantic relationships and structural compositions of these foundational models. This integration enables FBSFM to offer a unified semantic structure for representing system knowledge.

FBSFM ontology development and tools

This section details the development process of the FBSFM ontology, focusing on the methodology employed to integrate the extended FBS concepts with FMEA knowledge, along with the supporting tools used throughout the process.

Tools and formalization approach

The ontology was developed using Protégé, a widely adopted open-source ontology editor (Musen, Reference Musen2015), supporting modeling in the OWL. Protégé facilitated:

• • Definition of classes, properties, and axioms reflecting the integrated FBSFM conceptual model.

• • Management of complex relationships through the “Classes” and “Object Properties” tabs.

• • Logical consistency checking using the HermiT reasoner, which was employed to validate that the ontology structure was free from logical contradictions and semantic errors.

During ontology formalization, Manchester Syntax was preferred for expressing axioms. Its more human-readable format compared to traditional OWL XML-based syntaxes significantly improved validation sessions, particularly during expert reviews and ontology debugging stages. Relationships, such as “Structure delivers Unintended Behavior” and “Unintended Behavior manifests Failure Mode,” were articulated and verified more easily using Manchester Syntax.

Figure 5 shows a snapshot of the FBSFM ontology structure within Protégé, illustrating the developed hierarchy and semantic linkages between design and risk elements.

Figure 5.

FBSFM ontology representation in Protégé.

To validate the integrity of the proposed ontology and identify any potential implementation pitfalls, we employed the OntOlogy Pitfall Scanner (OOPS) (Poveda-Villalón et al., Reference Poveda-Villalón, Asunción and Suárez-Figueroa2014), which is a commonly used open-source tool to assess the quality of an ontology (Alkhariji et al., Reference Alkhariji, De, Rana and Perera2023). Figure 6 presents the results of the evaluation performed by the OOPS tool (Poveda-Villalón et al., Reference Poveda-Villalón, Asunción and Suárez-Figueroa2014; Alkhariji et al., Reference Alkhariji, De, Rana and Perera2023). As can be seen, the tool reported three minor pitfalls related to annotations, relationship declarations, and naming conventions. While none of the issues were critical, the feedback supported targeted refinements to improve the overall structure and consistency of the ontology.

Figure 6.

Evaluation results of the FBSFM ontology using the OOPS.

KG representation

Following formalization, the FBSFM ontology was visualized as a KG using OWLGrEd (Fig. 7), enhancing the understanding of the system design-risk analysis integration. Figure 7 depicts the KG representation, highlighting:

• • Key classes (e.g., function, behavior, structure, failure mode, failure cause).

• • Semantic interconnections between design knowledge and failure knowledge.

Figure 7.

Knowledge graph representation of the FBSFM framework.

This graphical representation offers an intuitive overview of the integrated knowledge, demonstrating how potential failure mechanisms are traced back to the system’s functional and structural elements.

The following section outlines the implementation of the FBSFM ontological framework through a real-world case study from the automotive industry. This case study demonstrates the ontology framework’s capability to collect, represent, manage, and maintain knowledge that will be used, synthesized, inferred, and verified during the design phase.

Case study implementation

The validation of the developed framework’s applicability and its ability to support structured failure knowledge representation was conducted through a real-world industrial case study of a headlamp system. This case study was undertaken in collaboration with practicing engineers and domain experts from a global automotive manufacturer, ensuring that the ontology was grounded in authentic engineering artefacts and practices. The implementation would demonstrate the capability of the FBSFM framework to consolidate multisource engineering knowledge into a coherent, machine-readable repository, linking design entities from user goals to potential system failures and enabling systematic validation of FMEA information against system models. The implementation steps are illustrated in Figure 8, which demonstrates the application of the methodology to a real-world case study. These steps are outlined as follows:

• • Step 1: Conduct a case study data analysis, including FMEA spreadsheets and system model data.

• • Step 2: Perform text preparation and preprocessing.

• • Step 3: Populate the preprocessed data into the constructed framework.

• • Step 4: Explore the populated ontology.

Figure 8.

Implementation steps for applying the ontological framework to a real-world case study.

Step 1: Case study analysis

For the headlamp case study, the documentation provided included two key elements as below:

1. (1) System architecture documentation, along with descriptions of system decomposition, functional decomposition, and functional requirements. Figure 9 presents the block diagram of the case study, illustrating the structural decomposition derived from the system architecture PDF.

2. (2) The existing FMEA documentation for the headlamp system, in a tabular database format (Excel spreadsheet) containing multiple sheets:

• • The FMEA table, structured similar to Table 2, following the AIAG/VDA standard.

• • The system architecture matrix, including the function and behavior analysis for the headlamp:

  • • A table listing the functions of the focus element.

  • • A column displaying the behavior of each function, referred to as the “function criteria.”

Figure 9.

Block diagram illustrating the structural decomposition of the case study derived from the system architecture.

The headlamp system case study comprises three system levels, as depicted in the snapshot from the FMEA table (Fig. 10):

• • Level 1: Represents the overall headlamp system, identified as the “Low Beam Lamp.”

• • Level 2: Includes the focus elements, such as the “LB Module” (Low Beam Module).

• • Level 3: Represents individual components, such as the “Housing.”

Figure 10.

Example from case study FMEA table showing three system levels of the headlamp system.

For the headlamp system case study analysis, the following parameters were used to populate the ontology by instantiating the FBSFM framework with data specific to the headlamp system.

1. 1. System structure

2. 2. System function

3. 3. System behavior

4. 4. Failure mode name

5. 5. Cause of failure

6. 6. Effects of failure

7. 7. Detection control

8. 8. Prevention control

9. 9. Detection

10. 10. Occurrence

11. 11. Severity

Step 3: Populate data into the ontological framework

Before populating instances from the case study into the ontological framework, it is important to note that the case study involves three levels of decomposition and analysis. The system is decomposed into a higher level, a focused element, and a lower level.

Figure 11 provides a screenshot of the ontological framework, showcasing the three-level system decomposition represented as a KG. The snapshot illustrates classes, such as “Lower-Level Function,” “Higher Level Function,” “Higher Level Effect,” and “Higher Level Cause,” along with their associated relationships.

Figure 11.

Extended ontological framework representing three-level system decomposition as a knowledge graph.

The FMEA sheets and function analysis sheet were imported into the ontology using Protégé. This was accomplished through the Tools menu by selecting the “Create axioms from Excel sheet” option. During this process:

• • Column mapping: The Excel sheet columns were identified and mapped to their corresponding ontology classes.

• • Relation assignment: The corresponding relationships between these classes were also defined.

These mappings and relationships were saved in JSON format by Protégé, enabling reuse for future case studies. This eliminates the need for the design team to recreate the ontological framework or reassign relationships for subsequent cases.

Once the instances were imported and assigned to their respective classes and relationships, the ontology was saved in Manchester Syntax format. This format facilitates further exploration and analysis of the populated ontology in the next step.

Step 4: Explore the populated ontology

The primary purpose of this exploration step is to support engineering practitioners in retrieving targeted failure knowledge linked to specific design elements, thereby enhancing traceability, reuse, and design validation. SPARQL queries were employed within the Protégé ontology editor to systematically explore the FBSFM ontology, enabling the extraction of structured knowledge from its semantic relationships. Integrated directly into the Protégé interface, this querying capability allows users to retrieve specific classes, properties, and instances that would otherwise be difficult to access manually (Satyamurty et al., Reference Satyamurty, Murthy and Raghava2017). For instance, as shown in Figure 12, a SPARQL query was used to retrieve all failure causes associated with the “Lens” component by filtering individuals linked through the object property Has_Failure_Mechanism_FocusElement_FailureCause. The resulting list presents domain-specific failure causes, such as: “Temperature_in_the_lens_is_higher_than_the_material_limit…,” and “Reduced_thickness_does_allow_a_proper_material_flow,” which were directly extracted from the ontology. This function supports both consistency checking and traceability, offering practical insight into the relationships among functions, structures, and failure mechanisms in complex engineering systems.

Figure 12.

Example SPARQL query retrieving all failure causes related to the lens.

To simplify the use and retrieval of knowledge from the saved ontology, a custom Python script was developed to process the populated knowledge repository and is available at https://github.com/Haythamyounus/FBSFM-Ontology. This script also replaces underscores in entity names and cleans URLs to enhance human readability. Compared to using SPARQL queries directly in Protégé, the script provides a more accessible and user-friendly way to explore the ontology content.

In the following examples, highlighted colors are used to distinguish ontology syntax:

• • Green: Represents entity categories.

• • Grey: Denotes related properties for each category.

• • Yellow: Highlights data derived from the case study.

Example 1: High-level structure

In the following example from case study ontology in Manchester Syntax, the example demonstrates one of the entities within the ontology: “Low Beam LAMP.”

Each entity in the ontology is defined as an “Individual” with the following key attributes:

• • Type: Indicates the individual’s class name.

• • Facts: Displays the relationships of the individual with other classes.

Figure 13 illustrates the details for the individual “Low Beam LAMP.”

Figure 13.

Detailed ontological representation of the individual “Low Beam LAMP” highlighting class type and associated relationships.

The ontological individual “Low Beam Lamp” is categorized as a “Higher Level Structure” and delivers two higher-level behaviors. However, the related failure mode for this system structure is not provided in the case study. This highlights the ontology’s capability to identify data gaps where important risk information is missing, providing actionable insights for further investigation. Additionally, the example demonstrates the semantic bridging from system structure to Structure behavior and Unintended behavior (failure modes), even where explicit risk elements are absent, reinforcing the framework’s support for linking design intent to potential risk analysis across system levels.

To validate the functionality of the developed script, a SPARQL query was executed to retrieve information about “LowBeam_LAMP.” The result was identical to that produced by the script, confirming its correctness, as illustrated in Figure 14.

Figure 14.

SPARQL query result for the individual “LowBeam_LAMP.”

Example 3: Lower-level structure

As illustrated in examples 1 and 2, example 3 (shown in Figure 15) demonstrates the knowledge repository of the case study ontology by exploring an individual called “Housing.” This individual is classified in the ontology as a “Lower-Level Structure” which delivers one lower-level behavior (Figure 16). However, no direct failure mode is available for this structure, as the case study focuses on failure modes at the focused level.

Figure 15.

Representation of the “LB module” as a focused element structure.

Figure 16.

Ontological representation of the individual “Housing” as a lower-level structure.

While the ontology does not link a direct failure mode to the “Housing” structure, it captures a failure mechanism: “electrical connection not ensured.” This provides insight into potential risks even at lower decomposition levels, demonstrating the ontology’s ability to systematically trace failure mechanisms. Furthermore, this example confirms the semantic bridging from lower-level structure to behavior and corresponding failure mechanisms, reinforcing traceability across decomposition levels in a machine-readable format.

Following the presentation of the three illustrative examples, it is important to clarify the scope and purpose of the ontology exploration. The selected examples were chosen to demonstrate different system levels within the case study and to highlight the ontology’s ability to support structured querying, cascading decomposition, and traceability across functions, structures, and failure modes.

While the publicly available version of the ontology contains only these three instances for confidentiality reasons, the framework itself was tested on a broader set of data internally. A dedicated Python script was developed to interface with the ontology, allowing users to specify search terms and retrieve associated knowledge entities and relationships automatically. This tool was provided to practicing engineers and domain experts within the industrial partner’s team, who were invited to explore and validate the ontology independently. Their interaction with the system demonstrated its usability and flexibility for navigating complex engineering knowledge, and their informal feedback indicated that the structured repository and search mechanism effectively supported traceability and design analysis tasks.

Additional instances can be generated and imported into the ontology framework by end users, depending on the focus of their analysis or the system under consideration. The GitHub repository (https://github.com/Haythamyounus/FBSFM-Ontology) contains only the three public examples discussed above, but the ontology structure is fully extensible and designed to support future population and reuse across case studies.