Dynamic Behavior Modeling (DBM) is an executable industrial behavior-modeling approach derived from CREEM. It describes how assets act, exchange data, and change state over time under runtime constraints.

Static information models describe assets and their properties. DBM also defines behavior subjects (RD), behaviors (FB), behavior composition (WF), execution semantics (BT + FSM), and runtime data exchange (DT).

For each behavior, DBM records who acts, which behavior is available, how actions are composed, which data is exchanged, and which runtime state the node reports. It can therefore drive execution as well as describe an engineering system.

Generate bilingual CREEM namespaces for industrial elements. The tool uses exact matches from the DeepDive Manual when available and applies naming rules to unknown elements.

• Input either English or Chinese, for example: collaborative robot, PLC, industrial camera, or conveyor.
• The tool returns the most likely RD namespace and a matching set of behavior namespaces.
• Results explicitly tell you whether the output was aggregated from the manual or logically generated from CREEM naming rules.

DBM addresses the practical gap between engineering-time descriptions and runtime execution in heterogeneous AI/IT/OT environments.

• Unifies behavior subject, behavior definition, execution logic, and data exchange under one model.
• Bridges business processes, IT workflows, and OT control behaviors in one executable structure.
• Supports frequent line changeovers and high-mix low-volume production without hard-coded logic.
• Improves traceability and interoperability across legacy systems through namespace and type mapping.
• Makes asynchronous equipment behavior explicit through tick, halt, exception, timeout, and retry semantics.
• Provides a DT blackboard so FB ports, HMI, historian, MES, digital twin, and AI agents can reference the same runtime values.

DBM is used by engineering teams and by software that consumes its structured semantics.

• Industrial architects and system integrators designing cross-domain solutions.
• OT/IT engineers authoring and operating workflows.
• Factory operations teams needing runtime-adjustable process logic.
• AI agents and software tools that consume structured semantics for planning, simulation, and orchestration.

DBM inherits CREEM's four-layer scope: Foundation Layer, Core Layer, Logic Fusion Layer, and Knowledge Repository Layer.

It models active behavioral elements and their execution semantics. Passive elements can be referenced, but the model focus is on entities that can perform or trigger behavior.

DBM is a compatibility surface, not a mandate to replace existing standards. Vendor systems can keep their native standards while mapping into a shared runtime model.

• Phase 1: consolidate base semantics (namespace, type tree, basic objects, FSM/BT execution rules).
• Phase 2: expand behavior libraries and reusable cross-domain workflow templates.
• Phase 3: complete static scene and dynamic behavior holography with digital twin alignment.
• Phase 4: strengthen agentic interoperability and runtime data-plane capabilities for industrial AI.

Author & Usage Statement: DBM was authored by Zhen Hua Zhou. SIEMENS provides funding. This work is intended for research, registered Siemens eco-partners, and internal Siemens use.

DBM grew out of CREEM research and engineering work, including smart-factory projects in several industries.

Special thanks to engineering, runtime, and domain teams that contributed practical feedback on interoperability, maintainability, and runtime reliability.

Most existing industrial information models describe static semantics well: asset identity, hierarchy, attributes, units, protocol mapping, documentation, and lifecycle metadata.

• Object/asset hierarchies and metadata definitions are usually complete.
• Runtime behavior composition, state progression, and cross-system orchestration are often fragmented across tool stacks.
• Different standards cover different layers, but end-to-end executable consistency is usually externalized to custom middleware.
• Dynamic behaviors often remain hidden inside PLC programs, robot jobs, MES rules, scripts, simulation models, or proprietary workflow engines.

DBM works with those models through namespace, type, parameter, resource, file, and content references. It adds an explicit behavior-execution layer above them.

• Static model and runtime orchestration are disconnected.
• Cross-standard interaction often relies on ad-hoc, project-specific adapters.
• Dynamic behavior tracing and replay are hard to maintain consistently.
• Extending to new devices, DSLs, and AI workflows typically increases integration cost.
• Execution states are not represented uniformly, so a robot command, a PLC step, an API call, and an AI inference job cannot be monitored through the same lifecycle contract.
• Data references are often tool-local instead of namespace-addressable, making audit, replay, simulation, and agent reasoning difficult.

I tried extending various existing information models, but ultimately could not find one that solved the dynamic-behavior problem end to end. Many standards can describe assets and properties, but they do not consistently describe how heterogeneous behaviors are composed, ticked, pre-empted, recovered, and observed at runtime.

The new framework is intended to be non-intrusive for brownfield environments: existing PLC code, robot programs, OPC UA nodes, AAS submodels, BPMN fragments, CAD/BIM files, AI services, and enterprise systems can remain in place. DBM adds a semantic orchestration layer above them by wrapping external logic as Function Blocks and binding them with namespace-addressable parameters.

This dynamic layer complements existing standards and supports prediction, simulation, optimization, replay, and AI-assisted orchestration.

In my definition, a model is intrusive when other systems must adopt or understand it before standardization, communication, or interoperability can work. Adoption may require teams to learn the model or modify existing product firmware and software. Intrusive models are often incompatible with competing model systems. By this definition, almost all existing industrial standards and models are intrusive.

A non-intrusive model does not require other systems or their developers to understand it. A middleware layer or orchestrator translates between the participating systems. To remain non-intrusive, that layer must interoperate with existing models through loose coupling.

Technically, this means DBM keeps strong contracts at the edge and loose coupling underneath: ResourceRef binds assets, ParameterRef binds ports and DT values, and external graphical or textual languages are encapsulated as FBs instead of forcing every tool to adopt one internal execution format.

Yes. AI increases the need for explicit models because reliable orchestration still depends on deterministic boundaries, typed interfaces, and state-safe execution semantics.

Models provide the shared contract that allows AI-generated plans to execute safely across heterogeneous industrial assets. A language model may propose a plan, but the industrial runtime still needs resource capability, input/output type, engineering units, safety state, timeout policy, retry strategy, and a deterministic response when an action returns FAIL.

DBM gives AI systems a structured reasoning surface while keeping final execution deterministic: AI can select, parameterize, or optimize workflows, but BT/FSM/DT semantics constrain the actual runtime behavior.

DBM provides AI-readable and machine-executable semantics in the same structure.

• AI can reason over assets, behaviors, and workflow constraints through structured metadata.
• The runtime executes behavior trees and FSM transitions deterministically.
• The global data table and namespace system provide stable references for agentic decision loops.
• AI models, inference services, and industrial agents can themselves be represented as RD categories and invoked through FB contracts.
• Prompt templates, ONNX/SafeTensors models, MCP manifests, APIs, and datasets can be indexed as resources and referenced from workflows.

DBM grew from practical attempts to model and orchestrate dynamic industrial behaviors across IT and OT without replacing entire ecosystems.

CREEM now provides the shared semantic foundation for this work. DBM remains the research direction focused on dynamic behavior.

Both. DBM contributes foundational abstractions such as global namespace, type inheritance, RD/FB/WF object boundaries, ResourceRef/ParameterRef binding, Industrial Behavior Tree semantics, and the four-state FB lifecycle.

It is also applied research because the abstractions are evaluated against real industrial constraints: brownfield integration, controller compatibility, asynchronous equipment, safety stops, operator intervention, data historian projection, workflow deployment, and cross-domain AI/IT/OT collaboration.

The model maps to established standards rather than competing with them. Current adaptation targets include IEC 61499, IEC 61131, OPC UA, AAS, MTP, ISA-95, and BPMN/UML-related ecosystems.

The work focuses on interoperability surfaces: meta-structure, namespace, types, units, status codes, and execution-logic mapping. The type tree can map to PLC types, OPC UA, ROS 2/DDS, JSON Schema, Protobuf, and Avro. RD identifiers can bind to CAD, BIM, USD/glTF, URDF/SDF, AAS references, and OPC UA nodes.

Existing graphical languages remain usable. FBD/CFC, SFC/statecharts, flowcharts, ladder, BPMN fragments, and AI pipeline graphs can be packaged as FBs or imported into equivalent BT subtrees. Industrial Behavior Tree remains the canonical orchestration layer.

This project is primarily written in JavaScript, so the OpenJS Foundation is the most obvious potential affiliation. We have not contacted the relevant foundations yet. The project targets industrial applications rather than JavaScript language infrastructure, so we first need to check whether their existing projects cover this kind of use case.

This project also includes WASM-based implementations for a web-based physical engine. That part is not currently planned for open source. If that changes, we would consider contacting the Bytecode Alliance.

A future contribution to WebGL-related standards could involve contacting the Khronos Group about membership.

DBM implementation follows a model-to-runtime path:

• Model behavioral subjects as Resource Descriptions (RD) and behaviors as Function Blocks (FB).
• Bind assets and behaviors through parameters, capability abstraction, and namespace references.
• Compose executable workflows through Industrial Behavior Trees and FSM state transitions.
• Exchange runtime data through the global data table and connectors to existing IT/OT systems.
• Declare timing, reentrancy, timeout, and recovery characteristics in FB metadata so the scheduler can execute predictably.

• RD: behavioral subject abstraction.
• RT: weak aggregation tree for RD instances; it can represent containment, composition, connection, or hierarchy.
• FB: user-facing atomic executable behavior, regardless of internal implementation granularity.
• WF: composed behavior process and minimum serviceable unit.
• DT: global shared data space, FB port blackboard, and projection surface.
• FSM/BT: deterministic lifecycle, traversal, pre-emption, retry, and recovery semantics.