A German rack manufacturer came to us with a cooling problem that had outgrown its hardware. Their high-density portfolio — 50kW and 100kW racks — needed fan control that could do more than run every unit at a fixed speed and hope. What we built for them became the POD-S6: a controller that drives each fan in a rack individually against a temperature curve, and which fails to full speed rather than failing quietly.
Why Fixed-Speed Fans Run Out of Road
At 5kW or 10kW a rack, cooling is forgiving. There is enough thermal headroom that a bank of fans running at one speed will cope with most of what the IT load throws at it, and if one fan degrades the others quietly absorb the difference. Nobody notices, and mostly nobody needs to.
That margin narrows at 50kW. At 100kW it is largely gone. Densities like these concentrate a great deal of heat into a small volume, and the airflow that removes it has to be both sufficient and evenly distributed. A single underperforming fan stops being a rounding error and becomes a hot spot — and a hot spot in a 100kW rack is not a gradual problem. Our client understood this perfectly well. What they wanted was control granular enough to see it happen and respond before it mattered.
Individual Fan Control, Not Group Control
The core design decision was to treat each fan as its own controlled device rather than as one element of a bank. Every fan gets its own speed target, derived from a fan and temperature curve, and ramps on measured performance rather than on a fixed schedule. Ask for more cooling in one part of the rack and only that part responds.
This has a second benefit that matters more than the efficiency argument. When every fan is driven and monitored separately, a fan that is drawing current but not moving the air it should is visible as a discrepancy — its neighbours are compensating and the controller can tell. Group control hides exactly this failure until the thermal consequences surface somewhere downstream.
Configurations From Two Fans to Twelve
A rack manufacturer does not build one rack. The portfolio needed the same control logic to work across quite different mechanical designs, so the controller supports fan arrays in configurations of 2, 4, 6, 8 and 12, running on 48VDC. Twelve fans at 48VDC is the configuration at the top of the range, where the 100kW racks sit.
Keeping one firmware behaviour across all five configurations was deliberate. It means the manufacturer's engineers learn one system, the commissioning process is the same regardless of which rack is in front of them, and a fault diagnosed on a four-fan unit reads the same way on a twelve-fan one.
Every Fail-Safe Ends the Same Way
- Lost connectivity — the controller stops hearing from the management layer and ramps to 100%
- Loss of power on the control path — fans default to full speed rather than to their last setpoint
- Implausible sensor readings — out-of-range, flatlined, or physically impossible rates of change
- Disagreement between sensors that should broadly agree with one another
- In every case the safe state is full airflow, held until a human or the platform says otherwise
The Safe State Is Loud
Most of the engineering effort went into deciding what the controller should do when it cannot trust itself. The answer we settled on is the same in every case: ramp every fan to 100% and stay there.
That sounds blunt, and it is meant to. The reasoning is an asymmetry of cost. Running a fan array at full speed when it was not strictly necessary costs energy, some acoustic comfort, and a little fan life. Failing to run it when it was necessary costs whatever is installed in the rack, and in a 100kW rack that is a great deal of equipment and quite possibly a customer's production workload. Given a choice between wasting watts and cooking hardware, the controller wastes watts every time.
Three classes of failure trigger it. The first is lost connectivity: if the controller can no longer reach the layer that tells it what to do, it assumes the worst about what it is missing. The second is loss of power on the control path, where the fans fall back to full speed rather than holding whatever setpoint they happened to have when the power went. The third is the interesting one.
Distrusting Your Own Sensors
A controller that has lost its network knows it is in trouble. A controller reading a broken sensor does not — it carries on regulating confidently against a number that is wrong. This is the failure mode that worries us most, because it looks like normal operation right up to the point where it does not.
So the controller checks its inputs for plausibility rather than taking them at face value. A reading outside the range the sensor can physically produce is rejected. So is one that has not moved at all when the load says it should have, or one that has jumped further and faster than the thermal mass of a rack allows. Sensors that ought to broadly agree with each other are compared, and a persistent disagreement is treated as a fault rather than averaged into a comfortable middle value.
Any of these lands in the same place: full airflow, and an alert. The controller does not attempt to guess a sensible fan speed from data it has just decided it cannot trust. Guessing well is not the goal — failing obviously is.
Part of the Deployment, Not a Bolt-On
The POD-S6 sits in the same wired range as our temperature, pressure, water detection and water temperature sensors, and it is commissioned as part of the same hardware deployment. That matters in practice: the fan curve is only as good as the temperature data feeding it, and having the sensing and the actuation come from one supplier removes a category of integration argument that tends to surface at exactly the wrong moment.
For the manufacturer, the outcome was a control layer they could specify across the high-density portfolio rather than a separate solution per rack size. For their customers, it is a rack where a failing fan announces itself instead of hiding, and where losing the management network means the cooling gets louder rather than stopping.
A Note on Ramp Behaviour
Ramping to 100% is a protective response, not a cooling strategy. It buys time and it protects hardware, but a rack sitting at full airflow is a rack telling you something is wrong. The alert matters as much as the ramp — the point is to get an engineer looking at it, not to run there indefinitely.
High-density racks remove the thermal margin that used to cover for imprecise fan control. Getting it right means controlling each fan on its own merits, and being honest about what to do when the data cannot be trusted. For us that meant one rule, applied without exception: when in doubt, full airflow.