Building a Maintenance Operations Domain Ontology in Manufacturing

In the previous articles, we defined a small core manufacturing ontology and extended it with the concepts needed to describe production and quality operations.

The same method can be applied to maintenance.

The core ontology already provides the general concepts needed to describe manufacturing operations:

• Process
• PhysicalEntity
• OperationalEntity
• Agent
• Location
• Capability
• Role
• Event
• State

However, it deliberately does not define concepts such as corrective maintenance, condition monitoring, spare parts, work orders, failure reports, or equipment-health states.

Those concepts belong in a maintenance-domain ontology.

The purpose of the maintenance ontology is to introduce the vocabulary needed to describe how manufacturing assets are monitored, serviced, repaired, and returned to operation, while preserving a direct semantic connection to the shared core.

In this example, the maintenance ontology covers:

• Preventive, corrective, and predictive maintenance
• Equipment condition monitoring
• Repair work
• Maintenance planning and work orders
• Failure reporting
• Spare parts and maintenance tools
• Equipment-health states
• Maintenance-significant events

The example is based on the upkeep of a food-production plant, but the same extension pattern could be applied across discrete, process, and hybrid manufacturing environments.

Extending the Core Ontology

The maintenance ontology adds more specific concepts by making them subclasses of the existing core concepts.

For example:

MaintenanceProcess SUBCLASS_OF Process

SparePart SUBCLASS_OF Material

MaintenanceWorkOrder SUBCLASS_OF OperationalEntity

MaintenanceTechnician SUBCLASS_OF Agent

RepairCapability SUBCLASS_OF Capability

MaintenanceEvent SUBCLASS_OF Event

DegradedState SUBCLASS_OF EquipmentState

The core remains unchanged.

It still describes the general semantic structure of manufacturing operations. The maintenance ontology adds the vocabulary needed to describe how equipment condition is observed, how maintenance work is initiated, and how assets move through the maintenance lifecycle.

The resulting architecture is:

Core ontology
    ↓
Maintenance-domain ontology

For example:

Process
    └── MaintenanceProcess
            ├── PreventiveMaintenance
            ├── CorrectiveMaintenance
            ├── PredictiveMaintenance
            ├── Repair
            └── ConditionMonitoring

Each maintenance-specific process inherits the meaning of the core Process concept: it is work that happens over time and affects something.

1. Extending Location with maintenance work areas

The maintenance ontology introduces:

MaintenanceWorkshop SUBCLASS_OF WorkCenter

A MaintenanceWorkshop is an equipped area where technicians can inspect, overhaul, repair, and calibrate plant assets away from the production floor.

An actual workshop could later be represented in the knowledge graph as:

CentralMaintenanceWorkshop
    INSTANCE_OF MaintenanceWorkshop

A repair execution could then be connected to that location using the core relationship:

PumpRepairExecution88
    OCCURS_AT CentralMaintenanceWorkshop

This allows the graph to distinguish maintenance work performed directly on installed equipment from work performed after an asset or component has been moved to a dedicated workshop.

The core provides the general concept of location. The maintenance ontology defines the type of location that matters for maintenance operations.

2. Extending PhysicalEntity with maintenance resources

The maintenance ontology introduces three physical concepts:

SparePart SUBCLASS_OF Material

MaintenanceTool SUBCLASS_OF Equipment

ConditionSensor SUBCLASS_OF Equipment

SparePart

A SparePart is a replacement component held so that failed or worn equipment can be restored.

Examples include:

Filler seal
Pump bearing
Homogenizer valve

An actual spare part could be represented as:

PumpBearingSP-447
    INSTANCE_OF SparePart

The spare part may participate in a repair process as a replacement component:

PumpBearingSP-447
    PARTICIPATES_IN PumpRepairExecution88

The core role model could then explain how it participates:

PumpBearingSP-447
    PLAYS_ROLE ReplacementComponent

The maintenance ontology does not define a new maintenance-specific role vocabulary, so concepts such as ReplacementComponent would either be introduced through a separate role extension or represented using a suitable shared role.

MaintenanceTool

A MaintenanceTool is an instrument or piece of equipment used by a technician to perform maintenance work.

Examples include:

Torque wrench
Vibration analyser
Alignment tool

An actual tool could be represented as:

TorqueWrench12
    INSTANCE_OF MaintenanceTool

and connected to a maintenance execution:

TorqueWrench12
    PARTICIPATES_IN PumpRepairExecution88

ConditionSensor

A ConditionSensor is a sensor mounted on equipment to track indicators of asset health.

Examples include measurements of:

• Vibration
• Temperature
• Motor current

For example:

VibrationSensor44
    INSTANCE_OF ConditionSensor

The sensor may participate in a condition-monitoring process:

VibrationSensor44
    PARTICIPATES_IN PumpConditionMonitoring91

These concepts allow the maintenance ontology to distinguish the asset being maintained from the physical resources used to diagnose and repair it.

3. Extending Process with maintenance work

The maintenance ontology introduces an abstract parent concept:

MaintenanceProcess SUBCLASS_OF Process

It then defines five types of maintenance work:

CorrectiveMaintenance
PreventiveMaintenance
PredictiveMaintenance
Repair
ConditionMonitoring

CorrectiveMaintenance

CorrectiveMaintenance represents work performed after equipment has failed or degraded.

For example:

FillerCorrectiveMaintenance88
    INSTANCE_OF CorrectiveMaintenance

Its objective is to remove the fault and return the affected equipment to a serviceable condition.

PreventiveMaintenance

PreventiveMaintenance represents scheduled work carried out at defined intervals before a failure occurs.

Examples include:

• Periodic lubrication
• Seal replacement
• Calibration
• Inspection
• Belt-tension checks

For example:

QuarterlyFillerService12
    INSTANCE_OF PreventiveMaintenance

The timing of the work is determined by a maintenance plan rather than by a detected failure.

PredictiveMaintenance

PredictiveMaintenance represents maintenance triggered by condition data indicating an emerging failure.

For example:

PumpBearingIntervention44
    INSTANCE_OF PredictiveMaintenance

The intervention may be initiated because vibration, temperature, or motor-current patterns suggest that the equipment is likely to fail.

Predictive maintenance therefore links condition monitoring to maintenance action:

ConditionMonitoring
    ↓
Degradation detected
    ↓
PredictiveMaintenance

Repair

Repair represents the work of fixing or replacing a faulty component.

For example:

PumpBearingReplacement88
    INSTANCE_OF Repair

A repair may be part of a broader corrective-maintenance execution:

FillerCorrectiveMaintenance88
    HAS_SUBPROCESS PumpBearingReplacement88

ConditionMonitoring

ConditionMonitoring represents the ongoing observation of equipment-health indicators.

For example:

PumpConditionMonitoring91
    INSTANCE_OF ConditionMonitoring

The process may use a condition sensor to identify degradation before functional failure occurs.

Together, these processes describe a maintenance lifecycle:

ConditionMonitoring
    ↓
HealthyState or DegradedState condition identified
    ↓
Predictive or Corrective Maintenance
    ↓
Repair
    ↓
Equipment restored

4. Extending OperationalEntity with maintenance intent and evidence

The maintenance ontology introduces operational entities used to plan, authorize, guide, and document maintenance work:

MaintenanceWorkOrder
MaintenancePlan
FailureReport
MaintenanceProcedure
SparePartsList

These can be divided into maintenance intent and maintenance evidence.

Maintenance intent

The following operational entities describe or authorize work:

MaintenancePlan
MaintenanceWorkOrder
MaintenanceProcedure
SparePartsList

A MaintenancePlan defines a time-phased schedule of preventive tasks for a set of equipment.

For example:

FillerAnnualMaintenancePlan
    INSTANCE_OF MaintenancePlan

A MaintenanceWorkOrder authorizes and dispatches a specific maintenance job on a particular asset.

For example:

MaintenanceWorkOrder882
    INSTANCE_OF MaintenanceWorkOrder

A MaintenanceProcedure describes how the work should be performed safely and correctly.

For example:

PumpBearingReplacementProcedureV3
    INSTANCE_OF MaintenanceProcedure

A SparePartsList identifies the components expected to be required for the task.

For example:

PumpBearingReplacementPartsList
    INSTANCE_OF SparePartsList

These operational entities can guide a repair process through the core relationship:

PumpRepairExecution88
    IS_GUIDED_BY MaintenanceWorkOrder882

PumpRepairExecution88
    IS_GUIDED_BY PumpBearingReplacementProcedureV3

PumpRepairExecution88
    IS_GUIDED_BY PumpBearingReplacementPartsList

The relationship is broad at the core level. A more detailed maintenance extension could later introduce relationships such as:

FULFILLS_WORK_ORDER
FOLLOWS_PROCEDURE
REQUIRES_PARTS_LIST

The current ontology does not define these specialized relationships, so it relies on the core IS_GUIDED_BY relationship.

Maintenance evidence

The primary evidence concept is:

FailureReport

A FailureReport documents:

• The failure event
• The affected equipment
• The identified cause
• The corrective action performed

For example:

PumpFailureReport88
    INSTANCE_OF FailureReport

A corrective-maintenance process may produce the report:

PumpRepairExecution88
    PRODUCES PumpFailureReport88

This gives the graph a distinction between:

What maintenance work was planned

and:

What failure occurred and what work was actually performed

That distinction is essential for maintenance history, reliability analysis, and root-cause investigations.

5. Extending Agent with maintenance participants

The maintenance ontology introduces:

MaintenanceTechnician SUBCLASS_OF Agent

ReliabilityEngineer SUBCLASS_OF Agent

MaintenanceTechnician

A MaintenanceTechnician inspects, services, and repairs plant equipment.

For example:

Technician17
    INSTANCE_OF MaintenanceTechnician

The technician may participate in a repair execution:

Technician17
    PARTICIPATES_IN PumpRepairExecution88

The core role model can describe the technician’s participation:

Technician17
    PLAYS_ROLE Performer

ReliabilityEngineer

A ReliabilityEngineer analyses failure patterns and defines strategies for improving asset reliability.

For example:

ReliabilityEngineer5
    INSTANCE_OF ReliabilityEngineer

The reliability engineer may participate in condition analysis or maintenance planning:

ReliabilityEngineer5
    PARTICIPATES_IN PumpConditionMonitoring91

or:

ReliabilityEngineer5
    PARTICIPATES_IN MaintenancePlanningProcess12

The maintenance ontology defines what types of agents exist. Their specific responsibility in a particular maintenance execution is expressed through participation and roles.

6. Extending Capability with maintenance abilities

The maintenance ontology introduces three capabilities:

RepairCapability
DiagnosticCapability
ConditionMonitoringCapability

These extend the core Capability concept.

RepairCapability

RepairCapability is the ability to fix or replace faulty components and return equipment to working order.

For example:

Technician17
    HAS_CAPABILITY RepairCapability

A repair process can declare that it requires this capability:

Repair
    REQUIRES_CAPABILITY RepairCapability

DiagnosticCapability

DiagnosticCapability is the ability to identify the cause of a fault or performance loss.

For example:

ReliabilityEngineer5
    HAS_CAPABILITY DiagnosticCapability

It may also be possessed by diagnostic software or specialized maintenance equipment.

ConditionMonitoringCapability

ConditionMonitoringCapability is the ability to observe and interpret equipment-health indicators.

For example:

VibrationMonitoringSystem4
    HAS_CAPABILITY ConditionMonitoringCapability

The corresponding process can state:

ConditionMonitoring
    REQUIRES_CAPABILITY ConditionMonitoringCapability

This creates the reusable matching pattern defined by the core:

MaintenanceProcess
    REQUIRES_CAPABILITY
Capability
    possessed by
Agent or PhysicalEntity

An application or AI agent can use this pattern to determine whether the required people, sensors, tools, or systems are available for a maintenance task.

7. Extending Event with maintenance-significant occurrences

The maintenance ontology introduces:

MaintenanceEvent SUBCLASS_OF Event

It then defines six maintenance events:

EquipmentFailed
FaultDetected
MaintenanceStarted
MaintenanceCompleted
MaintenanceWorkOrderRaised
MaintenanceWorkOrderClosed

FaultDetected

FaultDetected records that a fault or abnormal condition has been identified.

For example:

FaultDetectedEvent91
    INSTANCE_OF FaultDetected

The event may be generated during condition monitoring:

FaultDetectedEvent91
    OCCURS_DURING PumpConditionMonitoring91

and affect the monitored equipment:

FaultDetectedEvent91
    AFFECTS Pump101

EquipmentFailed

EquipmentFailed records that equipment stopped performing its intended function.

For example:

PumpFailureEvent88
    INSTANCE_OF EquipmentFailed

The event may change the state of the equipment:

PumpFailureEvent88
    CHANGES_STATE Pump101

Pump101
    HAS_STATE FailedState

MaintenanceWorkOrderRaised

MaintenanceWorkOrderRaised records that a work order was created and authorized.

For example:

WorkOrderRaisedEvent882
    INSTANCE_OF MaintenanceWorkOrderRaised

MaintenanceStarted

MaintenanceStarted records that execution of the maintenance job began.

It may indicate that the asset has entered an under-maintenance condition:

MaintenanceStartedEvent88
    CHANGES_STATE Pump101

Pump101
    HAS_STATE UnderMaintenanceState

MaintenanceCompleted

MaintenanceCompleted records that the maintenance work finished.

The event does not necessarily mean that the work order has been administratively closed. It records completion of the physical work.

MaintenanceWorkOrderClosed

MaintenanceWorkOrderClosed records that the maintenance work order was reviewed and formally closed.

Together, these events describe the work-order lifecycle:

FaultDetected or EquipmentFailed
    ↓
MaintenanceWorkOrderRaised
    ↓
MaintenanceStarted
    ↓
MaintenanceCompleted
    ↓
MaintenanceWorkOrderClosed

They provide the temporal evidence needed to reconstruct what happened to an asset and how the organization responded.

8. Extending State with equipment-health conditions

The maintenance ontology introduces four equipment-health states:

HealthyState
DegradedState
FailedState
UnderMaintenanceState

These extend the core State concept.

HealthyState

HealthyState means that equipment is operating within its normal condition limits and no fault has been detected.

For example:

Pump101
    HAS_STATE HealthyState

DegradedState

DegradedState means that the equipment can still operate, but its condition has worsened and indicates an emerging fault.

For example:

Pump101
    HAS_STATE DegradedState

This state is particularly important for predictive maintenance because intervention may be scheduled before functional failure occurs.

FailedState

FailedState means that the equipment is no longer performing its required function.

For example:

Pump101
    HAS_STATE FailedState

A corrective-maintenance process is normally required to restore it.

UnderMaintenanceState

UnderMaintenanceState means that the equipment is unavailable because maintenance work is currently being performed.

For example:

Pump101
    HAS_STATE UnderMaintenanceState

The state lifecycle may look like:

HealthyState
    ↓
DegradedState
    ↓
FailedState
    ↓
UnderMaintenanceState
    ↓
HealthyState

However, not every maintenance sequence must pass through all four states.

Preventive maintenance may move equipment directly from HealthyState to UnderMaintenanceState and back to HealthyState.

Predictive maintenance may intervene while the equipment is still DegradedState, preventing it from reaching the FailedState state.

9. Specializing the core relationships

The maintenance ontology introduces two specialized relationships:

MAINTAINS
RESTORES

Both specialize the core relationship:

Process AFFECTS Entity

MAINTAINS

The ontology defines:

Process MAINTAINS PhysicalEntity

MAINTAINS means that a process keeps an asset in, or returns it toward, a serviceable condition.

For example:

QuarterlyFillerService12
    MAINTAINS Filler201

The relationship is more precise than the general statement:

QuarterlyFillerService12
    AFFECTS Filler201

It tells us why the process affects the equipment.

MAINTAINS can be used for preventive, predictive, or general maintenance work.

RESTORES

The ontology defines:

Process RESTORES PhysicalEntity

RESTORES means that a process returns failed equipment to working order.

For example:

PumpRepairExecution88
    RESTORES Pump101

This is narrower than MAINTAINS.

A preventive-maintenance activity may maintain an asset without restoring it, because the asset had not yet failed.

A repair process restores an asset that was already failed or unserviceable.

The distinction can therefore be expressed as:

PreventiveMaintenance
    MAINTAINS Equipment

Repair
    RESTORES Equipment

Both relationships retain their connection to the core through:

MAINTAINS SPECIALIZES AFFECTS

RESTORES SPECIALIZES AFFECTS

A complete maintenance example

The resulting ontology can support a knowledge graph such as:

Pump101 INSTANCE_OF ProductionEquipment

VibrationSensor44 INSTANCE_OF ConditionSensor

PumpConditionMonitoring91
    INSTANCE_OF ConditionMonitoring

VibrationSensor44
    PARTICIPATES_IN PumpConditionMonitoring91

Pump101
    PARTICIPATES_IN PumpConditionMonitoring91

PumpConditionMonitoring91
    REQUIRES_CAPABILITY ConditionMonitoringCapability

FaultDetectedEvent91
    INSTANCE_OF FaultDetected

FaultDetectedEvent91
    OCCURS_DURING PumpConditionMonitoring91

FaultDetectedEvent91
    AFFECTS Pump101

FaultDetectedEvent91
    CHANGES_STATE Pump101

Pump101
    HAS_STATE DegradedState

A predictive-maintenance workflow may then continue:

MaintenanceWorkOrder882
    INSTANCE_OF MaintenanceWorkOrder

WorkOrderRaisedEvent882
    INSTANCE_OF MaintenanceWorkOrderRaised

PumpBearingIntervention88
    INSTANCE_OF PredictiveMaintenance

PumpBearingIntervention88
    IS_GUIDED_BY MaintenanceWorkOrder882

PumpBearingIntervention88
    IS_GUIDED_BY PumpBearingReplacementProcedureV3

PumpBearingIntervention88
    MAINTAINS Pump101

Technician17
    INSTANCE_OF MaintenanceTechnician

Technician17
    PARTICIPATES_IN PumpBearingIntervention88

Technician17
    HAS_CAPABILITY RepairCapability

PumpBearingIntervention88
    REQUIRES_CAPABILITY RepairCapability

MaintenanceStartedEvent88
    OCCURS_DURING PumpBearingIntervention88

MaintenanceStartedEvent88
    CHANGES_STATE Pump101

Pump101
    HAS_STATE UnderMaintenanceState

After the intervention:

PumpBearingIntervention88
    RESTORES Pump101

PumpBearingIntervention88
    PRODUCES PumpFailureReport88

MaintenanceCompletedEvent88
    OCCURS_DURING PumpBearingIntervention88

MaintenanceCompletedEvent88
    CHANGES_STATE Pump101

Pump101
    HAS_STATE HealthyState

MaintenanceWorkOrderClosedEvent882
    INSTANCE_OF MaintenanceWorkOrderClosed

The graph is specific to maintenance, but every major concept remains grounded in the core ontology.

For example:

PumpBearingIntervention88
    INSTANCE_OF PredictiveMaintenance
    SUBCLASS_OF MaintenanceProcess
    SUBCLASS_OF Process

and:

VibrationSensor44
    INSTANCE_OF ConditionSensor
    SUBCLASS_OF Equipment
    SUBCLASS_OF PhysicalEntity

This allows applications and AI agents to move between detailed maintenance facts and the general manufacturing semantics shared across domains.

Connecting maintenance with production

One of the main benefits of extending a shared core ontology is that maintenance does not remain isolated from production.

The equipment being maintained may already be represented through the production ontology:

Pump101 INSTANCE_OF ProductionEquipment

The maintenance ontology does not need to define the pump again.

Instead, it adds maintenance facts about the same operational entity:

PumpConditionMonitoring91
    AFFECTS Pump101

PumpBearingIntervention88
    MAINTAINS Pump101

PumpRepairExecution88
    RESTORES Pump101

Pump101
    HAS_STATE HealthyState

The production graph may also show:

Pump101
    PARTICIPATES_IN MaterialTransferExecution4711

An AI agent can therefore follow the graph across domains:

Equipment failure
    ↓
Affected production process
    ↓
Affected material and order
    ↓
Maintenance work order
    ↓
Repair execution
    ↓
Asset restored

This cross-domain reasoning is one of the strongest arguments for extending a common core rather than building separate, disconnected schemas for production and maintenance.

Conclusion

The maintenance ontology extends the core manufacturing ontology with the concepts needed to describe how manufacturing equipment is monitored, maintained, repaired, and returned to service.

It introduces vocabulary for:

• Maintenance workshops
• Spare parts, tools, and condition sensors
• Preventive, corrective, and predictive maintenance
• Repair and condition monitoring
• Maintenance plans, work orders, procedures, and failure reports
• Maintenance technicians and reliability engineers
• Repair, diagnostic, and condition-monitoring capabilities
• Maintenance-significant events
• Equipment-health states

It also introduces the specialized relationships:

MAINTAINS
RESTORES

These refine the more general core relationship AFFECTS.

The central principle remains:

The core ontology defines the shared structure of manufacturing operations. The maintenance ontology extends that structure with the concepts and relationships required to keep manufacturing assets healthy, diagnose degradation, manage maintenance work, and restore failed equipment.

This allows maintenance to become more detailed without separating it from production, quality, inventory, or the rest of the manufacturing knowledge graph.