Case study · Industrial digital twin
Cryogenic asset digital twin for bulk gas infrastructure
A monitoring and prediction architecture for cryogenic bulk tanks and ambient-air vaporizers operated across many regions. This page documents the system design, the physical reasoning behind icing forecasts, and the path from raw telemetry to decisions an operator can act on. The work was completed as a concept, architecture, technical model, and executive presentation, then delivered to the project team and executive stakeholders.
01 · The operating problem
A fleet of tanks, monitored one reading at a time
A bulk gas operation runs hundreds of cryogenic tanks at customer sites, spread over cities and regions. Each asset reports pressure, level, and temperature. Each has a fill history, a delivery route, a maintenance record, and its own exposure to weather. The data existed. What it lacked was interpretation: readings were watched as isolated measurements, while the questions the business actually asked were about the fleet.
Pressure was the recurring concern — fluctuation, excursions above critical thresholds, and the operational noise they create. Behind it sat a quieter and more physical problem: icing on ambient-air vaporizers, which begins as frost on a heat exchanger and can end as an equipment failure in the field.
The digital twin was designed to close that gap. Each asset is interpreted through one framework: sensor data, physical models, historical behavior, weather, and business constraints, connected in a single architecture.
The questions the system answers
- Q1Which tanks require attention this week, and why?
- Q2Which regions show abnormal pressure, icing, or delivery patterns?
- Q3Which assets are likely to cause a service interruption?
- Q4Which delivery schedules should move, given consumption and weather?
- Q5Which routes, trucks, and regions create avoidable operating cost?
02 · Model, shadow, twin
Three words that are often used as one
The literature separates three maturity levels by one criterion: how data flows between the physical asset and its digital counterpart.1 The distinction matters in practice, because each level carries different requirements for sensors, data quality, and update cadence — and different honest claims about what the system can do.
The architecture targets the shadow-to-twin range. The maturity of any deployment is determined by the telemetry, data quality, and operating cadence it can sustain.
Digital model
A static representation, updated by hand. No automated feedback from the physical asset.
Digital shadow
Operational data flows into the model automatically. The model reflects asset state and supports human-directed action.
Digital twin
Model, data, prediction, and operational decisions are connected. The system supports — and partially generates — the actions taken on the asset.
1 Kritzinger et al., “Digital Twin in Manufacturing: A Categorical Literature Review and Classification,” IFAC 2018.
03 · System architecture
From physical asset to decision interface
One directional flow, with two side inputs. Physics models and environmental data feed the digital shadow; machine learning reads from it; everything the business sees is derived downstream.
ELEMENTARY
What exists
Physical assets — tanks and vaporizers. Digital assets — models, databases, historical records. Information flow between them over industrial protocols (MQTT, OPC UA).
IMPERATIVE
What must be engineered
IoT devices and their health. Data pipelines and reconciliation. The ML layer. A security model. Evaluation metrics and recalibration, so the twin is periodically checked against reality.
PROPERTIES
What the twin must exhibit
Self-evolution as operating data accumulates. Domain dependence — gas physics shapes the model. Bounded autonomy, with human review. Synchronization tight enough for the decisions it serves.
04 · The physics layer
Reading icing risk from physical conditions
The icing layer is where industrial analytics has to respect the equipment. Telemetry alone shows that a condition exists; the physical model explains why it is developing and how quickly it may become operationally relevant.
An ambient-air vaporizer is a bank of finned aluminum channels standing in open air. Cryogenic liquid enters near the bottom and leaves as gas; the heat for that phase change comes from the surrounding air. As the air transfers heat into the vaporizer, it cools against the fins, grows denser, and sinks through the channels in a steady downdraft. Moisture carried by that air can condense on the cold surface and freeze.
Frost is an insulator. As the layer thickens, heat exchange degrades, outlet temperature falls, and a vaporizer that should sustain itself begins to freeze up. At fleet scale this is a safety matter as well as a maintenance cost. The model’s job is to translate weather, draw rate, and equipment state into an operating signal: normal, watch, intervene.
Moisture available in the air
Ambient temperature and relative humidity define how much water the incoming air can carry. The colder the surface and the wetter the air, the more material is available to condense and freeze on the vaporizer.
Input class: weather, humidity, local temperature
Heat exchange and natural airflow
The vaporizer cools the surrounding air as it absorbs heat for phase change. That cooled air becomes denser and moves down through the fin channels, carrying moisture toward the cold surfaces.
Input class: gas draw, geometry, inlet/outlet temperature
Condensation and frost capture
Only part of the available moisture freezes onto the metal. The effective capture depends on channel geometry, surface condition, local flow, and how much of the vaporizer is already frosted.
Input class: surface state, fouling, operating history
Thickness growth and operating window
Mass deposition becomes a thickness estimate over the active surface. Thickness is the useful operating variable because it connects directly to reduced heat transfer and the need for inspection or intervention.
Output class: icing severity, intervention window
Trigger conditions
The model becomes operationally important when cold weather and high gas draw coincide. That combination raises the value of an early warning because the asset may appear normal while the thermal margin is narrowing.
Decision class: monitor, schedule, inspect, dispatch
Model correction
The architecture calls for direct temperature measurement near the vaporizer exit so the model can be corrected against field behavior. The goal is a maintainable engineering model, calibrated over time.
Governance class: calibration, confidence, review
The working paper treated calibration as part of the architecture. Literature benchmarks were used to check the order of magnitude, and the design called for an added temperature measurement near the vaporizer exit. That sensor is important: it lets the model be corrected against measured field behavior instead of relying on assumptions carried forward from the first calculation.
05 · Weather as an operating input
Forecasting refills against the season
Weather enters the system twice. Once as a physics input — the icing model above — and once as a planning input, because consumption itself moves with temperature. The refill forecast treats recent behavior as the baseline and corrects it only when the season demands it.
The output is visible in the dispatch view: a tank’s consumption estimate in days, re-ranked when a weather alert lands on its site. A delivery scheduled comfortably for Thursday moves to Tuesday before the cold front does.
Forecast logic
- 1Take the last three refill cycles as the behavioral baseline.
- 2Record the average seasonal temperature during those cycles.
- 3Pull the expected monthly temperature for the period ahead.
- 4If the forecast stays above the critical threshold, project consumption from the baseline rate.
- 5If it crosses the critical range, adjust the projection for the expected temperature — and flag the delivery schedule.
06 · From model to decisions
Three tiers of the same data
The architecture separates the data foundation from the views built on top of it. Leadership sees regional condition and KPI movement; operations sees tanks, events, and queues; engineering sees forecasts, confidence, and model behavior. Each view is drawn from the same governed asset state.
Executive overview
Regional map, reliability leaderboard, KPI cards, critical-event counts. For business leadership: where the infrastructure needs attention, what is improving, and which risks deserve funding or management focus.
Regional operations
Tanks with active alerts, pressure-event history, icing status, refill and maintenance queues — filterable by region, gas, city, customer, or tank. For the teams who dispatch work.
Prediction & deployment
Refill forecasts, weather-adjusted schedules, route and truck optimization with cost inputs, model confidence indicators. For logistics planning and engineering.
ASSET PERFORMANCE CARD · ILLUSTRATIVE DATA
| gas | normal | warning | critical |
|---|---|---|---|
| H₂ | 141 | 8 | 10 |
| Ar | 86 | 15 | 6 |
| N₂ | 98 | 23 | 7 |
| O₂ | 109 | 21 | 7 |
| CH₄ | 55 | 6 | 7 |
| CO₂ | 77 | 24 | 9 |
| He | 46 | 16 | 7 |
EVENT MATRIX, LINKED TO RANKED TANK LIST · ILLUSTRATIVE DATA
07 · Measuring what matters
A KPI system the business already speaks
Technical indicators only earn their place when a business owner can act on them. Each KPI in the system belongs to a named category with a named audience.
| Category | Indicator | What it tells the business |
|---|---|---|
| Operational excellence | TUR | Tank utilization across the network — where new investment is needed and where existing capacity can be used better. |
| FEC | Fill/empty cycle efficiency — the health of the delivery logistics themselves. | |
| Predictive maintenance | MCR | Maintenance cost reduction from moving reactive work to predicted work. |
| MTBF | Mean time between failures — whether reliability is actually improving. | |
| Safety & compliance | IRR | Incident rate reduction — the safety case, stated as a number. |
| Inventory optimization | ICCR | Inventory carrying cost — working capital tied up in stored gas. |
| SFR | Stock-out frequency — supply interruptions a customer would feel. | |
| Environmental impact | CFR | Carbon footprint of routing and avoidable gas movements. |
| Strategic decisions | NEE | Network expansion efficiency — where the next tank should stand. |
| Customer experience | SLA | Service-level adherence — reliability as the customer contracts it. |
| CSS | Customer satisfaction, informed by real-time usage and delivery visibility. | |
| Financial impact | RoDI | Return on digital investment, compounded across all deployed areas. |
| TCO | Total cost of ownership across tank management and operations. |
From KPI structure to executive narrative
The design included a language-model step for executive reporting. KPI values are mapped into a structured SWOT — strengths, weaknesses, opportunities, threats — and that governed structure is what the model receives. The LLM drafts the narrative from measured indicators; a person reviews the explanation before anything is circulated. The analytical source remains the digital twin.
Computed from the digital shadow, per region and period.
Each indicator assigned to strength, weakness, opportunity, or threat by rule.
A pre-defined prompt turns the structure into an executive summary.
The narrative is checked against the numbers before circulation.
08 · Stated limits
Engineering limits
The executive presentation included a section on realistic expectations. That discipline matters: a digital twin becomes useful when its claims are bounded by data quality, sensor coverage, model confidence, and operational review.
Data governance follows the same logic. Every quality dimension the twin depends on — accuracy, completeness, reliability, integrity, sensor health, refresh cadence — is scored and stored alongside the readings themselves. When an input is suspect, the outputs that used it carry that context.
- Forecasts carry confidence bands, assumptions, and review thresholds.
- Implementation is staged around available telemetry, data quality, and operating ownership.
- Recommendations support decisions; accountable teams remain responsible for action.
- Models are recalibrated as operating data accumulates and field behavior changes.
- The physical layer is domain-specific by design, with assumptions visible to engineering review.
09 · Delivery
Where the project stands
The project was completed as a concept, system architecture, technical model, and executive presentation. It was delivered to the project team and executive stakeholders as a coherent proposal for turning distributed industrial telemetry into decision-grade operating intelligence.
The case is presented here for what it demonstrates: physical modeling, industrial data architecture, IoT integration, KPI design, and executive communication carried through one system concept by a practice that can move between engineering detail and business consequence.
Asset identifiers, event counts, and KPI values shown on this page are sandbox data prepared during design work. They preserve the structure and behavior of the system without describing any operator’s actual fleet.
Next step
Comparable infrastructure, comparable questions?
Distributed physical assets already produce the raw material for better decisions: telemetry, events, maintenance history, and operating context. A working session can identify the first bounded shadow worth building.