I published a proof-of-concept design this week: a data center BMS digital twin reference architecture, with a working demonstrator behind it. It is not a product, not a safety basis, and not connected to any live building. It is a way of showing, with running screens instead of slides, how a facility’s cooling, power, and environmental systems can be supervised from one coherent view — and how that view can travel from a control-room workstation to a browser without being rebuilt.
- Reference architecture: rainer1370.com/data-center-bms-architecture/
- Live web demo: rainer1370.com/dataone-bms/
- The running stack: rainer1370.com/data-center-stack/
- Control Lattice Systems: controllattice.com
The idea
A modern data center is a lot of systems that were never designed to talk to each other: chillers and pumps, CRAH and CRAC units, UPS and generators, rack-level sensors, and the building management controllers that sequence them. The operator’s job is to hold all of that in one picture — what is normal, what is drifting, and what needs attention first.
The architecture I published draws that picture as seven layers, from the physical plant at the bottom to operator and engineering workflows at the top. The middle layers are the point: device interfaces and gateways, deterministic control with independent protection, EPICS supervisory integration, and the data, time, and configuration context that makes a reading trustworthy. Two rules govern the whole stack, and I kept them from the fusion digital twin this work is a companion to: the twin begins read-only, and protection stays independent.
How it is built
The displays are built with Phoebus (Control System Studio) Display Builder — seven .bob files covering Overview, Cooling, Air Handlers, Power, Zones & Alarms, a 24-rack thermal map, and a PLC / EPICS Architecture screen that draws the integration boundary itself.
Live values come from EPICS 7 Channel Access. A caproto Python soft IOC serves a governed D1: process-variable namespace — 82 PV-bound widgets plus 24 rack-temperature PVs. A cooling-anomaly scenario cycles about every 20 seconds, so the chilled-water supply temperature, the delta-T, and the alarm state move together the way a real fault would present: CHWS 6.8 °C rising to 9.1 °C, delta-T collapsing from 5.5 to 3.2, a rack zone warming from 23.7 °C to 28.4 °C. That is the whole point of a twin — not a static picture, but a system whose parts fail together.
The part I care about most: portability
The same .bob file runs in two places. On the desktop it runs in Phoebus, the way an operator would use it. On the web, ORNL’s Display Builder Web Runtime (DBWR R1) renders that identical file unchanged in the browser, and PVWS R4 streams the live values over WebSocket. Nothing is rewritten, nothing is re-skinned, and there is no second UI to drift out of sync with the first.
The web copy is published through a funnel server — Tailscale Funnel in this demonstrator — and it is read-only by design. No control actions are possible from the page. That is not a limitation I worked around; it is the authority boundary the architecture insists on. Supervision travels; control stays with the plant.
For anyone who has maintained two versions of the same screen — one for the control room, one for the people who need to see it from elsewhere — that portability is the whole argument. Build the screen once, in the tool the controls engineers already use, and let the runtime decide where it renders.
Who it is for
I use this with my students, technicians, operators, and junior engineers. It is a teaching instrument as much as a design document:
- Students see what a supervisory system actually is — not a dashboard, but a governed namespace of named values with units, limits, and alarm states.
- Technicians see the integration boundary: existing PLCs (Allen-Bradley, Siemens) interface into EPICS through drivers. The demo shows that interface layer only. I interface working PLCs into EPICS middleware; I do not program PLC logic, and the demo does not pretend otherwise.
- Operators get a fault to watch. The anomaly scenario is a training fault with a physically coherent story — follow the chilled water, then the air handlers, then the racks, and the sequence of the failure reads itself.
- Junior engineers see the discipline that surrounds the screens: naming, configuration, time, data quality, and the line between what the twin may observe and what only the protection system may do.
What it is not
Everything in the demonstrator is synthetic, generated by a software IOC for demonstration only. Nothing is connected to a live building, BMS, or control system. It is not a certified design, a safety basis, an operating procedure, or a procurement specification. If you are evaluating it for a real facility, the honest next step is a workshop, a bounded subsystem pilot, or a simulation-to-IOC integration demonstrator — not a copy-paste of these screens.
Where it goes next
The companion piece to this work is the Fusion Digital Twin DCS Reference Architecture, built on the same seven-layer pattern for a very different machine. The pattern holding across both is the part I want to keep testing: the same supervisory discipline, the same read-only-first authority rule, and the same insistence that the screen an operator trusts is the screen everyone else sees.
If you run a facility, teach operators, or build the tools they work with, I would like to hear what you would change. The pages above are the place to start — and the live demo is the fastest way to judge whether the idea holds up.
Robert Rainer is Managing Director & Principal Engineer at Control Lattice Systems. Contact: rainer1370@gmail.com
Related pages
- Data Center BMS Reference Architecture — the seven-layer architecture this essay describes.
- Data Center BMS — Live Web Demo — the running Phoebus/EPICS demonstrator.
- Data Center BMS — System Stack — the running stack behind the demo.
- From Simulation to Operations: A DCS Infrastructure for Fusion Digital Twins — the companion architecture on the same seven-layer pattern.