Connect With Us:

Technology

Model predictive control

Model Predictive Control (MPC) is the backbone of our control and optimisation algorithms. MPC is an algorithm for controlling a system that uses a mathematical model of that system, in this case a building and its Heating, Ventilation and Air Conditioning (HVAC) equipment. The model predicts the impact of control options on the system cost over a period of time in the future. Using this model, the MPC finds the control setpoints that lead to the lowest system cost over the considered period, while satisfying a number of operational constraints that are also computed by the model. The cost function can be operational cost, CO2 emission, primary energy use or something else. For example, a building MPC computes the control variables that minimize the heat pump electrical power use for the next three days while maintaining a minimum temperature constraint within the building.

Many different types of models exist. In academic literature, models are often classified based on the type of information that they use. ‘Black box’ models require measurement data from a building - such as building temperature measurements - to train the model, while ‘white box’ models require physical information about the building, such as the building geometry (the floor plan) and the used building materials. Grey box models use a combination of both. For a short introduction into these model types, see this link.

Our approach & challenge

We have developed an MPC approach that uses white box modelling, implemented using a high level of detail. For this purpose we have developed the Modelica library IDEAS, which is available open-source. Instead of modelling a whole building as one zone, each room or group of rooms that has its own HVAC equipment is modelled individually, such that their temperature can de distinguished by the model. Furthermore, each building HVAC component is modelled individually. Consequently, the solar heat gains through each window, all heat flow rates, mass flow rates, pressure drops and efficiencies in pumps, fans, valves, heat pumps are computed and can be compared or benchmarked to building measurements. When implemented in an MPC, the mismatch between a model and the real building is corrected over time using measurement data. In fact, we thus use a grey-box approach. The level of detail however creates a clear distinction between what model parts are black or white, so feel free to call it a zebra-box model.

The resulting models typically consist of tens of thousands of equations, compared to a few tens of equations in less detailed models. While computationally much more demanding, these models can be optimised using our Toolchain for Automated Control and Optimisation (TACO). It is the heart and soul of our software, which has been developed and tested over the past 6 years.

MPC in action

A simple example model is illustrated in the figure below. The top right illustrates the schematic that is optimised, which consists of a water-water heat pump, two circulation pump and a valve. Note that the building envelope model is not shown in the figure. We minimise the electrical power of both pumps and the heat pump. Since the valve affects the system pressure drops, it also affects the pump power. The MPC looks for the best control actions (valve position, pump speeds and heat pump power) that still achieve the minimum room temperature of 21 ˚C (red line in top left).

Analysis 1 - zone temperature satisfied:
The animation illustrates the process where the solver searches for the correct control actions. Along the way, the floor heating temperature (top right, green), the electrical powers (bottom left) and system mass flow rates (bottom right) fluctuate, but the final solution is a smooth profile where the zone temperature (top left blue) touches the temperature limit (red).

Analysis 2 - optimality:
One might now ask wonder why the zonetemperature is not at the lower limit over the whole 3.5 day period. This would indeed require less energy simply because larger temperatures cause more heat losses, which inevitably have to be supplied by the heat pump. However, there is no linear relationship between the cost that we are trying to minimize and the heat that the heat pump provides. That relation is in fact non-linear. Larger heat flow rates require larger temperatures for the heat to diffuse through the floor heating system and the heat pump must work harder to achieve this higher temperature level. Therefore it is more efficient to continuously heat at a lower temperature instead of supplying a more peaked power profile just before the heat is required. Even though this requires more total heat, it requires less cost (electrical energy). A second complexity is that the floor heating delays the heat delivery to the room by a few hours.

Advantages and uniqueness

The main advantage of (white-box) MPC and the focus of Builtwins is to reduce energy use and the associated costs and CO2 emissions, and to improve thermal comfort. Our approach is designed to be scalable in size and complexity such that it is future-proof, with native support for exploiting time-of-use pricing, self-consumption of locally produced electrical power, etc. The large level of detail has numerous side-effects and potential for future development and we strive to deploy new algorithms for existing clients as they become available, further improving the return on investment.

We achieve these advantages through some unique features of our toolchain:

  1. Physics-based models: These models allow itercomparison of model results to real measurements, improving interpretability of the results.
  2. Non-linear models: Non-linear models allow capturing non-linear effects such as explained in ‘Analysis 2’.
  3. Detailed models: Our goal is to model each zone and component individually, such that each control option is properly accounted for and each zone can be controlled individually. By controlling each device, instead of only a part of them we also avoid integration problems with the existing controller.
  4. Data requirements: We do not rely on measurement data to create our model, ruling out dependencies of (possibly broken, badly positioned, etc.) sensors. This also makes the technology applicable to new buildings.
  5. Decoupled solver and model development: This allows systematic software updates (solver) of existing building projects (model).