DBM / CREEM Model Overview
A common runtime exchange model for IT/OT behavior

CREEM defines a four-part runtime contract: metadata identifies an object, UI information describes its presentation, data carries behavior payloads, and resources link related assets. DBM uses this model for workflow orchestration, behavior-tree execution, and AI-assisted engineering.

The same object can be read by engineering tools, executed by runtime services, and traced through lifecycle data without vendor-specific rewrites.

Core model notation
\( M = \langle Metadata, UIInformation, Data, Resource \rangle \)
\( x_{t+1} = \delta(x_t, e_t, c_t) \)
\( bind(resource, behavior) \rightarrow context_{namespace} \)
Manual-derived snapshot

Model Coverage

23 sections
Metadata types19
Locale examples35
Architecture layers4
Model Manual (Deep Dive)

The manual defines architecture layers, namespace rules, type inheritance, runtime semantics, and repository patterns. Use it when implementing or reviewing DBM-compatible artifacts.

Model-driven schema strategy

Authoring, validation, and runtime execution use the same canonical model contract, which reduces transformation loss between tools and services.

  • Metadata and UI segments are separated from payload data for tool-friendly authoring.
  • Global namespace identity is the anchor for cross-layer traceability.
  • FSM, BT, and data-table semantics cooperate in the logic fusion layer.
  • Model package boundaries preserve backward compatibility across versioned deployments.
Behavior Tree Workspace

Behavior trees remain the preferred executable projection of the model when the engineering target needs clear sequencing, retry branches, and state visibility.

Compared with a plain process script, the DBM/CREEM approach keeps ports, namespaces, and state transitions explicit, which makes the model safer to analyze and easier to reuse.

Execution contract details

Each behavior node can be analyzed by preconditions, transition triggers, and observable outcomes, which directly supports static checks and runtime diagnostics.

Model element Role
Namespace Stable identity and lookup contract.
Behavior tree Runtime sequencing and branching.
Global data table Shared context between behaviors and events.
Model Governance and Integration Readiness

This layer captures how DBM/CREEM artifacts move from design-time models to production-ready integration units. Teams can use it as a checklist before onboarding new plants, vendors, or AI services.

  • Namespace policy: stable IDs for nodes, assets, and runtime instances.
  • Type mapping policy: OT/IT protocol data mapped into reusable semantic types.
  • Validation policy: schema checks plus behavior-level safety constraints.
Readiness indicators
Schema completenessHigh
Behavior testabilityHigh
Connector portabilityMedium
Copyleft© Ciel Z • CC BY-NC-SA 4.0