FBS Ontologies for Engineering Design

• FBS ontologies are a formal framework that defines and interlinks function, behaviour, and structure to represent design artifacts.
• They employ rule-based classification and NLP techniques to automate the extraction and mapping of engineering properties into knowledge graphs.
• FBS models enable practical applications in modular system design, maintenance diagnostics, and industrial knowledge management.

The Function–Behaviour–Structure (FBS) ontology constitutes a foundational paradigm for representing, reasoning about, and automating knowledge regarding design artifacts, systems, and processes. By formalizing the triad of function (intended purpose), behaviour (observable properties or operational characteristics), and structure (the configuration or composition realizing behaviour), the FBS ontology supports rigorous knowledge integration, traceability, and computational reasoning across engineering disciplines. Significant formalizations span industrial knowledge management, modular system design, maintenance diagnostics, and automated knowledge graph generation from legacy data (Sahadevan et al., 2024, Labrousse et al., 2010, Diertens, 2015, Fujiu et al., 13 Oct 2025).

1. Formal Definitions and Ontological Structure

At its core, the FBS ontology is grounded in the following set of primitive concepts, their relationships, and formal constraints:

• Function ($F$): Any intended purpose, application, or adherence to standards of an artifact.
• Behaviour ($B$): Quantifiable properties or operational characteristics that enable or result from the realization of functions.
• Structure ($S$): Elements, sub-elements, or configurations of an artifact that give rise to its behaviours.

Class hierarchy (OWL/UML notation) organizes these under a root, typically ex:Component ($\mathsf{Component}$ for physical products), and introduces object properties including:

• ex:hasFunction ($\mathsf{Component} \to \mathsf{Function}$)
• ex:yieldsBehaviour ($\mathsf{Function} \to \mathsf{Behaviour}$)
• ex:realizedByStructure ($\mathsf{Behaviour} \to \mathsf{Structure}$)
• ex:hasPropertyName ($\mathsf{Concept} \to \mathsf{PropertyName}$)
• ex:hasPropertyValue ($\mathsf{PropertyName} \to \mathsf{PropertyValue}$)

Key class inclusion and role restriction axioms: $$\begin{aligned} &\mathsf{Function} \subseteq \exists\,\mathsf{yieldsBehaviour}.\mathsf{Behaviour} \ &\mathsf{Behaviour} \subseteq \exists\,\mathsf{realizedByStructure}.\mathsf{Structure} \ &\mathsf{Component} \subseteq \exists\,\mathsf{hasFunction}.\mathsf{Function} \ &\mathsf{PropertyName} \subseteq \exists\,\mathsf{hasPropertyValue}.\mathsf{PropertyValue} \end{aligned}$$ and the mapping axiom: $B$0 (Sahadevan et al., 2024).

2. Classification Rules and Automated Context Derivation

Efficient FBS ontology population from structured data exploits rule-driven classification combined with domain-specific NLP. A typical workflow (as in (Sahadevan et al., 2024)) parses specification sheets (e.g., PDF) into 〈propertyName, propertyValue〉 pairs. Property names are classified into $B$1 using layered rules:

• R1: If $B$2 or NER($B$3) = MeasurableQuantity or keyword match $B$4 in ClassificationKeywords $B$5 Behaviour
• R2: If NER($B$6) = Material or keyword match in MaterialKeywords $B$7 Structure
• R3: If keyword match in ApplicationKeywords or RegulationKeywords $B$8 Function
• R4: Else $B$9 Unknown

NER models (custom SpaCy/BERT), keyword lists, and cosine similarity (threshold 0.7) implement these rules. Extracted and classified properties then seed a knowledge graph (KG), where components (nodes) link to Function, Behaviour, and Structure nodes.

3. FBS Ontology Extensions: Modularity, Hierarchies, and Composite Systems

The FBS ontology extends naturally to accommodate modular design, system decomposition, and management of complexity. A composite FBS (C-FBS) formalism enables hierarchical nesting by integrating decomposition $S$0 and integration $S$1 operators (Diertens, 2015):

• Each parent system $S$2 decomposes to child systems $S$3.
• Constraints propagate downward: $S$4, $S$5, and behaviour/structure consistency is enforced through intermodule mappings and evaluation checks.
• Hierarchical generalization yields a rooted tree of FBS nodes, supporting local and global reformulation.

In Description Logic, the composite FBS ontology includes classes for frameworks, functions, behaviours, structures, decomposition/integration processes, and incorporates OWL/DL axioms for global consistency across layers (Diertens, 2015).

4. Industrial and Domain Extensions: FBS-PPR and Maintenance Diagnostics

The FBS paradigm underpins industrial knowledge ontologies such as FBS-PPR, which unifies Processus (process), Produit (product), and Ressource (resource) roles with the FBS triad (Labrousse et al., 2010). In the FBS-PPR meta-model, each object $S$6 receives a unique role and is simultaneously annotated with sets of functions, behaviours, and structures, with behaviour explicitly contextualized via process or resource interactions.

Key relations include:

• $S$7
• $S$8
• $S$9
• structural decomposition, state/behaviour mapping, and performance indicators (e.g., $\mathsf{Component}$0)

Industrial ontologies for diagnostics, such as the Diagnostic Knowledge Ontology (Fujiu et al., 13 Oct 2025), leverage an FBS-aligned schema where "System" nodes are recursively decomposed by has_Part links spanning Function $\mathsf{Component}$1 Behaviour $\mathsf{Component}$2 Structure. Maintenance records (failures, causes, effects) anchor to explicit system and FBS nodes, enabling causal inference and retrieval-augmented reasoning grounded in the artifact's design decomposition.

5. Workflow for Knowledge Graph Construction and Application

Automated FBS ontology-based knowledge graph creation centers on a pipeline involving:

1. Data Ingestion: Parsing structured datasheets into property lists (e.g., using Camelot-py to pandas DataFrame).
2. Context Derivation: Application of rules/NLP for $\mathsf{Component}$3 classification.
3. Ontology Population: Instantiation in a graph database (e.g., Neo4j) via scriptable APIs (py2neo). Nodes and edges adhere to the formal class/property structure.
4. Retrieval: Natural-language queries translate into graph constraints and Cypher queries; outputs include filtered part lists or diagnostic suggestions (Sahadevan et al., 2024, Fujiu et al., 13 Oct 2025).

Pilot evaluation demonstrates high classification performance (Function: Precision 94%, Recall 90%; Behaviour: Precision 88%, Recall 82%; Structure: Precision 91%, Recall 85%), with remaining errors primarily in ambiguous behaviour contexts (Sahadevan et al., 2024). Maintenance-specific applications show improved retrieval precision and recall, particularly under record scarcity or vocabulary mismatch, substantiating the FBS ontology's robustness for knowledge-centric engineering support (Fujiu et al., 13 Oct 2025).

6. Implications and Research Directions

FBS ontologies formalize design reasoning, enable automated assembly of computable knowledge graphs from both structured and semi-structured sources, and facilitate cross-domain knowledge sharing across the engineering chain. LaTeX axiomatics and OWL instantiations provide a foundation for SPARQL querying and description logic reasoning. Emerging opportunities include:

• Refinement of classification rules exploiting cross-facet links (e.g., behaviour-behaviour).
• Domain adaptation of NER and keyword sets for improved role assignment.
• Extension with hierarchical and processual constructs for integrated lifecycle representation (FBS-PPR).
• Implementation of robust inference mechanisms for engineering diagnostics and design automation.

This unified ontological infrastructure positions FBS as a linchpin in the formalization, retrieval, and computational utilization of engineering knowledge, with proven scalability from single components to complex systems (Sahadevan et al., 2024, Labrousse et al., 2010, Diertens, 2015, Fujiu et al., 13 Oct 2025).