How much complexity is too much?

Efficient control logic keeps getting more complicated. Interpretability is what you trade away, and we are not sure everyone is pricing it properly.

Welcome to edition six. Less of a how-to this time, more a question we argue about internally most weeks without ever quite landing it.

Take an unremarkable four chiller plant: four chillers, four condenser water pumps, six tower cells, variable speed on pumps and tower fans from 50 to 100 percent, chilled water setpoint from 42 to 46°F, condenser water setpoint from 65 to 85°F. Count the combinations at 1°F and 5 percent resolution and you get a little over 1.2 million ways to run that plant.

Not across a year. Right now, at this load, at this wet bulb. Move either one and the best of those 1.2 million moves somewhere else. Nobody finds it by intuition, which is why efficient control logic keeps getting more complicated, and why what you trade away is interpretability.

Interpretability just means being able to look at a system and understand why it did what it did. Large language models have put the word in the news, but the idea is older and it is not binary. It sits on a spectrum. So where is the line between control logic that is efficient and control logic a plant operator can still understand?

The equipment changed, and the logic followed

Thirty years ago, a pump was on or off, a tower fan was on or off, and a constant speed chiller above roughly 50 percent load held a reasonably flat kW per ton. The operator's mental model was close enough: run the fewest machines you can, keep them loaded, and you are near enough to optimal. The logic fell out of that. It fit on a page, and anyone in the plant room could predict what the plant would do. Simple logic is auditable, teachable, and easy to fault-find at two in the morning.

Then variable speed drives got cheap. They are now on almost everything: pumps, tower fans, and increasingly the chiller's compressors themselves. Add magnetic bearings and part load efficiency gets genuinely good. Every one of those changes added a degree of freedom. Speed changes flow, flow changes loop temperatures, temperature changes lift, lift changes efficiency, and every loop feeds back into the others. Sitting in the efficient region now takes logic that is, unavoidably, more complicated than what ran the old plant.

ASHRAE's Guideline 36 is the clearest public example. It gives the industry high-performance sequences that work across a wide variety of plant designs, and the 2021 revision extended it to chilled water plants. Read it next to a conventional functional description and the difference in complexity is obvious. But it is still interpretable: human-readable, open to being questioned, adjusted and overridden. Complexity went up. Transparency did not.

What we are shipping right now

Two things we are deploying for the first time, both moving us further along that complexity axis deliberately.

The first is a chilled water temperature reset using trim and respond logic, overridden by the most open valve position of any air handler on the loop. It trims in the efficient direction and responds when the building says it has gone too far. If a valve is more than 98 percent open, that zone cannot get what it needs, and comfort wins over efficiency.

The second is dynamic chiller staging setpoints. A fixed demand threshold leaves something on the table with modern machines: the efficiency you gain from reducing lift is itself a function of part loading. Concretely, with a variable speed magnetic bearing centrifugal on a low wet bulb day, it can be worth staging up sooner than you normally would. You pay for an extra pump set and tower and get back a machine sitting deeper in its part load sweet spot, with less lift across it, for longer. On a high wet bulb day the same move does not pay. Same plant, same load, different right answer.

More complex than a fixed threshold, and we think it is worth it. But it is right at the edge of what should be handed over without a conversation.

Why we build the way we build

This is why we have always tried to abstract the complexity away rather than ship it to site. The heavy lifting happens upstream, in the simulation and the optimization. The final step exports the result as a relatively simple algorithm, written as adjustable variables inside the existing BMS. Not a parallel controller. Not a gateway. The incumbent BMS keeps running the plant, and its contractor keeps their relationship with the building.

Yes, that algorithm carries more variables than the conventional version. But a condenser water reset with more variables in it is still, recognizably, a reset searching for the optimal approach to wet bulb. An operator can see what it is trying to do, even if the tuning came from somewhere they cannot. Feed the same problem to a neural network and you get numbers in, numbers out, leaving operators accountable for a plant they are not allowed to understand.

The people who look after these plants will still be there in five years, and they carry responsibility for safety and conditions every day. If the logic lives in their system, in their language, they can read it, question it and override it. We are not there to replace anyone, but to help their system perform better.

The other end of the spectrum

At the far end of the spectrum sits black box optimization. A separate controller sits alongside the building management system, dictates setpoints and staging in real time, and the BMS is reduced to passing those values through. The newer version does the same through a cloud AI gateway. The hidden algorithm is the business model, which is the vendor's problem right up until it becomes the site's.

When the plant does something surprising, nobody on site can tell you why. Not the operator, not the BMS contractor. Most questions become a support ticket. Each of those is a small withdrawal from the operator's trust, and nothing puts it back. That is the part we think is mispriced. The energy model gets scrutinized line by line while the trust debt sits off balance sheet, right up until the day it is called in.

The tipping point

This is where the trade-off stops being philosophical and starts being commercial.

Complexity and interpretability are not independent. Push complexity far enough and interpretability goes to zero, because at some point no human can follow the chain of reasoning behind a setpoint. So the real question for a site is not whether to add complexity, but how much interpretability it can afford to give up before crossing a tipping point. And that point moves. It depends on the operators, the BMS technicians, how the site is staffed, and what the organization is trying to achieve.

We have watched, repeatedly, what sits on the other side of that line. Black box controllers and real-time cloud optimization get switched off.

The reason is not necessarily that the savings were not realized. It is fear of losing control. Without knowing why the plant is operating the way it is, every edge case becomes a problem an operator cannot reason through. A chiller faults. A sensor drifts. Something behaves strangely at 3 am and the operator has to decide, right then, whether the optimizer is responding sensibly or making things worse. Their first responsibility is equipment integrity and conditions, so faced with a system that cannot explain itself, the safe move is manual mode.

And once it is off, it usually stays off. Nobody feels confident turning back on a thing they could not explain in the first place. The saving does not degrade; it stops. A strategy that saves 15 percent and runs for eight months saves less than one that saves 9 percent and runs for a decade. Uptime is a multiplier on the energy number, not a footnote to it.

We do not think we have the balance right yet

Here is the tricky question: how much complexity to introduce, and how quickly, is situational, and we are continuously learning where that line sits with every new deployment. One pattern we have noticed is geographic, and it dictates how a rollout should run.

United States: the deep knowledge of the HVAC system usually lives with the plant operators. They are on site, they are accountable, and they will ask you why.

Australia: closer to the reverse. Far fewer plant operators, and that skill set tends to sit with the BMS contractor, one step removed from the plant room.

Same logic, different room to convince, different pace.

So in the US we now more often stage it. Start with a dynamic condenser water temperature reset, let everyone live with it for three months, then come back. Then condenser flow reset. Then chiller staging and sequencing, then dynamic staging, then more variables in the algorithms already running. Slower, and the full saving arrives later, but each step is understood by the people accountable before the next one lands.

Whether that is the right rate is an open question. It depends on the BMS we find when we arrive, the plant, the team, and the appetite for change.

The questions we would put to the industry, and to you:

- Where is the tipping point, and can it be measured rather than discovered after the fact?

- What is the most complex piece of logic on your plant that your operators can still explain?

- If you have ever switched an optimizer off and left it off, what made you do it?

Especially if you have implemented Guideline 36, run a black-box optimizer, or hand-tune your own sequences. Get in touch.

Iain Stewart

Cofounder & CEO, Exergenics

‍