An industrial asset model and a telemetry schema should not share one lifecycle. The asset model answers what an entity is, where it belongs, and how it relates to other entities. The telemetry schema answers which fields an event carries, how values are typed and qualified, and which compatibility rules consumers may rely on. A separate binding contract connects the logical asset and signal to the physical source. These contracts may live in one repository or one administration screen, but they should not be forced to publish under one version whenever a machine moves, a gateway is replaced, or a sampling policy changes.
The practical test is not whether two JSON documents can be merged. Ask who approves a change, which consumers must revalidate it, and how it can be rolled back. If moving a compressor to another production line forces a time-series writer to accept a new payload version, or adding an optional temperature point forces maintenance authorization to upgrade, unrelated lifecycles have been coupled. Conversely, if the asset graph and signal definitions are separated without an auditable binding, the platform cannot explain which physical source makes bearing_temperature_c a property of a particular compressor. A sound design uses independent versions, explicit bindings, and joint release validation.
Start with one replacement that is really four different changes
Consider a logical asset named compressor-C17. It belongs to Line A, is maintained by the utilities team, and reports discharge pressure and vibration through gateway gw-04. Six months later, the plant moves the compressor to Line B. It then replaces the gateway, adds a bearing-temperature point, and raises vibration sampling from 1 Hz to 10 Hz. These actions are often described as “updating the device model,” but they affect topology, physical source identity, event structure, and delivery capacity respectively.
In a coupled contract, the asset tree, device connection, signal fields, units, sampling rate, and MQTT topic share one modelVersion. Every action appears to be a full model upgrade. Maintenance routing, tenant authorization, stream validation, time-series storage, and alarm evaluation cannot tell from that version which dependency changed, so all consumers must be revalidated.
The local evidence for this article models seven consumers across the asset, telemetry, and delivery-policy boundaries. It replays four changes: moving the asset, adding a signal, replacing the gateway, and increasing sampling. The deliberately coupled design produces 28 consumer revalidations; the separated design produces 13 based on explicit dependencies. These counts belong only to the fixture and are not a production cost or reliability benchmark. The useful result is that a contract boundary can express “not affected,” rather than proving a universal percentage of savings.
The asset model preserves identity and business relationships
The asset model exists to preserve object continuity. It should hold a stable asset_id, asset type, organizational and spatial placement, parent-child or composition relationships, maintenance ownership, lifecycle status, and a limited set of slowly changing properties required by business queries. It should not make an event's sourceTimestamp, current sampling frequency, or MQTT payload fields part of asset identity.
The OPC UA AddressSpace represents objects, types, and references that clients can browse, and OPC UA modelling guidance describes an Information Model as a contract between applications. The lesson is not that every platform must store a NodeSet. It is that object types, instances, and relationships carry durable semantics, so changes to them affect clients that depend on those semantics. Moving a compressor from Line A to Line B changes an asset-graph relationship. If the signal meaning remains the same, telemetry consumers should not be forced to parse a new payload contract.
An asset model is also not a bucket for every latest value. Rated motor power, installation date, and maintenance class can be slow-changing properties. Per-second current, vibration, and temperature belong in a state or time-series layer. Writing high-rate observations into the asset master record creates unnecessary write pressure for cache, audit, authorization, and graph queries. It also obscures the difference between configured state and the latest observation.
The telemetry schema defines event evidence, not the equipment directory
A telemetry schema defines how a class of messages is interpreted. At minimum, it should state an event type or schema ID, version, signal fields, data types, engineering units, nullability, quality semantics, source and receive time, and compatibility policy. It may reference a stable asset_id or source_id, but it should not repeat the entire asset hierarchy or all organizational properties in every event contract.
JSON Schema can validate object structure using properties, required, and additionalProperties, but structural validity does not prove semantic validity. A JSON field temperature: 72 could be Celsius, Fahrenheit, a setpoint, or an observation. Industrial telemetry therefore needs signal identity, unit, clock ownership, and quality status in addition to structural rules. W3C WoT Thing Description similarly distinguishes Thing-level metadata, interaction affordances, event data schemas, and protocol forms. The Thing and the data exchanged during an interaction are related, but they are not the same design question.
The telemetry schema should also be separated from delivery policy. Increasing vibration sampling from 1 Hz to 10 Hz may leave every payload field unchanged while altering bandwidth, queue, window, retention, storage, and alarm-computation assumptions. If sampling rate is embedded in the asset model version, the capacity team loses an independently reviewable policy change. If it is embedded in the payload schema, a rate change may be mistaken for a structural incompatibility. A versioned delivery policy for cadence, retention, and routing QoS makes capacity approval and rollback more explicit.
The binding contract connects logical signals to physical sources
Once the asset model and telemetry schema are separated, the system must still explain why a source represents a signal on an asset. That explanation belongs in a binding contract. A useful binding includes asset_id, logical signal_id, physical source_key, telemetry schema and version, mapping or conversion version, activation time, and deactivation time. It must be auditable and replayable so that a gateway replacement can preserve logical asset continuity.
For example, compressor-C17.discharge_pressure may initially bind to gw-04/modbus/40001, then bind to gw-09/opcua/ns=4;s=Pressure after replacement. The asset ID and business queries remain stable while the physical source changes. If the data type or engineering unit also changes, the release includes a new telemetry schema or mapping version. The platform can distinguish “same asset, new connection” from “changed signal meaning,” avoiding both a duplicate asset and a false continuation of an incompatible time series.
flowchart LR
A("Asset model
identity · type · relationships"):::blue --> C("Binding contract
asset + signal + source + version"):::orange
B("Telemetry schema
fields · units · time · quality"):::cyan --> C
D("Delivery policy
cadence · routing · retention"):::violet --> C
C --> E("Trusted state and time series"):::green
C --> F("Alarms, analytics, and operations"):::slate
classDef blue fill:#EAF4FF,stroke:#3B82F6,color:#16324F,stroke-width:2px;
classDef cyan fill:#E9FBF8,stroke:#14B8A6,color:#134E4A,stroke-width:2px;
classDef orange fill:#FFF3E8,stroke:#F08A24,color:#7C3F00,stroke-width:2px;
classDef violet fill:#F4EDFF,stroke:#8B5CF6,color:#4C1D95,stroke-width:2px;
classDef green fill:#ECFDF3,stroke:#22C55E,color:#14532D,stroke-width:2px;
classDef slate fill:#F8FAFC,stroke:#64748B,color:#1F2937,stroke-width:2px;
The diagram does not require four isolated microservices. It describes four contracts that can be evaluated independently. A small team may store them in one database, Git repository, or administration page, provided each has its own version, owner, compatibility policy, and change record. Physical deployment can be consolidated; semantic and release boundaries still need to remain visible.
Four changes reveal the real blast radius
| Change | Contract that should change | What should remain stable | Primary validation |
|---|---|---|---|
| Move the compressor from Line A to Line B | Asset relationship | Payload fields and units | Search, maintenance routing, authorization |
| Add bearing temperature | Telemetry schema and binding | Asset parent-child relationships | Stream validation, time-series write, alarms |
| Replace the physical gateway | Binding; schema if semantics change | Logical asset ID | Mapping, continuity, deduplication |
| Raise sampling from 1 Hz to 10 Hz | Delivery policy | Asset graph; schema if fields are unchanged | Capacity, windows, retention |
The table changes the release question from “did the model change?” to “which contract changed?” A line move can still record the active binding version, but it does not require every historical payload to be interpreted as a new format. An optional signal addition does not need to change the maintenance hierarchy, while telemetry consumers must decide how they handle unknown fields, new time-series columns, and default alarm behavior. A gateway replacement may change source identity, clock semantics, and quality status together; the binding and schema can be released jointly without sharing one version number.
The review is not trying to make two tables look identical. It verifies auditable evidence between identity, signal meaning, physical source, and activation version.
Assign version ownership to the team that owns the consequence
Domain or asset-governance owners normally approve asset-model changes because those changes affect organization, authorization, maintenance, and business queries. Protocol-integration and data-platform teams normally own telemetry schemas because they control parsing, validation, units, quality, and compatibility. Field integration or onboarding creates bindings, but production activation should require both the asset and data contracts to validate. Delivery policy needs joint approval from platform capacity and the business owner of latency.
Versioning should reflect consequence. Adding an optional slow-changing asset property can be a compatible minor release. Removing a relationship type, changing stable-ID semantics, or tightening a mandatory field usually needs a migration. Adding an optional telemetry field can allow new producers to deploy first. Removing a field or changing type, unit, or clock semantics normally requires a new major schema or event type. A binding record should not be overwritten; it needs an effective interval so historical data can be traced to the physical point and conversion active at that time.
Compatibility cannot remain a sentence in a design document. The release pipeline should run fixtures for old producer to new consumer, new producer to old consumer, unknown and missing fields, unit changes, duplicates, and out-of-order events. Asset validation should check stable IDs, orphan nodes, illegal cycles, relationship rules, and authorization inheritance. Joint validation then proves that asset_id + signal_id + schema_version + binding_version resolves to one meaning.
Co-location is acceptable; a shared lifecycle is the risk
Small systems do not need four services for architectural purity. When device types are few, the same team owns all changes, release cadence is similar, and consumer count is limited, keeping asset, signal, and connection declarations in one repository or file can be reasonable. The file should still expose assetModelVersion, telemetrySchemaVersion, and bindingVersion, and its tooling should be able to release only the affected contract. Otherwise “same repository” gradually becomes “same approval, same rollback, same blast radius.”
A prototype can start coupled if it preserves extraction points. Stable asset IDs should not be generated from MQTT topics. Logical signal IDs should not be database column names. Physical source keys should not leak into business queries. Sampling policy should not become an immutable asset-type constant. These decisions make later separation a release-process change instead of an identity rewrite.
If the platform only performs short-lived collection and has no graph relationships, maintenance ownership, inherited authorization, or long-term identity continuity, a full asset graph may be excessive. A minimal device registry plus a strict telemetry schema may be enough. Conversely, a maintenance-oriented twin with low-rate data may not need a complex streaming schema registry. Contract boundaries should follow actual consumers, not architecture fashion.
Microsoft's DTDL illustrates why serialization capability and service lifecycle are separate questions. A DTDL interface can describe properties, relationships, and components, while Azure Digital Twins documents service-specific behavior for telemetry and state. A standard can place several concepts in one language; a platform still has to decide who owns each change and how it is released.
Migrate the coupled model without rewriting everything at once
First freeze the meaning of the existing contract rather than splitting storage immediately. Classify each field by whether it serves asset queries, message parsing, source mapping, or capacity policy. Identify ambiguous shared fields such as deviceId, name, frequency, and path. Preserve the old reader through a compatibility adapter so that the separation does not silently change historical interpretation.
Next introduce a stable asset_id, logical signal_id, and binding_version. New messages can carry these identifiers without changing business meaning; an adapter can enrich legacy events. Separate asset-relationship releases from telemetry-schema releases and maintain dependency manifests for each. Retire the coupled contract only after dual-write, replay, and query reconciliation pass.
Finally, turn the four change scenarios into continuous tests. Moving an asset must not change the payload version. Adding an optional signal must not change the asset ID. Replacing a gateway must preserve logical time-series continuity while retaining source provenance. Raising sampling must pass capacity and window checks before activation. These tests are closer to production risk than validating that one large model file is syntactically valid.
For the identity and release chain below these contracts, read Industrial Tag Modeling and Governance. For placement from field to platform, see Layering the Industrial Telemetry Pipeline. If connected data still cannot safely drive alarms and analytics, see Brownfield Industrial Data Quality.
Final decision
Separating the asset model from the telemetry schema is not about creating more files. It prevents unrelated changes from sharing one blast radius. The asset model preserves durable objects and relationships. The telemetry schema preserves event structure and interpretation. Delivery policy governs cadence and capacity. The binding contract provides the auditable connection between logical signal and physical source. They may share a repository, user interface, or service, but they need independent versions, approvals, and rollback with joint validation before production activation.
If a team cannot answer whether a change affects asset consumers or data consumers, adding more digital-twin fields will not fix the ambiguity. Start with three version identifiers and one effective-dated binding, then test line moves, signal additions, gateway replacements, and rate increases. A scalable industrial model proves not only who is affected, but also who is not.
References
- OPC UA Part 3: Node Model
- OPC UA Modelling Best Practices: Overview
- W3C Web of Things Thing Description 1.1
- JSON Schema: Object
- Microsoft Learn: DTDL models in Azure Digital Twins
FAQ
Can the asset model contain current state?
It can contain a limited derived current state or slowly changing property, but the value should retain its telemetry and binding provenance. The asset master should not become a high-rate time-series store.
If DTDL or a Thing Description contains data schemas, why separate anything?
A representation language defines what can be expressed. It does not determine organizational ownership, version cadence, or release blast radius. Concepts can share a document while remaining independently versioned contracts.
When is a schema registry necessary?
It becomes valuable when producers and consumers deploy independently, event types multiply, and compatibility failures can contaminate state or alarms. A small single-team system can begin with versioned schemas in Git and CI.