The CIOS digital twin is a live 3D view of an MDCX site: every container, chiller and power module sits where it stands on the pad, and its alarm state shows on it in real time.
It is a view of the same plant model the rest of CIOS uses. The path tree stays the identity — the twin places geometry at those paths and colours it from live alarms. It never writes to the plant. The twin is a commercial CIOS surface (see open core).
What you see
| Layer | What it is | Where it comes from |
|---|---|---|
| Site shell | Building structure and floor slab | The site design file |
| Units | Containers, power modules, chillers and other equipment at their real position | One OpenUSD model pack per model, placed by site layout |
| Components | Racks, CDUs, pumps, fans, valves inside each unit | Named parts inside the model pack, bound to asset paths |
| Status shell | A thin shell around every unit and component that turns colour on alarm | Generated by CIOS; never part of a model pack |
| Labels | Asset names above top-level equipment | The asset model |
The stage is the whole viewport. Operations pages — alarms, tickets, capacity, maintenance, reports — open as panels over it, so the plant stays visible while you work.
Status shell
Every unit and component carries a status shell at all times. Its colour is the only thing that changes:
| Alarm state on that path | Shell |
|---|---|
| No alarm, or info / minor only | Fully transparent |
| Major | Orange, semi-transparent |
| Critical | Red, semi-transparent |
- The equipment itself is never recoloured. What you see on the body is its real appearance; status lives on the shell.
- Severity rolls up, never down. A container shows the worst state of anything inside it — a critical CDU turns its container red. A container alarm does not colour every rack inside.
- The shell takes no space. It is excluded from picking, measurement and layout: clicking always selects the equipment, not the shell.
- Alarm severities and their meaning are defined once in daily operations; the twin only displays them.
Enclosures
Container walls are rendered near-transparent, so racks, CDUs and piping inside are visible without an "open the box" action. There is no exploded view and no door animation — the interior is always in sight. The building shell can be toggled on and off.
Model packs
Each piece of equipment is one OpenUSD model pack: a single self-contained .usdc at true scale, Z-up, with named components and sensor markers. The same pack is placed as many times as the site needs; registering an asset is enough to put it in the scene.
- MDCX containers ship with their packs — the same files as the product-page downloads.
- Partner equipment (chillers, energy storage, switchgear) is delivered by the supplier to the same rules.
- Packs carry appearance only: plain colours, no textures, no transparency, no glow. Status and transparency are added by the twin at runtime.
- Full rules: OpenUSD model pack specification.
Live data
- Values and alarms come from the site API — the same reads an operator already has. Refresh follows the facility sampling rate (seconds), not GPU-level telemetry.
- If the site API is unreachable, the twin keeps the last known state and marks it stale; the scene is not rebuilt or cleared.
- Read-only: the twin cannot change a setpoint. Writes go through controlled writes.
- What you can see follows your access rights: assets outside your scope are not sent to your browser.
How it is built
The site scene is authored in OpenUSD — the site design plus one model pack per equipment model. The browser view is a derived copy of that scene, so every renderer shows the same layout and the same status rules. Geometry is loaded once; live updates change colours and values in place.