Ontology-Driven Digital Twin Framework for Aviation Maintenance and Operations

Abstract

This paper presents a novel ontology-driven digital twin framework specifically designed for aviation maintenance and operations that addresses these challenges through semantic reasoning and explainable decision support. The proposed framework integrates seven interconnected ontologies—structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental. It collectively provides a comprehensive semantic representation of aircraft systems and their operational context. Each ontology is mathematically formalized using description logics and graph theory, creating a unified knowledge graph that enables transparent, traceable reasoning from sensor observations to maintenance decisions. The digital twin is formally defined as a 6-tuple that incorporates semantic transformation engines, cross-ontology mappings, and dynamic reasoning mechanisms. Unlike traditional data-driven approaches that operate as black boxes, the ontology-driven framework provides explainable inference capabilities essential for regulatory compliance and safety certification in aviation. The semantic foundation enables causal reasoning, rule-based validation, and context-aware maintenance recommendations while supporting standardization and interoperability across manufacturers, airlines, and regulatory bodies. The research contributes a mathematically grounded, semantically transparent framework that bridges the gap between domain knowledge and operational data in aviation maintenance. This work establishes the foundation for next-generation cognitive maintenance systems that can support intelligent, adaptive, and trustworthy operations in modern aviation ecosystems.

1. Introduction

1.1. Background and Motivation

The aviation industry faces increasing pressure to ensure higher levels of operational safety, cost efficiency, and environmental sustainability while managing ever more complex aircraft systems [1]. Maintenance, repair, and overhaul (MRO) processes are central to these objectives, as they directly influence aircraft availability, reliability, and compliance with stringent regulatory standards [2]. However, traditional maintenance planning relies heavily on fixed schedules and reactive practices, which can lead to unnecessary component replacements, unplanned downtime, and limited insight into real-time system health [3].

Recent advancements in digital technologies have introduced the concept of the digital twin (DT) as a dynamic, data-driven virtual replica of a physical asset that synchronizes with the real system throughout its lifecycle [4]. Digital twins promise to transform aircraft maintenance by enabling predictive and prescriptive decision support, reducing operational costs, and extending asset life [5]. Yet, many existing DT implementations in aviation remain primarily numerical or simulation-based and lack explicit mechanisms for representing domain knowledge in a way that is transparent, consistent, and logically sound [6].

To bridge this gap, ontology-driven digital twins have emerged as a promising paradigm [7]. Ontologies provide formal, machine-interpretable models of domain concepts, relationships, and constraints. By integrating ontologies into a DT framework, it becomes possible to reason about system behavior, infer maintenance actions, and maintain a clear trace from sensor observations to operational decisions [8]. Such a semantic foundation is particularly crucial in aviation, where explainability and regulatory compliance are essential.

The goal of this paper is to develop and demonstrate a mathematically grounded, ontology-driven digital twin framework for aviation maintenance and operations that integrates structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental knowledge into a unified semantic model, enabling explainable, traceable, and data-driven decision support for predictive and prescriptive maintenance.

1.2. Related Works

Major aviation companies are actively creating platforms to forecast component wear and refine maintenance planning. Key examples are Aviatar by Lufthansa Technik [9], Skywise by Airbus [10], Predix by General Electric [11], PROGNOS by Air France Industries and KLM Engineering & Maintenance [12], and AnalytX by Boeing [13]. Despite their progress, these platforms are limited by data-sharing boundaries between stakeholders.

The study [14] examines DT use in aviation, showing how digital replicas address targeted use cases across production, logistics, and MRO, while also outlining integration and compliance challenges. Reference [15] explains DT construction through master and shadow models, stressing the need to tailor data structures, communication methods, and interaction mechanisms to business value, particularly in MRO contexts.

The study [16] introduces DT fundamentals and their role in maintenance, presenting system architecture and case studies on health monitoring, prediction, and management. Paper [17] tackles cabin lifecycle management, suggesting a DT to unify 3D/2D data and documentation to improve retrofit planning and reduce ground time.

Zaccaria et al. [18] describe a signature-based DT framework for engine diagnostics, while Yang et al. [19] develop a physics-based digital surrogate for turbofan disks to detect cracks from vibration signals. Wang et al. [20] integrate material properties and geometry in DT to simulate crack propagation. Chowdhury et al. validate a model-based DT for environmental control on actual aircraft [21].

Ezhilarasu et al. [22] build a DT for electrical power systems combined with a neural network for fault isolation. In [23], the same authors present the FAVER framework, merging DT concepts with reasoning methods for fault prediction, later expanded in [24] with simulation and hardware-in-the-loop testing. Ramesh et al. [25] apply a physics-based DT and recurrent networks to model landing gear faults.

Huang et al. fuse physics-based and data-driven models via feed-forward and recurrent networks to enhance aeroengine DTs [26]. Alvarez et al. propose a hybrid method for airspeed estimation when pitot sensors fail [27], and Peng et al. In [28] validate their aeroengine DT approach through controlled facility testing. Reference [29] offers a broad DT framework for lifecycle management, integrating IoT, big data, machine learning, 6G, and cloud computing.

Blockchain is highlighted as a solution to data integrity and traceability in MRO [30]. AI and blockchain integration is discussed for improving health monitoring [31]. Paper [32] suggests blockchain for secure maintenance records, while [33] addresses counterfeit part risks. Study [34] explores blockchain for efficient record-keeping and stakeholder collaboration. Organizational readiness is analyzed in [35], and ref. [36] points to regulatory caution in adopting new technologies.

Non-fungible tokens and DTs are examined in [37] as tools for asset management and authenticity. Their broader applications are outlined in [38] for digital provenance, [39] for supply chain traceability, and [40] for automotive lifecycle management. Aviation-specific challenges and long component lifecycles are discussed in [41,42,43,44], with references [45,46] emphasizing predictive maintenance and immutable records.

Finally, asset representations are clarified: refs. [47,48] define digital shadows as one-way data mirrors, refs. [49,50] explain their monitoring role, while refs. [51,52] describe DTs as bidirectional, real-time models enabling predictive and operational improvements in aviation.

Ontology-based products apply ontologies to technological domains with a focus on product definition. Examples include STEP, defined in the ISO 10303 standard [53]; the core product model to capture product function, form, and behavior [54]; the open assembly model for assemblies and tolerances [55]; and academic initiatives such as PRONTO, DPDM, and OntoPDM for modeling complex products [56]. In addition, principles-based frameworks like the industrial ontology’s foundry provide open, modular ontologies that can be adapted to specific domains [57].

Ontology-based applications use ontologies to achieve semantic interoperability across product development systems, integrating data more effectively than traditional approaches. Notable examples are the product semantic representation language by Patil et al. [58]; an ontology bridging CAD systems by Dartigues et al. [59]; and an ontology proposed by Szejka et al. for product development process information sharing, which links ontology-based products with practical applications [60].

Ontology-based engineering (OBE) systems describe well-defined domains through classification, behavior, and semantic perspectives, combining ontology-based product and application approaches with knowledge-based engineering (KBE) principles. Examples include IKAPS, an integrated assembly planning environment [61], and a framework by Zheng et al. [62] that uses ontological models and multi-attribute decision methods to design robotic manufacturing systems.

The models for manufacturing approach [63] extend OBE by capturing manufacturing knowledge through models and behavioral abstractions [64]. OBE systems support collaborative, interoperable tools and underpin the cognitive digital twin (CDT) concept, which integrates semantically linked models across lifecycle phases [65]. CDT enhances the digital twin paradigm with cognitive functions and autonomous capabilities, enabling validated manufacturing system solutions spanning subsystems and components throughout the entire lifecycle.

Recent studies demonstrate the growing use of ontologies to support complex aircraft design and manufacturing processes. Arista et al. in [66] developed an ontology-based engineering framework for aircraft manufacturing system design that integrates model-based systems engineering methods with semantic technologies to capture domain knowledge, automate design trade-offs, and enable cognitive digital twins. Their case study on fuselage orbital joint design highlights how application ontologies and knowledge graphs improve interoperability, reuse of design rules, and automated generation of design alternatives. Ast et al. in [67] reported on the development of the AIRCRAFT ontology to serve as a common semantic reference in conceptual aircraft design. Using it they created an ontology that captures system decomposition and component parameters, ensuring consistency across heterogeneous design models and facilitating data exchange between different engineering tools.

Some research has explored the integration of ontologies into MRO and data management systems, highlighting their role in improving data consistency, safety, and operational efficiency. Kraus et al. in [68] investigated the use of ontologies and structural conceptual models to enhance safety data management in aviation MRO organizations. Their study shows that ontologies enable standardized vocabularies and data structures, reducing ambiguity in safety reporting and supporting advanced safety management systems. Stefanidis et al. presented in [69] the ICARUS ontology, a multi-layer aviation ontology designed to integrate heterogeneous datasets, support semantic queries, and enable reasoning over aviation-related assets. This approach facilitates data interoperability across diverse sources and provides a foundation for recommendation systems and intelligent analytics.

Palacios et al. proposed an avionics maintenance ontology for failure diagnosis support [70]. Their framework aligns expert knowledge and multiple data sources to enable automated reasoning, helping maintenance teams identify causes of failures and reduce aircraft downtime. Gróf and Kamtsiuris demonstrated an ontology-based process reengineering method to support the digitalization of MRO operations [71]. By structuring process data and aligning it with industry standards, their method streamlines information flow, reduces turnaround time, and improves the integration of product lifecycle data in operational decision making.

Together, these works show how ontology-based approaches improve knowledge management and decision support in the aerospace sector.

1.3. Research Gap, Contributions, and Paper Structure

Despite extensive progress in the field of aviation digital twins, existing studies still exhibit significant gaps. Most current implementations are either purely data-driven or simulation-based and lack an explicit semantic layer that can formally represent domain knowledge, trace relationships between components, and ensure explainable reasoning. While ontology-based approaches have been proposed in manufacturing and product lifecycle management, their integration into aviation maintenance and operations remains limited and fragmented. Existing works rarely combine structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental perspectives into a unified semantic framework. As a result, traceability, interoperability, and compliance with regulatory requirements are only partially addressed, and decision support often remains opaque or system-specific rather than generalizable.

While platforms such as Aviatar, Skywise, Predix, and PROGNOS offer advanced analytics and data-driven predictive capabilities, they generally operate as proprietary, black-box systems with limited transparency in how decisions are derived from operational data. These systems focus primarily on performance optimization through statistical modeling or machine learning, and do not incorporate an explicit semantic layer to formally represent domain knowledge or support explainable reasoning.

In contrast, the ontology-driven digital twin framework proposed in this paper introduces a mathematically formalized semantic structure through the integration of seven interlinked ontologies. This approach enables transparent, rule-based reasoning that traces maintenance decisions back to clearly defined domain concepts, relationships, and regulatory constraints. Unlike existing platforms, which often lack interoperability and generalizability due to closed data models, the proposed framework promotes standardization, explainability, and modularity which are key attributes for scalable and certifiable decision support in aviation maintenance.

This article addresses these gaps by developing an ontology-driven digital twin framework tailored to aviation maintenance and operations. The main contributions are threefold:

• A unified multi-layer ontology with seven interlinked ontologies (structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental) are formalized and integrated into a single knowledge graph, providing a mathematically consistent foundation for reasoning about complex aviation assets.
• Semantic integration with real-time data on the base of framework which connects ontological models with live sensor data, lifecycle records, and operational constraints to enable predictive and prescriptive maintenance decisions that are explainable and certifiable.
• The approach is validated on a turbofan engine subsystem, with logical consistency checks and cross-ontology mappings confirming the framework’s capability to support traceable decision making in real-world scenarios.

The ontology-driven framework described in this article is embedded in a broader digital-twin-based model for aircraft maintenance and lifecycle management that has been developed and refined by the author in previous studies. In earlier works, various components of this model were presented and validated. For example, the decision-making structure for predictive maintenance in aviation was formalized in [72], where multi criteria reasoning was introduced for selecting and prioritizing life limited parts. The integration of real-time monitoring, AI-driven diagnostics, and maintenance optimization processes was detailed in [73]. The architecture for a digital twin ecosystem combining federated learning and lifecycle analytics was elaborated in [5].

Bringing these developments together, the current work consolidates a unified semantic model that links structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental ontologies within a digital twin. The result is a cohesive reasoning system capable of integrating heterogeneous data streams with formalized domain knowledge to support predictive and prescriptive maintenance decisions in a traceable and certifiable manner.

The remainder of the paper is organized as follows. Section 2 presents the materials and methods, including the conceptual model, formal architecture, and mathematical foundation of the ontology-driven digital twin, along with detailed descriptions of each ontology layer. Section 3 reports the results, focusing on ontology instantiation, integration metrics, and validation through cross-ontology reasoning. Section 4 discusses the significance of ontology-based digital twins, compares the proposed framework with existing approaches, and outlines limitations and directions for future research. Section 5 concludes the study by summarizing the findings and implications for aviation maintenance and operations.

2. Materials and Methods

2.1. Conceptual Model of Digital Twin for Aircraft Systems

The digital twin concept for aircraft systems in this study is built as a layered and semantically enriched representation of a physical object and its operational environment. Rather than being a static replica, the digital twin functions as a dynamic knowledge hub that continuously integrates data from sensors, maintenance records, operational logs, and engineering documentation. This model allows real-time monitoring, predictive assessment of component health, and generation of prescriptive maintenance recommendations.

At the core of the model lies a knowledge graph in which seven interconnected ontologies: structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental. They form distinct but complementary layers. Each ontology captures a specific perspective:

• the hierarchy and relationships of physical components,
• the operational processes they perform,
• the behavior and failure mechanisms they exhibit,
• the sensors and data streams used to monitor them,
• the tasks, resources, and constraints for maintenance,
• the evolution of each component through operational states, and
• the influence of external conditions such as temperature, humidity, and runway quality.

These layers are aligned through shared identifiers and cross-ontology relations, creating a unified semantic framework. For example, a high-pressure turbine blade (structural layer) is linked to the process of power extraction (functional layer), associated with vibration and thermal degradation patterns (behavioral layer), and monitored by specific sensors (monitoring layer). This chain is further connected to relevant maintenance tasks (maintenance layer), tracked across operational states such as installed or removed (lifecycle layer), and influenced by environmental factors like high ambient temperature or dusty runway operations (environmental layer). Figure 1 illustrates the conceptual model of the ontology-driven digital twin, showing how the physical and virtual domains are interconnected through layered ontologies.

The lower part of the Figure 1 represents the physical domain, which includes the aircraft engine, onboard sensors, operational logs, and environmental conditions. Data such as temperature, vibration, torque, and recorded maintenance actions flow from this domain into the virtual domain. The upper part of the figure shows the virtual domain composed of seven interconnected ontologies: structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental. These layers together provide a formal representation of component hierarchies, operational processes, failure mechanisms, sensor mappings, maintenance actions, lifecycle states, and environmental influences.

Arrows in Figure 1 illustrate the bidirectional flow between domains. Data from the physical domain populate and update the ontology layers in the virtual domain, where reasoning engines perform anomaly detection, failure inference, and task selection. In turn, the virtual domain feeds back prescriptive recommendations and decision support to maintenance engineers and operational planning systems. This loop ensures that every recommendation is not only data-driven but also context-aware and fully traceable.

Through the adoption of this ontology-driven conceptual model, the digital twin for aircraft systems becomes more than a real-time data mirror. It evolves into an explainable decision support system capable of tracing every maintenance recommendation back to specific components, processes, conditions, and regulatory requirements. This structure not only supports predictive and prescriptive maintenance but also facilitates compliance, auditability, and scalability across different aircraft platforms.

2.2. Digital Twin Architecture and Formalization

This section introduces the formal definition of the DT within the proposed ontology-driven framework. The goal is to bridge the gap between the semantic infrastructure and the computational logic of the DT system, explicitly modeling how domain ontologies are integrated into a dynamic, cyber-physical, and decision-support architecture.

We define the digital twin as a 6-tuple:

$${\mathcal{D}\mathcal{T}}_t=〈\mathcal{P},{\mathcal{O}}_{in}\left(t\right),{\mathcal{O}}_{out}\left(t\right),\mathcal{M},\mathcal{R},\mathcal{U}〉$$

where ${\mathcal{D}\mathcal{T}}_t$ denotes the state of the digital twin at time $t$; $\mathcal{P}$ is the physical asset (e.g., aircraft engine subsystem); ${\mathcal{O}}_{in}\left(t\right)$ is the set of instantiated input ontologies at time $t$; ${\mathcal{O}}_{out}\left(t\right)$ is the set of derived output ontologies at time $t$; $\mathcal{M}$ is set of semantic mappings and transformation rules; $\mathcal{R}$ is the reasoning mechanisms applied to the ontologies; and $\mathcal{U}$ is update function that allows the DT to evolve based on new information and outcomes. In this context, $\mathcal{U}$ denotes the state update function of the digital twin. It governs the evolution of the twin’s internal state over time by incorporating new information from the physical asset and the associated ontologies. The update function applies semantic reasoning results, maintenance actions, and observed sensor data to modify both the assertional knowledge (ABox) and derived ontological states, ensuring that the virtual representation remains synchronized with the actual operational condition of the asset. Thus, $\mathcal{U}$ encapsulates the dynamic adaptation mechanism that allows the digital twin to reflect real-time changes in both the physical domain and the semantic model.

Within the DT pipeline, we classify the ontologies based on their semantic roles. Figure 2 presents the formal architecture of the ontology-based digital twin, detailing the classification of ontologies, reasoning mechanisms, and semantic transformation processes that drive dynamic decision making.

Let us define the input ontology set at time $t$ as

$${\mathcal{O}}_{in}\left(t\right)=\left\{{\mathcal{O}}_{monitor}\left(t\right),{\mathcal{O}}_{env}\left(t\right),{\mathcal{O}}_{struct},{\mathcal{O}}_{life}^{past}(t)\right\}$$

where ${\mathcal{O}}_{monitor}\left(t\right)$ is monitoring ontology which represents instantiated sensor readings and observation time series, ${\mathcal{O}}_{env}\left(t\right)$ is environment ontology which encodes contextual conditions such as weather or runway surface, ${\mathcal{O}}_{struct}$ is the structural ontology (static), and ${\mathcal{O}}_{life}^{past}(t)$ is lifecycle which represents accumulated lifecycle records.

Let us define the output ontology set at time $t$ as

$${\mathcal{O}}_{out}\left(t\right)=\left\{{\mathcal{O}}_{behav}\left(t\right),{\mathcal{O}}_{maint}\left(t\right),{\mathcal{O}}_{func}(t),{\mathcal{O}}_{life}^{future}(t)\right\}$$

where ${\mathcal{O}}_{behav}\left(t\right)$ is behavioral ontology (detected deviations, failure patterns); ${\mathcal{O}}_{maint}\left(t\right)$ is maintenance ontology (prescriptive actions); ${\mathcal{O}}_{func}\left(t\right)$ functional ontology (updated process chains and system behavior), ${\mathcal{O}}_{life}^{future}(t)$ is updated lifecycle state.

The core transformation is modeled as

$${\mathcal{O}}_{out}\left(t\right)=\mathcal{R}\circ \mathcal{M}\left[{\mathcal{O}}_{in}\left(t\right)\right]$$

which denotes the application of reasoning $\mathcal{R}$ and mappings $\mathcal{M}$ over input ontologies to generate output semantics, symbol $(\circ )$ denotes function composition.

The internal state of the digital twin ${\widehat{x}}_t$ evolves over time according to the synchronized physical state $x_t$, governed by the estimation function:

$${\widehat{x}}_t=f({\widehat{x}}_{t-1},u_{t-1},y_t)$$

where $y_t$—sensor observations from ${\mathcal{O}}_{monitor}$; $u_{t-1}$—previous action/maintenance decision; and $f$—state update function incorporating semantic knowledge.

This state forms the basis for the DT’s simulated predictions and behavioral inferences.

The DT functions as a semantic controller that outputs prescriptive actions:

$$u_t=\pi [\mathcal{R}\left({\mathcal{O}}_t\right), c_t]$$

where $\pi$ is a policy that uses inferred ontology state ${\mathcal{O}}_t={\mathcal{O}}_{in}\cup {\mathcal{O}}_{out}$ and operational constraints $c_t$ (e.g., turnaround time, cost limits) to choose the optimal maintenance action.

The functional life of the digital twin progresses through the following discrete phases:

• Initialization: creation of ${\mathcal{O}}_{struct}$ and ${\mathcal{O}}_{life}^{past}$;
• Observation: ingestion and alignment of ${\mathcal{O}}_{monitor}$ and ${\mathcal{O}}_{env}$;
• Reasoning: execution of $\mathcal{M}$ and $\mathcal{R}$ to infer ${\mathcal{O}}_{out}$;
• Decision: evaluation of $u_t$ using policy $\pi$;
• Update: modify ${\mathcal{O}}_{life}$ and ${\widehat{x}}_t$ accordingly.

Each cycle improves the DT’s synchronization fidelity and prescriptive accuracy.

This formal model highlights the role of the digital twin as a semantic transformation engine, where ontologies serve both as knowledge containers and as inputs/outputs of a reasoning process. By embedding domain semantics into the DT’s core architecture, the framework ensures that physical observations, contextual factors, and maintenance knowledge are processed in a mathematically robust and explainable manner.

2.3. Mathematical Framework of Ontology Foundation

To ensure semantic rigor, consistency, and inferential soundness within the proposed ontology-driven digital twin framework, a mathematical foundation based on description logics and graph theory is employed. These formalisms support machine-readable semantics, enable deductive reasoning, and provide a framework for encoding domain constraints and relationships in a decidable and computationally tractable manner.

Let us define the ontology at time $t$ as

$$\mathcal{O}(t)=〈\mathcal{T},\mathcal{A}(t)〉$$

where

• $\mathcal{T}$ is the terminological box (Tbox) which contains the vocabulary (concepts/classes and roles/properties) and axioms that define the domain. It includes subclass relations, domain and range restrictions, disjointness conditions, and property characteristics. For example,

  $$\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}⊑\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}$$

  $$\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{s}⊑\mathrm{O}\mathrm{b}\mathrm{j}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{P}\mathrm{r}\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{t}\mathrm{y}$$

  $$\mathrm{D}\mathrm{o}\mathrm{m}\mathrm{a}\mathrm{i}\mathrm{n}\left(\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{s}\right)=\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}$$

  $$\mathrm{R}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}\left(\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{s}\right)=\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{o}\mathrm{n}\mathrm{e}\mathrm{n}\mathrm{t}$$
• $\mathcal{A}(t)$ is the assertional box (ABox) at time $t$, which consists of factual assertions about individual instances, such as

  $$\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}\#\mathrm{T}1:\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}$$

  $$\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{V}\mathrm{a}\mathrm{l}\mathrm{u}\mathrm{e}(\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}\#\mathrm{T}1,980)$$

The ABox is time-dependent because it evolves with new observations, sensor readings, or maintenance events.

Within the digital twin, TBoxes encode domain knowledge, while ABoxes represent current state knowledge, allowing real-time inference of behavior, failure modes, or recommended actions. The consistency between the TBox and ABox is verified through DL reasoning tools ensuring semantic coherence.

This distinction enables modular ontology design: the same TBox can be reused across different aircraft or systems, while the ABox dynamically evolves based on telemetry and lifecycle data. This modularity is critical for scalable and interoperable digital twin deployment in aviation systems.

The ABox assertions can be represented as triples in the resource description framework (RDF) format:

$$(\mathrm{S}\mathrm{u}\mathrm{b}\mathrm{j}\mathrm{e}\mathrm{c}\mathrm{t},\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{d}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{t}\mathrm{e},\mathrm{O}\mathrm{b}\mathrm{j}\mathrm{e}\mathrm{c}\mathrm{t})$$

For instance,

$$(\mathrm{L}\mathrm{a}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{G}\mathrm{e}\mathrm{a}\mathrm{r},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r},\mathrm{B}\mathrm{r}\mathrm{a}\mathrm{k}\mathrm{e}\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r})$$

This means the landing gear has a sensor, which is a brake temperature sensor.

RDF is designed for data sharing and integration. It forms the basis for reasoning about relationships in a semantic web or knowledge graph. This triple corresponds to an RDF graph edge and is semantically validated by the TBox.

The ontology achieves semantic closure when all implicit relationships have been inferred and made explicit by the reasoning engine. The closed, enriched ontology then supports downstream decision making in the digital twin system.

This TBox–ABox structure ensures a modular, explainable, and logically sound foundation for aviation-specific digital twins, accommodating real-time data integration and long-term domain knowledge accumulation.

2.4. Core Domain Ontologies for Aviation Digital Twins

To enable semantic reasoning, traceability, and domain knowledge representation within aviation digital twins, this framework defines a modular set of interrelated ontologies. Each ontology addresses a specific conceptual layer of aircraft operation and maintenance, from structural assemblies and functional behavior to contextual environments and sensor monitoring.

The seven ontologies described in this section form the semantic backbone of the digital twin architecture. Their alignment allows for real-time mapping of system status, dynamic failure modeling, and prescriptive maintenance planning. Each ontology is formally structured and serves a distinct role in ensuring consistency, interoperability, and explainability across the digital twin lifecycle.

The subsections that follow provide detailed descriptions of each ontology, including their scope, classes, key properties, and role within the overall reasoning process.

2.4.1. Structural Ontology

The structural ontology forms the mathematical backbone of the digital twin by defining a hierarchy of entities and formal relationships between them. It provides a graph-based representation of the asset’s physical composition and serves as a reference domain for all other ontology layers. Figure 3 presents the structure of the ontology.

The structural ontology can be regarded as a quadruple

$$O_S=(V_S,R,E_S,A)$$

where $V_S$ is the set of entities, $R$ the set of relations, $E_S$ is the set of labeled edges, and $A$ is the family of attribute functions. This formalization ensures that all other ontological layers in the digital twin are grounded in a mathematically consistent representation of the physical asset.

Formally, we define the structural ontology as a directed labeled graph

$$G_s=(V_S,E_S)$$

where the vertex set $V_S$ is partitioned into disjoint subsets

$$V_S=V_{System}\cup V_{Subsystems}\cup V_{Component}\cup V_{Part}$$

The set of top-level entities representing complete assets within the digital twin:

$$V_{System}=\{\mathrm{a}\mathrm{l}\mathrm{l} \mathrm{h}\mathrm{i}\mathrm{g}\mathrm{h}-\mathrm{l}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l} \mathrm{s}\mathrm{y}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{m}\mathrm{s} \mathrm{m}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}\mathrm{e}\mathrm{d} \mathrm{i}\mathrm{n} \mathrm{t}\mathrm{h}\mathrm{e} \mathrm{o}\mathrm{n}\mathrm{t}\mathrm{o}\mathrm{l}\mathrm{o}\mathrm{g}\mathrm{y}\}$$

Example:

$$V_{System}=\{\mathrm{A}\mathrm{i}\mathrm{r}\mathrm{c}\mathrm{r}\mathrm{a}\mathrm{f}\mathrm{t},\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e}\}$$

where $Aircraft$ is the whole platform, $Engine$ is a complete propulsion system.

A subsystem is more detailed than a system but broader than a single component:

$$V_{Subsystems}=\{\mathrm{a}\mathrm{l}\mathrm{l} \mathrm{s}\mathrm{u}\mathrm{b}\mathrm{s}\mathrm{y}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{m}\mathrm{s} \mathrm{b}\mathrm{e}\mathrm{l}\mathrm{o}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{g} \mathrm{t}\mathrm{o} \mathrm{s}\mathrm{y}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{m}\mathrm{s}\}$$

Example:

$$V_{Subsystems}=\{\mathrm{F}\mathrm{u}\mathrm{e}\mathrm{l}\mathrm{S}\mathrm{y}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{m},\mathrm{C}\mathrm{o}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{S}\mathrm{y}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{m},\mathrm{A}\mathrm{v}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{c}\mathrm{s}\mathrm{M}\mathrm{o}\mathrm{d}\mathrm{u}\mathrm{l}\mathrm{e}\}$$

where $FuelSystem$ within the engine, $CoolingSystem$ managing thermal loads, $AvionicsModule$ inside the aircraft.

The set of discrete, identifiable parts of a system or subsystem that perform specific functions:

$$V_{Component}=\{\mathrm{a}\mathrm{l}\mathrm{l} \mathrm{c}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{o}\mathrm{n}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{s} \mathrm{a}\mathrm{s}\mathrm{s}\mathrm{e}\mathrm{m}\mathrm{b}\mathrm{l}\mathrm{e}\mathrm{d} \mathrm{w}\mathrm{i}\mathrm{t}\mathrm{h}\mathrm{i}\mathrm{n} \mathrm{s}\mathrm{u}\mathrm{b}\mathrm{s}\mathrm{y}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{m}\mathrm{s}\}$$

Example:

$$V_{Component}=\{\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{r},\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{a}\mathrm{d}\mathrm{e},\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}\}$$

where $Compressor$ is part of the engine core, $TurbineBlade$ is a rotating airfoil in the turbine section, and $TemperatureSensor$ is embedded in the cooling loop.

The set of smallest replaceable or indivisible items that make up a component or assembly:

$$V_{Part}=\{\mathrm{a}\mathrm{l}\mathrm{l} \mathrm{i}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{v}\mathrm{i}\mathrm{d}\mathrm{u}\mathrm{a}\mathrm{l} \mathrm{p}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{s} \mathrm{u}\mathrm{s}\mathrm{e}\mathrm{d} \mathrm{i}\mathrm{n} \mathrm{c}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{o}\mathrm{n}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{s}\}$$

Example:

$$V_{Part}=\{\mathrm{F}\mathrm{a}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r},\mathrm{S}\mathrm{e}\mathrm{a}\mathrm{l},\mathrm{B}\mathrm{o}\mathrm{l}\mathrm{t}\}$$

where $F\mathrm{a}\mathrm{s}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}$ holds a sensor in place, $Seal$ ensures no fluid leaks in the cooling system, and $Bolt$ is used in the turbine blade mounting.

For any two vertices $u,v\in V_S$, an edge $(u,v,r)$ exists if and only if a relation $r$ holds between them. The relation set includes

$$R=\{hasPart,isPartOf,connectedTo,supports\}$$

For example,

$$(\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{r},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{P}\mathrm{a}\mathrm{r}\mathrm{t})\in {\mathrm{E}}_{\mathrm{s}}$$

$$(\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{a}\mathrm{d}\mathrm{e},\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{i}\mathrm{n}\mathrm{e},\mathrm{i}\mathrm{s}\mathrm{P}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{O}\mathrm{f})\in {\mathrm{E}}_{\mathrm{s}}$$

Each class in $V_S$ is associated with attribute functions

$$A_{sys}:V_{System}\to {\mathcal{A}}_{sys}$$

$$A_{subsys}:V_{Subsystem}\to {\mathcal{A}}_{subsys}$$

$$A_{comp}:V_{Component}\to {\mathcal{A}}_{comp}$$

$$A_{part}:V_{Part}\to {\mathcal{A}}_{part}$$

where ${{\mathcal{A}}_{sys},\mathcal{A}}_{subsys},{\mathcal{A}}_{comp},{\mathcal{A}}_{part}$ are sets of attribute tuples.

For instance,

$$A_{sys}\left(Aircraft\right)=(\mathrm{M}\mathrm{a}\mathrm{n}\mathrm{u}\mathrm{f}\mathrm{a}\mathrm{c}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{r}=\mathrm{B}\mathrm{o}\mathrm{e}\mathrm{i}\mathrm{n}\mathrm{g},\mathrm{M}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}=737)$$

$$A_{subsys}\left(FuelSystem\right)=(\mathrm{C}\mathrm{a}\mathrm{p}\mathrm{a}\mathrm{c}\mathrm{i}\mathrm{t}\mathrm{y}=5000 \mathrm{L},\mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}=\mathrm{I}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{a}\mathrm{l} \mathrm{W}\mathrm{i}\mathrm{n}\mathrm{g} \mathrm{T}\mathrm{a}\mathrm{n}\mathrm{k})$$

$$A_{comp}\left(TurbineBlade\right)=(\mathrm{M}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{a}\mathrm{l}=\mathrm{T}\mathrm{i}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{i}\mathrm{u}\mathrm{m},\mathrm{W}\mathrm{e}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}=2.5 \mathrm{k}\mathrm{g})$$

$$A_{part}\left(Fastener\right)=(\mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}=\mathrm{B}\mathrm{o}\mathrm{l}\mathrm{t},\mathrm{Q}\mathrm{u}\mathrm{a}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{t}\mathrm{y}=20)$$

Integration with other ontology layers is realized by defining cross-ontology mappings

$$f_{SF}:V_S\to V_F, f_{SB}:V_S\to V_B,{ f}_{SM}:V_S\to V_M$$

linking a structural entity to its functional processes, behavioral states, and monitoring sensors, respectively.

2.4.2. Functional Ontology—System Behaviors, Process Chains

The functional ontology formalizes the intended behaviors of the system by defining functions, capabilities, and operations, together with the relationships that link them. It provides a mathematical representation of how structural components contribute to higher-level objectives, forming process chains that describe system behavior under various operational conditions. Figure 4 illustrates the structure of the functional ontology.

The functional ontology can be expressed as a labeled graph (or quadruple) that captures its entities, relations, edges, and attributes:

$$O_F=(V_F,R_F,E_F,A_F)$$

where $V_F$—he set of vertices (concepts) in the functional ontology, $R_F$—the set of relation types between these concepts, $E_F\subseteq V_F\times R_F\times V_F$—the set of labeled edges representing functional relationships, $A_F$—the family of attribute functions that assign properties to each vertex.

In the context of the aircraft digital twin:

$$V_F=V_{Function}\cup V_{Capability}\cup V_{Operation}$$

where $V_{Function}$ represents high-level goals, $V_{Capability}$ represents the ability of a system or component to perform an action, and $V_{Operation}$ represents specific tasks or processes that implement a capability.

Examples:

$$V_{Function}=\{\mathrm{T}\mathrm{h}\mathrm{r}\mathrm{u}\mathrm{s}\mathrm{t}\mathrm{G}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{H}\mathrm{e}\mathrm{a}\mathrm{t}\mathrm{D}\mathrm{i}\mathrm{s}\mathrm{s}\mathrm{i}\mathrm{p}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\}$$

$$V_{Capability}=\{\mathrm{G}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{T}\mathrm{h}\mathrm{r}\mathrm{u}\mathrm{s}\mathrm{t},\mathrm{R}\mathrm{e}\mathrm{g}\mathrm{u}\mathrm{l}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\}$$

$$V_{Operation}=\{\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{n}\mathrm{V}\mathrm{a}\mathrm{l}\mathrm{v}\mathrm{e}\}$$

The edge set $E_F$ encodes semantic relationships:

$$R_F=\{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{s},\mathrm{s}\mathrm{u}\mathrm{p}\mathrm{p}\mathrm{o}\mathrm{r}\mathrm{t}\mathrm{s},\mathrm{a}\mathrm{c}\mathrm{h}\mathrm{i}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{s},\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{b}\mathrm{l}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y}\}$$

Each class is enriched with attribute mappings:

$$A_i:V_i\to {\mathcal{A}}_i|i=\{func,cap,op\}$$

For example,

$$A_{func}\left(ThrustGeneration\right)=(\mathrm{G}\mathrm{o}\mathrm{a}\mathrm{l}:\mathrm{“}\mathrm{P}\mathrm{r}\mathrm{o}\mathrm{d}\mathrm{u}\mathrm{c}\mathrm{e} \mathrm{f}\mathrm{o}\mathrm{r}\mathrm{w}\mathrm{a}\mathrm{r}\mathrm{d} \mathrm{p}\mathrm{r}\mathrm{o}\mathrm{p}\mathrm{u}\mathrm{l}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{”},\mathrm{E}\mathrm{f}\mathrm{f}\mathrm{i}\mathrm{c}\mathrm{i}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}=0.85)$$

$$A_{cap}\left(\mathrm{G}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{T}\mathrm{h}\mathrm{r}\mathrm{u}\mathrm{s}\mathrm{t}\right)=(\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{R}\mathrm{a}\mathrm{n}\mathrm{g}\mathrm{e}=\mathrm{20,000}-\mathrm{40,000} \mathrm{f}\mathrm{t})$$

$$A_{op}\left(StartEngine\right)=(Duration=30seconds,ExecutionFrequency=1)$$

The functional ontology provides a rigorous framework for reasoning about system behaviors and process chains, enabling the digital twin to analyze operational efficiency, diagnose functional issues, and recommend performance-optimizing actions in a mathematically consistent manner.

2.4.3. Behavioral Ontology—Failure Modes, Operational Patterns

The behavioral ontology provides a formal framework to represent dynamic aspects of the asset’s operation. It models how components and subsystems transition between operational states, how events trigger these transitions, and how sequences of states form operational patterns or failure modes over time. This ontology captures normal and abnormal behavior, enabling reasoning about future states, anomaly detection, and event management. Figure 5 illustrates the structure of the behavioral ontology.

The behavioral ontology can be expressed as a labeled graph (or quadruple) that captures its entities, relations, edges, and attributes:

$$O_B=(V_B,R_B,E_B,A_B)$$

Formally, we define the behavioral ontology as a labeled transition system:

$$G_B=(V_B,E_B)$$

where

$$V_B=V_{State}\cup V_{Event}\cup V_{Transition}\cup V_{Behavior}$$

with $V_{State}$—operational modes (e.g., Idle, Operational, CoolingDown); $V_{Event}$—occurrences causing state changes (e.g., StartUpEvent, FailureEvent); $V_{Transition}$—processes linking states (e.g., Idle → Operational); $V_{Behavior}$—higher-level sequences of states and transitions (e.g., Idle → Operational → CoolingDown).

Edges $E_B$ encode relationships:

$$R_B=\{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{t}\mathrm{e},\mathrm{t}\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{g}\mathrm{e}\mathrm{r}\mathrm{s},\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{u}\mathrm{l}\mathrm{t}\mathrm{s}\mathrm{I}\mathrm{n},\mathrm{c}\mathrm{a}\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y},\mathrm{i}\mathrm{s}\mathrm{P}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{O}\mathrm{f}\mathrm{B}\mathrm{e}\mathrm{h}\mathrm{a}\mathrm{v}\mathrm{i}\mathrm{o}\mathrm{r}\}$$

For example,

$$(\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{t}\mathrm{e})\in E_B$$

$$(\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{U}\mathrm{p}\mathrm{E}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t},\mathrm{I}\mathrm{d}\mathrm{l}\mathrm{e}\to \mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{t}\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{g}\mathrm{e}\mathrm{r}\mathrm{s})\in E_B$$

$$(\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l}\to \mathrm{C}\mathrm{o}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{D}\mathrm{o}\mathrm{w}\mathrm{n},\mathrm{C}\mathrm{o}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{D}\mathrm{o}\mathrm{w}\mathrm{n},\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{u}\mathrm{l}\mathrm{t}\mathrm{s}\mathrm{I}\mathrm{n})\in E_B$$

$$(\mathrm{F}\mathrm{a}\mathrm{i}\mathrm{l}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{E}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t},\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{c}\mathrm{a}\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y})\in E_B$$

Attribute functions enrich these elements:

$$A_{State}:V_{State}\to {\mathcal{A}}_{State}, A_{Event}:V_{Event}\to {\mathcal{A}}_{Event}$$

$$A_{transition}:V_{transition}\to {\mathcal{A}}_{transition}, A_{behavior}:V_{behavior}\to {\mathcal{A}}_{behavior}$$

with examples:

$$A_{State}\left(Operational\right)=(\mathrm{D}\mathrm{u}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}=3 \mathrm{h},\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}=\mathrm{N}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l}),$$

$$A_{Event}\left(FailureEvent\right)=(T\mathrm{i}\mathrm{m}\mathrm{e}\mathrm{s}\mathrm{t}\mathrm{a}\mathrm{m}\mathrm{p}=\mathrm{t}0,\mathrm{S}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{y}=\mathrm{C}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l}),$$

$$A_{transition}(Idle\to Operational)=(\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{t}\mathrm{e}=\mathrm{I}\mathrm{d}\mathrm{l}\mathrm{e},\mathrm{E}\mathrm{n}\mathrm{d}\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{t}\mathrm{e}=\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{T}\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{g}\mathrm{e}\mathrm{r}=\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{U}\mathrm{p}\mathrm{E}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t}),$$

$$A_{behavior}\left(FlightBehavior\right)=(\mathrm{N}\mathrm{a}\mathrm{m}\mathrm{e}=\mathrm{F}\mathrm{l}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}\mathrm{B}\mathrm{e}\mathrm{h}\mathrm{a}\mathrm{v}\mathrm{i}\mathrm{o}\mathrm{r},\mathrm{F}\mathrm{r}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}=2/\mathrm{d}\mathrm{a}\mathrm{y}).$$

Failure modes are represented as specific behaviors or sequences where transitions are caused by abnormal events:

$$\mathrm{F}\mathrm{a}\mathrm{i}\mathrm{l}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{B}\mathrm{e}\mathrm{h}\mathrm{a}\mathrm{v}\mathrm{i}\mathrm{o}\mathrm{r}=\left\{\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l}\stackrel{\mathrm{F}\mathrm{a}\mathrm{i}\mathrm{l}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{E}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t}}{\to }\mathrm{S}\mathrm{h}\mathrm{u}\mathrm{t}\mathrm{d}\mathrm{o}\mathrm{w}\mathrm{n}\right\}$$

Cross-ontology mappings connect these behavioral elements to structural, functional, and monitoring layers:

$$f_{BS}:V_{State}\to V_S, f_{BF}:V_{State}\to V_F,{ f}_{BM}:V_{Event}\to V_M$$

for example,

$$f_{BS}\left(Operational\right)=\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},$$

$$f_{BF}\left(Operational\right)=\mathrm{T}\mathrm{h}\mathrm{r}\mathrm{u}\mathrm{s}\mathrm{t}\mathrm{G}\mathrm{e}\mathrm{n}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},$$

$$f_{BM}\left(FailureEvent\right)=\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}$$

This formalization allows the digital twin to reason about dynamic operational patterns, detect anomalies, and anticipate potential failures by analyzing sequences of states, transitions, and events within a mathematically consistent framework.

2.4.4. Monitoring Ontology—Sensors, Data Types, Time Series

The monitoring ontology provides the formal layer for representing sensor infrastructure, data attributes, and time-series streams that link the physical domain of the asset to the reasoning capabilities of the digital twin. It captures how raw measurements are collected, contextualized, and associated with structural components, and how anomalies are detected through rule-based or statistical thresholds. This ontology supplies the data foundation for diagnostics, prognostics, and prescriptive maintenance. Figure 6 illustrates the structure of the monitoring ontology.

Formally, we define the monitoring ontology as follows:

$$G_M=(V_M,E_M)$$

where

$$V_M=V_{Sensor}\cup V_{Reading}\cup V_{Treshold}\cup V_{DataStream}\cup V_{Anomaly}$$

with $V_{Sensor}$—devices collecting data (e.g., VibrationSensor, TemperatureSensor); $V_{Reading}$—individual data points (value, timestamp, unit); $V_{Treshold}$—parameter limits defining normal operation (e.g., vibration limit = 10 g); $V_{DataStream}$—sequences of readings over time; and $V_{Anomaly}$—deviations from expected ranges or patterns.

Edges $E_M$ define semantic relationships:

$$R_M=\{\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{R}\mathrm{e}\mathrm{a}\mathrm{d}\mathrm{i}\mathrm{n}\mathrm{g},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{T}\mathrm{h}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{h}\mathrm{o}\mathrm{l}\mathrm{d},\mathrm{d}\mathrm{e}\mathrm{t}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{s},\mathrm{a}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{c}\mathrm{i}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d}\mathrm{W}\mathrm{i}\mathrm{t}\mathrm{h}\},$$

Time-series behavior is represented by the following:

$$D=\left\{\right(t_i,v_i\left)\right|i=\mathrm{1,2},\dots ,n\}$$

where each pair $(t_i,v_i)$ is a sensor reading. Deviations are detected by evaluating

$$v_i>\mathrm{U}\mathrm{p}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{i}\mathrm{m}\mathrm{i}\mathrm{t},v_i<\mathrm{L}\mathrm{o}\mathrm{w}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{i}\mathrm{m}\mathrm{i}\mathrm{t} \mathrm{o}\mathrm{r} \mathrm{L}\mathrm{o}\mathrm{w}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{i}\mathrm{m}\mathrm{i}\mathrm{t}<v_i<\mathrm{U}\mathrm{p}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{L}\mathrm{i}\mathrm{m}\mathrm{i}\mathrm{t}$$

Cross-ontology mappings connect monitoring data to structural entities, operational states, and functional performance:

$$f_{MS}:V_{Sensor}\to V_S, f_{MB}:V_{Reading}\to V_B,{ f}_{MF}:V_{DataStream}\to V_F$$

For example,

$$f_{MS}\left(VibrationSensor\right)=\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{r},$$

$$f_{MB}\left(r1\right)=\mathrm{I}\mathrm{d}\mathrm{l}\mathrm{e}\to \mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l}$$

$$f_{MF}\left(ThermalDataStream\right)=\mathrm{C}\mathrm{o}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}.$$

The monitoring ontology establishes a mathematically consistent bridge between raw sensor data and high-level reasoning in the digital twin, enabling real-time validation of behaviors, detection of anomalies, and formation of predictive maintenance insights.

Outlier detection in the monitoring ontology is currently handled through predefined threshold rules and semantic constraints. For example, a time-series signal that exceeds the specified upper or lower bounds of a monitored parameter (e.g., vibration amplitude, exhaust gas temperature) is flagged as a semantic anomaly. These anomalies are not immediately filtered or discarded; rather, they are preserved as formal instances within the ontology and linked to behavioral patterns via cross-ontology mappings. This ensures that potentially meaningful deviations are incorporated into failure inference and maintenance planning. At this stage, the framework does not apply automated statistical outlier filtering, as the emphasis is on explainable anomaly capture. Future versions may incorporate hybrid mechanisms that combine semantic rules with statistical learning to classify, suppress, or escalate outliers based on historical patterns and operational context.

2.4.5. Maintenance Ontology—Tasks, Tools, Schedules, Costs

The maintenance ontology provides a formal representation of maintenance activities, resources, and planning constraints. It defines how specific actions are associated with components, how tools and prerequisites are required for execution, and how schedules and cost parameters are captured to support decision making. By integrating this ontology with monitoring and behavioral layers, the digital twin can generate context-aware and cost-effective maintenance recommendations. Figure 7 illustrates the structure of maintenance ontology.

Formally, we define the maintenance ontology as follows:

$$G_T=(V_T,E_T)$$

where

$$V_T=V_{Action}\cup V_{Type}\cup V_{Schedule}\cup V_{Record}\cup V_{Health}$$

with $V_{Action}$—specific maintenance tasks (e.g., Inspection, Replacement, Repair); $V_{Type}$—categories of maintenance such as Preventive, Predictive, or Corrective; $V_{Schedule}$—planned intervals or triggers; $V_{Record}$—historical instances of completed actions; $V_{Health}$—states of component condition (e.g., Healthy, Degraded, Failed).

Edges $E_T$ encode relationships:

$$R_T=\{\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{e}\mathrm{d}\mathrm{O}\mathrm{n},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{M}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e},\mathrm{s}\mathrm{c}\mathrm{h}\mathrm{e}\mathrm{d}\mathrm{u}\mathrm{l}\mathrm{e}\mathrm{d}\mathrm{A}\mathrm{t},\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{d}\mathrm{A}\mathrm{s},\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{l}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{s},\mathrm{r}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{i}\mathrm{r}\mathrm{e}\mathrm{s}\}$$

For example,

$$(\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{a}\mathrm{d}\mathrm{e}\mathrm{R}\mathrm{e}\mathrm{p}\mathrm{l}\mathrm{a}\mathrm{c}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t},\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{a}\mathrm{d}\mathrm{e},\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{e}\mathrm{d}\mathrm{O}\mathrm{n})\in E_T$$

$$(\mathrm{I}\mathrm{n}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{P}\mathrm{r}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{i}\mathrm{v}\mathrm{e}\mathrm{M}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{M}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e})\in E_T$$

$$(\mathrm{I}\mathrm{n}\mathrm{s}\mathrm{p}\mathrm{e}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{C}\mathrm{y}\mathrm{c}\mathrm{l}\mathrm{e}200,\mathrm{s}\mathrm{c}\mathrm{h}\mathrm{e}\mathrm{d}\mathrm{u}\mathrm{l}\mathrm{e}\mathrm{d}\mathrm{A}\mathrm{t})\in E_T$$

$$(\mathrm{R}\mathrm{e}\mathrm{p}\mathrm{a}\mathrm{i}\mathrm{r}\mathrm{A}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{M}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d}\#45,\mathrm{r}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{d}\mathrm{A}\mathrm{s})\in E_T$$

$$(\mathrm{R}\mathrm{e}\mathrm{p}\mathrm{l}\mathrm{a}\mathrm{c}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{A}\mathrm{c}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{o}\mathrm{n}\mathrm{e}\mathrm{n}\mathrm{t}\mathrm{H}\mathrm{e}\mathrm{a}\mathrm{l}\mathrm{t}\mathrm{h},\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{l}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{s})\in E_T$$

$$(\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{R}\mathrm{e}\mathrm{p}\mathrm{a}\mathrm{i}\mathrm{r},\mathrm{T}\mathrm{o}\mathrm{r}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{W}\mathrm{r}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{h},\mathrm{r}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{i}\mathrm{r}\mathrm{e}\mathrm{s})\in E_T$$

Attributes enrich the following elements:

$$A_{Action}:V_{Action}\to {\mathcal{A}}_{Action}, A_{Schedule}:V_{Schedule}\to {\mathcal{A}}_{Schedule}$$

$$A_{Record}:V_{Record}\to {\mathcal{A}}_{Record}, A_{Health}:V_{Health}\to {\mathcal{A}}_{Health}$$

with examples:

$${\mathcal{A}}_{Action}\left(Repair\right)=(\mathrm{D}\mathrm{u}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}=4 \mathrm{h},\mathrm{C}\mathrm{o}\mathrm{s}\mathrm{t}=2000),$$

$${\mathcal{A}}_{Schedule}\left(InspectionSchedule\right)=(\mathrm{I}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{r}\mathrm{v}\mathrm{a}\mathrm{l}=200 \mathrm{c}\mathrm{y}\mathrm{c}\mathrm{l}\mathrm{e}\mathrm{s}),$$

$${\mathcal{A}}_{Record}(MaintenanceRecord\#45)=(\mathrm{P}\mathrm{e}\mathrm{r}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{e}\mathrm{d}\mathrm{A}\mathrm{t}=2025-01-10,\mathrm{O}\mathrm{u}\mathrm{t}\mathrm{c}\mathrm{o}\mathrm{m}\mathrm{e}=\mathrm{S}\mathrm{u}\mathrm{c}\mathrm{c}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{f}\mathrm{u}\mathrm{l}),$$

$${\mathcal{A}}_{Health}\left(TurbineBlade\right)=(\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{L}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l}=\mathrm{D}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{e}\mathrm{d},\mathrm{R}\mathrm{e}\mathrm{m}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{L}\mathrm{i}\mathrm{f}\mathrm{e}=50\mathrm{h}).$$

Tool and prerequisite requirements are captured by

$$\mathrm{r}\mathrm{e}\mathrm{q}\mathrm{u}\mathrm{i}\mathrm{r}\mathrm{e}\mathrm{s}:V_{Action}\to \mathcal{T}$$

where $\mathcal{T}$ is the set of required tools or resources:

$$requires\left(EngineRepair\right)=\{\mathrm{T}\mathrm{o}\mathrm{r}\mathrm{q}\mathrm{u}\mathrm{e}\mathrm{W}\mathrm{r}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{h},\mathrm{C}\mathrm{a}\mathrm{l}\mathrm{i}\mathrm{b}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{K}\mathrm{i}\mathrm{t}\}$$

Cross-ontology mappings ensure alignment:

$$f_{TS}:V_{Action}\to V_S, f_{TM}:V_{Action}\to V_M,{ f}_{TB}:V_{Action}\to V_B$$

for example,

$$f_{TS}\left(TurbineBladeReplacement\right)=\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{B}\mathrm{l}\mathrm{a}\mathrm{d}\mathrm{e}$$

$$f_{TM}\left(InspectionAction\right)=\mathrm{V}\mathrm{i}\mathrm{b}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}$$

$$f_{TB}\left(RepairAction\right)=O\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l}\to \mathrm{D}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{e}\mathrm{d}$$

The maintenance ontology provides a mathematically grounded structure for managing tasks, required tools, schedules, and associated costs. Within the digital twin framework, this enables automated planning, traceable history, and data-driven optimization of maintenance activities.

2.4.6. Lifecycle Ontology—Usage History, Upgrades, Documentation

The lifecycle ontology formalizes how an asset evolves across its distinct operational stages and how its usage history, upgrades, and documentation are represented in the digital twin. By linking lifecycle stages with records of utilization, component conditions, and maintenance actions, the ontology provides a rigorous basis for predicting remaining useful life (RUL), planning upgrades, and ensuring compliance with documentation and traceability requirements. Figure 8 illustrates the structure of lifecycle ontology.

Formally, we define the lifecycle ontology as follows:

$$G_L=(V_L,E_L)$$

where

$$V_L=V_{Stage}\cup V_{Usage}\cup V_{Condition}\cup V_{Transition}$$

with $V_{Stage}$—discrete stages in the asset’s life (e.g., Design, Manufacturing, Operational, UnderMaintenance, Decommissioned); $V_{Usage}$—records of asset usage (e.g., flight cycles, operating hours); $V_{Condition}$—health states of components (e.g., Healthy, Degraded, Failed); $V_{Transition}$—events or processes moving the asset from one stage to another.

Edges $E_L$ capture relationships

$$R_L=\{\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{L}\mathrm{i}\mathrm{f}\mathrm{e}\mathrm{c}\mathrm{y}\mathrm{c}\mathrm{l}\mathrm{e}\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{g}\mathrm{e},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{U}\mathrm{s}\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{t}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{T}\mathrm{o},\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{l}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y}\}$$

For example,

$$(\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{L}\mathrm{i}\mathrm{f}\mathrm{e}\mathrm{c}\mathrm{y}\mathrm{c}\mathrm{l}\mathrm{e}\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{g}\mathrm{e})\in E_L$$

$$(\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},\mathrm{U}\mathrm{s}\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d}1000 \mathrm{h},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{U}\mathrm{s}\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d})\in E_L$$

$$(\mathrm{C}\mathrm{o}\mathrm{m}\mathrm{p}\mathrm{r}\mathrm{e}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{r},\mathrm{D}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{e}\mathrm{d},\mathrm{h}\mathrm{a}\mathrm{s}\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n})\in E_L$$

$$(\mathrm{O}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{a}\mathrm{l},\mathrm{U}\mathrm{n}\mathrm{d}\mathrm{e}\mathrm{r}\mathrm{M}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e},\mathrm{t}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{s}\mathrm{T}\mathrm{o})\in E_L$$

$$(\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e},\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}:\mathrm{D}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{e}\mathrm{d},\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{l}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y})\in E_L$$

Attributes refine each class:

$$A_{Stage}:V_{Stage}\to {\mathcal{A}}_{Stage}, A_{Usage}:V_{Usage}\to {\mathcal{A}}_{Usage}$$

$$A_{Condition}:V_{Condition}\to {\mathcal{A}}_{Condition}, A_{Transition}:V_{Transition}\to {\mathcal{A}}_{Transition}$$

with examples:

$${\mathcal{A}}_{Stage}\left(Operational\right)=(\mathrm{S}\mathrm{t}\mathrm{a}\mathrm{r}\mathrm{t}\mathrm{D}\mathrm{a}\mathrm{t}\mathrm{e}=2022-01-01,\mathrm{D}\mathrm{u}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}=3 \mathrm{y}\mathrm{e}\mathrm{a}\mathrm{r}\mathrm{s}),$$

$${\mathcal{A}}_{Usage}\left(UsageRecord1000h\right)=(\mathrm{U}\mathrm{s}\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{T}\mathrm{y}\mathrm{p}\mathrm{e}=\mathrm{F}\mathrm{l}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}\mathrm{H}\mathrm{o}\mathrm{u}\mathrm{r}\mathrm{s},\mathrm{U}\mathrm{s}\mathrm{a}\mathrm{g}\mathrm{e}\mathrm{V}\mathrm{a}\mathrm{l}\mathrm{u}\mathrm{e}=1000,\mathrm{R}\mathrm{e}\mathrm{c}\mathrm{o}\mathrm{r}\mathrm{d}\mathrm{e}\mathrm{d}\mathrm{A}\mathrm{t}=2025-06-01),$$

$${\mathcal{A}}_{Condition}\left(Degraded\right)=(\mathrm{S}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{y}=\mathrm{C}\mathrm{r}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{c}\mathrm{a}\mathrm{l},\mathrm{R}\mathrm{e}\mathrm{m}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{U}\mathrm{s}\mathrm{e}\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{L}\mathrm{i}\mathrm{f}\mathrm{e}=50 \mathrm{c}\mathrm{y}\mathrm{c}\mathrm{l}\mathrm{e}\mathrm{s}),$$

$${\mathcal{A}}_{Transition}(Operational\to UnderMaintenance)=(\mathrm{T}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\mathrm{T}\mathrm{i}\mathrm{m}\mathrm{e}=2025-05-15,\mathrm{T}\mathrm{r}\mathrm{i}\mathrm{g}\mathrm{g}\mathrm{e}\mathrm{r}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y}=\mathrm{S}\mathrm{c}\mathrm{h}\mathrm{e}\mathrm{d}\mathrm{u}\mathrm{l}\mathrm{e}\mathrm{d}\mathrm{M}\mathrm{a}\mathrm{i}\mathrm{n}\mathrm{t}\mathrm{e}\mathrm{n}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e}).$$

These formal elements allow documentation of every upgrade or replacement:

$$\mathrm{L}\mathrm{i}\mathrm{f}\mathrm{e}\mathrm{c}\mathrm{y}\mathrm{c}\mathrm{l}\mathrm{e}\mathrm{T}\mathrm{r}\mathrm{a}\mathrm{n}\mathrm{s}\mathrm{i}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}:\mathrm{D}\mathrm{e}\mathrm{g}\mathrm{r}\mathrm{a}\mathrm{d}\mathrm{e}\mathrm{d}\stackrel{\mathrm{R}\mathrm{e}\mathrm{p}\mathrm{l}\mathrm{a}\mathrm{c}\mathrm{e}\mathrm{m}\mathrm{e}\mathrm{n}\mathrm{t}}{\to }\mathrm{H}\mathrm{e}\mathrm{a}\mathrm{l}\mathrm{t}\mathrm{h}\mathrm{y}$$

capturing not only the new condition but also the associated maintenance record and updated usage attributes.

Cross-ontology mappings support integration:

$$f_{LS}:V_{Stage}\to V_S, f_{LM}:V_{Usage}\to V_M,{ f}_{LB}:V_{Transition}\to V_B$$

for example,

$$f_{LS}\left(Operational\right)=\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e},$$

$$f_{LM}\left(UsageRecord1000h\right)=\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r},$$

$$f_{LB}(Operational\to UnderMaintenance)=\mathrm{C}\mathrm{o}\mathrm{o}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{D}\mathrm{o}\mathrm{w}\mathrm{n}\mathrm{B}\mathrm{e}\mathrm{h}\mathrm{a}\mathrm{v}\mathrm{i}\mathrm{o}\mathrm{r}.$$

The lifecycle ontology provides a mathematically consistent representation of usage history, upgrades, and documentation. It enables the digital twin to track component evolution, forecast remaining useful life, and ensure that maintenance actions and lifecycle records remain aligned with regulatory and operational requirements.

2.4.7. Environmental Ontology—Contextual Conditions (Weather, Runway, Etc.)

The environmental ontology provides a formal representation of external conditions that influence the performance, health, and lifecycle of aircraft components. It models weather, location, and operational environment parameters and links them to behaviors, sensor data, and maintenance actions. By integrating these contextual factors, the digital twin can adjust predictions and recommendations to the actual operating environment rather than relying on nominal assumptions. Figure 9 illustrates the structure of environmental ontology.

Formally, we define the environmental ontology as

$$G_E=(V_E,E_E)$$

where

$$V_E=V_{Condition}\cup V_{Weather}\cup V_{Location}\cup V_{Event}\cup V_{Impact}$$

with $V_{Condition}$—general environmental factors (e.g., Temperature, Humidity, Altitude); $V_{Weather}$—specific weather phenomena (e.g., Rain, Snow, Wind); $V_{Location}$—operational geographies (e.g., Airport, FlightPath); $V_{Event}$—discrete environmental events (e.g., Turbulence, Sandstorm; $V_{Impact}$—effects on asset performance or health (e.g., Overheating, ReducedEfficiency).

Edges $E_E$ capture semantic relationships:

$$R_E=\{\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{s}\mathrm{I}\mathrm{n},\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{l}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y},\mathrm{a}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{c}\mathrm{i}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d}\mathrm{W}\mathrm{i}\mathrm{t}\mathrm{h},\mathrm{c}\mathrm{a}\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{s},\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y}\}$$

For example,

$$(\mathrm{A}\mathrm{i}\mathrm{r}\mathrm{c}\mathrm{r}\mathrm{a}\mathrm{f}\mathrm{t},\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{A}\mathrm{l}\mathrm{t}\mathrm{i}\mathrm{t}\mathrm{u}\mathrm{d}\mathrm{e},\mathrm{o}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{s}\mathrm{I}\mathrm{n})\in E_E$$

$$(\mathrm{E}\mathrm{n}\mathrm{g}\mathrm{i}\mathrm{n}\mathrm{e}\mathrm{P}\mathrm{e}\mathrm{r}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{n}\mathrm{c}\mathrm{e},\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e},\mathrm{i}\mathrm{n}\mathrm{f}\mathrm{l}\mathrm{u}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y})\in E_E$$

$$(\mathrm{T}\mathrm{u}\mathrm{r}\mathrm{b}\mathrm{u}\mathrm{l}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{e},\mathrm{F}\mathrm{l}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}\mathrm{P}\mathrm{a}\mathrm{t}\mathrm{h},\mathrm{a}\mathrm{s}\mathrm{s}\mathrm{o}\mathrm{c}\mathrm{i}\mathrm{a}\mathrm{t}\mathrm{e}\mathrm{d}\mathrm{W}\mathrm{i}\mathrm{t}\mathrm{h})\in E_E$$

$$(\mathrm{H}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{H}\mathrm{u}\mathrm{m}\mathrm{i}\mathrm{d}\mathrm{i}\mathrm{t}\mathrm{y},\mathrm{C}\mathrm{o}\mathrm{r}\mathrm{r}\mathrm{o}\mathrm{s}\mathrm{i}\mathrm{o}\mathrm{n},\mathrm{c}\mathrm{a}\mathrm{u}\mathrm{s}\mathrm{e}\mathrm{s})\in E_E$$

$$(\mathrm{T}\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{e}\mathrm{r}\mathrm{a}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e},\mathrm{T}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r},\mathrm{m}\mathrm{o}\mathrm{n}\mathrm{i}\mathrm{t}\mathrm{o}\mathrm{r}\mathrm{e}\mathrm{d}\mathrm{B}\mathrm{y})\in E_E$$

Cross-ontology mappings support integration:

$$f_{ES}:V_{Condition}\to V_S, f_{EB}:V_{Event}\to V_B,{ f}_{EM}:V_{Condition}\to V_M$$

for example,

$$f_{ES}\left(HighHumidity\right)=\mathrm{W}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{S}\mathrm{t}\mathrm{r}\mathrm{u}\mathrm{c}\mathrm{t}\mathrm{u}\mathrm{r}\mathrm{e},$$

$$f_{EB}\left(Storm\right)=\mathrm{E}\mathrm{m}\mathrm{e}\mathrm{r}\mathrm{g}\mathrm{e}\mathrm{n}\mathrm{c}\mathrm{y}\mathrm{L}\mathrm{a}\mathrm{n}\mathrm{d}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{B}\mathrm{e}\mathrm{h}\mathrm{a}\mathrm{v}\mathrm{i}\mathrm{o}\mathrm{r},$$

$$f_{EM}\left(Temperature\right)=\mathrm{T}\mathrm{h}\mathrm{e}\mathrm{r}\mathrm{m}\mathrm{a}\mathrm{l}\mathrm{S}\mathrm{e}\mathrm{n}\mathrm{s}\mathrm{o}\mathrm{r}.$$

The environmental ontology creates a mathematically consistent framework for contextual conditions, such as weather, runway status, and geography. It enables the digital twin to account for external influences on performance, predict risk factors, and generate maintenance guidance tailored to the actual operating environment.

2.5. Ontology Interactions and Integration Strategy

The seven ontologies are not isolated modules but tightly coupled layers that form a unified semantic foundation for the digital twin. Each ontology defines a domain of entities and relationships, while cross-ontology mappings establish correspondences that enable reasoning across different perspectives.

Let each ontology be represented as a labeled graph

$${\mathcal{O}}_i=(V_i,R_i,E_i,A_i)$$

where $V_i$ is the set of entities, $R_i$ is the relation types, $E_i$ is the set of labeled edges, and $A_i$ is the attribute mappings.

The complete knowledge graph of the digital twin is then

$${\mathcal{O}}_{global}=\bigcup _{i=1}^n{\mathcal{O}}_i\cup C$$

where $C$ is the set of cross-ontology mappings.

Mapping $f_{ij}:V_i\to V_j$ ink entities across ontologies. These mappings ensure that knowledge flows bidirectionally. For example, an anomaly detected in the monitoring ontology propagates through $f_{MT}$ to trigger a maintenance action, which then updates lifecycle records via $f_{TL}$. Conversely, planned maintenance or environmental alerts can inform behavioral predictions through inverse mappings.

Integration is achieved through three main mechanisms:

• All ontologies reference the same unique identifiers for assets, components, and subsystems.
• Cross-ontology mapping functions $f_{ij}$ provide semantic links, enabling queries and reasoning to traverse ontology boundaries.
• The integrated ontology graph supports rule-based and data-driven reasoning.

As illustrated in the preceding subsections, the interaction between ontologies creates a coherent digital representation that aligns physical structure, functional intent, operational behavior, monitoring data, maintenance planning, lifecycle evolution, and environmental context. This integrated strategy allows the digital twin to

• interpret sensor readings in context,
• link anomalies to actionable maintenance tasks,
• propagate updates across lifecycle records,
• adjust recommendations according to environmental conditions.

Through these mathematically defined relationships and mappings, the ontology-based digital twin framework supports explainable, traceable, and adaptive decision making for aircraft maintenance and operation.

The diagram highlights that ontology interactions are not linear but part of a continuous improvement loop. Data, insights, and decisions flow dynamically around the cycle, ensuring that the digital twin remains synchronized with the real asset and capable of providing context-aware, adaptive maintenance and operational recommendations.

Figure 10 illustrates the main stages in the lifecycle of an asset, organized in a circular flow to emphasize their sequential and iterative nature. Beginning with design, the process moves into manufacturing, followed by the operational phase where the asset is in active use. As the asset ages or its condition changes, it enters the maintenance phase, where inspections, repairs, and upgrades are performed to extend service life and ensure compliance with operational requirements. Finally, the cycle reaches the retire stage, in which the asset is decommissioned, recycled, or replaced. This representation underscores that lifecycle management is not a linear process but an ongoing cycle of development, utilization, and refinement.

Within a digital twin framework, each of these lifecycle stages is semantically modeled and linked through dedicated ontologies:

• The structural ontology defines the physical configuration captured during the design and manufacturing stages.
• The functional ontology models the intended roles and processes that emerge from design specifications.
• The behavioral ontology represents operational patterns, transitions, and failure modes during service.
• The monitoring ontology structures sensor data streams and diagnostics that inform both operational and maintenance phases.
• The maintenance ontology captures actions, schedules, and tools applied to sustain or restore performance.
• The lifecycle ontology explicitly tracks the evolution of each component through these stages, including upgrades and usage records.
• The environmental ontology provides contextual information, such as weather, runway conditions, and external stressors that affect performance and health across all stages.

Through these ontologies, the digital twin serves as a knowledge-driven representation of the asset, synchronizing real-time monitoring data with design intent, operational history, and maintenance records

3. Results

The results of this study are presented with a focus on the development and integration of the proposed ontologies, rather than on the performance of any downstream implementation. The objective is to demonstrate that the seven ontological layers: structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental. They collectively constitute a coherent and interoperable knowledge base that can support digital twin applications in aviation.

Each ontology was instantiated for the selected engine subsystem and subjected to logical consistency verification using formal reasoning tools. Cross-ontology mappings were evaluated to ensure semantic alignment and seamless navigation between layers.

3.1. Ontology Metrics and Scope

All seven ontologies were designed to cover complementary aspects of the engine subsystem. They were verified with description-logic reasoning tools, confirming that no unsatisfiable classes or contradictory axioms were present after integration.

The turbofan engine subsystem was chosen as a representative case study for several reasons. First, it is a critical and highly complex system within commercial aircraft, comprising multiple interacting components such as compressors, turbines, and sensor arrays. This complexity enables comprehensive instantiation and testing of all seven ontological layers—structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental. Second, turbofan engines are equipped with dense sensor networks and generate substantial operational data, making them well suited for demonstrating semantic integration and real-time reasoning. Third, due to their safety-critical role and high maintenance cost, they are a natural target for advanced predictive and prescriptive maintenance strategies, where explainability and traceability are essential. These characteristics make the turbofan engine an ideal use case for validating the effectiveness of an ontology-driven digital twin framework in aviation.

Table 1. Qualitative summary of ontology layers and their contents.

Ontology Layer	Main Scope	Key Relation Types	Examples of Concepts and Instances
Structural	Hierarchy of systems, subsystems, components, parts	hasPart, isPartOf, connectedTo	Engine assembly, high-pressure turbine blade, shaft segment
Functional	Functions, capabilities, and operational processes	performsFunction, requires, enables	Thrust generation, power extraction, torque transmission
Behavioral	States, transitions, and failure modes	transitionsTo, triggeredBy, follows	Operational state, degraded state, thermal fatigue mode
Monitoring	Sensors, data streams, thresholds	monitors, measures, reports	Vibration sensor, temperature reading, anomaly signal
Maintenance	Tasks, tools, schedules, and costs	requiresTool, scheduledAt, performedBy	Blade inspection task, replacement action, certified tool
Lifecycle	Stages, records, and documentation	undergoesTransition, recordedIn, updatedBy	Installed state, in-service record, removal event
Environmental	External conditions and their impacts	influences, exposedTo, contextFor	High ambient temperature, dust storm, runway type

summarizes the scope of each ontology, the main categories of concepts they contain, and representative examples of relations and instances. This table demonstrates that each layer is well-defined and semantically distinct, yet compatible with the others through explicitly defined mapping relations.

All of these layers were integrated into a unified knowledge graph (Figure 11), with shared identifiers ensuring that, for example, a specific blade instance in the structural ontology can be directly linked to its functional role, monitored parameters, maintenance history, lifecycle stage, and relevant environmental conditions.

3.2. Cross-Ontology Integration and Validation

The integration process involved creating explicit mappings between ontology layers. For instance, each component in the structural ontology is connected to the sensors that monitor it, the functions it performs, the behavioral states it may enter, and the maintenance actions required. Lifecycle records and environmental factors are likewise linked to the same component instances.

Cross-ontology reasoning was validated through sample queries:

• Traceability checks confirmed that starting from any given component, related functions, monitoring data, and maintenance actions could be retrieved consistently.
• Contextual queries combined environmental and lifecycle data to identify components operating under specific conditions and usage thresholds.
• Verification of mappings ensured that every instance referenced across ontologies resolves to a defined class and is logically coherent.

The results demonstrate that the seven ontologies form a consistent, interoperable semantic foundation. Their integration enables explainable reasoning across structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental perspectives, laying the groundwork for future digital-twin-based applications in aviation maintenance and operations.

3.2.1. Illustrative Case Study: High-Pressure Turbine Blade Scenario

To demonstrate the practical value of the integrated ontology-based digital twin, we consider a representative use case involving a high-pressure turbine (HPT) blade within a turbofan engine subsystem.

The structural ontology identifies the HPT blade as part of the turbine module, linked to a specific engine serial number. The functional ontology associates the blade with the power extraction process and thermal management capabilities. Real-time monitoring ontology data streams include vibration frequency, temperature readings, and thermal cycling patterns from onboard sensors.

Over time, the behavioral ontology detects a deviation from normal operational patterns—an increase in vibration amplitude beyond the defined threshold, which correlates with a possible fatigue initiation. The environmental ontology adds context, indicating that the engine operated under high ambient temperature and dusty runway conditions, increasing the likelihood of erosive wear and thermal degradation.

Using this context, the maintenance ontology triggers a prescriptive recommendation: an inspection task for potential blade cracking, prioritized due to accumulated environmental stressors and detected anomalies. The lifecycle ontology updates the component’s state to “Under Inspection,” recording the action and linking it to the engine’s service history.

This case illustrates how the ontology-driven digital twin enables explainable, traceable, and context-aware decision making by dynamically combining domain knowledge, sensor data, and lifecycle context. It validates the framework’s potential to support intelligent, certifiable maintenance planning in complex aviation environments.

3.2.2. Reasoning Tools and Query-Based Validation

To verify the semantic integration and consistency of the knowledge graph, we employed SPARQL 1.1 queries [74] executed via the Apache Jena Fuseki server [75], with ontologies loaded in OWL 2 DL format [76]. Reasoning tasks were supported using the HermiT 1.3.8. reasoner [77], selected for its compatibility with OWL DL and its support for consistency checking and class subsumption inference.

A representative set of 12 SPARQL queries was developed to validate cross-ontology relations, such as the following:

• “Tracing a specific component from the structural ontology to its associated sensors (monitoring), failure patterns (behavioral), and prescriptive tasks (maintenance)”.
• “Identifying components exposed to extreme environmental conditions and determining whether associated maintenance tasks have been performed within acceptable time thresholds”.
• “Extracting components with a specific lifecycle status and validating alignment with historical maintenance records and environmental exposure”.

Each query was evaluated for correctness, logical consistency, and semantic completeness, based on whether the expected inferred entities, properties, and relations were returned. Consistency checks ensured that no contradictory or unsatisfiable classes were detected following integration. All ontologies were pre-validated using the Protégé ontology editor (ver. 5.6.5) [78] with HermiT integrated as a plugin.

3.3. Mathematical Foundation for Digital Twin Reasoning

The integrated knowledge graph described in Section 3.1 provides not only a qualitative semantic framework but also a formal mathematical basis for implementing reasoning within digital twin models. This foundation enables systematic linking of heterogeneous data sources, semantic interoperability between layers, and explainable reasoning paths.

This knowledge graph be defined as follows:

$$G=(V,E,L)$$

where $V$ is the set of vertices, $E\subseteq V\times V$ is the set of directed semantic edges, and $L:E\to \Sigma$ is a labeling function that assigns each edge a relation type from the label set $\Sigma$.

The node set $V$ is partitioned into seven disjoint subsets, each corresponding to an ontology layer:

$$V=V_s\cup V_F\cup V_B\cup V_M\cup V_T\cup V_L\cup V_E$$

where $V_s,V_F,V_B,V_M,V_T,V_L,V_E$ represent structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental elements, respectively.

Each ontology forms a typed subgraph:

$$G_i=(V_i,E_i,L_i)$$

with internal edges $E_i\subseteq V_i\times V_i$ and labels $L_i:E_i\to {\Sigma }_i$

Semantic integration is achieved through cross-ontology mappings:

$$E_c=\left\{\right(v_p,v_q\left)\right|v_p\in V_i,v_q\in V_j,i\ne j$$

The complete integrated graph is

$$G=\left\{\bigcup _i{V}_i,\bigcup _i{E}_i\cup E_c,L\right\}$$

where

$$L(e)=\left\{\begin{array}{c}{L}_i\left(e\right), e\in E_i,\\ mapping type, e\in E_c.\hfill \end{array}\right.$$

Within a digital twin environment, this knowledge graph becomes the backbone for reasoning tasks such as follows:

• Traceability queries across layers (e.g., from a physical component to its monitoring signals and maintenance tasks),
• Context-aware analytics combining environmental factors, lifecycle states, and behavioral patterns,
• Dynamic updates where new instances or relations are added without breaking logical consistency.

Formally, reasoning corresponds to path queries over $G$

$$q:v_a⇝v_b \mathrm{s}\mathrm{u}\mathrm{c}\mathrm{h} \mathrm{t}\mathrm{h}\mathrm{a}\mathrm{t} (v_a,v_b)\in E^{+}$$

Which means that $v_b$ can be reached from $v_a$ by following a chain of one or more relations, where $E^{+}$ is the transitive closure of the edge set $E$ representing the transitive closure of semantic relations. The notation $v_a⇝v_b$ means there is a chain of semantic relations across one or more ontologies, allowing the digital twin to reason from one concept (component, task, state) to another. This allows a digital twin model to infer new knowledge, detect inconsistencies, or trigger alerts when certain relational patterns appear.

The ontological approach and the integrated knowledge graph described above were applied in the development of broader digital twin models for aviation component management and predictive maintenance. These models integrate sensor data, operational parameters, lifecycle records, and maintenance procedures into a unified semantic environment, enabling explainable and traceable decision support. Detailed examples of such applications can be found in [79,80]. These references illustrate how the developed ontological layers can serve as the semantic backbone for operational digital twin ecosystems, supporting component lifecycle tracking and predictive maintenance strategies.

4. Discussion

4.1. Significance of Ontology-Based Digital Twins in Aviation

The integration of ontologies into digital twin architectures introduces a transformative shift in how aviation maintenance and operations are modeled, interpreted, and optimized. Traditional digital twin systems often focus on numerical simulation, data-driven prediction, or system-level visualization. However, these approaches typically lack explicit semantic representations, resulting in challenges related to transparency, traceability, and rule-based decision making. By embedding domain ontologies into the core of digital twin design, the proposed framework elevates the twin from a passive data mirror to an active semantic reasoning engine.

In the aviation domain, where safety, reliability, and regulatory compliance are paramount, ontology-driven digital twins offer several unique advantages. First, they enable explainable decision making through formal rule-based inference grounded in domain knowledge, allowing stakeholders to trace how sensor observations translate into prescriptive maintenance actions. Second, ontologies support standardization and interoperability across manufacturers, airlines, and regulatory bodies—facilitating knowledge reuse and harmonization of maintenance strategies. Third, the use of modular ontologies (e.g., for structure, behavior, lifecycle) allows scalable deployment of digital twins at different system levels, from individual components (e.g., turbine disks) to entire aircraft fleets.

Furthermore, the explicit modeling of concepts such as degradation behavior, maintenance history, environmental exposure, and remaining useful life provides a comprehensive and integrative view of the asset’s health state. This capability is crucial for predictive and prescriptive maintenance under tight operational constraints, particularly in modern aviation ecosystems that demand real-time responsiveness and minimal aircraft downtime.

Ontology-based digital twins represent a powerful step toward cognitive maintenance systems in aviation—blending formal knowledge engineering, mathematical inference, and real-time data integration to support intelligent, adaptive, and trustworthy operations.

4.2. Comparison with Traditional Data-Driven Approaches

Traditional digital twin implementations in aviation have largely been driven by statistical modeling, machine learning (ML), or physics-based simulations, focusing on numerical predictions of system behavior or failure likelihood. While effective in many scenarios, these approaches often operate as black boxes, with limited explainability, poor generalizability across systems, and weak support for logical reasoning or compliance verification. In contrast, the ontology-based digital twin framework introduced in this paper emphasizes semantic transparency, domain interpretability, and logical traceability.

One of the key limitations of conventional ML-based systems is their dependence on large, labeled datasets and their brittleness in the face of sensor drift, rare failure events, or novel configurations. These models are often trained on specific aircraft or operational conditions and lack transferability. By contrast, ontologies offer a domain-agnostic knowledge representation that can generalize across systems.

Data-driven models are typically focused on correlation-based predictions (e.g., a rise in vibration implies failure risk), while ontological reasoning enables causal and rule-based inference, such as deducing specific maintenance tasks based on regulatory thresholds, component interactions, or operational conditions. This is especially valuable in aviation where regulatory and procedural constraints are non-negotiable and must be codified into the decision engine itself.

Another important difference is in the auditability and certification potential. Ontology-driven decisions are inherently explainable—every inference can be linked to a rule, class, or property in the TBox and a set of observed facts in the ABox. This transparency is essential for aircraft certification, maintenance traceability, and safety case documentation—areas where data-driven systems still face resistance due to their opacity.

While data-driven approaches provide powerful tools for pattern recognition and forecasting, they are often insufficient as standalone systems in mission-critical domains like aviation. Ontology-based digital twins do not replace these models but instead offer a complementary and integrative layer that enhances semantic coherence, system reliability, and human trust in automated maintenance intelligence.

4.3. Comparison with Other Approaches

The integration of ontologies into digital twin architectures represents a fundamental advancement over more conventional approaches that rely solely on numerical models or data-driven techniques. To contextualize the contribution of the proposed framework, it is important to compare it with two commonly used categories: (1) digital twins without ontologies, and (2) machine learning-based systems without semantic reasoning.

• Digital Twins Without Ontologies.

Many existing DT implementations in aviation and other domains focus on mirroring the physical system using real-time sensor data, physical simulation models (e.g., finite element analysis, thermodynamic simulations), and rule-based automation. These systems excel at visualization, state tracking, and predictive analytics based on domain-specific physics or regression models. However, such DTs typically lack an explicit semantic layer to define what the data represent, how components relate, or what constitutes a valid or invalid state transition.

Without ontologies, the knowledge embedded in these DTs is often implicit, hard-coded, and domain-specific, making it difficult to generalize or validate. There is no clear distinction between domain knowledge and system state, which limits interoperability, explainability, and maintainability. For example, a traditional DT might simulate a turbine’s thermal stress distribution but cannot explicitly infer that a given stress pattern violates a manufacturer-defined limit unless manually programmed.

By contrast, the ontology-based DT framework proposed in this study provides a declarative, modular, and formally interpretable knowledge base, enabling both automatic reasoning and semantic traceability. It decouples structural knowledge from operational data, allowing multiple use cases (e.g., diagnostics, lifecycle tracking, maintenance planning) to operate over a common, reusable ontological core.

2.

Machine Learning-Based Systems Without Semantic Reasoning.

A second class of systems applies data-driven ML models such as support vector machines, random forests, or deep neural networks to predict component failures or optimize maintenance schedules. These systems are capable of handling high-dimensional, noisy, and nonlinear data streams, and they have shown strong performance in anomaly detection and RUL estimation tasks.

However, ML-based systems typically lack semantic grounding, meaning they cannot explain why a certain prediction was made, how it relates to domain rules, or what constraints might override the learned outcome. This black-box nature significantly limits their applicability in regulated domains like aviation, where transparency, traceability, and logical consistency are essential. Moreover, ML models are highly sensitive to training data distributions and may generalize poorly across aircraft types or configurations.

In contrast, the ontology-driven DT formalism proposed here supports explainable inference, rule validation, and regulatory alignment—capabilities that are difficult to achieve with ML models alone. Ontologies can also act as a semantic scaffold for hybrid systems, guiding data labeling, augmenting features, and enforcing consistency in ML pipelines. While this framework does not preclude the use of machine learning, it emphasizes that semantic reasoning is necessary to achieve robust, trustworthy, and certifiable maintenance intelligence.

4.4. Limitations and Future Enhancements

While the proposed ontology-driven digital twin framework introduces a robust and mathematically grounded approach to aviation maintenance and operations, it is not without limitations. These limitations primarily arise from the complexity of ontology engineering, the challenges of real-time integration, and the computational overhead associated with semantic reasoning at scale.

First, the development and validation of high-quality domain ontologies require substantial expert involvement, formal modeling expertise, and domain-specific knowledge elicitation. Although reuse of upper and modular ontologies (e.g., for sensors, components, behavior) can reduce this burden, tailoring ontologies to reflect airline-specific procedures or aircraft configurations remains a labor-intensive process. Moreover, aligning and maintaining consistency across multiple ontologies—particularly in distributed environments—poses semantic drift risks if not governed by strict version control and alignment strategies.

Second, real-time semantic reasoning remains a computational bottleneck, particularly when using expressive description logics profiles that go beyond tractable fragments. Although incremental reasoning, modularization, and rule-based approximation methods offer potential solutions, achieving low-latency, high-frequency inference across large fleets and high-dimensional sensor streams remains an area for future optimization.

Third, while the framework supports integration of predictive and prescriptive logic, it does not yet incorporate learning-based adaptation or feedback-driven model evolution. For example, updates to the ontological models based on observed failures or maintenance effectiveness are not yet formalized. Future work could integrate reinforcement learning or federated learning into the digital twin’s reasoning pipeline, enabling adaptive ontology enrichment and data-driven rule refinement.

From a deployment perspective, interoperability with legacy aircraft systems, conformance with certification frameworks and cybersecurity implications of ontology-driven decision automation are all open areas for research and standardization. Furthermore, scaling the approach from subsystem-level twins to aircraft-wide or fleet-wide digital twins introduces new challenges in ontology federation, provenance tracking, and cross-domain knowledge integration.

While the ontology-driven approach significantly enhances the explainability, modularity, and reasoning capabilities of digital twin systems in aviation, further work is needed to optimize its performance, adaptability, and operational scalability. These enhancements will be crucial for the broader adoption of semantic digital twins in future intelligent aviation ecosystems.

4.5. Future Directions of Research

The ontology-driven DT framework outlined in this paper sets the foundation for a new generation of explainable, interoperable, and mathematically grounded aviation maintenance systems. However, there are multiple promising avenues for extending this work both theoretically and practically.

First, future research should focus on the automation of ontology generation and maintenance. While manual ontology engineering remains a bottleneck, advances in natural language processing, knowledge extraction, and ontology learning from structured/unstructured data can facilitate the dynamic creation and updating of ontologies directly from technical documentation, maintenance logs, and regulatory bulletins. This will reduce development time and enable continuous evolution of semantic models in line with operational practices.

Second, the integration of learning-based reasoning with ontological inference presents an exciting hybrid paradigm. Techniques such as neuro-symbolic integration, reinforcement learning guided by ontological constraints, and federated learning over distributed aircraft twins can enhance adaptability while preserving explainability. These models could allow digital twins to evolve their inference capabilities in response to observed effectiveness of maintenance actions or emerging patterns not originally encoded in the knowledge base.

Third, extending the framework toward multi-scale and federated digital twins is a critical future step. While the current implementation focuses on subsystem-level twins (e.g., engine components), real-world deployment will require integration of fleet-wide ontologies, airport-level environmental knowledge, and inter-organizational alignment (e.g., across OEMs, MROs, and operators). This calls for ontology federation, versioning, and distributed consistency reasoning mechanisms.

Fourth, future work should develop semantic feedback loops that connect the outcomes of maintenance actions to ontology updates. This would allow the DT system to not only prescribe actions but also evaluate their long-term effectiveness and refine its internal models, creating a closed-loop intelligent maintenance system with memory and adaptation.

Developing benchmark datasets and shared ontological repositories will accelerate academic and industrial collaboration. Open, modular ontologies for aircraft systems, sensor semantics, and operational procedures backed by simulation environments or anonymized maintenance logs can serve as testbeds for reproducible research and cross-validation of reasoning models.

5. Conclusions

This paper presents a comprehensive ontology-driven digital twin framework specifically designed for aviation maintenance and operations, addressing the critical need for explainable, traceable, and semantically grounded decision support systems in the aerospace industry. The research establishes a mathematically rigorous foundation for integrating domain knowledge with real-time operational data through seven interconnected ontologies: structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental.

The key contributions of this work include the development of a formal mathematical framework based on description logics and graph theory that enables consistent semantic representation across multiple perspectives of aircraft systems. The proposed architecture transforms traditional digital twins from passive data mirrors into active semantic reasoning engines capable of providing explainable maintenance recommendations while maintaining full traceability from sensor observations to operational decisions.

The seven-layer ontological structure demonstrates several significant advantages over conventional approaches. First, it provides explicit semantic representation that enhances transparency and explainability—critical requirements for aviation applications where regulatory compliance and safety certification are paramount. Second, the modular design enables scalable deployment across different system levels, from individual components to entire aircraft fleets, while supporting knowledge reuse and standardization across manufacturers, airlines, and regulatory bodies. Third, the integration of cross-ontology mappings creates a unified knowledge graph that supports complex reasoning tasks, including anomaly detection, failure prediction, and prescriptive maintenance planning.

The mathematical formalization of the digital twin provides a clear computational framework for implementing semantic transformation engines that process heterogeneous data sources while maintaining logical consistency. The distinction between terminological boxes (TBox) for domain knowledge and assertional boxes (ABox) for real-time facts enables dynamic updates while preserving semantic integrity.

Validation results confirm that the integrated ontology layers form a consistent, interoperable semantic foundation capable of supporting complex queries across structural, functional, behavioral, monitoring, maintenance, lifecycle, and environmental perspectives. The framework successfully addresses the limitations of traditional data-driven approaches by providing causal reasoning capabilities, regulatory compliance support, and explainable decision pathways essential for mission-critical aviation applications.

The ontology-driven digital twin framework presented in this paper represents an advancement toward cognitive maintenance systems in aviation, providing a robust foundation for intelligent, adaptive, and trustworthy operations. By combining formal knowledge engineering with mathematical inference and real-time data integration, this approach establishes the basis for next-generation maintenance intelligence systems that can meet the demanding requirements of modern aviation ecosystems while ensuring safety, efficiency, and regulatory compliance.