24 Digital Twin Worked Examples
Apply Twin Decisions Without Letting the Model Drift
24.1 Start Simple
Start with one decision that would be safer if a live model stayed aligned with the physical system. In Digital Twin Worked Examples, the practical question is what state must be synchronized, who acts on it, and what evidence proves the twin is still fit to use.
24.2 Learning Objectives
By the end of this chapter, you will be able to:
- Build a worked-example record for a digital twin decision.
- Select replication and buffering patterns for different kinds of twin state.
- Design edge-first failover behavior for actions that cannot wait for cloud services.
- Apply a process-quality twin without confusing monitoring with optimization.
- Scope a building comfort twin around zones, schedules, equipment, and verification.
- Identify which assumptions must be checked before adapting a worked example. ## Worked Example Method {.depth-l1}
Each example in this chapter uses the same structure.
1. Decision State the physical or operational decision the twin should improve.
2. Scope Define the asset, system, process, fleet, or lifecycle record included in the model.
3. Evidence List the telemetry, events, inspections, relationships, and history required to keep the model current.
4. Model Explain what the twin estimates, predicts, simulates, or coordinates.
5. Feedback Choose display, alert, recommendation, approval workflow, or automatic command.
6. Verification Compare the physical outcome against the baseline and the model prediction.
24.3 Remote Asset State Replicas
24.3.1 Scenario
A remote asset fleet has local controllers, a site gateway, and a cloud service. Operators need current asset state for decisions, but the network can be intermittent. The twin must preserve important events, answer recent-state queries, and continue local protection when the wide-area link is unavailable.
24.3.2 Decision
Which state must remain available locally, which state must be replayed later, and which state can be summarized?
24.3.3 Scope
One fleet, several site gateways, asset-level twins, event logs, and a cloud history store.
24.3.4 Reasoning
24.3.5 Current State
Replicate the latest operating mode, health state, alarm state, command status, and freshness metadata at the site gateway.
24.3.6 Event History
Buffer alarms, state transitions, inspections, and command acknowledgements with timestamps and sequence numbers.
24.3.7 Raw Telemetry
Aggregate or compress high-volume measurements unless the decision requires full-resolution evidence.
24.3.8 Adaptation Checklist
- Does the local controller have enough state to protect the asset without the cloud?
- Which events must never be overwritten by a newer summary?
- How long can the site buffer operate during disconnection?
- What does the cloud do with late-arriving events?
- Which displayed values must show stale or replayed status?
Replicate by decision criticality, not by data volume. Current safety state, command acknowledgements, and event history are more important than copying every raw measurement everywhere.
24.4 Safety Action Failover
24.4.1 Scenario
A building service twin monitors a shared equipment room. A safety-relevant event occurs while the site gateway is degraded. The local controller must act according to approved rules, and the wider twin must reconstruct the timeline after connectivity returns.
24.4.2 Decision
Which actions must execute locally without waiting for a remote service?
24.4.3 Scope
One equipment room, local controller, site gateway, alarm events, command log, and operator notification path.
24.4.4 Reasoning
Detect locally The local controller evaluates the critical condition using direct evidence and approved rules.
Act within guardrails The controller applies only actions that are pre-approved for the degraded state.
Record the event trail The controller stores observation time, action time, command status, and confirmation status.
Synchronize after recovery The wider twin replays the event trail, marks the gateway outage, and reconciles the physical outcome.
24.4.5 Adaptation Checklist
- Which physical actions are allowed during degraded communication?
- Which actions require human approval even during an emergency?
- Which local evidence is authoritative?
- What command acknowledgements prove that the physical system acted?
- What should the dashboard show while the site gateway is degraded?
Do not design safety-relevant action paths that require a remote service to be reachable. The wider twin can coordinate, record, and verify, but the immediate protection path must be local.
24.5 Example 3: Process Quality Twin
24.5.1 Scenario
A production cell has repeated operations with measurable inputs, process settings, equipment state, and quality outcomes. The team wants the twin to recommend whether to keep the current recipe, adjust a parameter, or hold the batch for review.
24.5.2 Decision
Should the process run with the current settings, adjust within approved limits, or pause for review?
24.5.3 Scope
One process cell, recipe settings, machine state, material batch, environmental context, and quality check results.
24.5.4 Reasoning
24.5.5 Evidence Window
Use only the time window that can affect the current decision. Old data is useful for training, but current state needs fresh evidence.
24.5.6 Model Output
Separate quality risk, model confidence, and recommended action. A low-confidence result should not silently trigger an action.
24.5.7 Feedback Path
Start with advisory recommendations. Move toward automatic adjustment only after the recommendation record is trusted and bounded.
24.5.8 Verification
Compare predicted risk, chosen action, actual quality result, and any operator override.
24.5.9 Adaptation Checklist
- Which settings can be changed safely without re-approval?
- Which variables are causes, and which are only symptoms?
- How is operator override recorded?
- When does the model become degraded?
- How are bad recommendations used to improve the model?
24.6 Comfort and Scheduling Twin
24.6.1 Scenario
A teaching building has rooms, schedules, HVAC zones, occupancy evidence, air quality readings, and comfort complaints. The twin should recommend whether to pre-condition rooms before occupancy and identify which zone may need inspection.
24.6.2 Decision
Which spaces should be conditioned before scheduled use, and which equipment should be checked?
24.6.3 Scope
Rooms, zones, equipment, schedule, occupancy, comfort state, air quality, and recent work orders.
24.6.4 Reasoning
24.6.5 Relationship Model
Rooms connect to zones, zones connect to equipment, equipment connects to maintenance records, and schedules connect to occupancy expectations.
24.6.6 Prediction
The model estimates whether a room will be ready at occupancy time under the current equipment state and schedule.
24.6.7 Recommendation
The twin recommends pre-conditioning, inspection, or no action. The operator approves changes that affect comfort or energy use.
24.6.8 Verification
Compare predicted readiness with observed conditions and complaint records after occupancy begins.
24.6.9 Adaptation Checklist
- Does the model know which equipment serves each space?
- Are schedules trustworthy enough to drive recommendations?
- Which comfort and air-quality thresholds are policy decisions?
- How does the twin handle missing occupancy evidence?
- How are complaints tied back to rooms, zones, and equipment?
24.7 Pattern Summary
24.7.1 Replicate State
Use for remote assets and intermittent networks. Preserve critical current state and replayable events.
24.7.2 Fail Over Locally
Use for safety-relevant actions. Keep approved rules and command confirmation at the edge or site.
24.7.3 Optimize Process Quality
Use for repeated operations. Keep recommendation, confidence, action, and outcome as separate records.
24.7.4 Schedule Comfort
Use for spaces and equipment. Model relationships between rooms, zones, schedules, and complaints.
24.7.5 Label the Diagram
24.8 Common Mistakes
Worked examples are not deployment guarantees. Reuse the decision structure, evidence checks, conflict rules, and verification plan. Recalculate any local capacity, timing, cost, or performance assumptions with your own data.
A live dashboard can support a worked example, but optimization requires a model output, a feedback path, and outcome verification.
If a gateway is down, a sensor is stale, or the model is extrapolating, the worked example must show how the twin warns users and limits action.
24.9 Practice Checks
- A remote site has intermittent connectivity. Which data should be local current state, replayable event history, and summarized telemetry?
- A safety-relevant command was issued locally during an outage. What evidence is needed when the wider twin reconnects?
- A process model recommends changing a setting but reports low confidence. What feedback path should be used?
- A building comfort twin predicts a room will be ready, but complaints arrive after occupancy. Which model records should be reviewed?
24.10 References and Further Reading
- Digital Twin Consortium. Digital Twin Capabilities Periodic Table. Useful for capability vocabulary and trust considerations.
- ISO 23247 series. Automation systems and integration – Digital Twin framework for manufacturing. Useful for manufacturing examples and viewpoints.
- ISO/IEC/IEEE 42010. Architecture description. Useful for documenting assumptions, stakeholders, and viewpoints.
- W3C Web of Things Thing Description. Useful for properties, actions, events, and affordances in connected systems.
24.11 Adapt Patterns, Not Numbers
If you only need the working rule, use this layer: a digital twin worked example transfers when the decision, evidence, model, feedback, and verification pattern still match the new system.
Read each example as an architecture record rather than a recipe. The remote-asset example separates current state, replayable events, and compressed telemetry. The failover example separates immediate local protection from later synchronization. The process-quality example separates prediction, confidence, recommendation, and observed quality. The building-comfort example separates spaces, zones, equipment, schedules, and complaints. Those separations are the reusable lesson.
The values do not transfer automatically. A new site needs its own freshness budget, state authority, sequence-number rule, stale-data display, feedback level, approval owner, baseline, and outcome check. If the example assumes a site gateway, a historian, a building management system, or an operator approval path, replace that assumption with the real system and owner in the target environment.
A useful adaptation therefore names what stays invariant and what must be remeasured. Invariant pieces are the decision pattern and proof loop. Local pieces are timing, asset relationships, data quality, control authority, cost of being wrong, and the threshold for changing from display to advisory, approval-gated, or automatic action.
Decision
Keep the physical decision visible: preserve state, act locally, adjust a process, or schedule a space.
Evidence
Replace every example assumption with local telemetry, events, inspections, sequence numbers, and baseline outcomes.
Verification
Do not finish at the recommendation. Compare the predicted result, selected action, physical outcome, and adaptation limit.
24.12 Practitioner: Write The Transfer Record
Before reusing one of the chapter examples, write a short transfer record that names what stays the same and what must be remeasured. That record is what prevents a useful example from becoming a copied deployment claim.
Use four columns: example assumption, local replacement, evidence source, and acceptance test. For a remote-asset twin, the assumption might be a gateway cache similar to MQTT retained topics or a device-shadow pattern. The local replacement should name the actual controller, gateway, event buffer, timestamp source, sequence-number field, and replay rule. The acceptance test should prove that a late alarm, command acknowledgement, or inspection event is not overwritten by a newer summary.
For a process-quality twin, the transfer record should name the MES, SCADA system, historian, recipe identifier, material batch record, quality inspection, and operator override record used at the target cell. For a building-comfort twin, it should name the BMS/BACnet points, room-zone-equipment mapping, calendar feed, occupancy evidence, complaint channel, CMMS work order link, and approval owner. This turns the example from a story into a checkable integration plan.
Finish the record with a short failure rehearsal. Walk through an outage, stale sensor, missing schedule, low-confidence model result, and operator override. The rehearsal should say what the learner or operator sees, which actions are blocked, which actions are advisory only, and what evidence will be reviewed after the physical outcome is known.
Keep the record small enough to review in a design meeting. If a field cannot be filled with a real source system, owner, or test, mark it as an assumption and do not promote the example into a production control path.
Example pattern
Building comfort twin. Decision: pre-condition rooms before occupancy. Feedback: recommendation to the facilities operator. Verification: compare predicted readiness, observed conditions, complaints, and energy impact.
Local replacement
Replace the example schedule, zone map, equipment state, complaint baseline, air-quality threshold, approval owner, and action limit with the values from the target building.
24.13 Why Worked Examples Mislead
A worked example can be correct and still mislead a new deployment when the hidden assumptions are different.
The first failure mode is state semantics. A worked example may say "replicate state" while hiding whether the state is authoritative, cached, inferred, replayed, or stale. Last-write-wins updates can erase a late event if clocks drift, and timestamp sorting can misorder events from disconnected controllers. A defensible twin needs a source-of-truth rule, monotonic sequence or version fields where possible, idempotent replay, and visible freshness status.
The second failure mode is model transfer. A process-quality model trained on one recipe, material stream, operator practice, or maintenance regime may not represent another cell even when the sensors look similar. The transfer record should separate causal variables from correlated symptoms, record the training or calibration window, and define the drift signal that downgrades the model from recommendation to observation.
The third failure mode is control authority. An example that was safe as a dashboard can become risky when copied into automatic action. Under the hood, feedback level changes the safety case: advisory feedback needs explanation and acceptance tracking, approval-gated feedback needs an accountable owner and audit trail, and automatic feedback needs guardrails, rollback behavior, and a verified fallback state.
That is why the example's proof must include negative cases. The twin should show how it behaves when evidence is late, contradictory, outside the training envelope, or available only from a lower-trust system.
- Timing mismatch: the example tolerates delayed synchronization, but the new action needs current local state.
- Authority mismatch: the example uses advisory feedback, but the new system would issue automatic commands.
- Evidence mismatch: the example has reliable inspections, sequence numbers, or complaint logs that the new site does not collect.
- Baseline mismatch: the example verifies against a known outcome rate, but the new team has no measured starting point.
24.14 Summary
In this chapter, you learned:
- Worked examples should transfer reasoning, not fixed outcome claims.
- Replication should separate current state, replayable events, summaries, and raw telemetry.
- Safety-relevant actions need local approved behavior and later synchronization.
- Process-quality twins need prediction, confidence, action, and outcome records.
- Building comfort twins depend on room, zone, equipment, schedule, and complaint relationships.
- Verification and adaptation limits are part of every reusable worked example.
24.15 What’s Next
| If you want to… | Read this |
|---|---|
| Study digital twin architecture | Digital Twin Architecture |
| Select use case patterns | Digital Twin Use Cases |
| Compare industry applications | Digital Twin Industry Applications |
| Learn synchronization and modeling | Digital Twin Sync and Modeling |
| Test your understanding | Digital Twin Assessment Lab |
24.16 Key Takeaway
Worked examples should show the full twin loop: physical asset data, state model, synchronization, analysis, decision, and validation. Without that loop, the example is only a visualization.