INDUSTRIAL KNOWLEDGE GRAPH / DBM

Industrial semantics
for data-driven runtime.

An industrial ontology should answer more than "what is this?" It must also expose what an asset can do, which state it is in, what constrains the action, and where the evidence came from.

Identity
identifier + model version
Behavior
typed capability contract
Evidence
source + time + quality

LIVE SEMANTIC FIELD / THREE.JS

Traverse the plant as a graph

36 nodes68 relations
Embodied graph operatorLoading
WASD moveShift run
CLICK SCENE / WASD OR ARROWS TO WALK / ESC TO RESET
Asset identity Executable capability Runtime state Evidence and provenance

SEMANTIC RESOLUTION

A query returns a traceable result

FEDERATED MAPPING

Federate standards through versioned mappings.

Keep domain models under their own governance. Publish mappings as versioned products with assumptions, cardinality, transformation rules, provenance, and tests.

  • 01Preserve the source identifier and authoritative owner.
  • 02State whether a mapping is exact, narrower, broader, or conditional.
  • 03Reject a mapping when context or evidence is insufficient.
Source conceptRelationTarget contractGate
OPC UA::PumpTypenarrowerasset:CentrifugalPumpvalidated
ISA95::Equipmentconditionalasset:ProductionResourcecontext
DEXPI::ProcessInstrumentexactasset:Instrumentapproved
AAS::Capabilitybroadercapability:FunctionBlockreview
IEC61850::LogicalNodeconditionalasset:ControlComponentprofile
Each row is versioned, testable, and reversible.mapping-product:v1.4.2

OPEN IMPLEMENTATION PATH

Open-source RDF and graph tools

License labels apply to the linked repositories. Connectors, datasets, ontology content, plugins, and hosted services may use different terms.

Industrial Ontology Prototype
Dynamic Behavior Ontology Built on DBM
From Static Domain Vocabulary to Executable Industrial Semantics

Most industrial ontologies name assets, properties, documents, and relationships. Runtime integration needs more: capabilities, current state, dependencies, permitted actions, preconditions, and the control system that authorizes execution.

DBM connects those concepts to runtime definitions. A Resource Description identifies the subject, a Function Block describes a callable capability, a Workflow composes the process, and a Data Table carries shared context. Behavior trees define tick-driven control flow, while finite-state machines define states and transitions. Determinism depends on the model and runtime.

Core ontology shift
  • Entity concepts link to behavior definitions.
  • Properties supply typed runtime context.
  • Relations identify dependencies that the runtime may enforce.
  • Events record state transitions with provenance.
Agent query context
  • What is this asset?
  • Which actions are permitted, and who authorizes them?
  • What state is it in?
  • What evidence supports the action?
Behavior Ontology Layers

A DBM-based ontology can be read as four connected layers. Each layer keeps a clear responsibility, but all layers are bound by namespace, type inheritance, resource reference, and runtime trace identity.

LayerSemantic role
Asset ontologyDefines resources, hierarchy, location, ownership, equipment type, and engineering identity.
Capability ontologyDefines functions, ports, parameters, preconditions, postconditions, and service contracts.
State ontologyDefines lifecycle states, alarms, quality status, safety mode, failure mode, and recovery paths.
Workflow ontologyDefines behavior composition, sequence, fallback, parallelism, timeout, escalation, and evidence capture.

A runtime can interpret validated graph mappings as behavior definitions and record execution history. The ontology itself remains a semantic model; execution belongs to the runtime.

Fusion with Domain Ontology Standards

DBM links concepts from industrial standards to behavior definitions and runtime contracts. Each source standard keeps its own identifiers, scope, version, and governance.

  • ISA-95 / IEC 62264: enterprise-control integration concepts such as enterprise, site, area, work center, work unit, personnel, equipment, material, production schedules, and production responses.
  • ISA-88 / IEC 61512: batch-control concepts such as recipes, procedures, unit procedures, operations, phases, equipment modules, and control modules.
  • OPC UA: object nodes, variables, methods, events, information models, and server-side runtime connectivity.
  • Asset Administration Shell: asset identity, submodels, semantic IDs, properties, capabilities, and lifecycle documentation.
  • DEXPI / P&ID: process equipment, pipelines, valves, instruments, nozzles, loops, and topology-aware engineering relations.
  • BIM / Digital Twin: spatial hierarchy, geometry, system topology, maintenance context, and visual scene binding.
Ontology Contract for Industrial AI Agents
Context package

The agent receives a graph-backed package containing asset identity, domain type, location, current state, related documents, live values, alarms, and historical traces.

Behavior package

Capabilities are exposed as typed Function Blocks with input/output ports, preconditions, postconditions, safety limits, timeout policy, and allowed execution mode.

Evidence package

Every recommendation or action can cite model version, source mapping, runtime event, data quality, confidence, approval status, and replayable decision history.

The ontology defines terms and DBM maps them to runtime behavior. Execution traces record decisions and outcomes for review.