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 approach can be applied to maintenance.

The core ontology already provides the general concepts shared across manufacturing operations: Process, PhysicalEntity, OperationalEntity, Agent, Location, Capability, Role, Event, and State.

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

Those belong in a maintenance-domain ontology.

The purpose of the maintenance ontology is therefore to add the vocabulary required to describe how manufacturing assets are monitored, maintained, repaired, and returned to service, while keeping every maintenance concept connected to the shared manufacturing core.

In this example, the ontology covers preventive, corrective, and predictive maintenance, condition monitoring, repair work, work orders, spare parts, maintenance events, and equipment-health states.

Extending the Core Ontology

As with the production and quality extensions, maintenance concepts are introduced by specializing concepts that already exist in the core ontology.

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 describes the general semantic structure of manufacturing operations, while the maintenance ontology provides the vocabulary needed to describe asset health and maintenance work.

For example:

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


Every maintenance activity therefore remains understandable as a type of manufacturing Process.

Maintenance Locations and Physical Resources

Maintenance work may take place directly on installed equipment or in a dedicated workshop.

The quality of the model does not require a new location hierarchy, the maintenance ontology can simply specialize the existing WorkCenter concept:

MaintenanceWorkshop SUBCLASS_OF WorkCenter


An actual workshop can then be represented as:

CentralMaintenanceWorkshop INSTANCE_OF MaintenanceWorkshop

PumpRepairExecution
   OCCURS_AT CentralMaintenanceWorkshop

‍

The same pattern applies to the physical resources used during maintenance.

SparePart SUBCLASS_OF Material
MaintenanceTool SUBCLASS_OF Equipment
ConditionSensor SUBCLASS_OF Equipment

‍

Actual resources then become instances:

PumpBearing INSTANCE_OF SparePart
TorqueWrench INSTANCE_OF MaintenanceTool
VibrationSensor INSTANCE_OF ConditionSensor

‍

‍Their involvement in a particular maintenance activity is represented separately:

PumpBearing PARTICIPATES_IN PumpRepairExecution
TorqueWrench PARTICIPATES_IN PumpRepairExecution
VibrationSensor PARTICIPATES_IN PumpConditionMonitoring

‍

‍The ontology tells us what these physical entities are. Their participation tells us how they are involved in a particular maintenance process.

Defining Maintenance Processes

The maintenance ontology introduces:

MaintenanceProcess SUBCLASS_OF Process


and specializes it into the major types of maintenance work.

ConditionMonitoring represents the ongoing observation of equipment-health indicators.

PreventiveMaintenance represents planned work carried out at defined intervals before failure occurs, such as lubrication, inspection, calibration, or periodic component replacement.

PredictiveMaintenance represents intervention triggered by evidence that equipment condition is deteriorating.

CorrectiveMaintenance represents work initiated because equipment has already failed or is no longer performing as required.

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

For example:

PumpConditionMonitoring INSTANCE_OF ConditionMonitoring
PumpBearingIntervention INSTANCE_OF PredictiveMaintenance
PumpBearingReplacement INSTANCE_OF Repair

‍

‍A repair may also be represented as a subprocess of a broader maintenance execution:

PumpBearingIntervention
   HAS_SUBPROCESS PumpBearingReplacement

‍
Together, these concepts support different maintenance paths. Condition monitoring might detect degradation and trigger predictive maintenance before failure occurs.

ConditionMonitoring → Degradation detected → PredictiveMaintenance → Repair


Alternatively, an unexpected failure might trigger corrective maintenance:

Equipment failure → CorrectiveMaintenance → Repair


The ontology therefore models maintenance work without assuming that every asset follows the same lifecycle.

Representing Maintenance Intent and Evidence

Maintenance also requires a distinction between what work should happen and what actually happened.

The maintenance ontology extends OperationalEntity with concepts such as:

MaintenancePlan
MaintenanceWorkOrder
MaintenanceProcedure
SparePartsList
FailureReport


The first four represent maintenance intent.

A MaintenancePlan defines scheduled or recurring maintenance activities, a MaintenanceWorkOrder authorizes a specific maintenance job on a particular asset, a MaintenanceProcedure defines how the work should be performed, and a SparePartsList identifies the components expected to be required.

For example:

PumpRepairExecution
   IS_GUIDED_BY MaintenanceWorkOrder

PumpRepairExecution
   IS_GUIDED_BY PumpBearingReplacementProcedureV3

‍

‍The core IS_GUIDED_BY relationship is broad enough to express these connections. More specialized relationships such as FULFILLS_WORK_ORDER or FOLLOWS_PROCEDURE could be added later if greater precision is required.

FailureReport, by contrast, represents maintenance evidence. It records what failed, what equipment was affected, the identified cause, and what corrective action was performed.

For example:

PumpRepairExecution
   PRODUCES PumpFailureReport


This creates the same useful distinction we saw in production and quality:

what maintenance intended to do versus what actually happened to the asset and how the organisation responded.

That distinction is important for maintenance history, reliability analysis, and root-cause investigation.

Agents, Capabilities, and Roles

The maintenance ontology also specializes the core Agent concept.

For example:

MaintenanceTechnician SUBCLASS_OF Agent
ReliabilityEngineer SUBCLASS_OF Agent

‍A MaintenanceTechnician performs inspection, servicing, troubleshooting, and repair work. A ReliabilityEngineer analyses equipment condition and failure patterns and helps define maintenance strategies.

Their involvement in individual activities is represented through participation:

Technician PARTICIPATES_IN PumpRepairExecution
ReliabilityEngineer PARTICIPATES_IN PumpConditionMonitoring

‍The role they play remains separate from what type of agent they are:

Technician17 PLAYS_ROLE Performer


Maintenance capabilities can be modeled in the same way:

RepairCapability
DiagnosticCapability
ConditionMonitoringCapability


For example:

Technician HAS_CAPABILITY RepairCapability
ReliabilityEngineer HAS_CAPABILITY DiagnosticCapability

ConditionMonitoring
   REQUIRES_CAPABILITY ConditionMonitoringCapability

Repair
   REQUIRES_CAPABILITY RepairCapability

‍

‍This separates what a person, tool, or system is from what it is capable of doing.

An application or AI agent can therefore ask questions such as:

Which available technician has the capability required to perform this repair?

or:

Which sensors or systems can provide the condition-monitoring capability required for this asset?

The process does not need to be hard-coded to a particular person or system. Resources can be matched through the capabilities they provide.

Defining Maintenance Events

The maintenance ontology extends the core Event concept with significant occurrences in the maintenance lifecycle:

MaintenanceEvent SUBCLASS_OF Event

FaultDetected
EquipmentFailed
MaintenanceWorkOrderRaised
MaintenanceStarted
MaintenanceCompleted
MaintenanceWorkOrderClosed


These are different from maintenance processes. A repair takes place over time, while an equipment failure or work-order creation occurs at a particular point in time.

For example:

FaultDetectedEvent91 INSTANCE_OF FaultDetected
FaultDetectedEvent91 OCCURS_DURING PumpConditionMonitoring91
FaultDetectedEvent91 AFFECTS Pump101

‍

If the asset actually fails:

PumpFailureEvent88 INSTANCE_OF EquipmentFailed
PumpFailureEvent88 CHANGES_STATE Pump101

‍

‍A maintenance response can then generate its own event history:

MaintenanceWorkOrderRaised → MaintenanceStarted → MaintenanceCompleted → MaintenanceWorkOrderClosed


Notice that MaintenanceCompleted and MaintenanceWorkOrderClosed are deliberately separate.

The first tells us that the physical maintenance work has finished. The second tells us that the work order has been administratively reviewed and closed.

This event history provides the chronological evidence required to reconstruct what happened to an asset and how maintenance responded.

Defining Equipment-Health States

Events record what happened. States describe the resulting condition of the equipment.

The maintenance ontology specializes the core EquipmentState scope with:

HealthyState - the asset is operating within acceptable condition limits.
DegradedState - the asset can still operate but shows signs of deterioration.
FailedState - the asset can no longer perform its required function.
UnderMaintenanceState - the asset is unavailable because maintenance work is being performed.

A condition-monitoring event might therefore produce:

FaultDetectedEvent91 CHANGES_STATE Pump101
Pump101 HAS_STATE DegradedState

‍If intervention begins:

MaintenanceStartedEvent88 CHANGES_STATE Pump101
Pump101 HAS_STATE UnderMaintenanceState

‍and after successful repair:

MaintenanceCompletedEvent88 CHANGES_STATE Pump101
Pump101 HAS_STATE HealthyState

‍

The important point is that there is no single mandatory sequence.

Corrective maintenance might follow:

HealthyState → FailedState → UnderMaintenanceState →HealthyState


Predictive maintenance may intervene at DegradedState and prevent failure altogether. Preventive maintenance may move an asset directly from HealthyState to UnderMaintenanceState and back again.

The state model therefore describes asset condition without imposing one maintenance strategy.

Specializing Core Relationships

The maintenance ontology can also make the broad core relationship:

Process AFFECTS Entity


more precise.

Two useful specializations are:

MAINTAINS
RESTORES


For example:

QuarterlyFillerService12
   MAINTAINS Filler201

PumpRepairExecution88
   RESTORES Pump101


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

RESTORES is narrower. It means that a process returns failed or unserviceable equipment to working condition.

A preventive-maintenance activity might therefore MAINTAIN an asset without ever needing to RESTORE it.

These relationships give applications more useful semantics than the generic statement that maintenance merely AFFECTS equipment.

Connecting Maintenance with Production

The real value of extending a common core becomes clearer when maintenance is connected to production.

The equipment being maintained may already exist in the production ontology:

Pump101 INSTANCE_OF ProductionEquipment


Maintenance does not need to create a second representation of that pump. It adds new facts about the same asset:

PumpConditionMonitoring91 AFFECTS Pump101
PumpBearingIntervention88 MAINTAINS Pump101
PumpRepairExecution88 RESTORES Pump101
Pump101 HAS_STATE HealthyState

‍


The production graph may simultaneously tell us:

Pump101 PARTICIPATES_IN MaterialTransferExecution4711


Because both domains extend the same core, an application or AI agent can traverse from an equipment problem into its production consequences:

Equipment degradation or failure → Affected production process → Affected material or order → Maintenance work order → Repair execution → Asset restored


That cross-domain reasoning is one of the main reasons for building domain ontologies as extensions of a shared core rather than as separate schemas.

Conclusion

The maintenance ontology extends the core manufacturing ontology with the vocabulary required to describe asset condition, maintenance planning, monitoring, repair, and restoration.

It introduces maintenance-specific processes, work orders, procedures, failure records, participants, capabilities, events, equipment-health states, spare parts, tools, and sensors. Relationships such as MAINTAINS and RESTORES add more precise meaning to the core AFFECTS relationship.

But the central principle is the same as in the production and quality extensions.

The core ontology defines the shared structure of manufacturing operations. The maintenance ontology adds the concepts needed to keep manufacturing assets healthy and respond when their condition deteriorates.

Because both domains remain grounded in the same core, maintenance does not become a separate semantic island. The Knowledge Graph can connect asset health and maintenance work directly to the production processes, materials, and orders that depend on those assets.

‍