u/DatacenterGuidelines

Power comes back. The cooling plant doesn't.

A short voltage sag or transfer can last only a few hundred milliseconds. The electrical supply recovers. That does not mean the cooling system recovers with it.

What I keep seeing: A pump VFD trips and sits there waiting for a manual reset. The controller reboots slower than the drive. A network switch comes back after the plant controller. The run command disappears during restart. Devices come back "healthy," but in the wrong order.

Individually, every piece can be doing exactly what it was designed to do. The failure is the recovery sequence of the system, not a single bad component.

For critical cooling, "can the electrical system ride through?" is only half the question. The other half is: after the disturbance, what brings the plant back to a stable operating state, and how long does that actually take?

Ride-through on the UPS or ATS doesn't help much if the first pump that should start has no permissive, or the lead/lag logic is still booting.

Curious how others handle this in real plants: Do you rely on VFD auto-restart, or do you keep restart authority in the plant controller / BMS? How do you enforce start order after a brownout, and do you ever commission a short sag test (not just a full outage)?

What usually bites you: drive faults, network, or a lost run command?

I've been thinking about alarm philosophy on BMS/BAS jobs.

Not every abnormal condition should be an alarm.

A useful distinction is:

Status = what is happening Event = what changed Alarm = something requiring operator evaluation or action Interlock = logic that automatically prevents an unsafe or unwanted condition

Simple example:

A standby CHW pump being stopped is normal status.

But if the duty pump fails, the standby pump is commanded to start and fails to run, that is clearly an alarm.

The problem starts when every state change, communication hiccup and temporary deviation becomes an alarm.

Then the BMS may technically detect everything while operators effectively see nothing.

Where do you draw the line between status and alarm on something like a standby CHW pump?

I understand why CDUs are used. They separate the facility water loop from the IT cooling loop and make pressure, temperature, and water quality easier to manage.

But I keep wondering where the CDU becomes truly necessary, rather than just the safer design choice.

If the facility water already meets the rack requirements for temperature, pressure, cleanliness, and chemistry, what is the real downside of feeding it directly to the racks?

You would remove another piece of equipment, pumps, controls, and some failure points.

Has anyone here worked on a direct-to-rack design?

Did it work well, or did it eventually create problems?

I keep seeing N+1 mechanical designs where the controls architecture quietly reintroduces a single point of failure.

Two pumps. Two AHUs/CRAHs. Redundant power.

Then one supervisory controller, one network path, or one server is responsible for lead/lag, staging, DP control, resets, or other plant-level sequences.

At that point, is the plant actually N+1?

My view is that losing the supervisory layer should hurt optimization and visibility. It should not stop the basic plant from functioning.

Critical equipment should have enough local autonomy to continue operating in a defined degraded mode. Comms loss behavior should also be explicitly defined rather than left to whatever the controller happens to do.

And this shouldn't just exist in the SOO. Pull the network connection during FAT/SAT and see what actually survives.

Maybe I'm too conservative here, but I don't think mechanical redundancy means much if a single controls failure can defeat all of it.

Where do you draw the line?

Would you accept an N+1 mechanical plant where the main sequence cannot continue without the supervisor?