D3.4: Novel IoT-driven edge computing methodologies for LEC-integrated DHC network applications

HYPERGRYD. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101036656 WP3 – ICT Modules and Simulation Tools Task 3.3 – Development of novel machine learning techniques driven by IoT for LECintegrated DHC networks D3.4 – Novel IoT-driven edge computing methodologies for LEC-integrated DHC network applications Ref. Ares(2024)6909419 - 30/09/2024 D3.4 Novel IoT-driven edge computing methodologies for LEC-integrated DHC network applications 2 DISCLAIMER The opinion stated in this report reflects the opinion of the authors and not the opinion of the European Commission. All intellectual property rights are owned by HYPERGRYD consortium members and are protected by the applicable laws. Reproduction is not authorized without prior written agreement. The commercial use of any information contained in this document may require a license from the owner of that information. ACKNOWLEDGEMENT This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement Nº 101036656. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 3 Project Project Acronym HYPERGRYD Project Title Hybrid coupled networks for thermal-electric integrated Smart Energy Districts Grant Agreement number 101036656 Call identifier H2020-LC-GD-2020 Topic identifier LC-GD-2-1-2020 Innovative land-based and offshore renewable energy technologies and their integration into the energy system Funding Scheme Research and Innovation Action Project duration 42 months (From 1 October 2021) Coordinator ARCbcn Website http://hypergryd.eu Deliverable Deliverable No. 3.4 Deliverable title Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates Description D3.4 (Novel IoT-driven edge computing methodologies for LEC-integrated DHC network applications) summarizes the main activities in Task 3.3 (Development of novel machine learning techniques driven by IoT for LEC-integrated DHC networks) Energy communities, combined with IoT and energy storage technologies, are key enablers for renewable energy integration in the 4th and 5th generation district heating and cooling systems. In this context, edge computing is crucial for optimizing these technologies with low costs and high flexibility. In Task 3.3, KTH focuses on developing a standalone, secure, and scalable edge computing concept for district heating-powered communities, ensuring local data processing and enhanced reliability. This task also includes edge-based machine learning methods, allowing joint optimization of energy communities and renewables without cloud data sharing. WP No. WP3 Related task Task 3.3 - Development of novel machine learning techniques driven by IoT for LECintegrated DHC networks Lead Beneficiary 3 - KTH Author(s) Mustapha Habib (KTH), Qian Wang (KTH) Contributor(s) Valeria Palomba (CNR) Type R Dissemination PU Language English – GB Due 30/09/2024 Submission date 30/09/2024 Version Date Authors Description V.0.1 19/09/2024 Mustapha Habib (KTH) The first version for internal reviewing V.0.2 23/09/2024 Valeria Palomba (CNR) Review V.1.0 28/09/2024 Mustapha Habib (KTH) Final version after review D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 4 Table of Contents 1. Executive Summary ............................................................................................... 7 2. Introduction .......................................................................................................... 9 2.1. Scope ................................................................................................................. 9 2.2. Audience ........................................................................................................... 9 2.3. Abbreviations .................................................................................................... 9 2.4. Contributions of partners .................................................................................. 10 2.5. Relation to other activities ................................................................................ 10 2.6. Structure .......................................................................................................... 11 3. Proposed edge computing solutions for sector coupling ........................................ 12 3.1. Edge solution for coordinated DSM of DH-powered communities ...................... 12 3.1.1. Software architecture ....................................................................................... 12 3.1.2. From energy meters to the edge ....................................................................... 13 3.1.3. From the edge to the DH community member ................................................... 14 3.2. Edge solution for upgrading the building management system .......................... 15 3.2.1. Limitations of the current solutions ................................................................... 15 3.2.1.1. BMS limitations ............................................................................................. 15 3.2.1.2. Cloud-based solution limitations ................................................................... 17 3.2.2. Edge computing as a local optimization-based EMS ........................................... 17 3.2.3. Edge panel – hardware components .................................................................. 18 3.2.4. Edge panel – software components ................................................................... 19 4. Development and deployment strategies .............................................................. 20 4.1. Edge solution for DH communities management ............................................... 20 4.1.1. Data streaming format from the energy meters ................................................ 20 4.1.2. Data services from the DSM-server ................................................................... 21 4.1.3. Data exploitation in HYPERGRYD ....................................................................... 23 4.2. Edge for BMS upgrading .................................................................................... 25 4.2.1. Development phase at KTH ............................................................................... 25 4.2.2. Deployment phase at KEZO ............................................................................... 26 4.2.3. Test phase procedure ........................................................................................ 28 4.2.4. Next steps ......................................................................................................... 31 Conclusions .................................................................................................................... 33 Relation to continued developments ............................................................................. 33 D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 5 References ..................................................................................................................... 34 List of Figures Figure 1 The software architecture of the VM-based edge solution .................................................. 13 Figure 2 Data collection procedure (data journey from the DH community to the edge) ................. 13 Figure 3 Coordinated control as DSM strategy (data journey from the edge to the DH community) 15 Figure 4 Typical architecture of building management system .......................................................... 16 Figure 5 data circulation in classical a building management system ................................................ 17 Figure 6 edge-BMS connection point .................................................................................................. 18 Figure 7 hardware components of the edge panel ............................................................................. 19 Figure 8 software components of the edge panel .............................................................................. 19 Figure 9 Data format being sent by the MQTT broker ........................................................................ 21 Figure 10 DSM-server accessible services ........................................................................................... 22 Figure 11 DSM control execution mechanism: on the left-hand side, direct control via API or IoT (realtime), on the right-hand side, manual control (predictive) ................................................................ 22 Figure 12 Additional computing hardware for ensuring real-time remote control ............................ 23 Figure 13 DSM simulation (community-centric), top: HP optimal condenser temperature setpoint, bottom: TES SOC variation (bottom figure) in a 2-day simulation)..................................................... 24 Figure 14 Different purposes for connecting to the DSM-server database in the framework of HYPERGRYD ......................................................................................................................................... 24 Figure 15 Displaying sensor data for each building in Sonnenplatz community via the project platform ............................................................................................................................................................. 25 Figure 16 Edge panel during assembling and test at KTH campus ...................................................... 26 Figure 17 The targeted heating and cooling processes in the KEZO HVAC system (SCADA view) ...... 27 Figure 18 Edge panel during commissioning at KEZO research center ............................................... 28 Figure 19 Data flow during test phase of edge computing (AI-enabled PC is not included at this stage) ............................................................................................................................................................. 29 Figure 20 Web dashboard for an operation scenario of the CO2 heat pump for simultaneous heating and cooling .......................................................................................................................................... 29 Figure 21 Web dashboard for the same operation scenario generated locally by the edge panel .... 30 Figure 22 Screenshot from the KEZO SCADA system for the main status data of HP during the operation test ...................................................................................................................................... 30 Figure 23 standalone EMS role of the edge panel (next configuration) ............................................. 31 Figure 24 Simple representation of the reinforcement learning technique for the heat pump control ............................................................................................................................................................. 32 Figure 25 Sorption storage during the design phase .......................................................................... 32 D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 6 List of Tables No table of figures entries found. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 7 1. Executive Summary The goal of the HYPERGRYD project is the development of a set of replicable and scalable costeffective technical solutions to allow the integration of Renewable Energy Sources (RES) with different dispatchability and intrinsic variability inside Thermal Grids as well as their link with the Electrical Grids, including the development of innovative key components, in parallel with innovative and integrated ICT services formed by a scalable suite of tools for the proper handling of the increased complexity of the systems from building to Local Energy Community (LEC) levels and beyond, and accelerate the sustainable transformation, planning, and modernization of District Heating and Cooling (DHC) towards 4th and 5th generation. HYPERGRYD also aims to develop real-time management of electrical and thermal energy flows in the coupled energy network complex, including the synergies between them. Therefore, HYPERGRYD aims at three over-arching General Objectives: • To prove that smart energy networks are the future of efficient energy management in DHC and are in synergy with the electrical grids in LEC/smart cities of the future. • To define the roadmap to design and plan future DHC as well as the modernization of the existing ones in different climates and RES penetration levels toward 4th-5th generation, • To demonstrate HYPERGRYD RES-based Enabling Technologies, Smart Energy Grid Solutions empowered by new ICT tools and services as the key for this evolution. During the project, HYPERGRYD’s solutions will be implemented across four Live-In-Labs cases in three representative climates, with special consideration to their cost effectiveness and potential replicability to achieve these three main objectives. One of the targeted milestones in the HYPERGRYD project is the exploitation of edge computing for hosting data monitoring and control functionalities dedicated to energy network management, either at a building or a community level. Therefore, the edge solution frameworks are designed to be effective on three different levels: • System level: here the edge oversees the identification of the dynamic of complex energy systems (e.g., industrial heat pumps (HPs), sorption storage), which might unlock any potentiality for optimal control and management functionalities. Additional services such as predictive maintenance and anomaly detection can be inserted. • Network level: here the edge upgrades the computing and communication capability of the building management system (BMS) by leveraging deep data analytics and optimization as an advanced decision-making tool. Here, the edge can include online services (cloud-based) for better performance as weather forecast and energy market trends. • Community level: in some situations, particularly in residential communities, the end-users might create an agreement to coordinate their energy utilization by sharing their data and giving access to their H&C systems. Here, the edge solution can enable communication across the community and host this coordinated demand-side management (DSM). D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 8 By performing these functionalities, the designed edge computing strategies open the path towards a smooth and effective transition of actual DH networks to 4th and 5th generations where the energy management is more data-driven. The purpose of this deliverable in short is to: • Explain the different proposed edge computing architectures for different use cases. • Describe the software and hardware components used in each proposed architecture. • Go through the development, test, and deployment strategies of two main edge-driven energy management applications. On behalf of Authors Mustapha Habib, KTH D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 9 2. Introduction 2.1. Scope This deliverable summarizes the working principle of the edge computing solutions proposed by KTH, outlining the development, test, and commissioning stages. In this context, two main architectures were proposed: The industrial panel architecture: where the solution is designed to upgrade the BMS functionalities when dealing with complex hardware solutions (e.g., sorption storage). The virtual machine (VM)-based server architecture: where the solution is designed to manage locally the power and heat flows in DH communities by leveraging Internet of Things (IoT) communication. These two main architectures will make it possible to host algorithms for data-driven modeling, combined with metaheuristic and deterministic optimization approaches. The first functionality is dedicated to exploring the comportment of modern HVAC hardware solutions to enable optimal control, while the second functionality capitalizes on energy flexibility within DH communities, offering distributed control via IoT communication to achieve optimal DSM. 2.2. Audience This deliverable may provide useful inputs for those who are concerned with the data-driven control procedure of the new industrial HVAC systems and drive them within a sector coupling network. 2.3. Abbreviations AI : Artificiel intelligence API: application programming interface COP: Coefficient of performance DH: district heating DL: Deep learning DNS: Domain name system DSM: demand-side management EMS: energy management system H&C: Heating and cooling HP: Heat pump HTTP: HyperText Transfer Protocol D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 16 • Limited AI/ML capabilities: lack of advanced machine learning and AI technologies. • Data quality and consistency: challenges in ensuring high-quality, reliable data. Figure 4 Typical architecture of building management system In addition to the limitations listed above, data circulation in classical BMS architectures runs in a closed-loop path, from generation at the filed level, passing to the collection and processing in the control level, ending up at the management level for EMS services and reporting (see Figure 5). There is no stage within this data journey where deep data analysis or optimization-based energy management systems (EMSs) can take place. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 17 Figure 5 data circulation in classical a building management system 3.2.1.2. Cloud-based solution limitations When there is a need for managing the local energy resources at a building level optimally with a connection to DH, LV, and RES, upgrading the BMS capabilities to adopt optimization-based control can be the solution. In this context, cloud-based energy management systems (EMS) have recently become a promising strategy due to the unlimited data computing and storage resources (J.C.M. Siluk et al., 2023, T. Javied et al., 2019 and F. Condon et al., 2023). However, in any online EMS platform, security and data privacy concerns are always raised. Moreover, the dependency on the internet connection for ensuring continuous operation of EMS services is mandatory, which lowers the reliability of the whole management system. 3.2.2. Edge computing as a local optimization-based EMS To overcome the challenges raised previously, HYPERGRYD has come up with an innovative edge computing solution that upgrades the implemented EMS, typically implemented in a building management system (BMS), without the need for a cloud connection. The solution architecture is designed as an industrial panel which facilitates its deployment and integration to BMS. In such panels, data engineering, communication, and computing requirements are all handled locally. The edge panel is designed to have bi-directional data flows with BMS with the control level as Figure 6 shows. This makes it possible to access various sensor data at one single point, which is the monitoring programmable logic controller (PLC) of the targeted HVAC system and carries out control functions through the same PLC on a system level only. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 18 Figure 6 edge-BMS connection point 3.2.3. Edge panel – hardware components The edge panel gathers a set of devices that are indispensable for its presumed role. These devices are listed below with brief explanations of their roles (see Figure 7): • PLC: which is the first device that communicates with the targeted BMS controller since it supports the most common industrial communications adopted in buildings (e.g., Modbus, BACnet, etc.). In addition to the low-level communication capability, the PLC can be coded to incorporate security instructions to deal with any “unexpected” or miss-communication with the AI-enabled PC (see below), in such scenarios, the PLC takes the lead by replacing the advanced EMS hosted on the industrial PC by a local basic one. • Gateway: this device is the stage for processing data coming from the PLC, and sending it to any local or remote database. It is also possible to insert online information if needed (e.g., data for dynamic energy cost). • Industrial PC: with high computing capability, this Linux-based compact and fanless PC is responsible for handling optimization efforts associated with the advanced EMS. It is also the stage for hosting a local database needed for training ML and DL models. • Ethernet switch: needed for connecting the device mentioned above all in one network along with the BMS network. • Protection and power supply: needed for providing different voltage levels for each device and providing protection against overloading and short circuits. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 19 Figure 7 hardware components of the edge panel 3.2.4. Edge panel – software components In the proposed edge solution, the data journey from the BMS controller to the edge database goes through a set of software stages that ensure data interoperability, processing, and communication. Figure 8 gives an illustrative representation of the selected software solution for this purpose. In contrast to data processing and storage, where open-source solutions were adopted, the first stage of communication with BMS has to be with commercial software that supports the IEC 61131-3 standard for PLC programming. Figure 8 software components of the edge panel • S7-1200 firmware: as an operation system for SIMATIC S7-1200 of SIEMENS PLC, it makes it possible to communicate with the BMS controller thanks to the supported industrial D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 20 communication protocols. This firmware ensures also the execution of the logic coded and downloaded from Tia Portal software, this logic mainly incorporates the data request frequency, interlocks, alarming, and optionally a local rule-based EMS. Communication with a higher management level via open platform communication (OPC) is also included. • Node-RED: as an open-source web platform, this software solution is a powerful tool for handling data communication, processing, and conversion. It receives data from the PLC via an OPC client, processes it to handle Modbus limitations when it comes to constructing float values (32-bit based), and communicates with remote databases with write/read functions using RESTful API. Some functionalities had to be written natively in JavaScript as a highprogramming language. • InfluxDB: The time series database supports open-source versions for specific applications. It features an efficient mechanism for managing time series data and offers high scalability, making it a robust data storage solution. Designed for multi-solution communication, it provides integration through HTTP API, InfluxQL, and Python clients. • Python: installed on a Linux operation system, it represents the main edge backend where all data-driven modelling and optimization (advanced EMS) were written with (not shown in Figure 8). Thanks to the available open-source libraries, Python handles communication with the database for ML/DL model training/updating, and employing different optimization techniques. 4. Development and deployment strategies In this section, we cover details about the KTH edge solutions, from the development phase to the installation and commissioning on the chosen project pilots. Due to the profound difference between the applications and the specifications of the targeted pilots, the deployment procedure within HYPERGRYD of these two designed solutions is fundamentally different. 4.1. Edge solution for DH communities management Due to the difficulty of engaging the end-users of the DH energy community, managed by Sonnenplatz pilot, in the developed coordinated DSM, it was unfortunately not possible to deploy the solution locally in Gröschenau municipality in Austria. Therefore, applying coordinated DSM was evaluated on the simulation phase only, which is extensively explained and presented in D3.3. However, setting up the DSM-server with all data engineering requirements was completely commissioned at the KTH campus with remote communication to the meters and sensors in the Sonnenplatz community. 4.1.1. Data streaming format from the energy meters When the DSM-server subscribes to the MQTT broker with the right credentials using Python or any third-party software (e.g., Node-RED), data streaming starts flowing in real-time from the energy meters to the edge database. The data format in this case is an object-based format where the D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 21 measured values are sent all together with some metadata information (e.g., sensor ID, unit, measurement station ID). Figure 9 Data format being sent by the MQTT broker 4.1.2. Data services from the DSM-server Figure 10 shows how these setpoints are being sent to the targeted HPs using JavaScript Object Oriented (JSON) format. This JSON-based information package can be also published to the MQTT broker to which the targeted HPs are subscribing (typically employing a built-in communication feature or using additional hardware). The JSON package contains the targeted HP IDs, the condenser temperature setpoint or simply the ON/OFF command, and the applicable timestamp. Along with the control function, Figure 10 shows additional functionalities that are accessible by the DSM-server thanks to the implemented local time series database. Using web dashboards, DH data can be made public and accessible by all involved stakeholders for rapid and easy performance evaluation. Additionally, third-party commercial software (e.g., the digital twin platform from IDP and the simulation tool from ENCOORD) can take advantage of these real-time data and feed it to their software backends. Therefore, we see in Figure 10 that is possible to query data using simple Linux commands using HTTPS APIs or classical SQL querying. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 22 Figure 10 DSM-server accessible services Deploying the proposed edge-based coordinated DSM into real DHN-powered communities may lead to one common challenge which is the willingness of the end-users to give access to their HVAC systems (particularly HPs) for remote control. There is always the case where this is not possible due to privacy concerns. To overcome this, the study comes up with an alternative solution: the end-users who agreed to be involved in this coordinated DSM will receive, on a daily basis, an optimal setpoint profile to implement, which is applicable for the next 24-hour period. Since most of the recent HP technologies are programmable, the end-user who received the setpoint profile one day ahead (typically via a smart device) will just program the HP to operate accordingly. Figure 11 shows both proposed DSM control mechanisms. Figure 11 DSM control execution mechanism: on the left-hand side, direct control via API or IoT (real-time), on the right-hand side, manual control (predictive) If the end-user is willing to expose his HP for external control remotely, however, the HP technology might not support remote communication, in this case, there is a solution that consists of inserting additional devices into the HVAC control and monitoring panel, existing already, in the household/building (see Figure 12). Such extra investments will be either charged to the end-user D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 23 himself if he is satisfied with the presented payback period, or to the DH or LV grid operators since the coordinated DSM is, indeed, designed to lower the stress on both energy networks electricity and DH. However, the study outlined in this deliverable is solely technical and does not address the implementation strategy within real communities or the role of the stakeholders involved in this coordinated management.. Figure 12 Additional computing hardware for ensuring real-time remote control 4.1.3. Data exploitation in HYPERGRYD The DSM for the Sonnenplatz DH energy community has been validated in a simulation study, where historical energy meter data, stored in the edge database, has been used for this purpose. The goal is to simulate if possible to reach the energetic independence of the concerned buildings (here, four buildings were picked up). The method is based on optimally sharing the available photovoltaic (PV) and thermal energy storage (TES) to give higher flexibility to the HP units to work in optimal coordination and independently from the grid utility. The HP temperature setpoints, as well as the state of charge (SOC) evolution of each TES, are displayed in Figure 13. More information about this study was detailed in D3.3. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 24 Figure 13 DSM simulation (community-centric), top: HP optimal condenser temperature setpoint, bottom: TES SOC variation (bottom figure) in a 2-day simulation) In the framework of HYPERGRYD, the developed DSM-server has also offered an efficient data engineering solution for the project partners who are interested in Sonnenplatz community data. For this purpose, KTH created specific authentication credentials for each partner so they can access the server database remotely via HTTP APIs to get real-time and historical data. Figure 14 Different purposes for connecting to the DSM-server database in the framework of HYPERGRYD This access enabled the integration of sensor data from the Sonnenplatz community into the project platform, specifically within the digital twin software (see Figure 15). This approach provides public visualization, not only for the studied DH community but also for anyone interested in analyzing energy consumption patterns, whether electrical or thermal, in a typical sector-coupling system. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 25 Figure 15 Displaying sensor data for each building in Sonnenplatz community via the project platform 4.2. Edge for BMS upgrading Contrary to the first solution, the installation and commissioning of edge computing for a system to the building level was a straightforward mission. The targeted pilot is the KEZO research center in Warsaw, Poland, to optimize heat and electricity consumption within an emulated locally powered DH system. This is through employing advanced data-driven control of innovative hardware solutions, specifically the CO2 industrial HP and the sorption storage system. 4.2.1. Development phase at KTH Following a significant delay due to hardware delivery, which exceeded one year, the assembly of the panel devices, including the required coding and configurations, took approximately two months before being shipped to the pilot site. For local testing, there was a need to employ Modbus server simulators for troubleshooting Modbus communication. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 32 Figure 24 Simple representation of the reinforcement learning technique for the heat pump control Another key objective for the edge panel is to analyze the operational data of the sorption storage, to be installed at the same pilot as one of the innovative hardware proposed in HYPERGRYD, aiming to unlock its potential for optimal control. The approach involves implementing a simple rule-based EMS on the edge panel's PLC to operate the storage in various modes and evaluate its performance within the building's overall H&C circuits. This process will generate data that can be used to develop DL models for the sorption storage, supported by a mathematical representation of its physical properties, known as a physics-informed neural network (PINN). This, in turn, will pave the way for implementing advanced optimal control strategies, such as nonlinear model predictive control (NMPC). Figure 25 shows the sorption storage technology, during the design phase. Figure 25 Sorption storage during the design phase D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 33 Conclusions One of the milestones that HYPERGRYD is aiming to achieve is to leverage edge computing with the Internet of Things potentials for sector coupling, demonstrating their potential to revolutionize energy management in buildings. These solutions, designed to optimize energy consumption and enhance building management systems, adopt advanced technologies like machine learning, deep learning, and optimization algorithms. Key findings and achievements include: • Successful deployment of edge solutions in real-world operation conditions offered by the project pilots, either completely as in the case of KEZO live-in lab or partially as in the case of Sonnenplatz. • Defining the implementation frameworks and fulfilling the data engineering requirements needed for data-driven control strategies using machine learning and deep learning techniques for optimizing heat pump operations and sorption storage systems. • Integration with building management systems to enable more efficient and effective energy management. • Overcoming technical challenges related to hardware, software, and communication protocols during deployment. Relation to continued developments As edge computing solutions are designed to leverage data-driven approaches, this concept means that there should be a test phase in the project pilots where the main goal is just to collect, process, store data, and build predictive models and optimizations on top of it. While waiting for this process to complete, KTH has defined some potential activities to achieve: • Assess and quantify the KEZO building thermal mass and integrate this information into the edge control framework. This has the potential to give more flexibility to the optimization approaches to deal with the energy price and weather condition fluctuations. • Further develop and refine control strategies, particularly for sorption storage systems, utilizing advanced techniques, particularly, nonlinear model predictive control and reinforcement learning. • Concerning the coordinated edge-driven demand-side management, expanding the deployment to a larger number of buildings and communities to validate the scalability and generalizability of the solutions is targeted. Address potential challenges related to data privacy, security, and user acceptance, especially for residential communities. D3.4 Methodologies and frameworks to optimize demand response and peak load shaving for 4th-5th DHC in three typical European climates 34 References J.C.M. Siluk , P.S. de Carvalho , V. Thomasi , C.A. de O. Pappis, J.L. Schaefer. Cloud-based energy management systems: Terminologies, concepts and definitions. Energy Research & Social Science 106 (2023) 10331. T. Javied et al. / IFAC PapersOnLine 52-10 (2019) 171–175. F. Condon et al. Design and Implementation of a Cloud-IoT-Based Home Energy Management System. Sensors 2023, 23, 176.