24 Digital Twins Across Industries
-
When does the digital model stop matching the cold store?
24.1 Start Simple
Build the Twin Around One Field Choice
Imagine a cold store that has a digital model of each room. The model can show temperature, door state, and cooling demand. It is useful only if a worker knows when that view is fresh enough to protect the stock.
Start with one decision, such as whether to move food or call for repair. Name the physical thing, the facts needed, their source and time, the action owner, and the harm of a wrong answer. Leave out detail that cannot change this choice.
Latency means the time from a physical event to the result that needs it. Set a limit for each fact. A monthly energy study can wait. A warming alarm cannot. Show age and doubt beside the model rather than drawing an old state as current.
Keep identity, unit, quality, and software version with each update. Record which side may change a setting and how the other side learns the result. If both sides change while apart, write the rule for conflict before the break happens.
Test a stuck sensor, wrong clock, lost link, late work order, and replaced unit. Compare the model with a field check. Count wrong actions, missed warnings, catch-up time, and support work.
Now ask whether the same pattern transfers to a ship, farm, factory, or hospital. The decision, time limit, owner, and harm may all change. Reuse the method, not an untested promise.
Give the view to the person who will act. Ask them to find the newest fact, its age, the open doubt, and the safe next step. If they cannot, simplify the view before adding more detail.
Keep a known field case for later checks. Run it after a model, sensor, or service change. Compare both the answer and the stated doubt. A new version should not gain confidence without new proof.
End the trial by taking one asset out of service. The model should close or mark its record. It must not leave a retired unit looking live.
A twin is a bounded decision aid, not a perfect copy of the world. Practitioner builds the industry record. Under the Hood explains model drift, synchronization, authority, and why evidence from one field may fail in another.
Start with one decision that would be safer if a live model stayed aligned with the physical system. In Digital Twins Across Industries, 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:
- Map common digital twin patterns to manufacturing, buildings, healthcare, cities, energy, and logistics.
- Distinguish monitoring twins, simulation twins, optimization twins, and lifecycle twins.
- Explain why sector examples should be evaluated with proof rather than copied as fixed value stories.
- Build an industry application record with decision owner, model scope, data sources, feedback loop, and verification method.
- Identify common application mistakes such as dashboard-only twins, weak synchronization, and uncontrolled automation.
24.3 Application Patterns
Industry examples are easiest to compare when they are grouped by what the twin is asked to do.
Before application Patterns, inspect Figure 24.1 to compare “Twin” with “future risk”. Their juxtaposition makes digital twin industry patterns visible.
Read Figure 24.1 from “Twin” to “future risk”. Taken together, “Twin” and “future risk” express digital twin industry patterns. For application Patterns, the observed relationship between “Twin” and “future risk” is evidence that “Twin” carries into the next decision.
24.3.1 Monitor
Represent current asset, process, or environment state so operators can see what is happening now and whether the model is synchronized.
24.3.2 Predict
Use recent and historical records to estimate future condition, demand, degradation, or risk before it becomes visible in operations.
24.3.3 Simulate
Test a proposed change, treatment, route, schedule, or configuration in the virtual model before changing the physical system.
24.3.4 Optimize
Recommend better settings, maintenance windows, dispatch plans, energy schedules, or process parameters based on model records.
24.3.5 Coordinate
Connect several systems or teams through a shared model so decisions at one level do not conflict with decisions elsewhere.
24.3.6 Trace Lifecycle
Preserve the digital thread from design, commissioning, operation, maintenance, change, and retirement.
A digital twin application is not proven by a sector label such as smart city or Industry 4.0. It is proven by a decision record: what decision changed, what model supported it, what records synchronized the model, what action was taken, and what outcome was observed.
24.4 Sector Patterns
24.4.1 Manufacturing and Industrial Assets
Manufacturing twins commonly model equipment condition, production flow, quality, energy, and maintenance windows. They are useful when the system has repeated operations, observable state, and expensive disruptions.
24.4.2 Typical Model Scope
- Machine, line, cell, plant, or fleet
- Vibration, temperature, current, quality, cycle state, and maintenance records
- Product route, process recipe, and equipment configuration
24.4.3 Useful Decisions
- Which asset needs inspection?
- Which process setting should change?
- Which batch is at risk?
- Which maintenance window protects production?
Design guidance: keep fast control loops local, synchronize state to the plant or enterprise twin, and treat the cloud model as an analysis and coordination layer rather than the only operational source of truth.
24.4.4 Buildings and Campuses
Building twins usually connect spaces, occupants, equipment, comfort, energy, maintenance, and safety workflows. Their value often comes from hierarchy: room, floor, building, site, and portfolio views can use the same operating records differently.
24.4.5 Typical Model Scope
- Room, floor, building, campus, or property portfolio
- Occupancy, HVAC state, lighting, air quality, alarms, schedules, and work orders
- Relationships between spaces, equipment, zones, and users
24.4.6 Useful Decisions
- Which zone needs service?
- Which rooms can be conditioned differently?
- Which equipment affects several spaces?
- Which planned change should be simulated before work begins?
Design guidance: define the spatial hierarchy and equipment relationships before connecting analytics. Without that relationship model, the twin becomes a collection of sensor charts rather than a building decision system.
24.4.7 Healthcare and Life Sciences
Healthcare twins can represent equipment, clinical workflows, facilities, or patient-specific models. Patient-centered twins require stronger governance because the model may influence care decisions.
24.4.8 Typical Model Scope
- Medical device, operating room, care pathway, or patient-specific anatomy or physiology
- Imaging, device telemetry, clinician annotations, lab results, and workflow events
- Assumptions, confidence, provenance, and approval status
24.4.9 Governance Need
- Clinical ownership
- Validation against representative proof
- Privacy and consent controls
- Clear separation between decision support and automated clinical action
Design guidance: make the model boundary explicit. A patient-specific simulation is not the same thing as a hospital operations twin, and neither should be used beyond its validated purpose.
24.4.10 Cities and Public Infrastructure
City and infrastructure twins combine geography, assets, movement, weather, utilities, maintenance, and planning scenarios. They often need multiple levels of detail because modeling everything at maximum fidelity is not practical.
24.4.11 Typical Model Scope
- Road corridor, utility network, district, bridge, campus, or city service
- GIS layers, sensors, inspections, traffic, weather, asset condition, and service requests
- Scenario assumptions and stakeholder constraints
24.4.12 Useful Decisions
Read these decisions from service continuity toward change control. Start by asking which route or closure would reduce the observed disruption, then use asset condition and inspection evidence to set priority. Only after those immediate choices are bounded should the twin be used to compare development scenarios or rehearse emergency response. This order connects the model to an accountable public-service decision instead of treating simulation as an end in itself.
- Which route or closure plan reduces disruption?
- Which assets need inspection first?
- Which proposed development changes risk?
- Which emergency response plan should be rehearsed?
Design guidance: use multi-fidelity modeling. Keep high detail where an active decision is being made, and use lower detail for context elsewhere.
24.4.13 Energy, Utilities, and Grid Operations
Energy twins connect physical assets, weather, demand, control constraints, maintenance, and planning. They support both real-time awareness and longer-horizon investment decisions.
24.4.14 Typical Model Scope
- Feeder, substation, generation asset, microgrid, building portfolio, or field network
- Load, generation, weather, topology, alarms, maintenance, and switching state
- Operating limits and safety constraints
24.4.15 Useful Decisions
Use the energy twin to move from risk detection to a safe operating response. Identify the asset approaching a limit, compare only scenarios that preserve electrical and safety constraints, and schedule maintenance against the resulting outage exposure. Finish by naming which local control remains authoritative when upstream coordination is unavailable. That sequence keeps simulation, maintenance, and degraded operation tied to the same current topology and operating-state evidence.
- Which asset is approaching risk?
- Which operating scenario should be simulated?
- Which maintenance plan reduces outage exposure?
- Which local control should continue when upstream systems are unavailable?
Design guidance: separate real-time control, operational coordination, and planning simulation. A planning twin can be slower and richer; a control twin must be bounded and validated.
24.4.16 Logistics and Supply Networks
Logistics twins model movement, inventory, equipment, hubs, constraints, and disruption. They are useful when decisions depend on the relationship between local operations and a larger network.
24.4.17 Typical Model Scope
- Warehouse, route, vehicle, port, hub, supplier network, or product flow
- Orders, inventory, equipment state, transport events, service levels, and disruption signals
- Constraints such as capacity, temperature, availability, and priority
24.4.18 Useful Decisions
- Which route should change after a disruption?
- Which inventory needs priority movement?
- Which equipment bottleneck threatens service?
- Which scenario should be rehearsed before a seasonal peak?
Design guidance: decide how stale a model can be before a recommendation is unsafe. Logistics twins often depend on event freshness and exception handling more than geometric detail.
24.5 Proof Loop
A reusable industry twin pattern is a loop, not a one-time model build.
Before proof Loop, inspect Figure 24.2 to compare “APPROVAL” with “command”. Their juxtaposition makes digital twin proof loop visible.
Read Figure 24.2 from “APPROVAL” to “command”. Taken together, “APPROVAL” and “command” express digital twin proof loop. For proof Loop, the observed relationship between “APPROVAL” and “command” is evidence that “APPROVAL” carries into the next decision.
24.6 Pattern Selection Guide
Use the application constraint to choose a primary pattern, then combine patterns when the deployment needs more than one capability.
| Constraint | Primary pattern | Proof needed |
|---|---|---|
| High-frequency equipment state | Edge-cloud hybrid | Local filtering, anomaly rules, retained raw samples, upload policy |
| Cross-domain facility decisions | Hierarchical model | Spatial model, equipment relationships, shared identifiers, owner map |
| High-consequence physical change | Simulation before intervention | Model assumptions, validation data, approval workflow, rollback plan |
| City or portfolio scale | Multi-fidelity model | Level-of-detail policy, active decision area, update cadence |
| Long asset lifecycle | Digital thread | Design records, commissioning baseline, maintenance history, change control |
| Network-wide disruption planning | Scenario twin | Event data, constraints, alternatives, response playbook |
Most real deployments combine patterns. A warehouse twin may use edge filtering for conveyor telemetry, a hierarchical site model for equipment and zones, simulation for layout changes, and a lifecycle record for maintenance history. The point is to choose the combination deliberately rather than collecting technology features.
24.7 Industry Application Record
Use this record when evaluating a case study or planning a deployment.
24.8 Comfort and Energy Twin
A campus team wants one twin to support occupant comfort, HVAC maintenance, and energy planning. The team has room sensors, equipment alarms, space schedules, and work-order history.
24.8.1 Decision Walkthrough
24.8.2 Model Scope
Room, zone, air-handling unit, floor, building, and campus. The relationships matter more than a photorealistic view.
24.8.3 Decisions
Pre-condition spaces, flag comfort anomalies, prioritize equipment service, and compare energy scenarios before changing schedules.
24.8.4 Governance
Automation can adjust comfort settings inside approved limits. Maintenance tickets and major schedule changes require human approval.
24.8.5 Decision Record
| Field | Example entry |
|---|---|
| Primary pattern | Hierarchical model with scenario simulation |
| Record sources | Room conditions, occupancy events, equipment status, schedule data, work orders |
| Synchronization risk | Missing occupancy updates can cause incorrect comfort or energy decisions |
| Action path | Twin recommends schedule and equipment checks; approved actions update building controls |
| Verification | Compare comfort complaints, equipment alarms, and energy trend before and after the change |
| Failure mode | If model freshness is weak, fall back to conservative local control and flag the twin as stale |
This example avoids universal savings assertions. The value is measured in the campus team’s own baseline, outcome, and governance record.
24.9 Common Mistakes
24.9.1 Copying A Sector Story
An aircraft, city, hospital, or factory example does not transfer automatically. Copy the pattern and proof discipline, not the published numbers.
24.9.2 Building A Visualization First
A polished 3D scene can help communication, but it does not prove synchronization, prediction, simulation, or action quality.
24.9.3 Ignoring Model Freshness
A stale twin can make confident wrong recommendations. Every application needs a freshness rule and a visible stale-state behavior.
24.10 Practice Checks
24.11 References
- ISO 23247 series, digital twin framework for manufacturing.
- ISO/IEC 30173, digital twin concepts and terminology.
- NIST guidance on cyber-physical systems and smart manufacturing systems.
- buildingSMART and related open data modeling work for built-environment information exchange.
- ETSI and industry guidance on edge computing where local processing supports twin synchronization and decision paths.
24.12 Translate Sector Stories
If you only need the selection shortcut, this layer is enough: do not copy a published industry example as a promise. Translate it into a decision pattern, model scope, records, feedback path, and verification rule for your own domain.
The same headline can hide different work. A manufacturing twin may focus on line throughput, defect prediction, tool wear, or changeover rehearsal. A building twin may focus on comfort, energy, maintenance, occupancy, or emergency response. A city twin may focus on traffic, flooding, air quality, construction disruption, or public-service coordination. The useful question is not which sector sounds advanced; it is which physical decision has enough current records and authority to improve.
Start by translating the sector story into a reusable pattern: monitor current state, predict a future state, simulate alternatives, optimize an action, coordinate several systems, or trace lifecycle evidence. Then decide whether the feedback is display-only, advisory, approval-gated, or automatic control. That feedback level determines the proof burden. A display twin can tolerate more uncertainty than a twin that changes a production setpoint, dispatches a maintenance crew, or reroutes vehicles.
Local evidence still wins over sector vocabulary. Before adopting a published example, name the baseline, data freshness rule, source system, owner, action record, and outcome check that would prove the pattern in your environment.
Before translate Sector Stories, inspect Figure to compare "INCREASES" with "Governance". Their juxtaposition makes across sectors, a twin is useful when it scopes a decision, synchronizes trustworthy evidence, tests alternatives, records the action, verifies the outcome, and updates the model visible.
Read Figure from "INCREASES" to "Governance". Taken together, "INCREASES" and "Governance" express across sectors, a twin is useful when it scopes a decision, synchronizes trustworthy evidence, tests alternatives, records the action, verifies the outcome, and updates the model. For translate Sector Stories, the observed relationship between "INCREASES" and "Governance" is evidence that "INCREASES" carries into the next decision.
Pattern
Name whether the twin monitors, predicts, simulates, optimizes, coordinates, or traces lifecycle state.
Decision
State what changes in the physical workflow: inspection priority, schedule, route, setting, service window, or scenario plan.
Proof
Keep baseline, synchronization quality, action record, owner approval, model error, and measured outcome together.
24.13 Prove Campus Building Twin
For the campus comfort, maintenance, and energy twin, the industry label is not the proof. The proof is that the hierarchy, records, and feedback path support a bounded building decision before the team scales to a portfolio.
A practical campus record connects the physical hierarchy to operational systems. The hierarchy may come from BIM or buildingSMART IFC data, but the live decision usually depends on building management system points, BACnet equipment names, occupancy schedules, service-desk complaints, CMMS work orders, and energy meters. The twin should make the room, zone, air-handling unit, meter, work order, and complaint identifiers traceable instead of treating them as separate dashboards.
The first deployment should choose one decision, such as pre-conditioning rooms before scheduled use or prioritizing a failing air-handling unit. For that decision, record the baseline comfort or outage rate, the allowed feedback level, who approves action, how stale data is displayed, and what happens when a sensor, schedule feed, or work-order link is missing. That is more useful than modeling every campus building at once.
The operating playbook should also define what evidence closes the loop. For example, a comfort twin might require a complaint trend, supply-air temperature trace, occupancy record, BMS override log, maintenance closure note, and after-action energy check before it claims success. That keeps the team from treating a dashboard alert as an outcome.
Scale only after the proof loop survives normal exceptions: holidays, manual overrides, sensor replacement, temporary room closures, seasonal settings, and emergency maintenance. These exceptions expose whether the twin is a governed operational tool or only a polished sector demo.
Relationship record
Map rooms, zones, air-handling units, floors, schedules, equipment alarms, comfort complaints, work orders, and energy meters with shared identifiers.
Action record
Record the recommendation, owner approval, schedule or equipment change, stale-state behavior, energy impact, comfort outcome, and model update.
24.14 Why Industry Twins Transfer Poorly
Sector examples often hide the details that make a twin work: record provenance, synchronization cadence, local control limits, operating ownership, and how outcomes were measured.
The under-the-hood transfer problem is evidence equivalence. Two sites can use similar sensors and still have different calibration practices, missing-data rules, event histories, maintenance taxonomies, and authorization policies. A factory example based on OPC UA machine data and a mature historian does not automatically transfer to a line where operators record downtime in spreadsheets. A building example based on complete BIM relationships does not transfer cleanly to a campus with stale room metadata.
Governance also changes by sector. Healthcare, energy, transportation, manufacturing, and smart-city systems have different safety cases, privacy boundaries, audit expectations, and tolerance for automatic action. The same optimization pattern may be advisory in one sector and prohibited in another until review, fallback, and human approval are explicit. Treat the feedback path as part of the industry translation, not as an implementation detail.
The safest transfer method is a local proof contract: list which records are equivalent to the reference case, which are weaker, which controls reduce risk, and which outcome must improve before the team expands scope. If that contract is missing, the copied example is only inspiration.
- Different record quality: two factories, hospitals, campuses, or fleets may have similar sensors but very different inspection, work-order, and event records.
- Different feedback risk: a recommendation in logistics may be acceptable, while an automatic command in healthcare, energy, or safety contexts may require stronger governance.
- Different model scope: a high-fidelity model helps only where the active decision needs it; other areas may need lighter context or lifecycle records.
- Different verification baseline: published savings, comfort, quality, or outage claims do not transfer without a local baseline and outcome check.
24.15 Summary
Digital twin industry applications are best understood as reusable decision patterns. Manufacturing often emphasizes asset condition and quality. Buildings emphasize spatial and equipment relationships. Healthcare emphasizes validated model boundaries and governance. Cities emphasize multi-fidelity scenario planning. Energy and logistics emphasize constraints, freshness, and coordination. Across all sectors, a useful twin is judged by model scope, record quality, synchronization, action path, and verified outcome.
24.16 What’s Next
Continue with:
- Digital Twins: Introduction and Evolution to revisit core definitions.
- Digital Twin Synchronization and Modeling to deepen data freshness and model-update design.
- Digital Twin Use Cases to apply the patterns to additional scenarios.
- Digital Twin Worked Examples to practice decision records and architecture choices.
24.17 Key Takeaway
An industry digital twin is valuable when synchronized state changes an operational decision. The twin must connect asset data, model assumptions, update cadence, and accountable actions in the specific domain.