P19
The controller itself consists of four main modules. First, there is a Forecaster module. It forecasts the energy demand in the network for the upcoming few days based on weather forecasts and the historical behavior of the network. Moreover, it also forecasts the flexibility available in the network, i.e. it forecasts how much energy can be stored or released from the virtual buffer, based on the building thermal mass and the thermal state within the building.
This network also comprises decentralized heat pumps to boost the temperature of the ground water (~28°C), to the required level for space heating and domestic hot water production. The network is organized in clusters of buildings, and a backbone network connecting the clusters and the mines. In this network, the objective was to balance the consumption of the buildings to the available excess heat in the clusters of the network. In that way, the energy exchange with the overlaying backbone network was minimized. The overall goal here is to use the capacity of the backbone better: serving more clusters with the same backbone.
The second module is the Planner, which is like an optimizer. It uses the forecasts calculated by the Forecaster and has a
certain objective to fulfill, e.g. peak shaving. Based on these inputs, the Planner will calculate to which extent the demand profile of the network can be shaped towards the objective by using the available flexibility. In this exercise, the comfort constraints of each individual building are always taken into account. The output of the Planner is a control plan, which normally spans the coming 24 hours. Then, there is the Tracker module, which disaggregates the desired control plan generated by the
Figure 2: Layout of the Mijnwater DHC network.
Planner into individual control power demands for each building. Thereby, it tries to make sure that the actual heat demand curve of the network corresponds as close as possible to the optimized one from the Planner. Because of unavoidable model errors in the building and network models, it acts and reacts in real-time, by constantly updating the power demands sent out to the buildings. While the Forecaster and Planner operates on longer time periods of hours and days, the Tracker will normally operate on near-real-time time levels. Finally, each building connected to the control signal is represented by a software agent called a virtual Distributed Energy Resource (vDER). The vDER translates the power demand from the Tracker into a control signal able to be used in the control system of the building substation controller or
Also, part of the consortium was Zuyd Hogeschool, a Dutch university of applied sciences, who developed educational packages on intelligent control of DHCnetworks. The last partner is the DHC+ Technology Platform, who were responsible for the coordination of dissemination and communication activities. THE STORM CONTROLLER The STORM controller is integrated in the NODA Smart Heat Grid solution and is implemented in an AWS cloud platform. Besides the controller core, the product contains functionalities for communication with sensors and control systems by means of various communication protocols. Furthermore, also visualization features are part of the product (Figure 3).
building management system. This control signal makes the building react in the way the controller wants it to, in order to meet the control objective. Each vDER also continuously communicates with the Forecaster to provide the basis for making predictions on the available thermal flexibility.
Figure 3: Architecture of the NODA Smart Heat Grid solution.
www.dbdh.dk
J O U R N A L N 0 . 2 / 2 0 1 9
Made with FlippingBook Ebook Creator