A data center is an accessible example of the relationship between IT and OT. The useful output may be a digital service, but operating it requires electrical supply, heat removal, instrumentation, and controls. A server can remain powered while one of those supporting functions is deteriorating.
Understanding that dependency does not require endorsing a particular data-center project or its resource demands. It starts with the physical question: where does the heat go, and what happens when that path becomes unavailable?
Power continuity is not cooling continuity
A UPS can bridge an interruption for the equipment it actually supplies. It does not automatically power every chiller, pump, fan, or control dependency that supports that equipment.
In the cooling explorer, compute has an eight-model-minute UPS. The facility cooling chain does not. After utility power fails, compute initially continues generating heat while cooling capacity falls to zero. The browser display remains accessible because it is a teaching view, not an application hosted in the fictional room.
That split is a scenario assumption, not a statement about all data centers. Actual designs vary in backup-power coverage, cooling architecture, stored thermal capacity, control sequences, transfer behavior, and operating requirements.
Two units are not automatically N+1
The example has two 60 kW cooling trains and an 80 kW workload. Losing one leaves 60 kW, which is less than the heat being generated. Temperature starts rising even though one train remains healthy.
At the example's reduced 30 kW demand, that remaining train can cover the load. The relevant question is capacity at the required conditions and demand, not simply how many units are installed. An N+1 design claim requires an actual engineering assessment; this small model does not establish a resilience rating.
The two trains also share one water pump. If that pump fails, both lose a dependency. Duplicating the final equipment does not remove a common supply, control, or distribution failure.
Temperature responds over time
The explorer uses a deliberately simple heat balance: heat added minus heat removed changes an illustrative room temperature. It treats the room as one uniform thermal mass and uses fictional parameters. It does not represent hot spots, rack inlet temperatures, humidity, changing outdoor conditions, or real equipment protections.
The useful teaching result is the delay. A failure changes available cooling immediately; temperature takes time to rise. Restoring cooling changes capacity immediately too, but it does not instantly remove heat already stored in the example room.
That is why a green component status and a recovered physical condition are different observations.
Recovery is a sequence, not a reset button
The model deliberately latches the workload off after its fictional thermal or power stop. Restoring the pump or utility supply does not restart it.
To restart, restore sustained facility power and enough cooling for the selected demand, let temperature fall, run the example recovery check, then restart deliberately. A recent configuration or demand change invalidates the check. This is a teaching policy, not a real emergency or operating procedure.
It connects to the broader recovery decision exercise: returning software to an available state is only part of returning a physical service to operation.
The same failure can have different causes
A stopped pump or missing temperature value could result from an electrical problem, mechanical failure, maintenance, a configuration change, communications loss, or malicious activity. The symptom alone does not attribute a cyberattack.
Start with the physical function and its dependencies, then investigate the evidence. That habit transfers to water systems, building controls, manufacturing, and the other OT verticals.
Try three questions
- Can one remaining cooling train support the selected workload?
- Which dependencies does the UPS actually cover?
- What has to recover before the workload can restart, and what still needs observation afterward?
The downloadable activity sheet provides short experiments and suggested observations. Every temperature threshold, time, capacity, and protection behavior in the explorer is a fictional teaching choice.
Further reading
- DOE FEMP: Energy Efficiency in Data Centers: links to design, air management, metering, and efficiency resources, including the Center of Expertise at Lawrence Berkeley National Laboratory.
- NIST SP 800-82 Rev. 3: OT security guidance encompassing building automation and physical environmental monitoring, as well as industrial control.
Real facilities use different heat-rejection and air/liquid-cooling designs. Energy, water, and environmental implications depend on the design and location; the explorer does not calculate them.