Why We Built an Ontology Engine Instead of Another Rules System

Every IoT platform has a rules engine. We built something different: a 252-entity OWL ontology that understands what equipment is, not just what values it reports.

The Problem with Rules

Traditional industrial alarm systems work like this:

IF temperature > 80°C THEN alert

This works until it doesn't:

• False alarms: A pump starting up briefly spikes to 82°C. Is it failing, or just warming up? The rule doesn't know.
• Rule explosion: 100 equipment types × 20 parameters × 5 thresholds = 10,000 rules to maintain
• No context: "Pressure low" means different things for a water pump (cavitation) vs an oil well (depletion)
• Fragile thresholds: Each plant tunes its own thresholds. Nothing transfers between sites.

At Daqing Oil Field, false alarm rates exceeded 20% with the old rules-based system. Operators learned to ignore alarms — which defeats the entire purpose.

The Ontology Approach

An ontology models the structure of industrial equipment:

Pump ⊑ Equipment ⊓ ∃hasPart.Bearing ⊓ ∃measures.Pressure
Bearing ⊑ Component ⊓ ∃hasFailureMode.Overheat
Overheat → triggers(Alert) ∧ reduces(RemainingLife, 0.8)

When our platform reads a pressure value of 2.35 MPa, it doesn't just compare against a threshold. It knows:

1. This is a pump (not a valve, not a compressor)
2. The pump has a bearing
3. Bearings fail by overheating
4. Combined with vibration data, this pattern matches "bearing wear stage 2"
5. The recommended action is "schedule maintenance within 14 days" — not "sound alarm now"

The DLAS Architecture

We formalized this as a four-layer stack:

DATA     Parse (23 classes) · PostgreSQL · TDengine · EMQX
LOGIC    Ontology Engine · Model Registry · 3 ETS Tables
ACTION   Shadow (gen_statem) · MQTT · Rule Engine  
SECURITY JWT · RBAC · ACL/CLP · Audit Log

The key innovation: the ontology compiles to Erlang pattern matches. Each OWL axiom becomes native code. Reasoning happens at runtime speed — not query speed.

% OWL: Overheat → triggers(Alert)
handle_event(#event{type = overheat, device = Pid}, State) ->
    case ontology:class_of(Pid) of
        bearing ->
            {next_state, alert, schedule_maintenance(State)};
        _ ->
            {next_state, normal, State}
    end.

Shadow Devices: The State Machine Layer

Every physical device has a digital twin — a gen_statem process that mirrors its lifecycle:

init → auth → online → {normal, alarm, offline}

The shadow absorbs network chaos:

• Gateway drops offline for 30 seconds? Shadow holds state, retries silently.
• Device sends contradictory readings? Shadow evaluates against the ontology before propagating.
• Firmware updates? Shadow freezes state, swaps, resumes — no downtime.

This is why we run 928 gateways with 99.9999% uptime on a 10-person team.

Real Results

The false alarm reduction alone saved an estimated $2.3M in year one at Daqing.

When to Use Which

We still ship a rules engine. But for anything with mechanical structure — pumps, turbines, compressors, breakers — the ontology wins.

Try It

The full platform is open source (Apache 2.0):

git clone https://github.com/dgiot/dgiot.git
cd dgiot && docker-compose up -d

The ontology engine is in apps/dgiot_ontology/. Docs at docs/DGAIOT_ONTOLOGY.md.

Liu Shouxin is the founder of DGIOT. He's spent 20 years on industrial IoT, previously at EMQ and Huawei. The ontology approach came from his master's thesis at Zhejiang University — 22 years before it shipped in production.