Enhancing Building Monitoring and Control for District Energy Systems: Technology Selection and Installation within the Living Lab Energy Campus

Abstract

With regard to climate change, it is imperative to reduce greenhouse gas emissions. One solution approach is to increase energy efficiency in buildings. Buildings contribute a high share of the total global energy usage. As the rate of new building constructions is low, measures applicable to existing buildings become paramount. Before applying new approaches on a large scale, it is necessary to evaluate them in a representative, realistic environment. Living labs such as the Living Lab Energy Campus (LLEC) at Forschungszentrum Jülich (FZJ) facilitate innovative monitoring and control approaches in a real-world setting. In this work, we investigate the required steps for bringing sensor and control networks, comprising more than 1800 devices, into 18 existing and new buildings. This enables both room-level monitoring and control, as well as the integration of building-wide automation. By introducing an ICT infrastructure, we pave the way towards holistic approaches on a district level. We describe the workflows used for selected instrumentation variants and show first insights from the operation of the resulting infrastructure. We show that the investigated instrumentation variants exhibit similar characteristics; however, they affect control behavior differently. We emphasize that instrumentation should be planned in the context of existing infrastructure. Moreover, we present and evaluate sample measurements obtained from different buildings.

1. Introduction

With regard to climate change and its effects, it is an important task to limit the global temperature rise to $1.5$ $\mathrm{K}$, which requires the increase of energy efficiency and the decrease of the total energy consumption by 2050, according to [1]. Accounting for shares of the global final energy consumption in different sectors shows that the building sector accounts for 30% [2]. Therefore, a significant part of the solution to achieve improved energy efficiency lies in applying intelligent control to building automation.

The challenge to reduce energy usage and increase efficiency in the building sector has gained and continues to gain wide scientific interest. Intelligent control of buildings, especially, has been a major research topic in recent years [3,4]. Within this research area, model predictive control (MPC) for buildings significantly gained importance during the past few years and is well established in current research [3]. Serale et al. [5] estimated possible energy savings of 15% to 20% and a peak load shifting potential of around 30%

Methodologically, only few publications consider real-life applications [5]; most publications focus on method development using simulations [3,4].

Moreover, major parts of studies consider applications with relatively complex systems under control and focus on single buildings or a more abstract view of a district [3,5,6].

To summarize, important and interesting research questions arise with the evaluation of automation within a larger-scale living-lab scenario. This especially holds true for several aspects, such as real-life control reliability, user acceptance, or a long-term evaluation of user interactions. Furthermore, the technical integration into existing infrastructure as well as into information and communication technologies (ICT) infrastructure for scientific purposes is an active field of research [7,8]. This part will become even more important when the different control layers, ranging from the district level through the building level and down to the room level, are included along with their interactions.

In the Living Lab Energy Campus (LLEC), we address the set of questions described above. Within this paper, the main focus is on aspects at the room level and to show options for equipping rooms with sensors and actuators, to gain better knowledge and realize the possibility of controlling energy usage as close to the user as possible. We describe workflow examples for enabling smart buildings in such a real-life laboratory. These are designed in a way to not only integrate new buildings, but to consider especially refurbishment measures to include existing buildings. Based on this, we offer insights on samples from the first set of measurement data.

The remainder of the document is structured as follows. First, we give a rough overview of the literature regarding the monitoring, automation, and equipping of buildings in Section 2. Additionally, we list and compare different communication protocols and summarize the literature on existing living labs. In Section 3, we show the criteria and the methodology for selecting the building set to be incorporated as well as the buildings’ main characteristics. Moreover, we present a requirement analysis on the technical equipment and describe the variants selected and implemented in detail. Based on this, we describe the workflows we follow to equip buildings effectively in Section 4. In Section 5, we discuss our results. Finally, we give a conclusion and an outlook for the next steps in Section 6.

2. Literature

2.1. Monitoring and Controlling Real-Life Buildings

In buildings, multiple energy-related services (such as heating) are required to create a comfortable indoor climate. The apparatus to supply such services is often indicated as a building automation and control system (BACS). A BACS encompasses all technical components, including software, that are necessary to obtain information on and control a building’s indoor climate [9]. The most vital parts of a BACS comprise heating, ventilation, and air conditioning (HVAC) components, as well as lighting and shading applications [10]. Sources such as [11] give an overview of those techniques and a broad set of standards are formulated to provide guidelines for proper design and application, such as [12,13,14,15].

Over the past decades, the understanding of BACS evolved from numerous, individual systems that serve a dedicated purpose (e.g., heating a single room), to integrated BACS systems that manage building-wide energy use, applying high-level controllers [16].

A very promising approach to building-wide control is model-based control, or model predictive control (MPC) [3]. MPC applies models to predict system behavior, receiving continuous feedback in the form of measurements from the real-life building [17,18]. Thus, MPC usually requires detailed knowledge of the current building state and its environment, as well as the ability to influence the building [19,20].

To model BACS components, building envelopes, or other energy system components, different approaches exist [6]. The so-called white-box models are based on the principal physical correlations which characterize the system. These first-principle models are usually derived from in-depth knowledge of the system. On the contrary, black-box models rely fully on empirical relations to depict a system’s behavior, which is why they are also referred to as data-driven models. Data-driven models are derived from measurements obtained from a real-life system, and range from simple curves (e.g., for production efficiency), to modern artificial neural network (ANN) or long short-term memory (LSTM) modeling approaches [21]. Being a mixture of white-box and black-box models, gray-box models employ features of both modeling paradigms. Gray-box models usually incorporate important underlying physics, while the model’s parameters are fitted to real-life data [5]. Further information on modeling and MPC can be found in [3,5,6].

Applying MPC to building HVAC systems such as air handling units (AHU) or variable air volume (VAV) systems is an active field of research. In the most common approach for existing buildings, the current BACS is interfaced with the model-based controller via a dedicated interface [17,18,22,23,24,25,26,27]. For example the authors in [18,23] implement their model-based controller in MATLAB (Registered trademarks and proprietary names are not generally indicated as such in this publication. However, the absence of such indications does not imply that these names belong to the public domain with respect to trademark or copyright law.) [28], interfacing the BACS via its energy management tool, WebCTRL [29]. While Winkler et al. [24] also use the WebCTRL interface for implementing set-points, they retrieve sensor data by sending and receiving BACnet [30] telegrams on the communication bus directly. In [31], the so-called Building Controls Virtual Test Bed (BCVTB) is used to connect a controller and a BACS. In other cases, where no BACS exists or where one cannot be used, building automation components are addressed directly for the implementation of MPC set-points [32,33,34,35,36]. Such studies are usually limited to smaller buildings [32,34], a subset of thermal zones [33,35], or individual rooms [36]. However, the density of sensors and actuators deployed at the room level tends to be higher. This not only serves the purpose of enabling enhanced control, but also increases the availability of on-site measurement data, e.g., for in-depth monitoring and model calibration [37].

Energy saving potentials of sensor and control networks in the U.S. building sector were analyzed in [38]. According to Sofos et al. [38], the annual final energy savings in the year 2030 are estimated at 5% of the total final energy consumption in the U.S. building sector of 2018. Moreover, enabling advanced (model-based) control and human-in-the-loop control, the resulting overall energy savings are expected to be even 2–3-times higher. Hence, equipping buildings with sensor and control networks that go beyond the control of AHUs and VAV units, therefore, promises a significant reduction in the final energy consumption in this area [36,38].

Depending on the building structure and envelope type, either wired or wireless sensors and actuators, or a combination of both, are used [27,39]. As retrofitting measures in existing buildings are costly, in the case of existing buildings, wireless devices are preferred [39]. Compared to wired sensors, wireless devices can be deployed and installed easily. However, wired sensor and control networks, in general, tend to be more reliable and secure [38,40]. Consequently, there is a wide range of sensor and actuator types, technologies, and communication protocols.

Table 1. Communication protocols of common wired and wireless devices used in sensor and control networks, based on [38,40,50].

Protocol	Characteristics
Wired
BACnet	very common, especially in large commercial buildings initiated and maintained by ASHRAE 1 open protocol, standardized according to ISO16484-5 can be used from field to management layer master-slave architecture can implement security features (e.g., encryption)
KNX/EIB	used in both the residential and commercial building sector open protocol, based on ISO/IEC14543 tree network topology implements control applications by interconnecting devices through addresses wired or wireless (radio-based) communication (KNX-TP/KNX-RF)
Modbus	widely used in industrial automation, less frequently in building automation open-source protocol maser-slave architecture available via TCP, RTU, or in ASCII mode (Ethernet-, RS-232-, or RS-422-based)
M-Bus	common bus, dedicated to metering devices used, e.g., for gas, water, heating, and electricity meters standardized according to EN13757-2 and EN 13757-3 recently being extended by Wireless M-Bus
Wireless
EnOcean	frequently used in both residential and non-residential buildings developed by EnOcean alliance, standardized according to ISO/IEC 1453-3-1X uses radio frequency bands below 1 GHz. with a range up to 30 m uses energy harvesting (e.g., solar) and backup batteries supports several topologies. including mesh and point-to-point wide range of sensor/actuator types available
ZigBee	widely used in residential buildings seven-layer protocol (incl. security layer) based on IEEE 802.15.4 uses radio frequency bands between 900 MHz and 2.4 GHz low power consumption <0.05 W, low speed 40 Gbps to 250 Gbps range between 10 m to 100 m mesh, tree, and point-to-point topology based on master-slave architecture
LoRaWAN	used in several test-beds and research contexts uses radio frequency bands below 1 GHz low power consumption, low speed 27 kbps to 50 kbps range between 2 km to 15 km (urban and rural areas, respectively) star-of-stars topology
WiFi	mostly used on higher automation levels and not in the field based on the IEEs 802.11 standards family high transfer speeds of around 1 Gbps, high power consumption of 0.1 W to 0.8 W
GPRS/GSM	used, e.g., for mobile (phone) communication and short message service (SMS) decreased reliability and availability during periods of high external load

¹ American Society of Heating, Refrigeration, and Air-Conditioning Engineers.

gives an overview of the most common protocols used for sensor and control networks in the building sector.

From Table 1, it becomes obvious that multiple different technologies can coexist. This leads to higher implementation hurdles with an increasing number of devices due to increased efforts for device provisioning, bookkeeping, and registration [38]. Similarly, data collection and distribution architectures gain importance [3,10]. Hence, recent publications deal with the implementation of suitable information and control technologies (ICT) in buildings: Sauer et al. [37] investigate a setup based mainly on LoRaWAN [41] and 1-Wire [42] components, comprising 112 temperature and humidity sensors in three different buildings. To gather sensor data, they used Node-RED [43], in combination with a time-series database. In [44], the authors present an approach for connecting an existing BACS based on BACnet with a monitoring service in the cloud using FIWARE [45]. They also depict how cloud-based control with FIWARE is implemented, showcasing a controller applied to a virtual room. To implement model-based control for a laboratory with an area of 27 $\mathrm{m}$${}^2$, the authors in [46,47] equipped the room with several sensors, including air multisensors, occupancy sensors, and meters. Heater control set-points were implemented through actuators attached to distributed fan coil units. Field-level communication was handled by a dedicated gateway and data was stored in a central database. In addition to the application of model-based control, room users were also granted access to a monitoring dashboard showing air quality measures and energy use statistics. Communicating these indicators to users can contribute to reducing energy wastage in buildings by making the users aware of the energy-related effects of their behavior.

Some sources also report the need to develop specific metering devices for in situ tests. For example, refs. [48,49] design and apply measurement devices to deal with refurbishment in ancient buildings and the specific need of condensation monitoring.

2.2. Energy-Related Interaction of Users with Buildings

An extensive survey on the role of users and their activities in the context of energy-intelligent buildings was conducted by Nguyen and Aiello [51]. They found that most BACS lacked consideration of user activity and occupancy in building automation, although these two quantities can be considered as the most important inputs to a BACS. By analyzing relevant literature in that field, they draw the following conclusions for successful and effective BACS operation:

• no static assumptions regarding occupancy shall be made, as user activity is highly dynamic;
• maintaining user comfort remains crucial to assure user acceptance of retrofitted, ICT-based solutions;
• control of heating and lighting shall be based on occupancy and activity;
• energy savings in the range of 40% can be accomplished through activity-based control;
• reduced control performance can be tolerated to some extent in favor of reduced costs and increased ease of sensor/actuator interactions.

Additionally, they stress that energy-use-related information feedback to building users affects occupants’ behavior and, consequently, energy consumption. A recently published paper by Harputlugil and de Wilde [52] reviews published studies on users and their interactions with buildings. The authors conclude that despite the high amount of publications on individual effects (e.g., manual ventilation habits or heating set-point selection patterns), holistic and interdisciplinary considerations of user–building interactions are rarely found. In addition, energy-related consequences of user–building interactions, generally speaking, still remain underestimated, misunderstood, or even disregarded in current approaches. According to [52] more attention should be paid to individual users’ lifestyles and behavioral backgrounds when refining patterns from measured user-related data. In that regard, standardized data gathering and analysis methods were identified to be of particular significance. Finally, the authors underline that user behavior studies are typically limited to individual buildings and short time-spans, which clearly obstructs one from obtaining a holistic and in-depth understanding of energy-related user behaviors in buildings.

From the above findings, the following important research topics are summarized as follows. First, the behavior of building users highly affects energy consumption; consequently, user behavior should be fully accounted for in building energy control strategies. Secondly, user behavior should be observed and analyzed holistically in an extensive real-life use case, preferably over a long time horizon. Lastly, there is unused potential to positively affect energy-related user behaviors by giving users feedback and raising awareness, e.g., through dashboards.

To close the summarized research gaps, the need for a suitable and appropriate research environment arises.

2.3. Living Labs as Gap-Bridging Environments

In the general sense, the term “living lab” (also “living laboratory”) describes the concept of innovation within real-life contexts, with active participation from users, businesses, and governments [53,54,55]. The concept is applied across several domains, notably health and well-being, democracy and government, service and development, and energy [53]. A key feature of living labs that distinguishes them from test beds is that users are “co-producers” of the innovation, beyond being observed subjects [53,54]. Furthermore, living labs operate in a live production environment, unlike test beds, which are run in isolated and controlled environments. Nevertheless, the term “living lab” is sometimes (erroneously) used to describe a test bed.

In Germany, the equivalent term “Reallabore (der Energiewende)”, as defined by the German Federal Ministry for Economic Affairs and Climate Action (Bundesministerium für Wirtschaft und Klimaschutz, or BMWK) takes on an additional implication: the provision of a “legal sandbox”, in which selected laws are relaxed to facilitate ground-breaking research [56]. The “Reallabore” concept serves to accelerate the transfer of technology and innovation by enabling the implementation of sustainable energy technologies under real conditions on an industrial scale. These technologies include concepts that hold a large potential but are still not ready for market roll-out—as judged by the so-called technology readiness level (TRL)—thereby bridging the critical phase between technology development and market roll-out [57].

Living labs make extensive use of ICT for data gathering and analysis, as well as for the deployment and interconnection of the components that comprise the solutions in question. From the stated characteristics of living labs, certain requirements for any deployment begin to emerge, among which are that the disruptions caused by the study have real-world implications and must be compensated for in advance. As will be discussed in detail in Section 3 below, the LLEC builds this fact into its very architecture via various techniques and approaches, such as the ability to switch comfortably between default and scientific operation mode (via the “kill-switch” concept), multi-modal user interactions with technology (e.g., manual vs. automatic room temperature control), and testing phases/limited trials (space-limited controllers, access-controlled dashboards, etc.).

In the literature, there are examples of living labs and similar setups in the field of energy research. In [58], the implementation of an extensive sensor and control network in two real-life buildings at the Construction and Engineering Research Laboratory (CERL, USA) is shown. The authors assess the two existing buildings and their retrofitting potential in detail as well as sensors and technologies for instrumenting the buildings. Special emphasis was placed on retrofitting cost analysis and real-life implementation barriers of wireless devices. While they show the successful implementation of mode-based control of the buildings, user–building interactions and acceptance of the retrofit was not investigated. Additionally, by today’s standards the instrumentation techniques described have been superseded. Winkler et al. [24] investigate a model-based control approach, minimizing the cost of energy based on i.a. human-in-the-loop data obtained through a mobile app. Their setup consists of an existing building, comprising a floor area of 465 $\mathrm{m}$${}^2$, controlling zone air temperature and AHU set-points for eight zones. They interface with facility management and provide a (software) “kill switch” to prevent BACS failure. On the user side, occupancy detection is performed with PIR sensors, and a Markov model is used to predict occupancy. They analyze and evaluate MPC performance using the predicted mean vote (PMV) metric. The project ran for 20 days and for a single building.

The Living Lab smartEnergy project of the FZI Forschungszentrum Informatik [59] researches the coupling of different energy-demand sectors such as electricity, mobility, space heating and cooling, and gas supply using innovative energy management solutions. These solutions are tested in one building with real live-in occupants.

In [60], the Energy Lab 2.0 project at the Karlsruhe Institute of Technology (KIT) is described. In the project, the need for an integrated ICT solution, comprising monitoring, control, simulation, and visualization, is investigated. The authors integrate energy supply and storage units as well as buildings in their ICT platform, which then gives users feedback regarding the operation of individual components. Although the approach is on the district level, the integration of buildings is a rather small part.

The Energy Smart Home Lab (ESHL) was developed at KIT in several projects and demonstrates the possibilities of connecting the areas of living (smart home), transport (electromobility), and energy (smart grid) in an integrated approach such as this. The ESHL consists of a 60-square-metre two-bedroom flat equipped with state-of-the-art technology, such as smart appliances and a multi-model energy system. During longer periods, the houses are inhabited by real users. During these periods, residents had a complete overview of current energy flows and consumption, and innovative control concepts were tested using scheduling.

The presented LLEC addresses the gaps identified in the foregoing discussion, and the methodology employed is described in the two sections that follow. LLEC is part of the funding program “Energiewendebauen” by the Bundesministerium für Wirtschaft und Klimaschutz. A cross-evaluation of all funded (university or technology) campus projects (as a subgroup of district projects), as well as a description of the LLEC-preceding projects “EnEff:Campus RWTH Aachen/FZ Jülich—integrales Planungshilfsmittel” and “EnEff:Campus—Living Roadmap FZ Jülich” is given in [61].

3. Methodology: Requirements Analysis, Selection of Buildings, and Technologies

In the following, we first briefly describe the measures for translating the established need for real-world monitoring and control into a practical solution. Secondly, we give insights into the selection process for the buildings to be included in the studies, and show the characteristics of the selected buildings. Subsequently, we investigate the requirements and possible paths towards the selection and implementation of suitable technologies.

3.1. Goals, Requirements and Implementation Measures

Within the scope of LLEC, we intend to develop, test, and evaluate new automation variants, allowing for reduced energy consumption, an increased use of renewable energy sources, and the integration of energy storage in the building sector.

In the scope of this paper, we specifically focus on hardware-related instrumentation processes that we apply at the campus of FZ Jülich to enable monitoring and control at the room level. Moreover we give a short overview of the possibilities of integrating interaction points with automation elements on the building level for scientific purposes. To draw reliable conclusions and to allow for more elaborate comparisons, several buildings shall be equipped, operated, and monitored.

With regard to controlling and monitoring at the room level, it becomes necessary to fully equip rooms with sensors and actuators to measure their (thermal) state and to influence it, respectively. This especially holds true for older buildings, where currently there are generally no sensors or control networks in place. In the small number of rooms where sensors or actuators exist, room-level automation and control was only applied in a basic sense—local, isolated, and mostly unsophisticated controllers that handled aspects of room automation such as lighting or heating—which did not allow for utilization in an overarching MPC approach.

Likewise, at the building level, automation is present at least to some extent. For example, the metering of energy flows into the building (e.g., electricity or district heating) plays a major role for facility managers operating the buildings on campus, and a control of the heat supply temperature is implemented for every building. Although the present BACS installation in most buildings would, in theory, allow for control concepts superior to simple rule-based control, no (cloud-based) access points for data collection were available prior to the start of this project, so it was not possible to apply advanced cloud control concepts using the available infrastructure.

A holistic approach to building monitoring and control consequently requires at least temporary access to these infrastructures. Therefore, it is necessary to select appropriate devices and technologies depending on the buildings’ individual prerequisites.

In Figure 1, the connection points at the different levels of existing buildings are shown in the context of a sample district energy system. The connection to the ICT infrastructure for scientific purposes is indicated for different elements inside the total district energy system. Connections between the ICT infrastructure and metering at the building level, as well as automation at the building level and at the room level, are highlighted, as they are in focus in this work.

In the cases where scientific operation modes (e.g., an innovative control strategy) are to operate existing infrastructure, a safe “standard” operation mode still needs to be available. Moreover, a sophisticated “kill switch” needs to be implemented as a “safety hatch” for linking to existing automation structures (as seen, e.g., in [24]), including automation hardware and software. Such a kill switch is meant to enable the basic operator of the infrastructure to deny or allow scientific interaction with the buildings’ technical automation equipment. If necessary, automated checks might also be enabled, which can deny write access to existing building automation in cases of malfunction or unexpected behavior.

3.2. Choosing the Set of Buildings for Retrofitting Sensor and Control Networks

For the implementation of such measures, it is necessary to define the buildings to become the objects of investigation. Below, the considerations and the resulting selections for our project are described.

3.2.1. Selection Criteria

To ensure subsequent transferability of the developed approaches, they have to be tested in different buildings to cover the existing building stock and different usages. For the scope of this paper, two different groups of criteria for selecting buildings to be equipped can be distinguished.

The first group of criteria is closely related to the scientific preparation for the design of experiments and the possibilities to compare and interpret the data. For this reason, it is advantageous to select a set of buildings with different physical properties and usages. By comparing data out of such different buildings, possible sensitivities can be calculated. An example of such evaluation based on building archetypes is, e.g., given in [20], where the authors point out which kind of building characteristics are beneficial for applying MPC. When clustering is possible, subsets of similar buildings allow for the evaluation of different kinds of automation measures taken in the same time spans.

The second group of criteria relates to the practicability of equipping the buildings and running experiments. Physical access needs to be granted, and operators, as well as other stakeholders, need to be in line with the agreed-upon measures.

3.2.2. Selection of Buildings

In our project, we focus on buildings at the campus of FZ Jülich. A graphical overview of the buildings at the campus, including the construction years of the buildings, is given in [62]. There are about 150 buildings on the property of FZ Jülich in total, most of which could be considered for the project. For the building stock, a representative and statistically relevant subset of buildings was selected. Those to be equipped in a first phase are shown in

Table 2. Overview of selected buildings and their characteristics (Group 1).

Building Index	01	02	03	04	05	06	07	08	09
General Information
Construction Year	1976	2006	1964	2009	2019	1969	2018	2011	2016
Renovation Year			1979			2003
Number of Floors	2	3	2	1	4	3	1	3	2
Net Floor Area in $\mathrm{m}$${}^2$	999	403	1.002	692	3.304	3.582	1.964	1.735	859
Orientation	NW, SE	SE, NE	SE, NW	NE, SW	NW, SE	SW, NE	NE	NE, SW	SW
Typical Usage
Offices	x	x	x	x	x	x		x	x
Labs		x		x		x			x
Workshop			x
Childcare							x
Occupants/Users
Researchers	x			x		x			x
Management			x		x			x
Operative Staff			x
Visitors		x
Children							x
Heating
Radiators	x	x	x	x		x	x	x	x
Floor Heating		x			x		x
Ventilation
Manual	x	x	x	x	x	x		x	x
Automated				x		x
Large Consumers			x	x	x	x	x		x
Connection to LDTH 1									x

¹ Low-temperature district heating network.

. As the table shows, the selected buildings cover a large time span in the year of construction, and have different typical types of use and different characteristics in terms of the building envelope, heating, and ventilation systems. Another group of buildings listed and described in

Table 3. Further buildings to be equipped (Group 2).

Building Index	10	11	12	13	14	15	16	17	18
General Information
Construction Year	2021	1967	2004	1970	2024	2009	2010	2024	1961
Renovation Year									2006
Number of Floors	3	3	2	3	1	1	2	4	1
Net Floor Area in $\mathrm{m}$${}^2$	2.003	6.937	4.231	4.895	240	401	1.204	7.168	4.118
Orientation	NE, SW	NE	SW	SE, NW	SW	SE, NW	SE	SE, NW	SW
Typical Usage
Offices	x	x	x	x	x		x	x
Labs						x		x
Lecture		x					x	x
HPC 1		x	x	x	x
Canteen									x
Occupants/Users
Researchers	x	x	x	x	x	x	x	x	x
Management	x	x	x					x	x
Operative Staff		x	x						x
Heating
Radiators	x	x	x	x	x	x	x		x
Floor Heating									x
Underfloor Convector								x
Concrete Core Activation								x
Ventilation
Manual	x	x	x	x			x	x
Automated		x	x	x			x	x	x
Large Consumers	x	x	x	x	x	x			x
Connection to LDTH 2		x	x	x	x	x		x	x

¹ High-performance computing; ² low-temperature district heating network.

will be further equipped in the future. In total, about 18 existing buildings are earmarked to be included in the project. Many of these buildings are connected to the low-temperature district heating (LTDH) network installed on the campus.

In the following discussion, we highlight two buildings due to their role, prerequisites, and special suitability for the installation of sensor and control networks. The first is the existing building with index two in Table 2, which is the Jülich School Laboratory (JSL). The second is the proposed climate-neutral administrative building (CAB, index 17 in Table 3), for which planning is already well advanced. The JSL was chosen to become a special showcase for the installation of innovative BACS because the building is visited by both students and employees, as on-campus science courses and internal meetings are conducted there. The application of advanced sensor and control networks in newly erected edifices, as well as innovative ventilation concepts shall be studied in offices and shared areas within the planned CAB.

Erected in the year 2006, the JSL comes with modern insulation and a preexisting wiring infrastructure, enabling the easy retrofitting of wired devices (via cable trays). Additionally, lighting and blinds-control wiring is implemented centrally, allowing for the easy integration of actuation into advanced BACS setups. With regard to heating, two different systems are used at the JSL. On the ground floor, radiators are used together with floor heating in larger rooms. Offices and all remaining rooms on other stories are solely equipped with radiators. Cooling or air conditioning is not provided in the building. The only option to regulate indoor air quality is by manual ventilation.

The building, on the one hand, serves as a location for scientific courses and meetings, and on the other hand, provides offices for teaching and administrative staff. Hence, the resulting usage and occupants’ activities are mixed throughout the building and vary in time, although usage patterns tend to repeat as courses are offered on a regular basis.

To conclude, the building holds great potential in terms of load-shifting through the thermal activation of building mass and blinds control. Additionally, differing user behavior is expected depending on the buildings’ occupants, which offers the ability to thoroughly investigate energy-related user–building interactions (including heating, shading, and ventilation patterns).

Some BACS functionality was already present in the building. Heat supply from the campus’ district heating network was controlled based on heating curves that depend on the current outdoor temperature. For the floor heating, a wireless setup was used initially, comprising a human–machine interface (HMI) device, a controller, and valve actuators. However, the system did not work properly when the building was assessed in 2019, and neither did the building-integrated weather station, nor the (safety-related) blinds automation. The retrofit measures taken in this building regarding the room automation are described in more detail below, in Section 3.3.3.

Apart from existing buildings, new buildings are also equipped with a comprehensive read and write access to actuators and sensors to implement and evaluate innovative, model-based, and predictive control strategies. For new buildings, additional requirements for the realization of the innovative control strategies are already taken into account in the planning phase. This serves the purposes of aligning with all stakeholders involved in the construction and building automation process and creating a wide range of access possibilities, including the required hardware.

One major new-build project is the climate-neutral administrative building (for general information, see Table 3, index 17). The main objective is to achieve climate neutrality in operation by integrating renewable energies and waste heat in the building’s design and the application of optimal operations. The building is a planned mixed-usage office building, currently in construction, which will provide work spaces to approximately 300 employees with reoccurring occupancy patterns. It will be connected to the LTDH network of the campus. Accordingly, all heating systems are adjusted to low supply temperatures, such as a radiative heating concept, in the form of thermally activated building systems (TABS). Likewise, cooling at a high-temperature level is investigated. TABS can be considered as passive storage with a high inertia covering the base load of the building. Room-integrated underfloor convectors cover the peak load and consider individual thermal comfort preferences of the users, which can be specified via a state-of-the-art HMI. The building is coupled to a thermal buffer storage and a heat pump in case the temperatures of the LTDH network are not sufficient. To further decrease the ${\mathrm{CO}}_2$ footprint of the building, it is equipped with both roof-installed and facade-integrated photovoltaics.

Moreover, an innovative energy- and cost-efficient ventilation concept is implemented in the building. A scheme of the ventilation concept is given in Figure 2, comprising a quadrant of a floor. The innovative ventilation concept consists of ventilation of the central, shared areas of each floor. Fresh air is supplied to the offices located along the central area if the corresponding doors are opened. To induce the required air exchange between the central area and the offices, the fresh air is supplied with a temperature below the temperature levels in the offices.

The ventilation concept is characterized by reduced construction costs and efforts, as no decentralized ventilation or distribution system needs to be established. Moreover, the ventilation system can reduce the window ventilation heating losses while, at the same time, integrating a high-efficiency heat recovery within the AHU. The ventilation concept has been validated in CFD simulation studies, demonstrating a sufficient exchange rate of room air in case of open doors.

3.3. Deriving Technologies and Instrumentation Variants

In the following, the selection of instrumentation variants is described. This includes requirements, possible variants, and the final decision for the scope of our project.

3.3.1. Requirements

In the context of the general requirements discussed in the previous section, the following are aspects that were considered in the selection of devices.

Usability for Science

The measurement of several physical quantities is required for the scientific/research goals of the project. The overall goal is to improve the energy efficiency of the buildings, while maintaining or even increasing current comfort levels. To improve heating efficiency, the ability to sense the temperature of the thermal zones, as well as to automatically regulate the heating system, is required. Temperature sensors and radiator status sensors and actuators are, therefore, necessary. However, energy savings and user comfort often constitute conflicting goals. In line with standard considerations in BAS for non-residential buildings, it is important in this research project that the productivity of occupants is not negatively affected by energy-saving measures, as research shows that poor indoor air quality (IAQ) leads to decreased productivity [63,64]. Consequently, it is necessary that IAQ parameters are monitored in the various controlled spaces, so that energy-saving measures and metrics can be counterbalanced by acceptable IAQ conditions.

On the electrical energy side, luminosity sensors and electronic light switches are necessary for the efficient control of ambient lighting. Furthermore, according to research, plug and process loads take up to 47% of the energy consumption of commercial buildings in the USA [65], and up to 28% in the UK [66]. As a result, controllable power meters are beneficial to address this scenario.

Furthermore, user engagement is one of the key topics at LLEC, with a sub-topic being the evaluation of the energy performance of building occupants. It is also desirable to have motion sensors and occupancy detection devices to support this goal.

In addition to the quantities of interest themselves, the characteristics of the measurements are also important. For the purposes outlined above, the numerical resolution, time resolution, correctness, and the time constant of the devices need to be considered. Numerical resolution refers to the smallest change in the physical quantity that can be reported by the sensor. Time resolution refers the frequency of measurements that can be obtained from the sensor. The correctness of a measurement indicates the maximum deviation between the reported measurement and the real value. The time constant is especially important for tasks which close a control loop. From our experience, when searching for device models, we can report that, in many cases, time constants are only given for the pure sensor elements, but not for the total sensor device as delivered.

Acceptance by Users and Infrastructure Managers

In order to ensure user acceptance, the prevailing culture and social predispositions of the users need to be considered. For example, in Germany, privacy is taken more seriously than in many other societies, and supporting structures such as the Works Council and Data Protection Officers that serve to protect employees from infringements are more vibrant than in most other European countries [67,68,69,70]. Consequently, the installation of “intrusive” devices such as occupancy-detection devices is limited, with the goal of instrumenting with a set of devices that enables the achievement of scientific goals. For calibration and validation purposes, it is possible that a narrow area is earmarked for more detailed instrumentation. The handling of privacy-related topics within the scope of our project is briefly described in Section 3.4. Additionally, it is important to consider the requirements and expertise of the infrastructure manager. All necessary considerations were coordinated with the aforementioned stakeholders.

Device and Installation Costs

An overarching consideration for selecting devices and technologies is cost, which can be expressed in three categories. The first consideration is the investment costs, covering the cost of the procurement of equipment. Second is the installation costs, which include direct costs (e.g., the cost of rewiring a building to accommodate wired sensors, or the cost of breaking and joining pipes to install flow meters) and indirect costs, such as the temporary loss of work spaces due to installation work, or the suspension of building heating in order to rework heating piping. Finally, the operational costs are taken into account, which include the cost of maintenance and the associated consumables (e.g., replacement of parts, servicing of components, leasing of ICT infrastructure, etc.).

3.3.2. Possible Solutions and Alternatives

The consideration of solution possibilities can be framed around two aspects: the communication architecture and the actual technologies and protocols. Naturally, the choice of the first aspect limits the available options in the second, and vice versa.

For the first part, it is necessary to define a proper communication backbone architecture at the automation layer, which defines where and how many IoT gateways are used. Possible solutions range from totally decentralized to totally centralized variants. The most decentralized variant is the use of "IoT-ready" devices only, so that every device is able to communicate to some cloud infrastructure directly. An intermediate approach consists of clustering the communication to the cloud infrastructure by connecting several field devices to one IoT gateway. Such an approach lies on the continuum between the two extremes, depending on the the amount of devices connected to the used IoT gateways, which then communicate with the cloud infrastructure. At the totally centralized extreme, only one central IoT gateway is used to bridge all the field devices to the cloud infrastructure. To the best of the authors’ knowledge, the only available technology for such an approach in practice is LoRaWAN [41].

For the other aspect, it is important that the choice of technologies and protocols accommodates as many of the above-stated requirements as possible, if not all. For an overview, we again refer to Table 1.

3.3.3. Selected Variants

For equipping buildings on the room level, we chose the approach of using one IoT gateway per building and connecting the different devices to it as a general communication architecture. On the centralized–decentralized continuum, this is an intermediate approach, tending towards the centralized end.

As shown in

Table 4. Overview of selected physical EnOcean-based devices, including manufacturer, model, and purpose.

Device Type 1	Manufacturer	Model Name	Purpose
IoT Gateway	Beckhoff	CX5130 2	low-level automation and control collect data from (multiple) bus(es) access point to cloud
EnOcean Transceiver	Beckhoff	KL6583	receive EnOcean telegrams send EnOcean telegrams
Air Multisensor	Pressac	60.CO2 SLR TMP HUM.868	measure air temperature measure air CO2 measure air relative humidity
Window Handle	Thermokon	SRG02	measure window state (open/closed/tilted)
Contact Sensor	Eltako	FTKB	measure window/door state (open/closed)
Valve Actuator	Micropelt	MVA005	control radiator valve position implement local backup controller

¹ device type based on Figure 3; ² including necessary I/O and bus terminals.

, we use an industrial PC (IPC) by Beckhoff as a central IoT gateway or automation device per building. A huge advantage of such an IPC per building is its extendability: by adding hardware clamps to the same central CPU unit and adapting the freely configurable code on the IPC, it is possible to include several protocols and devices in a similar manner. Moreover, the need for several IP addresses for connecting different gateway devices to the cloud can be reduced significantly to one per building.

For different circumstances in the selected buildings, we use different solutions regarding the protocols used, which we describe separately in the following paragraphs.

Solution with EnOcean

We decided to implement a basic variant which uses EnOcean [71] devices in combination with the central IPC per building. The IoT gateway for the building connects to several EnOcean transceivers by cable, and those communicate wirelessly with the field devices (EnOcean sensors/actuators). In this way, it is possible to flexibly place field devices without the need for cabling, which then reduces the installation effort. To the best of the authors’ knowledge at the time of the selection, EnOcean was the only wireless technology which had devices to actuate a heater valve without the need for external power supply or frequent battery replacement. Recently, a wireless KNX [72] (KNX-RF) device for actuating heater valves has become available. Figure 3 shows an excerpt of a conceptual floor plan, indicating EnOcean field devices as well as the positioning of the central IoT gateway (the IPC). The devices used can measure temperature, relative humidity, CO₂ concentration, and the status of windows and doors. Measurements of temperature, relative humidity, and CO₂ concentration are used as indicators for IAQ and user comfort. To gain knowledge about the status of windows, different sensor devices can be used. Whenever possible, the window handle is replaced by a “smart” window handle. A second option is the installation of an additional sensor between the window handle and frame. In case the window frame does not not allow for any of the before-mentioned options, the windows are equipped with two window contacts. All three variants allow for the differentiation of the three possible states: tilted, opened, and closed.

The valve actuator can control a heater’s valve and reports several aspects of its status. A list of typically used device models is given in Table 4. Note, however, that the table does not contain every device model tested or used for comparison.

The “kill-switch” aspect for the automation of pure EnOcean actuators is built into the IPC program as well as the chosen devices: with regard to the first aspect, we wrote the program code in a way which easily allows one to switch between different control modes for sending commands to EnOcean actuators. Moreover, the valve actuators allow for an independent control when no command is set for a specific amount of telegram cycles.

Solution with EnOcean and KNX

In addition to the fully EnOcean-based solution, there will be parallel KNX installations in some of the buildings investigated. In close coordination with the infrastructure manager, it was decided to make use of KNX for the control of blinds and lights, for the sake of the continuous availability of a HMI in all control modes.

At the same time, existing switches will be replaced by a HMI for all interactions with the room. In this case, the EnOcean valve actuator will be integrated into the KNX backbone via EnOcean/KNX gateways, so as to allow users to control the heating via the HMI in the basic operation mode also.

Figure 4 shows a conceptual equipment variant for such a solution.

Table 5. Overview of KNX devices installed in addition to the EnOcean devices.

Device Type 1	Manufacturer	Model Name	Purpose
Presence Sensor	MDT	SCN-P360K4.03	detect occupancy (PIR)
Presence Sensor	Steinel	True Presence	detect occupancy (high-frequency technology)
Presence Sensor	Steinel	True Presence	detect occupancy and measure illumination, air quality
		Multisensor
Person Counter 2	Steinel	HPD2	count the number of persons in a room
HMI	MDT	BE-GT2TW.01	enable input of user set-points display current room state (e.g., air quality, blinds position) give feedback to users (e.g., suggest to open a window)
Blinds Actuator	MDT	JAL-B1UP.02	control blinds slope and position (local)
Blinds Actuator	MDT	JAL-0210.02	control blinds slope and position (central)
EnOcean/KNX Gateway	Weinzierl	KNX ENO 634	convert bi-directionally between EnOcean and KNX
EnOcean/KNX Gateway	ABB	EG/A32.2.1	convert bi-directionally between EnOcean and KNX

¹ device type based on Figure 4; ² also detects presence.

shows some of the KNX devices also used within the LLEC project. By also connecting the IPC to the KNX bus, the KNX devices can also be used to widen the data available for scientific purposes as well as to give additional actuators to be possibly included. To make actuators based on KNX available for scientific purposes at any point, a “kill-switch” element is to be introduced inside the KNX program. This switch element then allows one to decide whether a control command sent by the IPC or by a standard element in the KNX program becomes active. In addition to broadening the number of available sensors and actuators, another advantage of KNX installation is the availability of more elaborated HMIs directly on the field level.

An example where such a technique is already installed successfully is the JSL. Whenever possible, wired KNX sensors and actuators were installed, primarily based on guidelines and regulations set by the infrastructure manager. This includes the following devices:

• presence sensors in offices, labs and meeting rooms;
• person counters in labs and meeting rooms;
• air multisensors in offices, labs and meeting rooms;
• electric meters in offices, labs and meeting rooms;
• human–machine interfaces (HMI) in every room;
• lighting actuators;
• external blinds actuators, if present;
• floor heating valve actuators on the ground floor.

Additionally, wireless sensors were used where necessary. Due to the market availability of a variety of devices that are based on the EnOcean protocol [71], devices using the EnOcean technology were used. The set of EnOcean sensors and actuators installed in the JSL comprises the following items:

• contact sensors for door and window state measurement;
• radiator valve actuators in offices, labs, meeting rooms, and other common areas;
• a limited set of air multisensors in offices, labs, and meeting rooms to compare KNX/EnOcean sensor characteristics.

In the JSL, all wireless EnOcean devices were integrated in the KNX system via dedicated, bidirectional EnOcean/KNX gateways. The gateway installation positions were chosen based on radio range tests, minimizing the overall number of gateways used.

The wired KNX backbone is connected to one IoT gateway, which can send and receive telegrams on the bus. While a conventional building automation layer is established via the KNX program, the gateway also allows for advanced building control, e.g., via cloud-based algorithms. To assure safe and comfortable building operation, even in cloud-based operation mode, a “kill switch” is implemented in the IoT gateway. In case of undesirable behavior, the “kill switch” will disable cloud-access to the underlying BACS and activate local, KNX-inherent controllers for, e.g., heating the building.

Integration of BACnet

To include automation elements which are connected via BACnet protocol, a connection is also planned and is currently in a first testing phase. BACnet is used especially for automation elements that are relevant for the building instead of the room level, e.g., the control of a heater system feed temperature.

To maintain safe operation, again, the “kill-switch” principle will be used. Therefore, additional switching elements are going to be introduced in the BACnet automation and a limited access for scientific purposes will be available via an OPC UA [73] server.

Another key aspect within LLEC, which is enabled by the use of the BACnet protocol, is the demonstration of the LTDH network, which integrates waste heat from high-performance computing (HPC) resources into the heat supply of surrounding buildings [74,75]. The buildings that will be connected to the LTDH are shown in Figure 5. A section of the existing district heating network is repurposed and extended with new pipes where needed to accommodate the increased mass flows, in order to form the future LTDH network. At the different building connections, orifice plate measuring sections are planned for an accurate measurement of the flows. Since the waste heat’s temperature is too low to supply the heat demand of the existing buildings without retrofitting them directly, heat pumps are installed. Via the heat pumps, a connection is established between heat and electricity, which, e.g., allows for the use of the thermal capacity of buildings as a storage, which, in turn, allows for the operation of the heat pump in such a way that the electricity grid is supported. To have a detailed insight on the effects and to have the potential to act on multiple levels, the buildings connected will be equipped with sensors and actuators at the room level, along with additional meters as well as full access to the heat pump with the associated heat storages. This setup makes it possible, for example, to examine the flexibility potential of different buildings for the electricity grid in detail.

Integration of M-Bus Metering

For metering several consumption data points, access to measurements is two-fold in the solution we derived and plan to derive for use in FZ Jülich. On the one hand, metering data, including heating, cooling, electricity consumption, and tap water use, are acquired by the on-campus infrastructure management. These data are accessed for research purposes through a TCP/IP-based interface between the existing campus infrastructure and our ICT infrastructure. The implementation of a first version of this coupling is described in [76]. Technical details for the interface are not within the scope of this paper, but will be presented in a separate paper in preparation.

On the other hand, first steps towards the integration of additional M-Bus [77] meters for research purposes have been taken. These meters can be integrated with the previously described IoT gateways in the selected buildings.

Combination of Protocols Used in the Climate-Neutral Administrative Building (CAB)

In the CAB, which is currently under construction, it is planned to integrate all listed protocols of BACnet, KNX, EnOcean, and M-Bus. BACnet will be used for the operation of the actuators of TABS, heating and cooling ceilings, VAV systems, AHU, heat pumps, and buffer storage. KNX is used for the room-individual actuators of the underfloor convector, shading blinds, and illumination (also coupled to DALI [78]). Sensing in KNX is realized for room temperature, occupancy, and illuminance. Users can specify their room-specific comfort preferences for shading, illumination, and room temperature control via state-of-the-art HMIs. EnOcean is employed for further room sensor equipment through window and door sensors (for evaluation of the ventilation concept) and multisensors (temperature, ${\mathrm{CO}}_2$, humidity). For metering heating, cooling, and electrical energy flows, M-Bus meters are included.

In the CAB, distributed and hierarchical MPC concepts will be implemented; these are currently developed and evaluated based on simulative test beds [79]. Controller and simulation models are created based on the open-source Modelica simulation library AixLib [80].

The base for the application of innovative control concepts can be implemented as an additional control layer added to the standard building automation control. In order to be capable of applying both innovative and standard control strategies, “kill-switch” elements are introduced. These are accessible logic elements implemented in the building automation to switch between different control modes. It is favorable to implement the “kill switch” at a higher spatial resolution to be able to evaluate control strategies on a smaller scale that is exposed to a small number of disturbances and interactions, simplifying fault detection and system analysis. For example, for a multi-floor building, the “kill switches” can be configured to be spatially resolved according to individual floors, or further separated into thermal zones. A higher spatial resolution of the “kill switch” simplifies the comparison of an innovative control strategy to a reference control, which can be applied at the same time to another area of the building that is exposed to the same weather disturbances and operation conditions. Apart from this, the “kill switch” could be also resolved according to groups of actuators (e.g., heating, ventilation, shading) to focus on a subgroup of components, which facilitates a comparative analysis. For central components such as an AHU or a heat pump, it is recommendable to implement individual “kill switches”.

For the evaluation of innovative control strategies, it is further interesting to enable control at different control levels. A ventilation system, for example, can be controlled by specifying a set-point for the ${\mathrm{CO}}_2$ concentration (reference variable) of the ventilated area, or by prescribing a volume flow rate (manipulated variable). In the former case, the control of the volume flow rates is shifted to a low-level (sub-optimal) controller, which is configured to track the specified ${\mathrm{CO}}_2$ concentration set-point, whereas in the latter case, the volume flow itself is controlled by the innovative controller. This allows for the analysis of high- and low-level control strategies and may result in a higher potential for energy savings.

When implementing innovative control concepts, user acceptance plays a major role. Preferences communicated by the user (e.g., in the form of touch panels or web applications) are directed to the control cloud. They are either integrated in the control concept, are realized independently of the control mode (e.g., for shading control), or lead to a switch-back into the standard mode.

3.4. Tackling Non-Technical Implications of the Instrumentation Measures

Of all measures within LLEC, the extension of monitoring and control capabilities has most likely the largest impact on general staff members during both installation and operation. In addition to the new features offered by the developed systems, the following, mostly non-technical implications are, therefore, important to consider, and have been taken care of:

• During the installation of sensors and actuators on the room level, the use of the room might be impaired. The extent and duration varies between hardly any implications for a few minutes (wireless components) and noticeable implications for a few hours with (a short) interruption of the power supply (wired components) Within the LLEC project, we try to reduce the impact to a minimum by selecting a hardware setup which limits the effects of the retrofitting of sensors and actuators in existing buildings. Moreover, the execution of proper preparations, including, e.g., pre-assembly, further reduces the disturbance of the user;
• Furthermore, users might have concerns regarding data privacy, especially with respect to sensors on the room level, which allow one to deduce insights into a user’s behavior. Already in the early phase of development, an elaborated data protection concept has been developed and coordinated with the IT Committee of the Works Council and the Data Protection Officer to develop a system and a set of measures which comply with the European General Data Protection Regulation (GDPR). The developed concept is based on the following main aspects. Firstly, measurement data is stored in secured databases, with certain precautions. Scientific staff with access to the system and databases have completed data protection training. Secondly, room users are only granted access to their own rooms’ data and only if all users assigned to the room digitally sign a user consent form. An elaborated digital workflow has been developed and implemented, incorporating the allocation of users to rooms stored in a dedicated database of the building department. If a user moves out of a room, access to the data of that room is automatically revoked for this user. In line with this, access is blocked for all users, in case a new user moves in, until every necessary consent is given. Irrespective of the users’ consent, the measurement data can be used at any time for scientific purposes in an anonymised and/or aggregated form. This is important, since the sensors serve many scientific studies, and for many of the research activities, it is very important to capture the data in all rooms, e.g., due to the thermal coupling between adjacent rooms;
• Although the measures taken offer additional functionalities, users have to become used to the operating concept after installation. To facilitate this process within LLEC, we provide easy access to supporting information, e.g., manuals which are also kept updated during the whole process of development.

To involve the users early, the planned measures have, moreover, been presented and discussed in multiple workshops since the beginning. In addition, users are continuously informed about inspections for planning purposes, installation measures, and new developments by e-mail.

4. Description of the Proposed Workflows

Dealing with the numerous devices during their procurement, installation, and operation requires a clearly defined workflow. Below, the developed workflows for devices in EnOcean and KNX, which differ slightly, are presented. Still, the general (and also somewhat intuitive) approach of:

• collecting all necessary information;
• deciding which measures to take;
• preparing the actual installation steps;
• doing the installation work;
• testing the installation;
• and finally, operating the solution,

is followed in both cases. The diagrams in Figure 6 and Figure 7 are intended to show the first parts for an operation with the local IoT gateway. Further steps for, e.g., high-level automation, or similar steps, are not included here (but are planned to be described in a separate publication in preparation). Both figures show the general steps before a decision for the technology (in those cases EnOcean or KNX) is made.

4.1. Workflow for EnOcean Components on the Room Level

The workflow to install EnOcean devices is shown in Figure 6. As a large part of the installation can be completed without the need for access to electrical installations, the majority of the required steps are taken by the research institute. Steps requiring close connection to the existing infrastructure must be carried out by a qualified electrician. In this project, such services must be put out to tender.

The first step in the procedure is to collect all the necessary information about the building and the rooms. After determining the building to be equipped, it is important to obtain an overview of the rooms to be equipped based on existing floor plans. The next step is to visit and assess the rooms on site to capture any details that are not included in the accessible plans, such as the position and number of the heating elements in the room, the nature of windows and doors, etc. With this information available, the selection of technologies and the planning of execution steps can be performed. Finally, it is confirmed with the responsible infrastructure manager whether the envisaged measures can be carried out.

Afterwards, the installation of backbone components (including power lines, IPC, signal cables, and transceivers), the assigning of specific devices (meaning not only the type but the exact IDs) to their planned installation positions, as well as the preparation of the IPC program can be executed in parallel. Within the task of assigning devices, the steps “Select Devices”, “Prepare Devices”, and “Register Devices” inside Figure 6 are implied. To store the decisions taken in these steps, we use a management web application with an underlying database, which was developed internally and is called WALDO (WALDO stands for Web AppLication for Device Organization). Processes such as ordering and storing hardware or the assembly of the IPC components are assumed to be executed up front and, thus, are not discussed further at this point.

With a basic IPC program available and the backbone components being installed, a test of the backbone is executed. Moreover, the IPC program can be configured. This puts the logic into place, which allows the IPC to communicate with the devices prepared before.

After these two steps are successfully carried out, all devices can then be installed. For actuators that require a teach-in process, this can now be carried out with the program specially parameterized for the building while the IPC is running. If no such teach-in procedure is required, the device installation can, of course, be carried out independently of the IPC program or the backbone installation.

Before the final operation, a short test of the total system is performed.

4.2. Workflow for KNX Components on the Room Level

Similar to the diagram for a workflow with EnOcean devices, a diagram for a KNX installation is shown in Figure 7. Nevertheless, some responsibilities and details are different.

As stated, the first steps to come to a decided execution plan are the same as in Figure 6.

Additionally, the backbone components that are related to the pure infrastructure to connect to an IPC usable for research purposes remain the same. The same applies to the step of creating the basic IPC program without application-specific configuration.

Based on the decision of what kind of devices to install, and where to install them, a trained electrician needs to install the KNX devices and connect them properly to the bus. To achieve the required functionality of the KNX installation, the KNX ETS program also needs to be written and installed on the devices. Analogous to other steps, it is good practice to also test the stand-alone KNX system.

From the KNX program, data points in terms of the so-called “Group Addresses” are retrieved by parsing a file provided by the installation company. Facilitating versioning capabilities of GitLab [81], data points are stored and subsequently made available through both a RESTful API and a graphical user interface. Thereby, information on the data points can be used to configure the IPC program. Lastly, the IPC program is tested and, finally, ready to be operated.

5. Results and Discussion

Within LLEC, we have started to equip buildings on the campus of FZJ as described above.

5.1. Current Status and Setup Process

For the first group of buildings we considered, this is apparent from the corresponding number of devices and measurement points that can be seen in

Table 6. Overview of preexisting, updated, and newly installed sensor and control networks for the buildings in Group 1.

Building Index	01	02	03	04	05	06	07	08	09	10
Existing KNX BACS			x		x		x			x
Installation of Sensor and Control Network
EnOcean	x	x	x	x	x	x		x	x	x
KNX		x					x
Installation/Update of KNX BACS
Blinds Control		x	x 1	x 1	x 1	x 1	x 1	x 1	x 1
Light Switches		x	x 1	x 1	x 1	x 1	x 1	x 1	x 1
Dimmable Lights		x			x 1
Equipped Rooms
# offices	35	4	11	5	89	29	TBD	71	6	51
# meeting rooms	0	1	0	1	3	0	0	3	0	0
# labs	0	3	0	0	0	0	0	0	0	0
# kitchens	2	1	1	0	0	1	TBD	4	0	3
EnOcean Devices
# multisensors	37	4	12	7	89	35	TBD	70	6	54
# door state sensors	30	23	14	7	92	39	TBD	71	16	59
# window state sensors	0	38	52	28	0	234	TBD	0	10	164
# window handles	55	0	4	0	246	0	TBD	180	0	0
∑ sensors	122	65	82	42	427	308	TBD	321	32	277
# heater actuators	48	20	15 1	7 1	0	39 1	TBD	71 1	5 1	86 1
# light switches	40	0	0	0	0	0	TBD	0	0	0
# switchable plugs	0	0	32 1	15 1	125 1	86 1	TBD	98 1	0	0
∑ actuators	88	20	47 1	22 1	125 1	125 1	TBD	169 1	5 1	86 1
KNX Devices
# multisensors		9
# presence sensors		12
# person counters		3
# HMI		9
# electric power meters		15
∑ sensors		48
# heater actuators		2
# blinds actuators		10
# light dimmers		12
# light switches		12
∑ actuators		36

¹ Installation planned.

. In all listed buildings, except the one indexed as number seven, EnOcean devices are used. Building number two (JSL) is equipped with KNX additionally.

For buildings with indexes from number three to number nine, further KNX installations are currently in preparation.

From the process of initial planning to the current status, we came across several aspects that could also help other researchers who want to deal with living labs in general or living labs in the context of buildings in particular.

First, certain aspects relate more to technical issues. Specifically, when choosing a topology, a balance must be found between the various requirements and the preexisting status. For example, some buildings already have some technologies independent from the project. Furthermore, it is necessary to decide the level of involvement of the scientific staff in the field level of automation. In our case, the decision was made to involve the scientific staff in the field level, since this offers the advantage of granting them a deeper understanding of the system and increased control possibilities. At the same time, this implies the need to care about this low-level of automation. Additionally, it became clear that some components, which seem to be well-suited for the intended task with reference to the datasheet, did not perform as specified. This especially held true for devices we evaluated, in which cases the manufacturers did not comply with the standard specifications of the protocols.

Secondly, organizational aspects are very important. One element here is the use of elaborate workflows, which we found to be very helpful after their development. Related to this, we encountered unexpected delivery times and delays in the process, which were even more pronounced when ordering large amounts of devices. As pointed out in Section 3.1, a living lab project includes several parties and dependencies. This makes it imperative to agree on a common understanding and to develop a plan of measures which are in line with the requirements of all participating parties. It is useful to also allot time for discussions and resolutions to find solutions.

5.2. Measurements and Interpretation

In addition to the results regarding the overall equipment and the process, the data measured so far also already provide interesting insights, some of which are described below.

For comparison purposes, different EnOcean-based sensors where installed in the same room. Figure 8 displays values from five temperature sensors over the span of four days. The sensor models used are given in

Table 7. Sensor models for the comparison of temperature measurements.

Sensor Index in Figure 8	Manufacturer	Model Name
A	Eltako	FTFSB
B	Nodon	temperature and humidity sensor
C	Thermokon	SR06
D	Pressac	60.CO2 SLR TMP HUM.868
E	Nodon	temperature sensor

.

First of all, it is noticeable that the shape of the curves is quite similar among all sensors. Nevertheless, differences regarding the numerical resolution, time resolution, and reaction time can be observed. When using EnOcean, a longer time resolution is generally to be expected, as the protocol is designed for low power consumption. This becomes particularly visible in combination with larger resolutions (e.g., with sensor A having a resolution of $0.32$ $\mathrm{K}$).

Based on these different sensor measurements, we also investigated the effects of the different measurement options on the temperature control in a first small control experiment. We used different control modes and different sensors serving as the input for a temperature controller that set the valve-opening values in the room. A part of the results is displayed in Figure 9. The time spans were selected to give similar conditions, such as ambient temperature or temperatures at the beginning of the plots. Due to the fact that the experiments were run in a real-world setting, there are still some differences since identical conditions cannot be guaranteed. Nevertheless, the data can be used to reveal interesting insights.

The results shown in subplot (Figure 9a) were obtained during the operation where only a temperature set-point was sent to the actuator. The selected Micropelt MVA005 uses a locally measured and processed room temperature and an internal controller. Compared to the other plots, relatively large oscillations become visible. One possible explanation for this is the local proximity of the temperature sensor to the radiator, which makes it difficult to estimate the room air temperature, especially in dynamic heating phases. Even though the control performance is lowered compared to the other subplots, this ability is an important backup functionality, as described in Section 3. Subplots (b) and (c) show data within times where a controller in the cloud calculated valve-position set-points, which were sent to the valve actuator. In both times, a proportional controller with $K_P=150$ was used. The difference between the subplots is the temperature measurement used by the controller. In the case of subplot (b), the measurement by the Pressac sensor was used, and in the case of (c), the measurement by the Nodon sensor was used. As expected from the interpretation of the pure sensor characteristics (compare Figure 8), the faster reaction time of the signal by the Nodon sensor is also advantageous for control. Despite this, control is still possible when using the temperature measurement by the Pressac sensor. Nonetheless, the Pressac sensor is installed usually in our project because of its ability to measure further relevant data.

Another comparison of temperature data is given in Figure 10, with respect to the orientation of the rooms in which the measurements were taken. The temperature measurement by sensor three was taken in a room whose windows are oriented towards the south-west. The measurement by sensor four was taken in a room on the opposite side which, moreover, is close to a small forest. The weather data shown in this figure is based on Deutscher Wetterdienst (DWD) [82,83]. During the two days where the peaks of temperature were significantly lower, one can see relevant cloudiness and reduced global radiation. Despite being measured in a living lab with unmeasured influences, the huge effect of solar radiation can be seen. In addition to this, another possible influence is the position of blinds, which was not recorded at that room within the interval.

As mentioned earlier, we have designed our measurements to give us several different data points that we can use for different scientific applications and to derive different quantities of interest. Including also different buildings with different construction types and construction dates allows us to compare CO₂ concentrations under different circumstances. An exemplary comparison between measurements taken in an older building (sensor one, blue line) and a newer building (sensor two, red line) is given in Figure 11.

First of all, measurement noise is visible in both curves. Additionally, we conclude two main effects from the curves here. While in the older building, the concentration falls to a ground level of approximately 700 ppm, this value is only reached twice in the entire time span visualized for a short amount of time in the measurement data taken in the newer building. The level also drops very slowly throughout the day of the eleventh of February. We conclude that the air infiltration rates differ significantly between the buildings. Secondly, changes in CO₂ concentration indicate differing manual ventilation patterns. This suggests potentially significant differences in occupants’ behavior.

Finally, our retrofitted sensor and control network allows for in-depth analysis of energy-related user behavior patterns. In Figure 12, the electric power consumption of one office located at the JSL is shown together with the output signal of a ceiling-mounted presence sensor.

From a simple analysis of the data, several observations can be made (from left to right in Figure 12). First, there are intervals of ICT communication interruptions, which are indicated by gaps in the measurement data. Secondly, inter-day and weekend periods can be observed by analyzing the occurrence of absence and electric power drawn from the sockets. In that regard, it becomes obvious that a certain stand-by consumption remains present also during, e.g., weekends. This may be a result of loads such as screens, printers, or other devices that, out of convenience, are usually not un-plugged, even during longer periods of absence. During periods of occupancy, differing patterns are observed. In weekday pattern A, an electric load in the range of 60 W to 75 W occurs for roughly two days, while in pattern B, the load reduces to approximately 10 W to 50 W. The deviation of 50 W to 65 W fits well to the consumption of a conventional notebook, which suggests some randomness in the usage patterns of the notebook. Lastly, singular power-draw events appear. Such events could, e.g., be caused by the charging of devices or the switching on of electrical appliances for a short time period.

Based on the obtained measurements, first conclusions regarding user behavior can be drawn and typical patterns be derived. Analyzing concurrency of energy use and occupancy consequently enables improved forecasting of, e.g., electric power consumption. The obtained data not only facilitates a qualitative understanding of behavioral patterns, but also allows for the training of data-driven models. In the context of model-based control, these models can be integrated directly into an energy system model, or be used to provide forecasts as external inputs to the controller. The application of data-driven forecasting is the subject of ongoing research at the JSL test-site, where multi-input/multi-output approaches based on ANN and LSTM models for predicting electric power consumption (building-wide and on the room level) are compared and evaluated. Such enhanced forecasts can boost MPC approaches significantly, unlocking further energy-saving potential in building automation and control.

6. Conclusions and Outlook

Starting from the necessity of further development in building monitoring and automation, we pointed out the open research field of evaluations in living labs on larger, industrial scales, reaching from the district to the room level. With a main focus of enabling a research infrastructure at the room level, this paper outlines the requirements for equipping buildings in an existing building stock, as well as new buildings, with sensors and actuators. Different solutions are discussed and workflows are provided to describe the necessary steps of the installation process. Within the project described, we use EnOcean, KNX, BACnet, and M-Bus for sensing and automation. Regarding automation on the room level, more than 1800 devices are already in place. Moreover, first data analyses of resulting measurements and control experiments are discussed. The obtained measurements indicate that we can detect and decipher user behaviour patterns, device usage characteristics, building properties, and dependency of control performance on device features, among others.

From the presented work, we derive the following main recommendations to serve as a guide for similar research projects:

• It is essential to clarify not only the technical requirements of involved stakeholders as early as possible, but also to deal with diverging viewpoints, so as to establish a common understanding for all the participants of the project;
• The individual characteristics and prerequisites of buildings to be included in retrofitting projects should be identified actively prior to selecting devices and technologies. Where possible, buildings should be selected such that a rich variety of characteristics are represented, making it easier to derive statistics that are more general and more meaningful;
• The choice of devices to be used should be carried out conscientiously, taking into account the scientific purpose as well as the preexisting circumstances (for example, the general building infrastructure or usage of the buildings in consideration). Especially when there is no prior experience with the devices in terms of their characteristics and behaviour, a test with a small number of such unknown devices is helpful to determine their usefulness. Additionally, if several alternative device models exist, having a small test setup with redundant device models allows for comparison, which enables a more informed choice of device models;
• Based on the set of selected buildings, a suitable/tailored ICT infrastructure and corresponding technologies should be chosen and implemented;
• The proposed workflows in Section 4 can be used as a blueprint with potential adaptations to the site-specific requirements and environment, and should be followed systematically.

On the basis of the set-up infrastructure and first results retrieved, further work is planned and ongoing. With regard to the project of LLEC at the FZ Jülich campus, the installation process will be continued and the number of equipped buildings will be extended. Buildings of different ages, usages, and HVAC equipment to be considered for this are listed in Table 3. An important aspect constitutes the energy supply via the low-temperature district heating network (LTDH), which is also implemented under scientific guidance and evaluation. In this way, a holistic district energy system with respect to the monitoring and control of the energy supply and consumption at the room and district levels will be investigated. In addition to such an extension of the scope of installation, the infrastructure that we set up will be used for experiments and evaluations of different methods from the fields of IoT infrastructure, monitoring, control, and user interaction. A core focus of our ongoing research deals with employing the measured data to extract versatile building models in order to determine, e.g., the thermal dynamics, as well as other energy-relevant measures. These models are, in turn, applied to a variety of research scenarios. Additionally, we investigate forecasting techniques both for control purposes and for estimating energy-saving potentials during building operation.