Integration and Verification of PLUG-N-HARVEST ICT Platform for Intelligent Management of Buildings

Abstract

THe energy-efficient operation of microgrids—a localized grouping of consuming loads (domestic appliances, EVs, etc.) with distributed energy sources such as solar photovoltaic panels—suggests the deployment of Energy Management Systems (EMSs) that enable the actuation of controllable microgrid loads coupled with Artificial Intelligence (AI) tools. Such tools are capable of optimizing the aggregated performance of the microgrid in an automated manner, based on an extensive network of Advanced Metering Infrastructure (AMI). Modular adaptable/dynamic building envelope (ADBE) solutions have been proven an effective solution—exploiting free façade areas instead of roof areas—for extending the thermal inertia and energy harvesting capacity in existing buildings of different nature (residential, commercial, industrial, etc.). This study presents the PLUG-N-HARVEST holistic workflow towards the delivery of an automatically controllable microgrid integrating active ADBE technologies (e.g., PVs, HVACs). The digital platform comprises cloud AI services and functionalities for energy-efficient management, data healing/cleansing, flexibility forecasting, and the security-by-design IoT to efficiently optimize the overall performance in near-zero energy buildings and microgrids. The current study presents the effective design and necessary digital integration steps towards the PLUG-N-HARVEST ICT platform alongside real-life verification test results, validating the performance of the platform.

1. Introduction

Nowadays, energy crisis is one of the most compelling problems that society must face. According to studies from the U.S. Department of Energy and the European Commission Directorate-General for Energy, nearly 40% of the total energy consumption in modern society is attributable to buildings [1,2,3]. The transition from a conventional power grid to a smart grid which integrates Advanced Metering Infrastructures (AMIs), and Energy Management Systems (EMSs) systems is mandatory if we want to move forward to a more energy-efficient future. The key ingredients of smart grids are the so-called microgrids, miniature versions of a larger utility grid, capable of disconnecting from the main grid and operating in a landed mode (if needed) utilizing the available RES production [4]. However, the energy-efficient operation of microgrids, as well as the optimal harvesting of available Renewable Energy Sources (RES), calls for the design and development of appropriate Building Automation (BA) systems that manage all controllable loads in the microgrid aiming to optimize the overall operation of the system [5].

Nonetheless, providing energy efficient control actions for a building is not a trivial process since a plethora of parameters should be respected [6]. The most crucial aspect is the aspect of thermal comfort for the occupants, as well as the integration of RES and the flexibility of the grid. Therefore, modern BA systems require substantial installation and operational costs and time to provide optimized operation for a building or a microgrid. The vast majority of real-time decision making in microgrids requires an extensive fine-tuning process, continuous calibration, and time- and cost-consuming programming. Such examples [7,8,9,10] provide optimized control actions for microgrid nodes as buildings and EVs based on weather conditions, occupancy schedules, installed infrastructure, and combined optimization.

Related Work

During the last decades, the introduction of BA systems and EMSs led to several control strategies and methodologies that promote and lead to improved building internal conditions by utilizing the building automation ecosystem [11]. However, the concept of utilizing these building automation systems by connecting to them though the Internet [12] has only recently emerged. A first attempt to fill this gap was presented in [13], where a static IP was used in order to connect remotely to the automation system of a building. To do so, in this work, gateway devices were used in order to facilitate the communication between the building system and the remote controller through an HTTP connection utilizing the TCP/IP protocol. Furthermore, this approach presents a first attempt for controlling remotely through the Internet, a scenario that is also described in [14,15].

With the rise of the Internet of Things (IoT) and cloud computing, engineers and researchers investigated the utilization and integration of various off-the-self low-cost and wireless sensors, actuators, and devices [16]. The deployment of IoT sensors is also used to enhance and connect existing and legacy building management systems [17] to offer an even smarter building. On the other hand, the introduction of cloud computing offers access to high volumes of computing power, facilitating and enhancing the use of artificial intelligence, model predictive control, and reinforcement learning techniques.

However, a lot of problems regarding the integration of advanced control mechanisms to building automation systems still remain to be solved and studied [18]. Field test experiences show that the development of IoT devices is a major challenge that needs to be addressed by the whole industry to create common standards and provide interoperability and scalability [19]. Moreover, another major concern the security and privacy of the data, as well as the secure connection between all these devices [20,21].

This paper presents the steps for the integration and verification of the Plug-N-Harvest Information Communication Technologies (ICT) platform for Intelligent Management of Buildings or block of buildings and the performance of the presented system in comparison with state-of-art works tackling the challenges presented above. The current work is based on the previous work of the authors [22], however, we focused on the integration and verification steps of the proposed architecture tackling the major obstacles and challenges that arise in cloud BA systems. Moreover, in contrast with most literature works, this paper presents real life implementations and tests validating the operation of the proposed cloud based platform and the necessary integration steps that required for the realization of this idea. In Section 2, the user and system requirements towards a fully secured and automated building operation are analyzed. Section 3 presents the integration steps between the different architecture modules, focusing on data models, the cloud-based ICT architecture, the workflow, and the token-based execution sequence that produce the finalized version of the proposed method. Section 4 describes the real-life results obtained from the unified operation of the PLUG-N-HARVEST ICT platform. Finally, conclusions and ongoing research are drawn in Section 5.

2. System and User Requirements

User requirements are of key importance as they refer to the activities and actions a user must perform. These user needs are eventually exploited as an input to create and build the system requirements. These requirements could be functional and/or supplemental. In addition, each system must meet some main key objectives (KOs). The PLUG-N-HARVEST (P-n-H) platform for Intelligent Management of Buildings reports various KOs that regulate the Building Energy Management (BEM). The current section briefly presents the links between the identified requirements as elicited within the overall architecture framework of the P-n-H architecture of the system and the respective measures taken within the BEM tools and applications created in this regard.

The KOs along with their requirements are listed and presented mainly toward the respective mitigation undertaken and are summarized in

Table 1. User and system requirements.

Requirement	Actions
Flexible integrated planning process	Integration of various communication protocol and actuators, seamless monitoring, interoperability.
Low-installation costs and operational cost	Remote web servers and cloud servers, minimization of equipment, minimum operational costs.
Optimal control of the different ADBE elements	Holistic building management operation, robust adaptive control designs.
Cost-efficient incorporation of new ADBE technologies	Easily implemented, low-cost, upgradable, and interoperable system.
Optimal Energy Management System	Contain buildings with highly different characteristics and usage, contain different types of occupants’ and financial capabilities, district aggregated information.
Connection and integration with various energy networks	Collection of data and aggregation of information from different power supply domains.
Shift demand among consumers and optimization of energy trading	Optimization of the energy trading between consumers, storage systems, and both the thermal and electrical grid.
District/Smart grid Cyber Security	Safety mechanisms with the cloud ecosystem, preservation of  data quality and fault filtering.
Protection of the infrastructure elements	security framework, strongly and securely shielded BMS middleware platform
Support privacy for data collections in the IMCS/OEMS modules	Data privacy schema implementation within the BMS middleware.
Low-cost installations for IMCS	Wireless deployment of the necessary automation equipment, no local server for hosting the software ecosystem.
Reusable and recyclable materials	Careful material assessment both for  the ADBE and the building automation devices,  circular economy business model, and exploitation plan advance.
Maximum energy reductions and energy harvesting	Reduce the overall energy consumption, maximizing the harvested energy exploitation, and preserving indoor comfort.
Different modules of the P-n-H solution installation in different buildings	Several collaborating sub-modules.
Deployment and tests with many different real-life pilots	Wide range of building properties, diversity and versatility, scalable and reconfigurable  standalone software tools.

, within the P-n-H ICT BEM architectural framework as follows:

• “Flexible integrated planning process”. All the building’s information and data of the façade system are usable and accessible within the Building Information Model (BIM) [23]. Therefore, the P-n-H overall system considers wireless metering and various communication protocols and actuating technologies [24] which enable seamless monitoring and acting to all diversified elements of the building automation network in a cost-effective manner while ensuring the system’s interoperability. Furthermore, all modules tailored for managing data coming from and forwarded to the respective connected devices have been designed and thoroughly tested.
• “Low-installation costs and almost-zero operational costs for controlling the Adaptive Dynamic Building Envelops (ADBEs)”. Within this context, P-n-H flexible ICT modules for safety, fault mitigation, control, and optimization have been designed and developed in response to this requirement. All modules stand on remote web servers and cloud servers to minimize the equipment and human effort costs for their local installation and maintenance. Considering that a robust and reliable Internet connection is available, the overall system requires minimum additional operational energy resources: energy consumption of the internet router (i.e., around 20W), energy consumption from wireless sensors (i.e., around max 5W each), and energy consumption of the network gateways (i.e., around 15W each).
• “Optimally control the different ADBE—and Conventional Controllable Building Elements (CCBE)”. In case there are CCBE elements, actions are coordinated towards an integrated manner, while achieving maximum possible energy use reduction and energy harvesting from RES and maintaining user satisfaction and safety of the overall operations. Therefore, the advances in P-n-H have been aligned with the integration of existing building automation elements to increase the degree of freedom of control, enabling a more holistic building management operation within P-n-H solutions. The first and most important issue that the P-n-H framework tries to tackle is the control of safety derived from fault-free data, as well as robust adaptive control designs. Furthermore, the optimization criterion as formulated within the Intelligent Management and Control System (IMCS) tool takes into account three main indices representing total energy consumption, total energy generation, user thermal comfort, and maximum available flexibility.
• “Easily implemented, low-cost, upgradable, and interoperable”. The system enables the easy and cost-effective incorporation of new ADBE technologies. Moreover, it is easily and inexpensively upgradable and interoperable to enable the easy and cost-effective incorporation of new ADBE technologies.
• “Optimal Energy Management System (OEMS) at District/Grid Level”. The plug-and-play nature can be deployed in districts containing buildings with highly different characteristics and usage, as well as different types of occupants and financial capabilities. Therefore, the cloud ecosystem consists of the OEMS module, which is dedicated to integrating information from every P-n-H-equipped building to feed the support with district aggregated information. Therefore, decisions are made by local building optimizers and controllers (IMCS). The idea behind the district optimizer is to provide each of the local IMCS with essential hints regarding the overall district situation, i.e., energy consumption, energy generation, energy stored, and available flexibility, in order to take mutually beneficial decisions at the building level and create a synergistic district aggregated block of smart buildings/neighborhoods.
• “Connection and integration with various energy networks”. Buildings within the P-n-H system are connected and integrated with various energy networks (e.g., electricity, heating/cooling, domestic hot water). As a result, the OEMS module collects data and aggregates information from different power supply domains, which may affect the performance and utilization levels of each other. Specifically, to optimize the indoor thermal comfort of the building occupants, both district heating systems and locally driven heating systems (e.g., gas boilers, electric heaters, air conditioners) are integrated and managed in a coordinated manner.
• “Shift demand among consumers and optimization of energy trading”. The P-n-H ICT system properly shifts the demand among consumers at different times and optimizes energy trade between consumers, storage systems, and both the thermal and electrical grid. Additionally, the district energy management system predicts and monitors both energy generation from integrated neighborhood systems and user consumption while providing information to end users and allowing them to participate in the management of their energy demand. As a result, the OEMS collaborate with the Demand Response Flexibility Forecasting and Optimization (DRFFO) module, which is responsible for calculating and forecasting, based on real-time data, the available flexibility at a building and aggregated district scale. Such functionality allows the respective building operators (e.g., energy aggregators, homeowners) to actively adjust the level of their compliance and, consequently, their benefits, with the demand response strategies (demand shifting and shaping) implied by the Distribution System Operators (DSOs) in different power supply domains. Moreover, within the P-n-H cloud ICT ecosystem, an auxiliary, yet able to provide quite informative situation insights, user visualization platform grants different levels of access to different users (occupants, building operators, DSOs, etc.), allowing simple actions/strategies to be selected by them.
• “District/Smart grid Cyber Security”. Cyber security measures include fault identification mechanisms to allow an easier reconfiguration and improved resilience of the distribution grid when the RES harvested within the ADBE solutions is provided in the grid. Therefore, the safety mechanisms foreseen with the cloud ecosystem are dedicated to preserve data quality and fault filtering in emergent or abnormal occasions such as sensor malfunctions/lags or power shut downs. Fault-free data enable a more resilient and reliable operation of the overall system, allowing the control mechanisms to react to reliable data reflecting the real-life situation of the building plant.
• “Protect the infrastructure elements”. To ensure the protection of the infrastructure elements based on sensors and gateways from attacks and possible threats, a security framework is defined to bootstrap and commission possible components of the P-n-H architecture and its integration with the ADBE and IMCS/OEMS applications. Therefore, BMS middleware, which is responsible for routing and transmitting data and information to and from every interconnected ICT module, has been designed and developed to enable specially designed JAVA-based security protocols and interfaces. Moreover, the strongly and securely shielded BMS middleware platform serves as the cloud end-point to the local building automation network (internet router), which establishes a reliable and secure communication channel with all other ICT modules.
• “Support privacy for data collection in the IMCS/OEMS modules”. To support privacy-preserving solutions for data collections on the IMCS/OEMS modules and in between points of data aggregation, the end users have the capability to have control over how his/her data are disclosed. Therefore, the data privacy schema has been implemented within the Building Management System (BMS) middleware framework, granting different levels of access to different potential actors of the energy grid where needed according to the preferences and consent of the data owners (i.e., end-users, occupants).
• “Low-cost installations for IMCS”. The ICT P-n-H activities take into account the requirements of low intervention and low installation costs, considering a fully wireless deployment of the necessary automation equipment. To this end, only the metering and actuating devices need to be deployed physically at the building level, while no local server for hosting the software ecosystem is needed since the software deployment is fully on a cloud server. Furthermore, the IMCS software tool, along with the collaborating BMS, OEMS, DRFFO, and Security and Safety Security Mechanisms (SSM) platforms, are designed and implemented to be easily reconfigurable on-the-fly. In addition, they are also capable of re-adjusting their operation according to the scale of the building plant.
• “Reusable and recyclable materials”. Within this context, special measures for careful material assessment, both for ADBE and building automation devices and increasing recyclability and reusability, were taken after the final selection and purchase of the respective devices by the pilot owners. This assessment is carried out according to the advances in the circular economy business model and the exploitation plan. Moreover, installing, maintaining, and replacing automation devices has already been extensively documented online, providing instructions for Do-It Yourself (DIY) deployment.
• “Maximum energy reductions and energy harvesting”. The ICT mechanisms have been proven capable, within previous European-funded projects, to drastically reduce the overall energy consumption (>30%) while maximizing the harvested energy exploitation and preserving indoor comfort.
• “Different modules of the P-n-H solution installation in different buildings to optimally exchange renewable energy”. The P-n-H ICT ecosystem is consisting of several collaborating sub-modules which have already become available as standalone tools from previous P-n-H contributors, activities, and projects. As a result, each part of the ICT cloud ecosystem can be individually selected according to the needs of each building operator. Being versatile and flexible extends to selecting from a collection of enabling functionalities by the potential users/customers. Moreover, the same P-n-H solution is flexible and easily configurable to expand—by defining the scale of the building plant—its applicability to diversified types and sizes of building-plants.
• “Deployment and tests with many different real-life pilots”. The selected pilots also cover a wide range of building properties as those of various sizes, energy labels, insulation, operational with or without additional conventional RES harvesting systems, glazing materials, materials for frames (steel, aluminium), systems for heating and hot water production, and low- or high-energy-consuming buildings. As a result, P-n-H ICT modules have taken the appropriate measures to ensure compatibility and interoperability with commercially available and certified wireless building automation devices through well-established and widely used communication channels and protocols. Diversity and versatility have already been considered as one of the main differentiating features of P-n-H by tailoring scalable and reconfigurable standalone software tools which had already reached medium Technical/Technological Readiness Levels (TRLs).

3. Integration of Core Architecture Components

The current section presents the details of the integrated ICT cloud ecosystem framework, the common data model which enables a uniform interpretation of the available data, the token-based execution manager, as well as the conceptualized considered architecture. Moreover, an extensive representation of the tokenized sequence that is used during the integration tests is presented, describing the sequence where the modules are operating. Finally, all updated core ICT sub-modules, already elaborated, are briefly described herein, too.

3.1. Data Models and Interfaces

To establish a common communication manner among all ICT modules, a common set of data objects, having the same structure and attributes for all interfacing cases, has been defined and agreed among the technology providers of the PLUG-N-HARVEST Cloud Ecosystem framework. Data objects aligned with the JSON [25] format are considered to be the most common and widely used nowadays. The JavaScript Object Notation (JSON) is an open-standard file format that uses human-readable text to transmit data objects consisting of attribute–value pairs and array data types (or any other serializable value), plus it is a language-independent data format. The JSON data objects are grouped into five different types according to their origin, which corresponds to the intended location/placement of the sensors as well as the number of necessary attributes that are required for the smooth operation of the ICT ecosystem. As a result, the defined object types are briefly described as shown in

Table 2. Common Data Object types.

Type	Description
Gateway: Zone Sensors	Group of data attributes originating from sensors installed per zone.
Gateway: Zones-Block Sensors	Group of data attributes originating from sensors installed per block of zones (or building) case.
Gateway: Zone Actuators	Group of data attributes originating from actuators installed per zone.
Gateway: Zones-Block Actuators	Group of data attributes originating from actuators installed per block of zones (or building) case.
Gateway: Optimization Criterion	Group of processed and aggregated data attributes originating from post-processing of the real-time data objects “Gateway: Zones-Block Sensors” and “Gateway: Zone Sensors” for calculating certain metrics and indices necessary for calculating the optimization criterion.
Gateway: WebSource	Group of data attributes originating from virtual/fictitious sensors retrieved from the web (e.g., virtual sensors for outdoor temperature prediction) per building case.

below, while the categorization of the devices’ set also complies with the concept considered in Section 4.

3.2. Cloud Ecosystem Architecture

The architectural topology of the cloud ecosystem considered within the PnH project is shown in Figure 1. The entire ICT ecosystem, after reviewing the user requirements in Section 2, has been designed to be fully hosted on a cloud environment to minimize the intervention in the indoor living or working environment of the pilot sites by neglecting the presence of local servers.

The architectural topology can be divided into two operational layers: (a) the building automation network hardware at the pilot site and (b) the ICT cloud ecosystem, which are discussed in more detail below.

3.2.1. Building Automation Network Layer

The building automation hardware components consider Z-WAVE enabled wireless sensing and actuating devices. Z-WAVE technology has reached a high level of market and developers-community maturity where a wide variety of devices has become available while extended tutorials and DIY manuals for their deployment are freely available on the web [26]. To this matter, the PnH cloud ecosystem Z-WAVE compliance is an additional factor which could extend its replicability and user acceptance. Moreover, acting in the same respect, the gateways enabling the necessary Z-WAVE connection, structuring and preprocessing raw data, as well as serving as the endpoint for external communication of the building automation layer, are based on recent advances on open, flexible, and cheap miniPC AIO Raspberry Pi Model 3 [27] platform technologies.

During the monitoring phase, each sensor is certainly linked to a specific gateway, and the gateways are responsible to collect (sending Z-WAVE state queries) the current time-step measurements, structure them, and forward them outside of the automation network layer borders, i.e., to the BMS Middleware platform, through a secure (Java-based encryption module) interface. The exact opposite applies for the actuation phase, when the control cycle executed at the ICT cloud ecosystem layer has finished and the optimized control decisions are requested from the BMS Middleware. The received control decisions are then translated/interpreted into actionable control commands by a dedicated Control2Command API hosted on each gateway in accordance to the operational particularities of the available controllable appliances. The resulting control commands are compared to the current state of the actuators, and the ones which are the same are detected and neglected to avoid losing time, energy, and system safety by eventually imposing the same commands. Finally, the control commands are applied to the respective actuators of the available appliances by employing a repeated procedure ensuring the smooth update of their state while preventing lags or infinite hardware acceleration loops through operationally sensible rules.

3.2.2. Cloud Ecosystem Layer

The ICT ecosystem, outlined within the yellow box in Figure 1 above, is foreseen to be hosted entirely on the cloud. Here, the cloud term does not strictly refer to web-platforms with unlimited (or almost unlimited yet very high) computational resources available on-demand rather than to either elaborate remote server deployments of each ICT module comprising the PnH ICT ecosystem. Therefore, the term cloud refers to a fully server/web-based deployment and intercommunication strategy among all constituent ICT modules.

The functionalities of the considered ICT modules are supported and endorsed by auxiliary services and tools developed or tailored for P-n-H scope by the main contributors of WP3 (see also Section 4). A standalone web-based application which is responsible for retrieving weather data, and most importantly, forecasted weather data, for the location of each specific PnH application exploiting free web repositories has been incorporated within the cloud ecosystem framework. In addition, another standalone API is responsible for calculating the accumulated as well as the zone-referring indoor thermal comfort of occupants based on the widely accepted Predicted Mean Vote (PMV) and Predicted Percentage Dissatisfied (PPD) indices. In addition, a payment and energy exchange platform based on conceptual blockchain principles has become available to introduce and eventually enable energy flexibility trades among several actors of the same supply chain (power distribution grid). Finally, different visualization platforms with data access at different levels of the overall system have also become available to support a more informative end-user participation within the concept of energy trading and preservation. However, the main visualization application will enable, through completely configurable dashboard user interfaces, different actors to retrieve valuable data of different types (either raw or aggregated according to the access granted based on the data owners’ case-specific agreement, which should always comply with the national and European legislation).

Most importantly, the cloud ecosystem is composed of four main tools, namely: (a) BMS Middleware; (b) Security and Safety Mechanisms (SSM); (c) Optimal Energy Management System and Demand Response Flexibility Forecasting at district-level framework (OEMS and DRFFO); and (d) Intelligent Management and Control System, at the single building level (IMCS). Firstly, each of these tools implements a local database that minimizes heavy data traffic at the central database node, while BMS Middleware is responsible for populating the central structured database. The central module where all data are routed and exchanged through is the BMS serving as the middleware platform, responsible for buffering locally or storing in a central structured database. The BMS Middleware platform enables secure, sensitive, anonymized data with all other modules handled by specially encrypted JAVA-based incoming queries, as well as implementing a straight-forward, token-based execution management for the whole cloud ecosystem.

The SSM implements pattern recognition methodologies to detect the occurrence of faulty raw data, recognize the type, and cure/mitigate the faulty raw data readings originating from the sensor network. In cases where no data-healing strategy (model) is available, the SSM will raise system alarms for the building operators/owners. The OEMS is responsible for emulating demand request strategies (considering virtual neighboring PnH buildings during real-life pilot tests) from the grid operator’s side, which will guarantee a holistic district-scale, situation-aware operation, together with the DRFFO, which focuses on predicting the flexibility levels at the single building or district scale. Both OEMS and DRFFO implement data-mining tools for modeling and predicting macro- and microgrids’ dynamic behaviors. Finally, the IMCS module is responsible for aggregating all necessary information coming from the SSM as well as from the OEMS and DRFFO to compute the optimized control decisions originating from an Artificial Intelligence (AI) mechanism considering thermal comfort, energy consumption, and RES exploitation as the main cost-criterion indices.

3.2.3. Workflow Description

The operational workflow, which implies an iterative control procedure, is considered to start from the monitoring phase and finish at the actuation phase. Usually the duration of each control cycle in real-life buildings is set equal to a few minutes (from 10 to 15 min) depending on the thermal inertia (shell insulation, power, and size of HVACs; occupancy intensity, etc.) of the building plant. The workflow can be briefly described as a discretized procedure discretized into 13 steps and is presented in Figure 2 as follows:

• Initially, the restricted or open-source device managers (hardware accelerators) will be tailored according to the needs of the PnH project, hosted at the level of the gateways. These mechanisms will implement an iterative procedure until all expected devices have replied to their state (measurements) publishing queries. If at any point some of the devices expected to respond did not, then the respective entry in the stream of data readings will be replaced by an indicative value (e.g., a negative or NULL) denoting the problem which should be mitigated by the dedicated SSM mechanism in the cloud ecosystem framework. This mechanism will be triggered every few minutes according to the control-cycle-defined duration. For this matter, wireless Z-WAVE (or ZigBee if needed) communication protocols and respective data parsers have been considered.
• The received data readings are then structured at the gateway level in order to meet the common data model attributes and structure as described in Section 3.1. The data objects created at this level meet the design attributes of “Gateway: Zone Sensors” and “Gateway: Zones-Block Sensors” depending on the actual role of each respective gateway.
• The structured data are forwarded through a secure JAVA-based channel through the available Internet data routers to a certain static IP on the Internet denoting the BMS server acting as the middleware.
• The structured data are parsed and buffered locally at the BMS middleware level, while an indicative token is created by the execution manager which triggers the following: the SSM in order to heal/cleanse any faulty data or patterns recognized according to the historic data patterns identified, as well as the weather-forecast-retrieving API in parallel, adopting the same secure JAVA-based encryption mechanism as in step 3 above.
• The SSM filters faulty data using commonly used curing techniques driven by pattern recognition methodologies to detect and recognize the type of the fault. Moreover, already easily recognizable errors (recognized at the gateway level—see Step 1) indicated with certain imposed values are also treated appropriately at this point. Moreover, in severe error incidents, specific alarms are logged as important events and notifications are triggered for the system operator.
• After the completion of step 5, the reception of weather prediction data as well as fault-free measurements, the BMS Middleware temporarily buffers the data objects needed for the other ICT modules. Evidently, the respective flag-token triggers step 7’s mechanisms: thermal-comfort-calculating API, weather API, and OEMS service initiation.
• The thermal-comfort-calculating API, based on the buffered data, and the database manager, which permanently stacks the respective new entries—reflecting the current control cycle—for evaluation purposes in the central data base, are executed while their responses are sent back to the BMS Middleware through the overarching secure JAVA-based channel considered for all data exchanges through the BMS. The input data objects at this level meet the design attributes of “Gateway: Zone Sensors” while the output data objects meet that of “Gateway: Optimization Criterion”. Moreover, in parallel, the OEMS—responsible for emulating the grid behavior, as well as the demand requests of the operator of the grid at the district level—and the weather retrieving API are also initiated in order to collect forecasted weather data for the specified building plant location available in open web repositories (e.g., www.tutiempo.net, accessed on 10 February 2022). Both modules communicate through the same JAVA-based secure channel (as presented in Step 3) with the BMS Middleware. The input data objects as well as the output ones at this level meet the design attributes of “Gateway: Zone Sensors” and “Gate-way: Zones-Block Sensors”, respectively, while the weather forecast API considers void/NULL inputs and “Gateway: WebSource” output objects, respectively.
• The DRFFO is responsible for calculating the current flexibility, as well as predicting the future available flexibility, at a building and emulated district level—modules are also executed in a closely cooperative manner. The input data objects at this level meet the design attributes of “Gateway: Zone Sensors” while the output objects meet those of “Gateway: Optimization Criterion”.
• After the completion of step 8 and the reception of the thermal comfort index, as well as the availability of demand flexibility index, the BMS Middleware temporarily buffers the data that are necessary for the optimization criterion calculation in the local building optimizer module IMCS. Evidently, the respective flag/token which triggers the IMCS module in step 9 is generated.
• The IMCS module is executed, being responsible for calibrating the control strategy on-the-fly based on the real-time accumulated optimization criterion values on a periodic basis, i.e., usually every few hours. The optimization criterion considered in a weighed summation of the normalized climate (HVAC) devices energy consumption (available directly from the sensor network), the thermal comfort index (available through step 7), and the available flexibility index (available through step 7 also). Moreover, based on the buffered cured data measurements (originating from step 5) and the calibrated control strategy, the optimized control decisions for every controllable climate (HVAC) device are generated by implementing a closed loop piece-wise linear control schema. Similar to the above, a secure JAVA-based channel is considered for parsing the resulting decisions back to the BMS. The input data objects at this level meet the design attributes of “Gateway: Zone Sensors” and “Gate-way: Optimization Criterion”, while the output ones meet those of “Gateway: Zone Actuators” and “Gateway: Zones-Block Actuators”.
• After the completion of step 9 and the reception of the control decision data, the BMS Middleware temporarily buffers the data objects while the database manager is triggered in order to populate the database with the results from OEMS, DRFFO (i.e., flexibility forecasts, demand requests), and the IMCS (i.e., control decisions) necessary for the operational evaluation of the system. Evidently, the respective flag/tokens which trigger step 11 and 12’s mechanisms, the data manager token at the gateway level, are generated.
• The data manager sends a data query requesting the structured control decisions buffered at the BMS middleware level already. Similar to the above, the query is sent via a secure JAVA-based Internet channel. The input data objects at this level meet the design attributes of “Gateway: Zone Sensors” and “Gateway: Optimization Criterion”, while the output ones meet those of “Gateway: Zone Actuators” and “Gateway: Zones-Block Actuators”.
• The structured control decision data are parsed back to the respective gateways according to their granted level of access to certain data objects. At this point, a specially designed module, namely, the Control2Command API, is triggered in order to interpret the optimized control decisions, generated by the IMCS module at step 9, into device-acceptable and -understandable actuation signals and commands.
• Finally, the actuation signals are compared with the previous ones in order to identify which actuators should and should not change their state. The respective actuation signals, only for the devices identified, are sent wirelessly through the device manager end-point service while an iterative procedure ensuring their actual application on the controllable devices completes step 13’s activities.

Figure 2. Sequence between the PnH ICT modules.

Figure 2. Sequence between the PnH ICT modules.

3.3. Token-Based Execution Manager

The token-based execution will be implemented by means of the above-mentioned REST/JSON API of the BMS server to exchange synchronization tokens among ICT tools (i.e., OEMS, DRFFO, Weather Module, Comfort Module, IMCS, and Safety). The idea is not to exchange data but only execution tokens in a sequential manner to appropriately trigger each idling sub-module considered within the cloud ecosystem. This way, the operation is considered more secure since cyber-attacks cannot affect data and decision making, only the execution sequence. This could potentially lead to low operational risks, which can easily and safely be mitigated by disarming the PnH cloud ecosystem. For this matter, a subscribing REST/JSON function, which is already available as a verified functionality of the BMS Middleware, has been considered. The sequential execution of the overall automation system of PnH is presented in a subsection below. Moreover, one of the main goals of this token-based implementation will be also to check whether each cooperating interconnected ICT sub-module is responding as expected. A dedicated framework consisting of certainly defined timers and secondary tokens, indicating the execution progress internally in each exogenous sub-module, will be implemented, depending on the experience gained during the pre-pilot test phase. For instance, the token-based module will be used to synchronize the operations of IMCS and DRFFO before completing their execution. In particular, when the DRFFO generates the calculated vlexibility data and publishes it in the BMS server via a secure connection, the DRFFO will send a respective token to the BMS that will trigger the IMCS through the subscription mode. At that moment, the IMCS will be aware that there are new calculated data in the BMS and will request them via a secure connection to progress its task within a single control cycle. The tokens shared in the common communication channel are composed of Json-formatted messages (Figure 3). The messages contain all the necessary information in order to activate the right module according to the sequence selected by the technical partners. Below you can find the Json-formatted message with all accepted inputs for every field:

"src":[], "dst":[], "pilot":[], "action":[], "msg":""

src = (Gateway, Safety, Weather, Comfort, Oems, Drffo, Imcs, ALL); dest = (Gateway, Safety, Weather, Comfort, Oems, Drffo, Imcs, ALL); pilot = (Cardiff, Grevena, Barcelona, Aachen, University, Thessaloniki); action = (Initiation, Partially Processed, Finished, Error, Timeout); msg = (Complementary human ready information about the error...).

Figure 3. Real-Life Testing of the Communication Channel—Token Sequence.

Figure 3. Real-Life Testing of the Communication Channel—Token Sequence.

4. Validation Results in Pilot Cases

All P-n-H pilot test cases (i.e., Thessaloniki prepilot test-bed, Greece; Aachen, Germany; Grevena, Greece; Barcelona, Spain; Cardiff, United Kingdom) are equipped with a large amount of sensors and actuators related to the P-n-H concept, such as smart plugs, energy consumption meters, smart lighting, indoor and outdoor environmental conditions meters, HVAC metering and controlling equipment, etc. All these sensors/actuators/smart appliances are connected with various protocols (e.g., ZigBee, TCP/IP (wired and wireless), z-wave, Bluetooth, enOcean, M-BUS, etc.). Appropriate gateways were developed and are ’running’ on a Raspberry Pi and are capable of collecting all raw information and data and sending it to the BEMS server. All P-n-H systems are equipped with an MQTT server [28], where each device/ sensor can send and retrieve information in real-time. Furthermore, the system supports RESTful services [29].

Consequently, all devices send their information using either the MQTT server and/or the RESTful services. This information is stored (optional local service) in a hybrid database (DB) in order to present historical information. The hybrid DB is comprised of a nonstructural database, MongoDB [30], where all static information such as building information, users, sensor information, etc., are stored. On the other hand, a time-series DB, namely, the InfluxDB [31], is utilized for storing the time-series data retrieved by the sensors, e.g., energy consumption measurements. At the top of this management system, there is the visualization tool, which is an Angular JS-based module [32] able to visualize the raw information. It supports multiple users with different rights and access to the platform, where each user can visualize different data and information depending on his/her rights. It supports five kind of users, i.e., administrator, white label user, portfolio users, site users, and building users.

Its main functionalities are summarized below:

• Support for different IoT Gateways is used in a variety of domains to support seamless data collection and aggregation;
• OEM platform is easily configurable and adaptable to user needs and preferences. Multi-hierarchical-level support for user authentication and category management;
• Innovative low-power, embedded-intelligence-incorporating next-generation communication protocols (i.e., LoRa);
• Open reference Connectors API (customized REST services) for enabling third parties to collect, analyze, and store big data in platform instances (either on the premises or on the cloud);
• Based on Open Architecture and existing standards such as MQTT to ensure interoperability and industrial-grade performance;
• Deployment agnostic solution (Cloud/On Premises).

Furthermore, each user can have multiple dashboards, which are completely dynamic, and he/she can modify and adjust them to his/her needs. Specific areas where the user can compare the data of the sites/buildings are provided. The raw data, as they are received by the sensors, are also available to users with proper rights. A complex dynamic ruling system is available to the user, where each user can create his/her own rules according to his/her needs. Finally, the system is equipped with a dynamic reporting system, where the user can create specific reports and retrieve them either on demand or automatically every day, week, month, etc. Real-life experiments and integration tests were conducted on all pilot premises. The goals of these experiments were the following:

i

Validate the connection between the different ICT components through the common communication and tokenized channel;

ii

Test their connection with the BMS server, facilitating the posting and retrieval of building data;

iii

Test the technical properties and the functionality of each technical component.

The test experiments were successful, providing a tool to test each P-n-H module and finalize applications through extensive testing. Below, one can find figures that showcase the P-n-H’s functionalities and testing results, as they are presented in the system Graphical User Interface (GUI), during real-life experiments that took place in all pilots. In the following sub-sections, the main results of all phases of the PLUG-N-HARVEST ICT platform are presented.

4.1. PLUG-N-HARVEST Dashboard Menu

The P-n-N dashboard main tab consists of all available clients, tools, and applications. As depicted in Figure 4, the administrator may visualize all available clients as he holds the higher-level administrative rights. Within this context, through a navigation pane, the administrator user may select one of the available clients to assess the respective dashboard (i.e., Cardiff, Greece, Spain, Germany, Pre-pilot Thessaloniki). On the other hand, a site user would be able to access only his/her information. Each client is mapped only to his/her devices, sensors, and information. Apart from the administrator, none of the other user types could have access to all pilots. In addition, specific clients and information are available to the building user (e.g., all apartments per building block) if necessary and defined.

As depicted in Figure 5, the user can navigate to all available tools and select the one that he/she is interested in monitoring. As it has been already mentioned, the dashboard menu is configurable; as a result, the user may hide the panes that he/she is not interested in and restore the hidden pane when needed.

4.2. Validation Results: Gateway

To validate that a gateway functions properly, all accessible data and information from all available user’s devices, sensors, and ICT equipment are visualized on the dashboard. If the process designed to obtain the data from the devices and sensors is continuous, the daily graph is complete with no gaps, as depicted in Figure 6. As a result, the developer responsible for tracking the malfunctions from data retrieval will be able to monitor possible errors. Furthermore, the site user is capable of monitoring both current and daily conditions.

Moreover, designing different types of dashboards, various types of the system’s gateways may be validated while providing a more user-friendly perspective (Figure 7 and Figure 8).

4.3. Validation Results: P-n-H Modules

Likewise to the gateway’s validation, the P-n-H modules may be monitored through the dashboard. Comfort and discomfort are depicted in Figure 9 and Figure 10, respectively. It may be observed that the specific tool functioned properly during the day. Current weather and forecasted weather modules are depicted in Figure 11 and in Figure 12, respectively.

Finally, the DRFFO module is depicted in Figure 13. This module simulates all possible energy states as presented in the Building Simulation pane. As observed in the example, there are three possible building energy states. Furthermore, the daily upper and lower energy flexibility is monitored through the flexibility pane. All possible states are assessed through predefined key performance indicators (KPIs) and are presented in the KPIs pane. Finally, all states are evaluated based on the selected KPIs, and the optimal state is presented to the user along with the score as depicted in the optimal state and optimal state evaluation pane, accordingly.

4.4. Validation Results: Intelligent Management Flow

To validate the IMCS tool, a different and more complex procedure must be followed to test that it is operating smoothly. More tests must be conducted than a simple visualization of the respective tool’s dashboard. The following steps of the validation procedure of the IMCS tool are depicted in Figure 14. Overall, the indoor conditions are checked, and after the recommended IMCS actions are produced, the indoor conditions gateway is checked again for the applied actions. When the recommended IMCS actions are visualized by the indoor conditions dashboard, the procedure is considered successful.

To set an example, the indoor conditions gateway is checked at 14:00 (Figure 15). During this time interval, the lights are on, as stated by the light dimming that is equal to 100 %. Furthermore, it is observed that the light consumption is 54 watts. The HVAC’s set temperature is 24 Celsius degrees, the HVAC’s fan speed is 4, and the operating mode is set to 5.

The DRFFO module during the same check time produces all possible states of the lights (on/off) (Figure 16). The lights are the only devices that are taken into consideration in the DRFFO module, as they are the only ones for which the consumption is known. As a result, the possible states are twofold: One is that the lights are on (i.e., light dimming equals 100%), and the other is that the lights are off (i.e., light dimming equals 0%). The consumption of the two produced states is simulated. In tandem, the flexibility of the upper room is estimated. Finally, the KPIs are estimated and, based on the optimal state, are produced along with its score. The optimal state produced by the DRFFO is to dim down the lights to 0 (off).

Consequently, the IMCS module is checked. The recommended actions as depicted in Figure 17 are the following: set the HVAC temperature to 23 degrees Celsius and the HVAC fan speed to 3. These actions are produced to mitigate energy consumption while preserving the occupants’ thermal comfort.

Finally, the indoor conditions gateway is checked at the next time interval (10–15 min) as depicted in Figure 18. It may be observed that the recommended actions were successfully adopted by the BMS. The overall procedure described above in the validation flow chart and the figures is presented in

Table 3. Overall validation assessment.

System Validation
	Actions	Timestamp	Result	Comments
1	Check current indoor conditions	current	Light dimming = 100 %,    Light consumption = 54 W, HVAC set Temp = 24 ${}^{\circ }\mathrm{C}$ ,    HVAC mode = 5, HVAC fan speed = 4	successful
2	Check DRFFO module	current	Building simulation:      current state:  lights on  state1 =  lights off  state2 =  lights off Optimal state: STATE 1	successful
3	Check IMCS	current	HVAC set Temp = 23 ${}^{\circ }\mathrm{C}$, HVAC mode = 5,  HVAC fan speed = 3	successful
4	Check   next quarter indoor conditions	current	Light dimming = 100 %,  Light consumption = 54 W, HVAC set Temp = 23 ${}^{\circ }\mathrm{C}$,   VAC mode = 5 ,     VAC fan speed = 3	successful
Overall assessment				successful

.

5. Conclusions

This work, together with previous work by the authors, presented a novel architecture for secure, modular, and intelligent management of buildings and microgrids. In the current work, we proposed the integration of multiple cloud energy management systems (i.e., IMCS, DRFFO, OEMS, Weather, and Comfort modules) to achieve better energy efficiency, maximization of the thermal comfort, integration of RES, and optimized grid flexibility both in the building and district levels. To provide secure and coordinated communication and data exchange between the cloud systems, the architecture integrated a novel BMS system. Furthermore, the final steps of verification, integration, and testing of the proposed solution were presented, alongside the main user and system requirements, demonstrating the operation of the ICT platform in real conditions.

Specifically, before initiating the integration of the overall recommended system, the main system and user requirements were assessed to be deployed into the BMS. The key objective is to encounter fundamental key objectives that enhance the building’s energy management while providing a low-cost and robust system. These include a flexible integration planning process, low-cost installation, optimal controls, easy updates, interoperability, and others. Overall, user and system requirements must be covered at an early designing phase to ensure the users needs and systems functionality.

The proposed system was integrated based on an ICT cloud ecosystem framework. The available system modules (i.e., IMCS, DRFFO, OEMS, Weather, Comfort) are exploiting a common data model interpreting all available data and information while exchanging data amongst them during an execution cycle. To handle the execution of different modules and ensure the system’s interoperability, a token-based execution manager is deployed that handles the execution of each module. An in-advance execution sequence is developed based on the inputs each module demands to operate.

During a testing and evaluation period the system was tested following various tests. Initially, each module is tested to be distinctly successful. When the distinct modules operate successfully, their functionality is also tested applying the token execution manager. This test intends to ensure both the correct token sequence and the sub-systems integration to one system. Finally, the results are evaluated through a UI visualization.