Heat Network Optimisation
Heat network optimisation is the trendy term used for fixing sub-standard communal heating and hot water systems.
We have suffered decades of erroneous guidance, a complete lack of regulation, and a systemic refusal to look at operational data until recently.
Heat networks have historically only needed to work. Working efficiently was never on the agenda. As long as occupants had hot water and heating that was job done. And with gas as a standard heat source, there was no need to be careful about temperature drops or commissioning valves to work as they should.
So now we are in an end of the world scenario and just waking up to how poor building services have been in reality. What we do next needs to work, and work well. We can't afford any more theories or excuse our delay on a lack of suitable technology. We have everything we need, technically, to deliver superb value for money low carbon heat networks, but as long as people follow promises rather than data it will be impossible to effect real change.
The past five years has seen a huge focus on HIUs. It was obvious that HIUs were one of the root causes of inefficiencies, with a wide variety of designs and levels of quality, and a strong tendency for the industry to value engineer out anything related to efficiency. Establishing standards was a very important first step, and the BESA independent testing gave us that. We were lucky enough to be in the first set of tests, and have been heavily involved since. Our hydraulics and controls expertise delivered us the best test results by far, with return temperatures not far off theoretical perfection, and have never been matched in the years since. This is not said as a boast, but rather as a testament to the use of data to develop products that actually work. Without a proper feedback loop, it is impossible to improve technology, just as it would be to improve a recipe you never taste.
Heat networks as a whole are no different. To the untrained eye energy centres generally look like impossibly complex. Looking at schematic drawings on the walls they appear to be highly engineered machines. But once you get to know them, its quite a different story. Generally a glance at return temperature gauges gives it away, with a one or two degree temperature drop. But that's down to the network, the HIUs, so as long as the practices are in place to correct that side it should all, theoretically, work.
Again, experience shows otherwise. The layouts of most energy centres often makes it impossible to run a an efficient system, even once the network itself is delivering decent return temperatures. The use of headers and bypasses has historically been prolific, and the standard forms of boiler sequencing simply do not work well with a heat network that likes a steady flow temperature. Buffer stores are rarely used, and where they are used are never installed correctly. Pumps and boilers are commonly so oversized as to make it impossible to match low load conditions without rapid cycling.
One of the best examples of how reality differs from practice is radiator balancing. A critical factor in achieving low return temperatures, yet in practice they rarely work. Only those network operators that have invested the time in monitoring know the truth of how difficult it is to achieve a 30C drop specified. In practice, anything more than 20C is doing very well in the UK. Yet there are simple well tested solutions used in other countries and on very rare occasion in the UK.
And then we come to the biggest hurdle of all, the controls. As manufacturers of HIUs and substations we often have a need to integrate with building energy management systems, however we have found this to be almost impossible due to a lack of centralised technical support to discuss modern protocols like MQTT. Almost all BMS systems are designed to lock one into contracts and licences rather than do the job at hand. Many BMS controllers are deliberately throttled down to enable them to charge for decent processor power (that you have already paid for). Every control point carries a licence, as does every modbus interface. You are then locked into a centralised network where problems like an IP clash can take down numerous sites at once. In short, it is simply impossible for anyone other than the employed BMS installer to write, check, debug, and improve controls logic. Its no wonder very few control panels have ever even been connected for remote monitoring, either because of the costs involved or for reasons of plausible deniability. Without any remote data, and nobody ever having the desire to even look, is it any wonder the things never worked?
So, now we are aware of the scale of the problem, who do you approach to fix these monstrosities? Who can fix these problems, and at what cost?
The HIU end network end is pretty straight-forward. All of the problems with HIUs are well documented and it only takes a thermometer and DP meter to start spotting them. The list of fixes is fixed, and it's a case of examining the cost/benefit of possible solutions. One can employ one of a number of companies now to report on performance and list the potential remedies. Some are better than others, but all operate within a certain envelope of experience. What if its not HIUs, but its a separate DHW system as in many existing council blocks? What happens if there is a buffer store that is incorrectly piped and controlled?
