Heating makers: hybrid switching, small controllers, models

Heat pump and boiler compete in hybrid systems

What happens. In a hybrid heating system, the heat pump and the gas or oil boiler share the load. The usual rule switches on an outside-temperature threshold, with a fixed point for all houses and all tariffs.

What it costs. The household pays a higher bill than needed, because on some days the boiler is cheaper and on others the pump is, and a fixed threshold gets half of those days wrong.

Why the usual fix fails. Setting the threshold with the installer by the rule of thumb is slow to correct. Adding a price input to the rules makes them complex and does not give the best result.

How a fixed-price remote diagnosis checks it. From logs of a hybrid system (temperatures, heat meters, tariffs), I compare the actual switching with the cheapest choice hour by hour. The fixed-price remote diagnosis tells you how much economic switching could save the household and whether it can run in your controller.

Small embedded controllers allow only simple strategies

What happens. Heating controllers run on small processors with little memory and a cheap price target. Strategies are therefore simple rules, even when a smarter approach exists on a laptop.

What it costs. Simple strategies leave efficiency and comfort on the table, and the heat pump or boiler works harder than needed.

Why the usual fix fails. Buying a bigger processor for every unit adds cost across the whole production run. A clever algorithm written for a desktop computer does not fit onto the small target.

How a fixed-price remote diagnosis checks it. I look at your target hardware and the strategy you run, and test whether a reduced-size predictive controller would fit. The fixed-price remote diagnosis tells you what computing power and memory the controller needs, and which real-time code approach suits your platform.

Control functions in C++ need modelling and testing in the loop

What happens. Makers of heating systems write control functions in C++ and want to develop and test them on a model before they go onto the hardware. That needs people who master both the language and the modelling.

What it costs. Roles for this combination stay open. Functions are tested late on real units, where faults cost days and a trip to the test hall.

Why the usual fix fails. Writing code first and testing afterwards finds problems at the worst time. A separate modelling team that does not write the code makes the model fall out of step.

How a fixed-price remote diagnosis checks it. I review one function and its tests: model, code structure, simulation cases. The fixed-price remote diagnosis tells you where model-based design and test in the loop would find faults earlier, and how your own team can carry on.