Photo: data center aisle — net-serve.org
This page is the companion to the Data Center BMS Digital Twin Reference Architecture. Where that page describes the design, this one describes the running system: every layer of the stack behind the live demonstration, what each piece does, and what would change to operate a real facility with it.
The running stack LIVE
7 Browser — Phoebus Display Builder Web RuntimeAny modern browser, nothing to install. The same seven .bob displays as the desktop Phoebus demo, rendered unchanged.
6 Public access — Tailscale FunnelHTTPS on rain-meerkat.taildd0ff9.ts.net, certificate issued automatically. Works behind CGNAT with no open firewall ports.
5 Web services — Apache Tomcat 9 + Java 21DBWR R1 and PVWS R4 (ORNL nightly builds). PVWS streams live values over WebSocket; the web demo is read-only by design.
4 Supervisory integration — EPICS 7 Channel AccessGoverned D1: PV namespace. 82 PV-bound widgets plus 24 rack-temperature PVs, all served as Channel Access process variables.
3 Simulation — caproto Python soft IOCA software IOC generates synthetic values, including the cooling-anomaly scenario that cycles about every 20 seconds.
2 Device interfaces — BACnet / Modbus + EPICS driversThe integration boundary. In a real facility, existing PLCs (Allen-Bradley, Siemens) interface here through drivers. Not connected in the demo.
1 Physical plant — chillers, CRAH, UPS, generators, racksSynthetic in the demo. This is the facility the stack is built to manage.
How it fits together
Soft IOC serves PVs → PVWS streams them over WebSocket → DBWR renders the .bob displays → Funnel publishes them → your browser
The displays, the PV namespace, and the simulator are versioned together in a private repository, so the demo on screen always matches the code that produces it. The .bob files the web server shows are copies of the repository files; editing a display means re-copying it to the server.
From demo to facility
What changes to operate a real data center with this stack:
- Replace the simulator IOC with real device IOCs and drivers — BACnet gateway to the existing WebCTRL/BMS, Modbus to meters and UPS, and field-controller interfaces.
- Add the deterministic layer: sequences of operation, chiller staging, alarm management, and the facility's own protection and life-safety systems, which stay independent of the twin.
- Add data services: archiving, trending, configuration control, and event identity, so every value carries its time, source, and calibration.
- Keep the twin read-only at first. Advisory outputs — replay, state estimation, optimization suggestions — are reviewed by operators before anything changes in the plant.
- Expand authority only after verification and operational acceptance, with bounded authority, safe fallback behavior, and cybersecurity review.
Running it
The stack runs on a single Ubuntu machine and restarts in this order: the IOC (python simulator/dataone_ioc.py --interfaces 0.0.0.0), then Tomcat (bin/startup.sh), then the tunnel (tailscale funnel 8080). Everything is user-level — no sudo, no open firewall ports.
Open the live demo — rainer1370.com/dataone-bms
Read the reference 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. This page is not a safety basis, operating procedure, or procurement specification.
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.
Contact: rainer1370@gmail.com
Portfolio: rainer1370.com
GitHub: Rainer1370
Status
Public technical preview — November 9, 2026. This is a reference architecture and a working demonstrator, not a certified design, safety basis, operating procedure, or procurement specification.