Data Center BMS Digital Twin Reference Architecture

This page presents a facility-scale controls and digital-twin architecture for data-center operations. It is an independent engineering concept developed by Robert Rainer using public information, established scientific-controls practice, and original systems-engineering work.

It is not affiliated with, endorsed by, or representative of the internal systems of DataOne or any other data-center operator.

The idea

A useful data-center digital twin cannot be a single thermal model sitting beside the facility. It must be connected to the operational control system through governed interfaces, shared identifiers, trustworthy time alignment, configuration control, and explicit boundaries between supervisory control, deterministic control, and safety.

This reference architecture uses EPICS as a supervisory integration fabric while leaving fast control and independent protection in the layers where they belong. The digital twin is treated as a lifecycle capability: it can begin in simulation, support controls development and virtual commissioning, then evolve into replay, model comparison, diagnostics, optimization, and operator decision support.

Public architecture

The system is intentionally divided into operational zones so that simulation or analytics cannot silently become a safety authority.

Live demonstration LIVE

A working demonstrator of layers 1, 2, 4, and 7 runs now: a software IOC serves synthetic PVs for a data-center cooling plant, air handlers, power chain, environmental zones, and a 24-rack thermal map, rendered in the browser as the same Phoebus Display Builder screens used on the desktop. The cooling-anomaly scenario cycles about every 20 seconds, so watch the chilled-water temperature and the scenario label change.

Displays: Overview, Cooling, Air Handlers, Power, Zones & Alarms, Rack Thermal Map, PLC / EPICS Architecture.

Note: All values in the demonstrator are synthetic, generated by a software IOC for demonstration only. Nothing here is connected to a live building, BMS, or control system, and the displays are read-only — no control actions are possible from this page. The demonstrator is not a safety basis, operating procedure, or procurement specification.

How it's built — Phoebus & EPICS

The displays are built with Phoebus (Control System Studio) Display Builder: seven .bob files — Overview, Cooling, Air Handlers, Power, Zones & Alarms, Rack Thermal Map, and PLC / EPICS Architecture.

Live values come from EPICS 7 Channel Access: a caproto Python soft IOC serves a governed D1: PV namespace — 82 PV-bound widgets plus 24 rack-temperature PVs. The cooling-anomaly scenario cycles about every 20 seconds, so the chilled-water temperature, delta-T, and alarm state move together the way a real fault would present.

On the web, ORNL's Display Builder Web Runtime (DBWR R1) renders the same .bob files unchanged in the browser, and PVWS R4 streams the live values over WebSocket. Both run as web applications inside Tomcat 9 on Java 21, and Tailscale Funnel publishes Tomcat to the public web — so the chain is: DBWR makes the HTML, PVWS makes it live, Tomcat hosts them, and Funnel makes them public. The web demo is read-only by design — no control actions are possible from the page.

The integration boundary is the same one this architecture draws: in a real facility, existing PLCs (Allen-Bradley, Siemens) interface into EPICS through drivers. The demo shows that interface layer only — the values are synthetic and nothing is connected to a live BMS.

What is public — and what is reserved

This technical preview publishes the system structure, engineering principles, lifecycle, and collaboration model. Deployment-grade details are intentionally withheld, including exact device inventories, addresses, credentials, protection thresholds, facility-specific network maps, detailed PV databases, vendor BOMs and cost models, and implementation-specific automation.

Related work — The Observable Machine

The same discipline behind this twin is the subject of The Observable Machine, my book on engineering diagnostics and reliability: before resetting a machine after an intermittent failure, what evidence should you preserve? Observe first, preserve the evidence, and let the system tell its story — whether the machine is a single instrument or a whole data center.

Collaboration

I am interested in collaborating with data-center operators, facilities teams, laboratories, universities, and engineering teams that want to evaluate, adapt, or deploy this architecture. Engagement can begin with an architecture workshop, a bounded subsystem pilot, or a simulation-to-IOC integration demonstrator.

Authorship and permitted use

This page is published for technical review, professional discussion, and collaboration. No license is granted for commercial implementation, redistribution, or derivative deployment. Contact the author to discuss evaluation or deployment rights.

Status

Public technical preview — November 9, 2026. This is a reference architecture, not a certified design, safety basis, operating procedure, or procurement specification.