Abstract
Sustaining complex engineered systems over decades is not only a data-integration challenge, but a semantic one: upgrade decisions require coherent reasoning across configuration identity, degradation and failure behaviour, temporal evolution, and decision rationale—yet these dimensions are typically modelled in separate tools, with incompatible assumptions about “what a system is over time.” Existing document-centric approaches and many model-based systems engineering/PLM implementations can store artefacts and trace links, but they do not provide the ontological constructs needed to infer, compare, and justify upgrade trajectories (e.g. how a sequence of baselines across epochs produces capability effects under constraints). This paper, therefore, analyses system upgradability as an ontological problem and derives the System Upgrade Ontology (SUO) as a federated semantic solution. SUO operationalises upgradability as a property of configuration trajectories (not isolated components), grounded in rigorous upper-ontology commitments and aligned to enterprise architecture meta-frameworks. It integrates (1) stable representations of system identity and configuration change, (2) imported maintenance/Prognostics and Health Management semantics for degradation and failure, (3) epoch–era temporal structures for long-horizon evolution, and (4) multi-criteria decision factors that make upgrade trade-offs explicit and auditable. A naval combat system case study demonstrates SUO’s explanatory power by showing which upgrade implications are not expressible in operational logistics records alone, and how SUO enables repeatable reasoning over alternative upgrade paths and their multidimensional impacts across service eras.
1. Introduction: the imperative of a capability sustainment ontology
Sustaining complex, engineered systems throughout their operational lives presents a profound challenge. Traditional, document-centric approaches, where information is siloed in disconnected data repositories and exchanged via static files, struggle with fundamental issues of data consistency, traceability, and automated reasoning. 1 This fragmented information landscape leads to inefficiencies, increased maintenance costs, and significant risks to operational readiness. The complexity is particularly acute for modern, heterogeneous systems such as aircraft, industrial smart factories, smart transportation systems, modern medicine, and defence platforms such as naval vessels, which are composed of hundreds of thousands of interconnected components, often supplied from numerous enterprises, and whose performance depends on a continuous flow of materials and data from design to disposal. Similar challenges have been observed in network-centric military environments, where ontologies have been used to integrate heterogeneous data sources and support dynamic replanning and situational awareness across distributed systems. 2 In response to these challenges, systems engineering (SE) has evolved from traditional, document-based methods to model-based systems engineering (MBSE). MBSE provides a step forward by formalising system architectures through models that support requirements elicitation, design, and development. 3 However, MBSE alone does not solve the core problem of semantic ambiguity. This limitation is consistent with findings in digital engineering research, which indicate that traditional MBSE approaches are not sufficiently broad to support lifecycle-wide integration of models, data, and decision-making, motivating a shift towards model-centric and digital engineering paradigms.4,5 Different stakeholders, from the customer to design engineers, maintenance crews, and operational personnel, often use different modelling languages and terminologies to describe the same system, leading to “heterogeneous modelling languages” and “discrepancies among data structures” that make information exchange difficult [1]. Even within a single enterprise, these variations can result in significant information deviations when connecting data flows across the system’s lifecycle.3,6 This paper argues that a central barrier to rigorous upgrade planning is ontological. Similar challenges have been addressed in ontology-based data fusion systems, where structured semantic models enable the integration and transformation of information from multiple sources into higher-level, decision-relevant representations. 7 The result is that organisations can store and trace upgrade information, but cannot compute over it coherently: for example they cannot consistently infer how a specific configuration state, degraded subsystem behaviour, and decision constraints jointly determine the viability and impact of an upgrade in a future epoch. The next logical evolution is then the adoption of formal ontologies for sustainment.
As a form of semantic technology, an ontology provides a “common, often formal, language” with “rigorously scrutinized” definitions for knowledge representation.
6
It is a conceptual model that defines the concepts, relationships, and properties within a specific domain, serving as a structured and standardised vocabulary.8,9 By providing a shared understanding of a domain, ontologies address the limitations of MBSE by enabling true “semantic interoperability,” which allows for the seamless integration and reuse of information from various modelling tools.
10
Ontology-based frameworks, such as the system entity structure (SES), have demonstrated how structured semantic representations can support information exchange, interoperability, and tailored data extraction in networked environments.
7
Within digital engineering environments, semantic technologies are recognised as key enablers for ensuring consistency, enabling data reconciliation across tools, and supporting computer-augmented decision-making across stakeholders.
4
Furthermore, the formal, logic-based structure of an ontology facilitates “automated reasoning” and “explicit representation” of complex systems, providing the basis for intelligent, data-driven decisions.
10
Accordingly, the research question this paper addresses is as follows, What ontological commitments and semantic constructs are necessary to reason coherently about system upgradability across configuration change, degradation behaviour, temporal evolution, and decision rationale—such that alternative upgrade trajectories can be compared, justified, and audited over decades of service?
To answer this, the paper analyses upgradability as a lifecycle-spanning semantic integration problem and derives the System Upgrade Ontology (SUO) as a federated ontology architecture. SUO is an architecture that integrates data and knowledge across an asset’s entire lifecycle, from the identification of the current and future relevant stakeholders, through requirements analysis, design and manufacturing, to operations, maintenance, and eventual disposal, to ensure its continued operational effectiveness.
The remainder of this paper is structured as follows: Section 2 reviews foundational and domain-specific ontologies relevant to capability sustainment; Section 3 presents the proposed SUO and its architectural components; Section 4 demonstrates the application of SUO through an ANZAC-class frigate case study; and Section 5 concludes the paper with key findings and future directions.
2. Background on foundational ontologies
The development of robust, domain-specific ontologies for capability sustainment is predicated on a shared, underlying formal foundation. This foundational layer provides the essential conceptual framework and semantic alignment necessary for disparate systems to interoperate over the entire system’s lifecycle. Two prominent foundational ontologies stand out in the literature: the Basic Formal Ontology (BFO) 11 and the International Defence Enterprise Architecture Specification (IDEAS). 12
BFO serves as a top-level, domain-neutral framework, providing a core set of terms and relationships that can be extended by application-specific ontologies.8,9,11 BFO’s purpose is to ensure that domain ontologies, regardless of their specific focus, are conceptually consistent and semantically aligned with a rigorous, high-level structure. Its primary distinction is between continuants and occurrents.8,9,11 A continuant is defined as an entity that “persists through time while maintaining its identity,” such as a physical object or a quality. An occurrent is an entity that “happens, unfolds, or develops through time,” such as a process or an event.8,9 This simple but powerful distinction is crucial for modelling a system’s lifecycle, as it provides a formal way to separate the physical parts of a system from the processes, states, and events that happen to them. Many of the domain ontologies discussed later in this paper, including the Ontology Model for Maintenance Strategy Selection and Assessment (OMSSA) and those developed by the Industrial Ontology Foundry (IOF), explicitly align with or import concepts from BFO to ensure their reusability and integration within a broader semantic network.8,9 IDEAS serves as another critical formal foundation, specifically for the defence and enterprise SE domains. 12 IDEAS was developed by a consortium of defence departments from the United States, the United Kingdom, Canada, Australia, and Sweden. The DM2, the meta-model of the DoD Architecture Framework (DoDAF), is explicitly founded on IDEAS. The significance of IDEAS lies in its advanced mathematical underpinnings, particularly its use of “type (or set) theory” and “4D mereotopology.” 12 The application of these mathematical principles is not an academic exercise but a deliberate design choice to solve fundamental problems in capability sustainment. The concept of “4D spatial-temporal extent” means that every object is represented as an entity that exists in space and time. This allows the ontology to track an asset’s identity with precision over time, which is essential for managing its evolving state and configuration. For example, comparing the similarity of two objects can be grounded in whether they occupy the “precisely the same space at the same time.” 12 The methodology also separates names from the “things” they represent, eliminating potential confusion. A particularly sophisticated feature of the IDEAS foundation is its use of powertypes. A powertype is a type whose members are all the possible subsets of the members of another type. This enables the creation of “multiple categorization schemes or taxonomies” based on the same underlying set of individuals. 12 For a large enterprise like the Department of Defence, where different functions require different views of the same asset, this is a core requirement. A logistician, for instance, may categorise a component by its mass and dimension, while a weaponeer may classify the same component by its lethality and means of delivery. The powertype construct ensures that these different, context-dependent perspectives can exist and be reconciled because they both trace back to the same four-dimensional individuals. This formal structure provides the “mathematical rigor needed for precise architectural descriptions” that can be used for detailed SE and operations planning. It is this deep-rooted capability for temporal reasoning and multi-perspectival representation that makes a framework like IDEAS a powerful foundation for managing the complexity of long-term capability sustainment.
2.1. Literature review on the ontological landscape of sustainment
The field of capability sustainment is an amalgamation of specialised domains, each with its own set of ontologies and standards. A review of the literature reveals several key initiatives that, while distinct, share a common goal of providing semantic rigour for data and knowledge management.
Maintenance, as a core component of sustainment, has been a significant area of focus for ontology development. The IOF is a key organisation, working on an open suite of ontologies for manufacturing and engineering domains. 13 The IOF Maintenance Working Group has adopted a “bottom-up” approach, developing a minimal reference ontology (IOF-MAINT) based on real-world use cases in asset reliability, failure analysis, and maintenance management. 13 This ontology is aligned with IOF Core and BFO and contains a core set of concepts identified as common across various maintenance application ontologies. Key classes include the following: 13
degraded state,
disposition to exhibit undesirable behaviour,
failed state,
failure effect,
failure event,
failure mode code,
maintenance activity,
maintenance process,
maintenance strategy, and
maintenance work order record.
Another notable effort is the OMSSA. 14 OMSSA was developed to facilitate the complex task of selecting and assessing maintenance strategies (e.g. corrective vs predictive) by providing a formal terminology framework. It retrieves information from multiple sources, such as Failure Mode, Effects and Criticality Analysis (FMECA) and cost–benefit–risk analyses, to assist in decision-making. 14 Like the IOF ontology, OMSSA is built on the BFO to ensure its reusability and integration with other industrial ontologies. Ontologies also play a critical role in Prognostics and Health Management (PHM), a discipline focused on predicting failures before they occur.8,9 The development of PHM systems for complex equipment like spacecraft avionics and industrial production systems has been significantly enhanced by ontology-based approaches. Ontologies provide a standardised vocabulary for concepts like failure modes, effects, and criticality, allowing engineers to query the system with hardware or software entities to obtain failure information. These ontologies support a shift from traditional document-based system engineering to a semantic-based approach that addresses the challenges of heterogeneous data and enables the integration of structured and unstructured information.
A foundational standard for product data exchange is ISO 10303-239 (PLCS), which defines a generic information model to support a product throughout its life. 15 PLCS is one of the standards in the STEP (STandard for the Exchange of Product model data) family and is specified using the EXPRESS information modelling language. 15 To manage its broad scope and provide application-specific precision, PLCS uses a concept called Data Exchange Specifications (DEXs) and Reference Data Libraries (RDLs). Crucially, PLCS leverages the W3C Web Ontology Language (OWL) to define and manage its standardised RDLs. OWL provides the “semantic precision” needed to classify and refine the generic constructs of the PLCS model, such as defining a “safety-critical part” by adding a classification to a basic part construct. Each RDL becomes an OWL ontology in its own right, which can import other ontologies and be extended by organisations with their own specific subclasses. This use of OWL demonstrates a key strategy: leveraging a semantic web standard to add a layer of meaning on top of a legacy data exchange standard. This transformation from legacy formats to semantic models is also the focus of the National Institute of Standards and Technology (NIST) OntoSTEP project. 16 OntoSTEP is an open-source software that automates the conversion of STEP schemas (EXPRESS) and instance files (P21) into OWL files. This is significant because, as the literature notes, manually converting STEP models to ontologies is “time-consuming and prone to misunderstandings.” 16 OntoSTEP enables logical reasoning and inference mechanisms on legacy Computer Aided Design(CAD) 16 models by translating them into semantically enriched OWL-DL models, thereby building a crucial link in the “digital thread” of a product’s lifecycle.
The concept of a Digital Twin, a virtual representation of a physical asset, is a central theme in modern manufacturing and sustainment. The Asset Administration Shell (AAS) provides a standardised and machine-readable “self-description” of an asset, acting as a central component for implementing digital twins in the context of Industry 4.0. 17 The AAS is divided into modular “submodels,” which represent specific aspects of a product or system, such as a “digital nameplate.” 17 This standardised structure and use of interfaces promote interoperability and data exchange between different stakeholders and IT systems along the value chain. Platforms like Microsoft’s Azure Digital Twins also rely on an ontological approach, using the Digital Twins Definition Language (DTDL) to define the types of entities and their relationships. 18 These ontologies, which can be custom-authored or converted from other standards like Resource Description Framework (RDF) or OWL, provide a common vocabulary that enables “seamless integration between different partners and vendors.” 18
Logistics and supply chain management are inherently complex, involving multiple stakeholders and a vast amount of data, and this complexity increases in systems with long life cycles. The Supply Chain Operations Reference (SCOR) model, developed by the Association for Supply Chain Management (ASCM), provides a universally accepted framework for describing supply chain processes. 19 The model’s core processes, Plan, Source, Make, Deliver, and Return, offer a high-level blueprint for business process engineering and performance measurement. While the SCOR model is widely used, a review of the logistics ontology landscape reveals significant challenges. Many existing ontologies, particularly domain-specific ones, “fail to address aspects related to internal logistics and sustainability.” 19 Furthermore, there is an absence of a clear standard for representing physical resources in detail and a lack of effort to integrate existing ontologies. This fragmentation and limited scope demonstrate a critical gap that prevents a seamless ontological model for end-to-end sustainment.
Overall, the literature shows that capability sustainment is supported by a wide array of ontologies covering maintenance, PHM, product lifecycle data, digital twins, and logistics, but these remain largely domain-specific and poorly integrated. Mature efforts such as IOF-MAINT, OMSSA, and PHM ontologies provide clear semantics for failure behaviour and maintenance reasoning, while PLCS and OntoSTEP help translate legacy engineering data into machine-interpretable OWL models. Digital Twin frameworks (AAS, DTDL) reinforce the trend towards semantic self-description of assets, but they vary widely in modelling choices and are more technology-driven than conceptually harmonised. In contrast, logistics ontologies are still fragmented and lack consistent representations of physical resources, internal logistics, and sustainability. The collective picture is one of semantic richness but structural fragmentation, where each initiative solves local problems but no shared framework spans the full sustainment lifecycle. This gap highlights the need for an integrating ontology capable of aligning concepts across maintenance, lifecycle engineering, digital twins, and logistics to support coherent digital threads and truly end-to-end capability sustainment.
2.2. Architecting the capability sustainment ontology: a unified framework and conceptual model
The literature review demonstrates that a holistic capability sustainment ontology cannot be a single, monolithic artefact. Rather, it must be a federated, multi-layered architecture that intelligently integrates disparate standards and ontologies to create a unified framework. The DoDAF meta-model (DM2) provides a compelling blueprint for this architecture.
The DM2 is a top-down, enterprise-level framework for architectural descriptions within the Department of Defence. 12 Its ontological foundation in IDEAS provides the semantic rigour necessary to model high-level concepts and their complex relationships.12,20 The DM2 explicitly models capability as a “subtype of property,” linking it to the tasks performed to achieve that capability. 12 This provides a structured, top-down view that can be instantiated with more granular, bottom-up data. The strength of the DM2 framework lies in its ability to reconcile the fundamental tension between a standardised enterprise view and the diversity of domain-specific needs. The analysis of the various ontologies reveals a clear distinction,
The solution to this apparent contradiction is to view these as complementary, not competing, approaches. The DM2’s ability to support “multiple categorization schemes or taxonomies” through the use of powertypes is a formal mechanism to handle this very challenge. It allows a large enterprise (defence as well as non-defence) to define its overall capabilities using the DM2 as the organising principle, and then seamlessly integrate detailed, pre-built domain ontologies for maintenance, logistics, and supply chain without having to re-engineer them from scratch. This intelligent integration facilitates interoperability, knowledge reuse, and scalability across the enterprise.
The following conceptual model illustrates a multi-layered, federated architecture for a capability sustainment ontology. This model is based on the synthesis of the reviewed literature and provides a clear pathway for implementation.
3. SUO: a comprehensive and formalised model for sustainment
This section defines a proposed ontology for naval capability sustainment, incorporating recommendations from the literature review to enhance its rigour, scope, and applicability. As shown in Table 1, this ontology is formally aligned with a top-level framework, such as the Basic Formal Ontology (BFO) 21 and IDEAS. 20 This alignment provides a robust, domain-neutral foundation that distinguishes between continuants (physical things like a Ship) and occurrents (processes that happen over time, like an Upgrade or MaintenanceWindow). This approach enhances interoperability and enables advanced temporal reasoning, a core requirement for managing a system’s lifecycle.
SUO foundational alignment.
To provide coherence across the diverse elements of the SUO, the ontology’s categories can be organised into a set of seven mega-types—high-level conceptual groupings that clarify the role and ontological nature of each class (Table 2). The Framework and Meta-Level Constructs acknowledge the imported ontological foundations (BFO, IDEAS, DM2) and category labels that shape the SUO’s structure. Collectively, these seven mega-types provide a clean, scalable organisational scheme that clarifies the purpose of each ontology class, improves conceptual consistency, and supports robust reasoning across the full spectrum of naval capability sustainment and upgradability.
IDEAS mega-types illustrated using SUO ontological elements.
The SUO spans multiple layers of the four-layer architecture. It does not operate at the foundational level, since it relies on upper ontologies such as BFO or IDEAS for basic categories, but it builds directly on top of them. At the meta-framework level (layer 2), the SUO-Core functions as an enterprise-wide schema for sustainment, defining high-level concepts such as sustainment capabilities, support relationships, lifecycle structures, and readiness measures, similar in role to DoDAF DM2, but focused specifically on sustainment. At the domain level (layer 3), the various SUO modules, covering maintenance, logistics, PHM, digital twins, upgradability, and supply chain processes, provide the detailed, application-specific vocabularies needed for modelling each aspect of sustainment. Finally, SUO governs the instantiation of real data in layer 4, where fleet records, sensor readings, maintenance events, and system configurations populate the ontology as individuals. In this way, SUO bridges the abstract architectural layer and the practical operational layer, providing both a unifying framework and a set of domain ontologies grounded in a common semantic foundation.
3.1. Core SUO
System upgradability is not captured by any single lifecycle activity (e.g. maintenance, modification, or obsolescence management). Instead, it emerges from the interaction of system identity, configuration state, temporal context, and decision constraints across long service lives. Existing lifecycle data sources, such as MBSE models, logistics records, maintenance databases, and PHM systems, each encode partial views of this problem but make incompatible assumptions about what persists and what changes when a system is upgraded. For example, logistics systems track replaceable items and work orders; MBSE models represent structural decomposition; PHM models describe degradation processes; and decision frameworks assess cost, risk, and performance. However, none of these representations provides an explicit semantic mechanism to reason about configuration trajectories—that is, how a sequence of configuration states across epochs produces cumulative capability effects and constrains future upgrade options. This gap motivates the definition of a core SUO layer that establishes shared ontological commitments before domain-specific extensions are applied.
The core physical layer of the SUO establishes the foundational representation of all tangible and configuration-defining elements of a system, forming the essential backbone for modelling upgradability and lifecycle sustainment (See Table 3). Its objective is to capture, in a semantically precise and interoperable manner, the system, its subsystems, configuration items, interfaces, and associated baselines so that every physical and logical component of the platform can be consistently identified, related, and traced across decades of service. The scope of this layer spans from high-level platform structure (e.g. the naval vessel and its major subsystems) down to individual hardware and software elements governed by configuration management, as well as the connections and approved configurations that define how these elements function together at any point in time. By formalising this domain, the core physical SUO provides the stable semantic anchor required for evaluating upgrade impacts, managing configuration evolution, integrating multi-source engineering data, and ensuring traceability across complex refit and modernisation cycles. Its importance lies in enabling accurate reasoning about how changes propagate through the vessel’s architecture, supporting more reliable upgrade planning, reducing integration risk, and establishing a common vocabulary that aligns system designers, maintainers, operators, and decision-makers throughout the system’s lifecycle.
SUO-core physical module class/properties and its submodules.
Furthermore, a fundamental ontological challenge in upgrade reasoning is distinguishing system identity from system configuration. In practice, a system may undergo extensive physical, software, and functional changes while remaining the “same” asset for ownership, certification, and operational purposes. Most engineering data models conflate these notions implicitly, leading to ambiguity when comparing pre- and post-upgrade states. SUO treats system as a persistent continuant whose configuration states are temporally indexed realisations. Configuration changes do not create new systems; instead, they generate new configuration states that participate in an ordered trajectory. This commitment enables reasoning such as
comparing capability before and after a specific upgrade;
identifying when accumulated changes constitute a functional divergence; and
and determining whether two baselines are compatible with a proposed future upgrade.
These core physical entities establish the structural basis for configuration representation; they also raise a fundamental semantic question: how system identity is preserved as configurations change over time. Without an explicit distinction between the enduring system and its evolving configurations, upgrade reasoning becomes ambiguous, particularly when comparing baselines across long service lives.
Maintenance and PHM ontologies typically focus on failure modes, degradation mechanisms, and maintenance actions. Still, they do not explicitly connect these behaviours to evolving configuration states in a way that supports long-horizon planning. SUO integrates degradation and failure semantics by linking behavioural processes (imported from maintenance and PHM ontologies) to the configuration states in which they manifest. Degradation is, therefore, not treated as an abstract property of a component class, but as a state-dependent behaviour that influences upgrade feasibility, timing, and effectiveness. This separation allows SUO to answer questions such as,
Whether a degradation trend invalidates a future upgrade path?
How condition-based constraints alter the value of competing upgrade options?
A brief description of the key core physical entities of SUO is as follows: System, Subsystem, ConfigurationItem (CI), Interface, and Baseline form the foundational layer for representing the structure and configuration of a system across its lifecycle. The System represents the overall platform as a long-lived, upgradeable asset, while Subsystems capture its major functional divisions such as propulsion, combat systems, and communications. ConfigurationItems provide the granularity needed to track hardware and software elements under configuration control, enabling precise management of change, obsolescence, and logistics. Interfaces describe the physical or logical connections between CIs and subsystems, making integration impacts visible during upgrade planning. Finally, the Baseline defines the approved configuration at a particular point in time, ensuring traceability as the system evolves.
Upgrade decisions are often justified using narrative arguments, spreadsheets, or one-off analyses. While results may be stored, the reasoning structure—trade-offs, assumptions, constraints, and stakeholder priorities—is rarely preserved in a machine-interpretable form. SUO models UpgradeDecisionFactors as explicit entities linked to configuration states and trajectories. These factors include cost, risk, performance impact, schedule, certification burden, and strategic constraints. Decisions are, therefore, represented as reasoned selections among alternatives, rather than as isolated events. This enables auditability, comparison of alternative decisions, and reuse of rationale when similar upgrade contexts recur.
3.2. SUO-PHM and maintenance concepts
Most engineering and logistics systems represent time implicitly through timestamps, version identifiers, or baseline dates. While sufficient for audit and traceability, such representations are inadequate for reasoning about system upgradability across long service lives. Timestamps indicate when a change occurred, but not why it occurred, under what contextual assumptions, or how long those assumptions remain valid. In upgrade planning, the relevant temporal question is rarely “what happened at time t?” but rather “under which operational, technological, and regulatory conditions was this configuration valid?” and “how do those conditions differ from the present or future?” Without explicitly modelling these contextual regimes, comparisons between past, current, and proposed configurations risk semantic inconsistency. The PHM and maintenance concepts within the SUO provide the semantic framework necessary for representing the health status, degradation, and failure behaviour of systems, enabling data-driven sustainment and upgrade decision-making (Table 4). These ontologies are directly imported from IOF and other industrial maintenance ontologies. 13 Their objective is to capture how configuration items operate, degrade, and fail over time through well-defined states and events, such as functioning, degraded, failed, and specific failure modes, so that maintenance actions and prognostic insights can be accurately linked to the physical and operational realities of the vessel. The scope of this component extends from real-time condition monitoring and diagnostics to historically accumulated maintenance records and prognostic models, ensuring that both current system health and future performance predictions are represented in a unified, machine-interpretable manner. This layer is critically important because naval vessels depend on continuous readiness, and unplanned failures can impose major operational and financial costs. By formalising the relationships between degradation mechanisms, failure events, and maintenance activities, the PHM and maintenance ontology components enable predictive interventions, optimise maintenance windows, and support risk-informed upgrade planning. Ultimately, they provide the analytical foundation for transitioning from reactive maintenance to proactive, evidence-based sustainment, thereby improving system availability, reducing lifecycle costs, and informing when upgrades should be prioritised based on emerging or projected system health trends.
SUO-PHM and maintenance module.
Figure 1 presents the core conceptual structure of SUO, highlighting the explicit semantic relationships linking configuration, failure, assessment, upgrade, and capability concerns and demonstrates how SUO integrates these constructs into a single, coherent knowledge structure. Configuration Items form the structural backbone of the ontology and are associated with failure modes and failure causes that represent degraded system behaviour grounded in the underlying system structure. Failures are linked to maintenance activities and assessments, distinguishing operational sustainment actions from evaluative processes that quantify failure impact and system performance. Capability is modelled as a first-class concept, enabling explicit representation of how configuration state, degradation, and interventions influence operational outcomes. Upgrades are represented as intentional change actions that modify configuration items and establish new baselines. These actions are informed by assessments and governed through change proposals, providing traceability from analytical evidence and organisational intent to implemented system change. By explicitly linking upgrades to capability effects, SUO supports coherent reasoning across system structure, behaviour, evaluation, and decision-making, forming a compact semantic foundation for lifecycle analysis and upgrade planning.
Show the relationships of some of the core structures of SUO to the PHM and maintenance module.
3.3. SUO-Epoch/era planning extension
The SUO-Epoch/Era Planning Extension (Table 5) provides a formal temporal framework for modelling how naval platforms evolve under changing strategic, technological, and operational conditions. Complex systems such as naval platforms experience discontinuous shifts in context over their lifecycle. These shifts include changes in mission doctrine, threat environment, technology maturity, certification standards, supply chains, and sustainment strategies. Treating time as a continuous scalar obscures these regime changes and leads to inappropriate inferences—for example, assuming that a configuration valid under one operational concept remains viable under another. SUO, therefore, treats time not only merely as chronology but also as context. SUO adopts an epoch–era temporal structure to explicitly represent contextual validity,
Epoch represents a bounded temporal interval characterised by relatively stable assumptions regarding missions, threats, technologies, regulatory constraints, and sustainment conditions.
Era represents an ordered sequence of epochs that together describe a higher-level phase in the system’s lifecycle (e.g. initial service, mid-life modernisation, life extension).
Epochs and eras are not arbitrary time slices; they are semantic containers that define the conditions under which configurations, degradation behaviours, and upgrade decisions are meaningful. This commitment allows SUO to state, explicitly and formally,
which configuration states are valid within a given epoch,
which upgrade paths transition the system between epochs,
which decision rationales are contingent on epoch-specific assumptions.
Within SUO, configuration trajectories are interpreted relative to epochs and eras rather than absolute time alone. A trajectory, therefore, represents not only a sequence of configuration states but also a context-sensitive evolution path. This distinction is critical for upgrade reasoning. Two configurations separated by 10 years may be equivalent in structural terms but radically different in upgrade feasibility if they belong to different epochs with different constraints (e.g. obsolescence, certification rules, or mission requirements). Epoch–era modelling enables these differences to be made explicit and computable. Within this structure, ConfigurationPaths capture alternative upgrade sequences across epochs, enabling planners to compare competing modernisation strategies under varying constraints. The extension also models key change mechanisms, including modularity, interoperability, reconfigurability, and design margins (space, weight, power, cooling), that determine the adaptability of the system across eras. By embedding these temporal and adaptability constructs into the ontology, the SUO supports reasoning about when upgrades should occur, how configuration baselines evolve, and which upgrade pathways maximise operational capabilities and minimise lifecycle risk. This provides a rigorous semantic foundation for long-term upgrade planning, mid-life modernisation, and evaluation of future force design options.
SUO’s temporal ontology (epoch–era) module.
Without explicit epoch–era constructs, upgrade reasoning degenerates into one of two failure modes,
Over-generalisation, where past configurations are assumed to be reusable without recognising contextual invalidation.
Over-fragmentation, where every configuration appears unique, preventing meaningful comparison or reuse of prior analyses.
Both failure modes undermine long-horizon decision support. By contrast, SUO’s temporal commitments allow upgrade planners to reason about classes of configurations within epochs, while still preserving detailed traceability at the configuration-item level.
By anchoring upgrade decisions to epochs and eras, SUO enables,
explicit justification of why an upgrade is viable now but not later,
comparison of alternative upgrade timings and sequences, and
alignment of technical decisions with strategic planning horizons.
Temporal reasoning thus becomes an integral part of the ontology, rather than an external assumption embedded in analysis artefacts. For clarity, Figure 2 illustrates the relationships between temporal context (epochs and eras), configuration evolution, and strategic system properties SUO. Epochs represent distinct operational contexts nested within longer-term eras, while configuration paths capture permissible sequences of system configurations over time. Structural properties such as modularity, interoperability, and reconfigurability enable or constrain feasible configuration paths, which in turn influence available margin and strategic options. Strategy governs the selection of configuration paths across eras, linking near-term operational decisions to long-term capability evolution.
Strategic configuration evolution across epochs and eras.
3.4. Epoch upgrade assessment and decision factors
The decision factor component of SUO addresses a fundamental limitation of conventional upgrade representations: while technical changes and configuration states can be described, the rationale for selecting one upgrade path over another is typically implicit, fragmented, or lost. In practice, upgrade decisions are shaped by a combination of technical feasibility, sustainment implications, operational impact, strategic alignment, and organisational constraints, yet these considerations are rarely represented in a form that is both explicit and reusable across lifecycle stages. SUO formalises these considerations by modelling decision factors as first-class ontological entities (Table 6), rather than as external annotations or narrative justifications. The intent is not only to prescribe decision outcomes but also to provide a coherent semantic structure within which heterogeneous assessment domains—such as logistics and sustainment burden, system integration risk, training and workforce readiness, operational performance impact, cyber security exposure, certification complexity, industrial participation, environmental considerations, and strategic alignment—can be consistently represented and related to specific configuration states and upgrade transitions.
SUO’s upgrade assessment and decision factors module.
Crucially, the scope of this component spans both quantitative and qualitative assessments. Quantitative measures, including lifecycle cost deltas, commonality indices, and integration risk metrics, coexist with qualitative judgements concerning doctrinal compatibility, organisational readiness, or long-term strategic fit. By encoding both forms of assessment within a shared ontological framework, SUO enables comparison of upgrade options without reducing complex trade-offs to a single optimisation criterion.
The ontological significance of the decision factors layer lies in its ability to make decision rationale explicit and traceable. Upgrade decisions are represented as reasoned selections among alternatives, grounded in stated assumptions and constraints, rather than as isolated outcomes. This supports longitudinal analysis, reuse of prior decision logic under comparable conditions, and systematic exploration of how changes in context—such as a shift in operational doctrine or industrial capability—alter the preferred upgrade trajectory.
By integrating decision factors with configuration trajectories and epoch–era structures, SUO ensures that upgrade decisions are interpreted within their appropriate temporal and contextual boundaries. As a result, system upgradability is treated not only merely as a question of engineering feasibility or performance improvement, but also as a lifecycle property emerging from the interaction of technical, operational, organisational, and strategic considerations over time.
3.5. SUO key properties
The key properties of SUO define the semantic relationships and measurable attributes that make reasoning about system upgradability possible. While classes establish what exists within the ontology, properties define how those entities interact, evolve, and are evaluated. Without explicit and well-scoped properties, the SUO would remain a static classification scheme rather than an operational reasoning framework. SUO properties formalise the relationships between physical entities, processes, assessments, and temporal constructs that collectively determine upgrade feasibility and impact (Table 7). Object properties such as hasParticipant, isPrecededBy, hasAssessment, and hasState encode causal, temporal, and dependency relationships, enabling explicit representation of configuration evolution, upgrade sequencing, and decision context. Data properties such as integrationRisk, capabilityGain, lifecycleCostDelta, and commonalityScore capture quantitative and ordinal attributes required for comparative evaluation of alternative upgrade paths.
SUO’s upgrade assessment and decision factors module.
The scope of the key properties layer spans both structural relationships and analytic descriptors. Structural properties link upgrades to change proposals, work orders, configuration states, and affected system elements, ensuring traceability across lifecycle artefacts. Analytic properties associate configurations and upgrade transitions with evaluative measures, such as cost deltas, certification complexity, environmental impact, or operational benefit, enabling these considerations to be reasoned over systematically rather than treated as external annotations. The ontological role of key properties is foundational. They enable the SUO to represent configuration trajectories across epochs, compare alternative upgrade sequences, detect logical or temporal inconsistencies, and support algorithmic reasoning over upgrade trade-offs. In this sense, properties do not merely enrich the ontology; they define its inferential capability. By establishing explicit semantic relationships and well-defined evaluative attributes, the key properties layer transforms the SUO into a functional knowledge graph capable of integrating heterogeneous data sources, maintaining coherence across configuration changes, and supporting explainable, lifecycle-aware upgrade decision support.
3.6. SUO design patterns
Ontology design patterns provide reusable semantic structures that constrain how concepts may be related, interpreted, and reasoned over within an ontology (Table 8). Rather than serving as stylistic modelling guidance, patterns define explicit commitments about permissible relationships, dependencies, and interpretation logic, thereby ensuring that similar phenomena are represented consistently across the model. Within SUO, design patterns are essential for maintaining semantic coherence across upgrade, sustainment, and lifecycle representations. SUO spans multiple interacting concerns—including configuration change, degradation and failure behaviour, decision assessment, and temporal evolution—and without explicit patterns, these concerns risk being modelled in incompatible or incomplete ways. Such inconsistency undermines traceability and can lead to incorrect or ambiguous inferences, particularly in naval sustainment contexts where configuration decisions carry significant operational, safety, and cost consequences. SUO patterns formalise recurring modelling structures, such as the relationship between a ConfigurationItem and its associated FailureMode, the linkage between an Upgrade, its originating ChangeProposal, and its resulting CapabilityEffect, and the evolution of baselines across epochs and eras. By enforcing these structures, the ontology ensures that key lifecycle phenomena are represented in a predictable and machine-interpretable manner, independent of the specific system instance or analysis context. The ontological role of design patterns is, therefore, foundational. They provide the structural backbone that enables consistent reasoning, validation, and data integration across heterogeneous sources and tools. Through these patterns, SUO operates not only as a loose aggregation of concepts but also as a coherent semantic system capable of supporting lifecycle analytics, automated inference, and defensible upgrade decision-making across long service lives.
Key structural relationships between SUO ontologies.
Note. The symbol ⊑ means “is a subclass of.”
4. ANZAC-class frigate example
The ANZAC-class frigate has been the workhorse of the Royal Australian Navy since the mid-1990s, providing air-defence, anti-surface, and anti-submarine capabilities across a wide range of operations. Over its service life, the class has undergone substantial capability enhancement programmes, most notably the Anti-Ship Missile Defence (ASMD) upgrade, initiated in 2003 and implemented across the fleet between 2010 and 2017, and the Anzac Mid-life Capability Assurance Program (AMCAP), which commenced in 2018. Together, these programmes introduced advanced phased-array radar systems, enhanced combat system integration, and a suite of platform reliability and obsolescence-management upgrades aimed at extending operational effectiveness into the late 2020s and beyond. Recent strategic reviews have called for an enhanced lethality surface combatant fleet and foreshadow the replacement of ANZACs by new Tier 2 frigates, while requiring the existing class to remain credible into the 2030s. 22 It is worth noting that the first-of-class HMAS Anzac decommissioned in 2024 after approximately 28 years of service; the remaining ANZAC-class vessels are now operating within an extended service-life window, requiring continued sustainment and selective modernisation to remain credible into the late 2020s and early-to-mid-2030s.
In this context, there is a need for a structured way to represent ship configurations, upgrades and decision factors that influence sustainment and replacement strategies. SUO provides such a representation by formally modelling both the physical and decision-making dimensions of naval capability evolution. SUO captures core entities, including System (ship), Subsystem, Upgrade, UpgradePackage, and WorkOrder, and extends these with an epoch–era layer to support lifecycle and transition planning, as well as a decision-factor layer to enable multi-criteria assessment of upgrade options. The decision-factor extension introduces UpgradeAssessment subclasses that capture logistics, training, integration, operational, strategic, cyber, industrial, environmental, and certification concerns, as well as sovereign capability concerns, each linked to controlled ImpactLevel values (low, medium, high). The seven remaining Australian ANZAC frigates (Arunta, Warramunga, Stuart, Parramatta, Ballarat, Toowoomba, and Perth) are instantiated as Ship individuals with commissioning dates, planned withdrawal windows, and links to their major ASMD and AMCAP upgrades.
Beyond simple instantiation, the ANZAC-class case study highlights how the SUO can interface with and enhance the existing data contained within the Naval Logistics Information Systems (NLIS) to form a coherent, semantically enriched representation of the class. The platform’s extensive configuration and maintenance history maps directly onto the SUO constructs such as ConfigurationItem, Baseline, WorkOrder, FailureEvent, and MaintenanceWindow. These data sources, while currently dispersed across NLIS applications, align naturally with a SUO’s structured vocabulary and relational model. In particular, historically accumulated maintenance actions, defect trends, configuration changes, and logistics consumption patterns can be mapped to the SUO individuals and properties to provide an authoritative semantic layer over the platform’s sustainment narrative. This linkage enables the ontology to perform tasks that operational data systems alone cannot: tracing configuration evolution across ASMD and AMCAP increments, identifying subsystem interdependencies that constrain future upgrade options, and evaluating how past maintenance behaviour affects the viability and timing of upcoming modernisation activities.
Integrating these data streams into the SUO, therefore, allows the ANZAC-class model to function as a living digital asset rather than a static representation. It enables automated reasoning over historical trends and projected states, supports comparison of alternative upgrade paths, and provides a consistent framework for evaluating the multidimensional impacts of capability decisions as the class approaches its planned withdrawal. In this way, the ANZAC-class instantiation does not simply populate the ontology; it demonstrates how SUO can unify technical, logistical, and operational information into a single, lifecycle-focused decision support structure for surface combatant sustainment and transition planning.
4.1. Case study: HMAS Parramatta (IV)
HMAS Parramatta (IV) (Figure 3) was commissioned in 2003 and has since received both ASMD and AMCAP upgrades (2016), including CEAFAR long-range radar, improved communications and support for Naval Strike Missile (NSM) and Evolved Sea Sparrow Missile (ESSM) Block 2 missiles. Within SUO, these changes can be captured as Upgrade individuals (ASMD_Parramatta_2016, AMCAP_Parramatta_2026) linked to the ship and to their parent programmes.
An image of HMAS Parramatta (IV).
Prospective upgrades, such as integration of additional strike weapons, enhanced electronic warfare systems or further combat system modernisations, are modelled as candidate Upgrade instances with associated UpgradeAssessment objects. For example, a Naval Strike Missile package may carry a LogisticsAssessment (capturing commonality with other NSM-equipped platforms, inventory cost deltas and supply risk) and an OperationalAssessment (capturing capability gain and impact on ship availability). An epoch/era abstraction is used for grouping these decisions over time. For example, an “extended service” era for HMAS Parramatta from 2025 to 2037 is split into epochs, each with specific context assumptions (e.g. pre-Tier-2-frigate introduction, post-introduction). ConfigurationPath individuals represent alternative sequences of upgrades across epochs, allowing planners to compare different trajectories such as “AMCAP + NSM only” versus “AMCAP + NSM + Tomahawk + EW enhancements.”
4.2. Reasoning and decision support
Standard OWL axioms ensure basic data integrity (e.g. each Upgrade must have at least one UpgradeAssessment, core classes are disjoint) and facilitate automated classification, such as identifying all upgrades with high operational impact but less than high logistics burden. Additional class expressions can define convenient concepts like HighImpactUpgrade, allowing automated tagging of upgrades that meet certain assessment patterns. SPARQL (SPARQL Protocol And RDF Query Language) is the standard semantic query language and protocol for retrieving and manipulating data stored in RDF format, designed for graph-based, linked data. SPARQL can query over the SUO knowledge base, enabling analysts to list all ANZAC ships and their ASMD completion dates, to retrieve all planned upgrades for a specific ship along with their impact levels, or to rank candidate configuration paths according to chosen criteria. When combined with quantitative inputs such as cost, availability, or reliability models, the ontology acts as a semantic integration layer that links heterogeneous evidence sources—such as engineering data sets, sustainment and logistics analyses, and formal audit or assurance reports—into a coherent, machine-interpretable decision context for sustainment and upgrade planning. The integration of structured sustainment data also supports fleet-level analytics and end-of-life reasoning. In addition to the seven commissioned ANZAC-class frigates, the first-of-class vessel is included in the model to represent decommissioning and disposal as a decision outcome applicable to any hull. With this complete class representation, SPARQL queries can identify divergence in subsystem configurations, quantify the logistics burden arising from non-common equipment fits, and evaluate the impact of alternative modernisation, life extension, or withdrawal schedules on class-wide capability availability and cost. These analyses go beyond the capabilities of existing logistics or configuration management systems, as SUO’s explicit treatment of capability effects, decision factors, temporal evolution, and retirement states enables whole-of-lifecycle reasoning rather than static, in-service snapshot reporting. This demonstration shows that an ontology-based approach can effectively structure complex information about warship upgrades, sustainment, and strategic planning. By instantiating the SUO with ANZAC-class data, including major upgrade programmes and strategic guidance, we obtain a reusable knowledge base that supports transparent, repeatable, and extensible decision-making. The same pattern can be applied to future frigate classes and to other surface vessels, providing continuity of reasoning even as platforms and technologies evolve.
5. Conclusion
The proposed ontology glossary, with its modular and multi-layered design, directly addresses the fragmentation and limitations identified in the existing literature. It provides a concrete, implementable framework that moves beyond abstract concepts and offers a practical path towards true semantic interoperability for capability sustainment.
The literature review revealed a landscape of ontologies that are either too general (e.g. a top-level framework like DoDAF DM2) or too specific (e.g. a maintenance ontology like IOF-MAINT). While these individual efforts are valuable, the central challenge is their lack of seamless integration. Our proposed ontology architecture solves this problem by providing a domain-specific meta-framework that intelligently combines these disparate parts.
Federated and Multi-Layered Structure: By organising the ontology into a core model, a temporal planning extension, and a set of decision factors, we have created an architecture that mirrors the federated approach recommended in the literature. This design allows for the reuse of specialised knowledge, such as detailed failure modes from an industrial ontology, without having to re-engineer them from scratch.
Extending the Standard: The inclusion of concepts like IndustrialAssessment and EnvironmentalAssessment with specific properties like industrialBenefit and emissionsImpact directly fills a known gap in the logistics and sustainability literature, where existing ontologies were found to be insufficient in their representation of these aspects. This demonstrates the ontology’s ability to be customised for defence-specific requirements while retaining its core, reusable structure.
The enhancements to the ontology, particularly the addition of granular maintenance and process-related concepts, significantly bolster the ontology’s ability to support automated reasoning and explainable AI (XAI). Traditional data-driven approaches are often considered “black boxes” because it is difficult to understand their internal reasoning. SUO creates a semantically transparent framework that can trace a decision back to its source.
Connecting Cause and Effect: By explicitly linking a ConfigurationItem to a FailureMode and then to a MaintenanceProcess, the ontology creates a formal chain of cause and effect. This allows an automated system to not only identify that a component is in a DegradedState but also to reason that this state is a disposition to a specific FailureMode and, therefore, triggers a PHMAssessment.
Formalising Process Flow: The addition of properties like isPrecededBy and hasState to processes like Upgrade and WorkOrder formalises the sustainment workflow. This is crucial because many existing ontologies lack the ability to model the connections between processes. With these relationships, a reasoner can verify that a WorkOrder has been properly authorised by a ChangeOrder and can track its status, ensuring traceability and compliance throughout the upgrade process.
By providing both a high-level organisational structure and the granular detail necessary for specific sustainment tasks, this ontology moves beyond a simple vocabulary and becomes a true knowledge-based framework for intelligent lifecycle management.
Footnotes
Funding
The authors received no financial support for the research, authorship, and/or publication of this article.
Declaration of conflicting interests
The authors declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.