Building an Energy Operations Domain Ontology in Manufacturing

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

The same approach can be applied to energy and plant utilities.

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 boilers, electricity meters, steam, energy tariffs, demand management, or peak-demand events.

Those concepts belong in an energy-domain ontology.

The purpose of the energy ontology is to introduce the vocabulary needed to describe how utilities are generated, distributed, measured, consumed, and managed across manufacturing operations, while keeping those concepts connected to the shared core.

In this example, the energy ontology covers:

• Electrical power
• Steam
• Compressed air
• Cooling water
• Utility-generation and distribution equipment
• Metering and energy monitoring
• Electrical-demand management
• Energy tariffs and demand charges
• Energy budgets and reports
• Energy-significant events
• Peak and off-peak pricing periods

The example is based on the utility operations of a ketchup-production plant, but the same extension approach can be applied across process, discrete, and hybrid manufacturing environments.

Extending the Core Ontology

The energy ontology introduces more specific concepts by making them subclasses of the core concepts.

For example:

EnergyProcess SUBCLASS_OF Process

Boiler SUBCLASS_OF Equipment

EnergyCarrier SUBCLASS_OF PhysicalEntity

EnergyTariff SUBCLASS_OF OperationalEntity

EnergyManager SUBCLASS_OF Agent

MeteringCapability SUBCLASS_OF Capability

EnergyEvent SUBCLASS_OF Event

PeakPeriodState SUBCLASS_OF State

The core remains unchanged.

It still defines the shared semantic structure of manufacturing operations. The energy ontology adds the vocabulary needed to describe the utilities that supply production and the work performed to measure and control their use.

The resulting architecture is:

Core ontology
    ↓
Energy-domain ontology

For example:

PhysicalEntity
    ├── Equipment                       (core)
    │       ├── EnergyMeter             (energy)
    │       ├── PowerMeter
    │       ├── Boiler
    │       ├── CoolingSystem
    │       └── CompressedAirSystem
    │
    └── EnergyCarrier
            ├── Electricity
            ├── Steam
            ├── CompressedAir
            └── CoolingWater

The energy ontology becomes more precise without changing the meaning of the core concepts it extends.

1. Extending the location tier with utility and metering structures

The core already divides Location into the ISA-95 levels — Enterprise, Site, Area and WorkCenter. The energy ontology extends the level that matches, and attaches directly to Location only where nothing fits:

UtilitiesArea SUBCLASS_OF Area

MeteringPoint SUBCLASS_OF Location

MeteringPoint is the exception. A metering point is finer than a work centre — often a single measurement tap on one asset — so it has no ISA-95 level to specialise and stays a direct subclass of Location.

UtilitiesArea

A UtilitiesArea is the functional area that houses the plant systems responsible for generating and distributing utilities such as:

• Steam
• Compressed air
• Cooling water
• Electrical power

An actual utilities area could later be represented as:

PlantUtilitiesArea
    INSTANCE_OF UtilitiesArea

Utility equipment can then be connected to that location:

Boiler1
    IS_LOCATED_AT PlantUtilitiesArea

AirCompressorSystem1
    IS_LOCATED_AT PlantUtilitiesArea

The concept gives the energy domain a way to identify the operational area from which utilities are generated and distributed.

MeteringPoint

A MeteringPoint is a defined place in the plant where an energy carrier is measured.

Examples include:

• The incoming electrical supply
• A submeter serving a production line
• A steam meter on a boiler header
• A compressed-air meter serving the packaging area

For example:

PackagingLinePowerPoint
    INSTANCE_OF MeteringPoint

A metering process could then be associated with that location:

PackagingPowerMetering88
    OCCURS_AT PackagingLinePowerPoint

The distinction between a meter and a metering point is important.

The meter is a physical device. The metering point identifies where in the utility network the measurement applies.

2. Extending Equipment with utility assets

The core divides PhysicalEntity on one question: does the plant operate the thing, or does it flow through? Utility plant is operated, so it attaches directly to the core Equipment class:

Boiler SUBCLASS_OF Equipment

There is deliberately no intermediate UtilityEquipment parent. The :Energy label and the /energy/ URI namespace already record which domain owns an asset, and a domain-owned parent would sit as a sibling of the production and quality equipment parents, implying a subsumption between them that does not exist.

The energy ontology defines five types of utility asset:

EnergyMeter
PowerMeter
Boiler
CoolingSystem
CompressedAirSystem

EnergyMeter

An EnergyMeter measures the consumption of an energy carrier such as:

• Steam
• Gas
• Compressed air
• Cooling water

For example:

SteamMeter12
    INSTANCE_OF EnergyMeter

The meter may participate in an energy-metering process:

SteamMeter12
    PARTICIPATES_IN SteamMeteringExecution88

PowerMeter

A PowerMeter is an electrical meter that measures:

• Active power
• Electrical demand
• Energy consumption

For example:

PackagingLinePowerMeter
    INSTANCE_OF PowerMeter

It may provide the readings used to identify peak demand or trigger demand-management actions.

Boiler

A Boiler is a fired vessel that raises steam for plant operations.

In the example plant, steam may be supplied to:

• Cook kettles
• Buffer-tank jackets
• Clean-in-place circuits

For example:

Boiler1
    INSTANCE_OF Boiler

CoolingSystem

A CoolingSystem is the chiller and cooling-water plant used to remove heat from product and equipment.

For example:

CoolingPlant1
    INSTANCE_OF CoolingSystem

It may supply cooling water to hot-filled product, cooling tunnels, and process equipment.

CompressedAirSystem

A CompressedAirSystem supplies pressurized air to pneumatic equipment.

For example:

CompressedAirPlant1
    INSTANCE_OF CompressedAirSystem

The air may be consumed by:

• Pneumatic valves
• Actuators
• Packaging machinery
• Material-handling devices

The core ontology tells us that each utility asset is a physical entity. The energy extension tells us what kind of physical entity it is and what part it plays in plant energy operations.

3. Extending PhysicalEntity with energy carriers

The energy ontology also introduces:

EnergyCarrier SUBCLASS_OF PhysicalEntity

An EnergyCarrier is a medium that delivers usable energy to a manufacturing process.

The extension defines four energy carriers:

Electricity
Steam
CompressedAir
CoolingWater

Electricity

Electricity supplies power to:

• Motors
• Production equipment
• Control systems
• Meters
• Packaging machinery

For example:

GridElectricity
    INSTANCE_OF Electricity

Steam

Steam transfers thermal energy from the boiler to production and cleaning processes.

It may be consumed by:

• Cooking
• Vessel heating
• Buffer-tank temperature control
• Clean-in-place processes

CompressedAir

CompressedAir supplies pneumatic energy to valves, actuators, and machines.

For example:

PlantCompressedAir
    INSTANCE_OF CompressedAir

CoolingWater

CoolingWater carries heat away from product and process equipment.

It may be used by:

• Cooling tunnels
• Heat exchangers
• Process vessels
• Utility systems

Representing energy carriers as physical entities allows them to participate in processes in the same way as other physical things.

For example:

Steam
    PARTICIPATES_IN CookingExecution4711

or, using the specialized energy relationship:

CookingExecution4711
    CONSUMES_ENERGY Steam

4. Extending Process with energy-management work

The energy ontology introduces:

EnergyProcess SUBCLASS_OF Process

It then defines three energy processes:

EnergyMetering
DemandManagement
LoadShedding

EnergyMetering

EnergyMetering represents reading and recording the consumption of an energy carrier at a metering point.

For example:

PackagingPowerMetering88
    INSTANCE_OF EnergyMetering

The process may involve:

• Reading the power meter
• Associating the reading with a metering point
• Recording the measurement timestamp
• Calculating interval consumption
• Publishing the reading to an energy-monitoring system

DemandManagement

DemandManagement represents coordinating electrical loads to keep total demand below a defined target.

For example:

PlantDemandManagement12
    INSTANCE_OF DemandManagement

Demand management may compare current plant demand with:

• A contractual demand limit
• An internal target
• The current billing-period peak
• A demand-charge threshold

If demand approaches or exceeds the target, the process may initiate load shifting or load shedding.

LoadShedding

LoadShedding represents deliberately reducing or curtailing non-critical loads.

For example:

LoadSheddingExecution31
    INSTANCE_OF LoadShedding

The objective is to return electrical demand below the permitted limit.

A load-shedding action might temporarily reduce or stop:

• Non-critical refrigeration loads
• Battery charging
• Auxiliary pumps
• Deferred cleaning operations
• Other flexible utility consumers

Together, the energy processes describe a demand-control lifecycle:

EnergyMetering
    ↓
DemandManagement
    ↓
Demand limit exceeded
    ↓
LoadShedding

5. Extending OperationalEntity with energy-governance artifacts

The energy ontology introduces four operational entities:

EnergyTariff
DemandChargeRate
EnergyBudget
EnergyReport

These describe the commercial and managerial context in which energy is consumed.

EnergyTariff

An EnergyTariff is the utility rate schedule that determines how energy is priced.

It may distinguish between:

• Peak pricing
• Off-peak pricing
• Time-of-use periods

For example:

PlantElectricityTariff2026
    INSTANCE_OF EnergyTariff

The tariff provides the pricing context required to translate energy consumption into cost.

DemandChargeRate

A DemandChargeRate defines the rate applied to the highest measured electrical demand during a billing period.

For example:

MonthlyDemandCharge2026
    INSTANCE_OF DemandChargeRate

This is different from the unit price of electricity.

A plant may have moderate total energy consumption but still incur a high cost if it creates a large short-duration demand peak.

EnergyBudget

An EnergyBudget defines the planned allowance for energy consumption or cost.

It may apply to:

• The entire plant
• A production area
• A line
• A utility system
• A reporting period

For example:

AugustPlantEnergyBudget
    INSTANCE_OF EnergyBudget

EnergyReport

An EnergyReport summarizes energy consumption, cost, and intensity over a period.

For example:

JulyEnergyPerformanceReport
    INSTANCE_OF EnergyReport

It might report:

• Total electricity consumption
• Steam consumption
• Peak demand
• Energy cost
• Energy per tonne produced
• Variance against budget

The energy processes can use or produce these operational entities.

For example:

PlantDemandManagement12
    IS_GUIDED_BY PlantElectricityTariff2026

PlantDemandManagement12
    IS_GUIDED_BY MonthlyDemandCharge2026

PlantEnergyAnalysisJuly
    PRODUCES JulyEnergyPerformanceReport

This creates a distinction between the commercial rules governing energy use and the evidence produced by energy-management activities.

6. Extending Agent with energy participants

The energy ontology introduces two agents:

EnergyManager SUBCLASS_OF Agent

EnergyMonitoringSystem SUBCLASS_OF Agent

EnergyManager

An EnergyManager is the person accountable for plant energy cost and efficiency.

For example:

EnergyManager1
    INSTANCE_OF EnergyManager

The energy manager may participate in:

• Energy budgeting
• Energy-performance review
• Demand management
• Load-shedding decisions
• Utility optimization

For example:

EnergyManager1
    PARTICIPATES_IN PlantDemandManagement12

EnergyMonitoringSystem

An EnergyMonitoringSystem is the software that collects meter readings, tracks demand, and reports energy performance.

For example:

PlantEnergyMonitoringSystem
    INSTANCE_OF EnergyMonitoringSystem

It may participate in an energy-metering process:

PlantEnergyMonitoringSystem
    PARTICIPATES_IN PackagingPowerMetering88

It may also participate in demand management by identifying when current demand approaches or exceeds the target.

The energy ontology defines the types of agents. Their particular responsibilities in a process can be represented through the core participation and role model.

7. Extending Capability with energy abilities

The energy ontology introduces two capabilities:

MeteringCapability
DemandControlCapability

These extend the core Capability concept.

MeteringCapability

MeteringCapability is the ability to measure and record consumption of an energy carrier at a defined point.

For example:

PackagingLinePowerMeter
    HAS_CAPABILITY MeteringCapability

The corresponding process can state:

EnergyMetering
    REQUIRES_CAPABILITY MeteringCapability

This allows an application or AI agent to determine which meters or monitoring systems can perform a required measurement.

DemandControlCapability

DemandControlCapability is the ability to keep electrical demand below a limit by curtailing or shifting loads.

For example:

PlantEnergyMonitoringSystem
    HAS_CAPABILITY DemandControlCapability

The demand-management process can require it:

DemandManagement
    REQUIRES_CAPABILITY DemandControlCapability

This creates the reusable core pattern:

EnergyProcess
    REQUIRES_CAPABILITY
Capability
    possessed by
Agent or PhysicalEntity

The capability model separates what a system is able to do from the particular demand-management process it is currently executing.

8. Extending Event with energy-significant occurrences

The energy ontology introduces:

EnergyEvent SUBCLASS_OF Event

It then defines four energy events:

PeakDemandReached
TariffChanged
DemandLimitExceeded
MeterReadingTaken

MeterReadingTaken

MeterReadingTaken records that a consumption or demand reading was captured from a meter.

For example:

MeterReadingEvent882
    INSTANCE_OF MeterReadingTaken

The event may occur during an energy-metering process:

MeterReadingEvent882
    OCCURS_DURING PackagingPowerMetering88

PeakDemandReached

PeakDemandReached records that the plant established a new peak demand during the billing period.

For example:

PeakDemandEvent31
    INSTANCE_OF PeakDemandReached

The event is important because it may increase the demand charge applied to the billing period.

TariffChanged

TariffChanged records that the applicable energy price changed.

For example:

PeakTariffStartedEvent
    INSTANCE_OF TariffChanged

The event may indicate a transition from off-peak to peak pricing.

DemandLimitExceeded

DemandLimitExceeded records that measured demand rose above the defined target.

For example:

DemandLimitExceededEvent31
    INSTANCE_OF DemandLimitExceeded

The event may occur during demand management and trigger load shedding:

DemandLimitExceededEvent31
    OCCURS_DURING PlantDemandManagement12

Together, these events provide the temporal evidence required to reconstruct energy operations:

MeterReadingTaken
    ↓
DemandLimitExceeded
    ↓
LoadShedding

or:

TariffChanged
    ↓
PeakPeriodState begins
    ↓
Demand-management strategy changes

9. Extending State with tariff periods

The energy ontology introduces two states:

PeakPeriodState
OffPeakPeriodState

Every state class in the ontology ends in State. Classes share one namespace, and the natural name for a state is also the natural name for the event that causes it — TariffChanged the event against the period it produces — so the suffix keeps the two apart.

These extend the core State concept directly, unlike most states. The core divides State into five scopes that say whose lifecycle a condition belongs to — EquipmentState, ProcessState, OrderState, WorkOrderState and MaterialState. A tariff period fits none of them: it is a condition of time, not of any equipment, process, order or material. It therefore has no lifecycle owner and stays a direct child of State, which is a deliberate exception rather than an oversight.

PeakPeriodState

PeakPeriodState represents a time window during which energy is priced at the peak rate and demand charges apply.

For example:

PlantElectricitySupply
    HAS_STATE PeakPeriodState

OffPeakPeriodState

OffPeakPeriodState represents a time window during which electricity is priced at a reduced rate.

For example:

PlantElectricitySupply
    HAS_STATE OffPeakPeriodState

A tariff-change event can indicate the transition:

PeakTariffStartedEvent
    CHANGES_STATE PlantElectricitySupply

PlantElectricitySupply
    HAS_STATE PeakPeriodState

The state affects how an energy-management agent interprets consumption.

The same quantity of electricity may have a different financial impact depending on whether it is consumed during a peak or off-peak period.

10. Specializing the core relationships

The energy ontology introduces two specialized relationships:

CONSUMES_ENERGY
METERED_BY

CONSUMES_ENERGY

The core defines:

Process AFFECTS Entity

The energy ontology specializes this with:

Process CONSUMES_ENERGY PhysicalEntity

In practice, the target physical entity is an EnergyCarrier.

For example:

CookingExecution4711
    CONSUMES_ENERGY Steam

PackagingExecution882
    CONSUMES_ENERGY Electricity

CappingExecution91
    CONSUMES_ENERGY CompressedAir

CONSUMES_ENERGY is more precise than the general statement:

CookingExecution4711
    AFFECTS Steam

It explains that the process draws usable energy from the carrier.

The ontology therefore defines:

CONSUMES_ENERGY SPECIALIZES AFFECTS

METERED_BY

The energy ontology also defines:

Entity METERED_BY PhysicalEntity

The target physical entity is normally an EnergyMeter or PowerMeter.

For example:

PackagingExecution882
    METERED_BY PackagingLinePowerMeter

Steam
    METERED_BY SteamMeter12

The relationship identifies the meter used to measure an energy carrier or process.

The current source ontology models METERED_BY as a specialization of PARTICIPATES_IN. Conceptually, however, this mapping should be reviewed.

The core PARTICIPATES_IN relationship connects:

Entity → Process

while METERED_BY connects:

Entity → PhysicalEntity

Its domain, range, and direction therefore do not align cleanly with the core relationship it claims to specialize.

A cleaner model may treat METERED_BY as a new energy-domain relationship grounded in core concepts rather than forcing it to specialize PARTICIPATES_IN.

For example:

METERED_BY
Domain: PhysicalEntity, Agent
Range: PhysicalEntity

This would preserve its meaning without creating an inconsistent relationship hierarchy.

Note that METERED_BY does specialize PARTICIPATES_IN in the implemented ontology, and its domain is therefore constrained to be no wider than its parent's: PhysicalEntity and Agent, but not OperationalEntity. A specialization that accepted a domain its parent forbids would be incoherent.

A complete energy example

The resulting energy ontology can support a graph such as:

Boiler1
    INSTANCE_OF Boiler

Steam
    INSTANCE_OF Steam

CookingExecution4711
    INSTANCE_OF ProductionProcess

CookingExecution4711
    CONSUMES_ENERGY Steam

Boiler1
    PARTICIPATES_IN SteamGenerationExecution12

Metering can then be represented as:

SteamMeter12
    INSTANCE_OF EnergyMeter

SteamMeter12
    HAS_CAPABILITY MeteringCapability

SteamMeteringExecution88
    INSTANCE_OF EnergyMetering

SteamMeteringExecution88
    REQUIRES_CAPABILITY MeteringCapability

SteamMeter12
    PARTICIPATES_IN SteamMeteringExecution88

Steam
    METERED_BY SteamMeter12

MeterReadingEvent882
    INSTANCE_OF MeterReadingTaken

MeterReadingEvent882
    OCCURS_DURING SteamMeteringExecution88

Electrical-demand management may be represented as:

PackagingLinePowerMeter
    INSTANCE_OF PowerMeter

PlantEnergyMonitoringSystem
    INSTANCE_OF EnergyMonitoringSystem

PlantEnergyMonitoringSystem
    HAS_CAPABILITY DemandControlCapability

PlantDemandManagement12
    INSTANCE_OF DemandManagement

PlantDemandManagement12
    REQUIRES_CAPABILITY DemandControlCapability

PlantEnergyMonitoringSystem
    PARTICIPATES_IN PlantDemandManagement12

PlantDemandManagement12
    IS_GUIDED_BY PlantElectricityTariff2026

PlantDemandManagement12
    IS_GUIDED_BY MonthlyDemandCharge2026

When demand exceeds the target:

DemandLimitExceededEvent31
    INSTANCE_OF DemandLimitExceeded

DemandLimitExceededEvent31
    OCCURS_DURING PlantDemandManagement12

LoadSheddingExecution31
    INSTANCE_OF LoadShedding

EnergyManager1
    PARTICIPATES_IN LoadSheddingExecution31

LoadSheddingExecution31
    PRODUCES DemandResponseReport31

The graph is specific to energy operations, but its major concepts remain grounded in the core ontology.

For example:

LoadSheddingExecution31
    INSTANCE_OF LoadShedding
    SUBCLASS_OF EnergyProcess
    SUBCLASS_OF Process

and:

PackagingLinePowerMeter
    INSTANCE_OF PowerMeter
    SUBCLASS_OF Equipment
    SUBCLASS_OF PhysicalEntity

Connecting energy with production and maintenance

One of the main benefits of extending a shared core is that energy operations do not remain isolated from production.

A production process may consume an energy carrier:

CookingExecution4711
    CONSUMES_ENERGY Steam

PackagingExecution882
    CONSUMES_ENERGY Electricity

The production ontology may show which equipment participates in those processes:

CookKettle101
    PARTICIPATES_IN CookingExecution4711

Filler201
    PARTICIPATES_IN PackagingExecution882

The energy ontology may show how those processes are metered:

CookingExecution4711
    METERED_BY SteamMeter12

PackagingExecution882
    METERED_BY PackagingLinePowerMeter

An AI agent can therefore connect energy use directly to operational context:

Energy consumption
    ↓
Production process
    ↓
Equipment
    ↓
Product and production order

This enables questions such as:

Which production process consumed the most energy per tonne of product?

Or:

Which loads can be delayed without affecting the current production order?

The maintenance ontology can also provide important context.

For example, rising power consumption may be connected to equipment degradation:

Pump101
    PARTICIPATES_IN MaterialTransferExecution91

MaterialTransferExecution91
    CONSUMES_ENERGY Electricity

Pump101
    HAS_STATE DegradedState

An agent could use this information to investigate whether an increase in energy intensity is associated with a maintenance problem rather than normal production demand.

Conclusion

The energy ontology extends the core manufacturing ontology with the concepts needed to describe how plant utilities are supplied, consumed, measured, and managed.

It introduces vocabulary for:

• Utility areas and metering points
• Meters, boilers, cooling systems, and compressed-air systems
• Electricity, steam, compressed air, and cooling water
• Energy metering, demand management, and load shedding
• Energy tariffs, demand-charge rates, budgets, and reports
• Energy managers and monitoring systems
• Metering and demand-control capabilities
• Energy-significant events
• Peak and off-peak pricing periods

It also introduces the specialized relationships:

CONSUMES_ENERGY
METERED_BY

CONSUMES_ENERGY cleanly refines the core AFFECTS relationship by expressing how a process uses an energy carrier.

METERED_BY expresses a useful energy-domain relationship, but its current specialization of PARTICIPATES_IN should be reviewed because its domain and range do not align with the core relationship.

The central principle remains:

The core ontology defines the shared structure of manufacturing operations. The energy ontology extends that structure with the concepts and relationships required to understand where energy comes from, how it is consumed, what it costs, and how its use can be managed.

This allows energy data to become part of the same operational knowledge graph as production, quality, maintenance, and inventory, rather than remaining isolated in utility meters and monthly reports.