How to read the diagram
The diagram separates definition from execution. The concentric model on the left is the CREEM Schema: it defines the type system and the rules used to construct a valid model. The Meta Base Structure in the center is the conformance boundary. It converts schema types into instance structures without discarding identity, inheritance, metadata, or extension rules. The right side is the CREEM Instance: it binds a validated model to workflows, software services, devices, files, operators, analytics stores, and asset interfaces.
The solid horizontal path is the primary type-resolution path. A domain-specific type resolves through type-tree mapping and the core inheritance tree before it reaches the metadata type and meta-structure contract. Dotted lines show mappings, generated projections, and runtime associations. Filled connection points mark explicit interfaces where an implementation must preserve identity, type, status, and provenance.
Schema side: three levels of specialization
| Schema level | Contents shown in the figure | Technical responsibility |
|---|
| Core Layer | Global Namespace, Finite State Machine, Type Inheritance Tree, Base Objects, Meta Information | Defines stable identity, lifecycle state, subtype rules, common object semantics, and descriptive fields. Every higher-level object must resolve to these contracts. |
| Common Domain Layer | Global Data Table, Global Status Code, IoT Behavior Tree, Workflow DSL, Workflow Description, low-code and 3D mappings | Adds execution concepts that recur across industries. It standardizes shared state, status propagation, workflow composition, and scene-to-model binding without assuming a specific plant domain. |
| Domain Specific Layer | Domain types, architecture, scene models, planners, service builders, compiler and interpreter specifications | Specializes the common contracts for an engineering discipline or facility. A domain package may add types and tools, but it cannot bypass core identity, inheritance, or lifecycle semantics. |
The A1 to A5 core anchors
The five numbered anchors form the minimum semantic kernel. Each answers a separate runtime question. If an implementation collapses them into a generic object, validators cannot distinguish identity errors from state, type, object-model, or metadata errors.
| Anchor | Question answered | Runtime consequence |
|---|
| A1: Global Namespace | Which object is this? | Supplies a stable address across packages, repositories, workflows, scenes, and protocol adapters. Local vendor identifiers remain aliases; the global namespace holds the canonical identity. |
| A2: Finite State Machine | What lifecycle state is the object in? | Defines allowed transitions and terminal outcomes. Behavior Tree nodes can schedule work, while the FSM rejects calls that violate the current state. |
| A3: Type Inheritance Tree | Which contract does the object satisfy? | Resolves inherited ports, constraints, capabilities, and validation rules. Type-tree mapping uses this anchor to compare heterogeneous source models. |
| A4: Base Objects | Which common object semantics are available? | Provides reusable roots for resources, data, events, functions, and composite structures, so adapters do not invent a new object model for each protocol. |
| A5: Meta Information | What evidence describes this object? | Carries version, ownership, source, language, timestamps, quality, and governance data required for audit and controlled deployment. |
Meta Base Structure: the conformance boundary
The center of the diagram defines the conformance model used by every serializer and API. Meta Data Type specifies the fields and primitive constraints available to a model. Meta Structure specifies how those fields form objects, references, compositions, and extension points. Internationalisation and extensibility also belong at this boundary. Language variants and domain additions therefore travel with the model contract instead of sitting in application-specific side data.
A model crosses this boundary only after namespace resolution, inheritance checks, required-field checks, reference validation, and extension validation succeed. The result is a typed instance that tools can exchange without agreeing on one authoring application. This is also the correct boundary for schema version migration: migration changes the typed structure first, then regenerates dependent views and bindings.
Instance side: digital description and execution
| Instance subsystem | Objects in the figure | Execution role |
|---|
| Authoring inputs | Natural Language, UML/SysML, Flowchart, BPMN2, Prototype, SOP | Produce candidate structures and workflow definitions. Schema and policy validation decide whether the generated objects can enter the runtime model. |
| Digital Description | Workflow, Resource Tree, FB Library, Resource Library | Holds the executable process graph and the resource references it can resolve. Library entries are versioned definitions; workflow nodes bind to concrete resources at deployment or dispatch time. |
| IT Resource | IT Device, Server, Software, File, Asset Interface, Microservices | Hosts services, model files, APIs, and enterprise-side execution. The asset interface translates CREEM operations into native service calls while retaining status and provenance. |
| OT Resource | OT Device, Protocol Manager, Human, OT File, Asset Interface | Represents the controlled operational boundary. Protocol managers perform transport and data conversion; the model still enforces capability, state, and authorization constraints. |
| FB Encapsulation Level | Application Template, Skill, Behavior, Instruction | Defines increasing execution specificity. Templates compose reusable solutions, skills expose capabilities, behaviors coordinate stateful actions, and instructions bind to executable endpoints. |
| Semantic and data services | Semantic Domain Model, Semantic Ontology, Core Repository, OLTP, OLAP, AAS | Connect operational identity to domain meaning, current transactions, historical analysis, and Asset Administration Shell representations. The Workflow Runtime remains responsible for state transitions and dispatch. |
Runtime resolution path
At execution time, Workflow Canvas selects a workflow node and resolves its namespace against the Resource Tree. The resolver checks the node's inherited type and required Function Block contract, chooses a compatible IT or OT asset interface, and verifies the target FSM state. The Workflow Runtime then dispatches the call. Status codes and output values return to the Global Data Table, while the instance records the resource identity, model revision, timestamps, and result. A failure therefore remains attributable to a particular model version, adapter, endpoint, and state transition.
The standards along the lower boundary connect through adapters. Mapping contracts translate IEC 61131, IEC 61499, OPC UA, and ROS 1/2 data into CREEM types without changing the native control programs. AAS exposes the resulting asset identity and submodel views. CREEM then supplies the common type, behavior, and evidence contract used by the services above those systems.
Technical abstraction in LaTeX notation
\( Schema = (N, T, O, F, M), \quad T_d \preceq T_c \preceq T_{core} \)
\( Instance = instantiate(Schema, bindings, extensions) \)
\( target = resolve(namespace, inherited\_type, capability, state, policy) \)
\( S_{t+1}, C_{t+1}, E_t = \delta(S_t, C_t, event_t, binding_t) \)
