## Abstract

This paper presents a novel architecture for model predictive control (MPC)-based indoor climate control of multi-zone buildings to provide energy efficiency. Unlike prior works, we do not assume the availability of a high-resolution multi-zone building model, which is challenging to obtain. Instead, the architecture uses a low-resolution model of the building that is divided into a small number of “meta-zones” that can be easily identified using existing data-driven modeling techniques. The proposed architecture is hierarchical. At the higher level, an MPC controller uses the low-resolution model to make decisions for the air handling unit (AHU) and the meta-zones. Since the meta-zones are fictitious, a lower level controller converts the high-level MPC decisions into commands for the individual zones by solving a projection problem that strikes a trade-off between two potentially conflicting goals: the AHU-level decisions made by the MPC are respected while the climate of the individual zones is maintained within the comfort bounds. The performance of the proposed controller is assessed via simulations in a high-fidelity simulation testbed and compared to that of a rule-based controller that is used in practice. Simulations in multiple weather conditions show the effectiveness of the proposed controller in terms of energy savings, climate control, and computational tractability.

## 1 Introduction

The application of model predictive control (MPC) for commercial heating, ventilation, and air conditioning (HVAC) systems for both energy efficiency and demand flexibility has been an active area of research; see the review articles [1,2] and the references therein. Our paper contributes to this literature, specifically to that on model predictive control of air handling units (AHUs) and the zones they serve through variable air volume (VAV) boxes. Figure 1 shows an illustration of such a system, which are common in large commercial buildings.

Several of the MPC formulations proposed in the past are for buildings with one zone [3–6] or a small number of zones [7,8]. A direct extension of such formulations for large multi-zone buildings has two main challenges. First, solving the underlying optimization problem in MPC for a building with a large number of zones is computationally complex because of the large number of decision variables. To reduce the computational complexity, several distributed and hierarchical approaches have been proposed [9–15]. The second challenge, which has attracted far less attention, is that MPC requires a “high-resolution” model of the thermal dynamics of a multi-zone building. High-resolution means that the temperature of every zone in the building is a state in the model and the control commands for every zone are inputs in the model. One way of obtaining such a multi-zone model is by first constructing a “white box” model, such as by using a building energy modeling software, and then simplifying it to make it suitable for MPC, e.g., Ref. [16]. But constructing a white box model is expensive; it requires significant effort [17]. Moreover, the resulting model may not reflect the building as is. Another way of obtaining a high-resolution multi-zone model is by utilizing data-driven techniques, which use input-output measurements. Getting reliable estimates using data-driven modeling is challenging even for a single-zone building, as a building’s thermal dynamics is affected by a non-trivial and unmeasurable disturbance, the heat gain from occupants and their use of equipment, that strongly affects quality of the identified model [18]. In the case of multi-zone model identification, it becomes intractable since the model has too many degrees-of-freedom: as many unknown disturbance signals as there are number of zones. To the best of our knowledge, there are no works on reliable identification of multi-zone building models without making assumptions on the nature of the disturbance affecting individual zones [19].

In addition to the challenges mentioned above, most of the prior works—whether on single-zone or on multi-zone buildings—ignore humidity and latent heat in their MPC formulations. The inclusion of moisture requires a computationally convenient cooling and dehumidifying coil model. MPC formulations that exclude humidity can lead to poor humidity control, or higher energy usage as they are unaware of the latent load on the cooling coil [5].

In this work, we propose a humidity- and latent heat-aware MPC formulation for a multi-zone building with a VAV HVAC system, such as the one in Fig. 1. Cooling and dehumidification of air occur only at the AHU, using chilled water. Heating of air occurs only at the VAV boxes and is provided through either heating hot water or electricity. The problem we consider is making optimal decisions in real-time for actuators in both the AHU and the VAV boxes; details of control commands are described in Sec. 2.

A two-level control architecture is proposed here, consisting of a high-level controller (HLC) and a low-level controller (LLC), to address the challenges mentioned earlier. The high-level controller decides the control commands for air handling unit, while the low-level controller decides the control commands for individual zones. The HLC is an MPC controller that uses a “low-resolution” model of the building with a small number of “meta-zones”, with each meta-zone being a single-zone equivalent of a part of the building consisting of several zones. For instance, in the case study presented here, a 33-zone three-floor building is aggregated to a three meta-zone model, with each meta-zone corresponding to a floor. The advantage of such an approach is that a high-resolution multi-zone model is not needed as a starting point. Rather, a single-zone equivalent model of each meta-zone, in which disturbance in all the zones are aggregated into one signal, can be directly identified from measurements collected from the building. The identification problem of such a single-zone equivalent model is more tractable [20]. In this paper, we use the system identification method from Ref. [20], though other identification methods can also be used. Since the HLC uses a low-resolution model with a much smaller number of meta-zones than that in the building, its computational complexity is low. However, this reduction of computational complexity creates a different challenge. Since the decision variables of the optimization problem in the HLC correspond to the meta-zones (air flowrate, temperature, etc.), they do not correspond to those for the actual zones of the building. The LLC resolves this difficulty by solving a projection problem that appropriately distributes aggregate quantities computed by the HLC to commands for individual zones. The LLC uses feedback from each zone to assess their needs and ensures that indoor climate of each zone is maintained and the aggregate quantities for each meta-zone are consistent with what the HLC computed for that meta-zone.

The proposed controller—that includes the HLC and LLC—is hereafter referred to as *MZHC* which stands for *multi-zone hierarchical controller*. Its performance is assessed through simulations on a “virtual building” plant. The plant is representative of a section of the Innovation Hub building comprising of 33 zones and is located at the University of Florida campus. The plant is constructed using modelica [21]. The performance of the proposed controller is compared with that of *Dual Maximum* controller as a baseline [22]. The dual maximum controller—which is referred to as *BL* (for baseline)—is a rule-based controller, and is one of the more energy efficient controllers among those used in practice [22]. Simulation results show that using the proposed controller provides significant energy savings when compared to *BL* while maintaining indoor climate.

Compared to the literature on MPC design for multi-zone building HVAC systems, our work makes three principal contributions, with details discussed in Sec. 1.1. (i) The first contribution is that the proposed method does not assume availability of a high-resolution model of the multi-zone building which is difficult to obtain. Instead, it can utilize existing data-driven methods that can quickly identify a low-resolution model of the multi-zone building from measurements. (ii) Since the MPC part of the proposed controller uses a low-resolution model with a small number of meta-zones, the method is scalable to buildings with a large number of zones. Although distributed iterative computation has been proposed in the literature as an alternate approach to reducing computational complexity, ours can be solved in a centralized setting. (iii) The third contribution is the incorporation of humidity and latent heat in our multi-zone MPC formulation, which has been largely ignored in the literature on MPC for buildings, and especially so in the literature on multi-zone building MPC. Our simulations show that when using *MZHC*, the indoor humidity constraint is active, especially during hot-humid weather. Without humidity being explicitly considered, the controller is likely to have caused high space humidity in an effort to reduce energy use.

The rest of this paper is organized as follows. Section 1.1 discusses our work in relation to the literature on multi-zone MPC. Section 2 describes a multi-zone building equipped with a VAV HVAC system and the models we use in simulating the plant (the system to be controlled). Section 3 presents the proposed MPC-based hierarchical controller. Section 4 describes a rule-based baseline controller with which the performance of the proposed controller is compared. The simulation setup is described in Sec. 5. Simulation results are presented and discussed in Sec. 6. Finally, the main conclusions are provided in Sec. 7.

### 1.1 Comparison With Literature on Multi-Zone Model Predictive Control.

The works on MPC for multi-zone buildings can be roughly categorized into three bins based on the control commands considered in their formulation: zone-level commands only, AHU-level commands only, and both AHU- and zone-level commands.

The first category of works use MPC to vary only the zone-level control commands such as the zone temperature set points and supply airflow rates but not the AHU-level commands such as conditioned air temperature and outside airflow rate [7,9,10,12–15,23]. Since these works do not consider all the available degrees-of-freedom, their energy savings potential is lower.

The second category is a complement of the first: MPC is used to vary only the AHU-level control inputs but not the zone-level control inputs. The controller presented in Ref. [24] belongs to this category. Focusing only on AHU-level inputs helps them avoid the need to identify a high-resolution multi-zone model. However, excluding zone-level control inputs reduce energy savings potential since the controller cannot use all available degrees-of-freedom.

The third category of papers, which this work belongs to, considers both zone-level and AHU-level control inputs in their formulation [8,11,25]. In Refs. [8,25], centralized approaches are used as multi-zone buildings with only a small number of zones are considered. In Ref. [11], a distributed algorithm is proposed to reduce the computational complexity of multi-zone building MPC, but their algorithm requires a high-resolution multi-zone model.

Besides, none of the papers mentioned earlier take into account humidity and latent heat explicitly in their optimization problem formulation.

## 2 System and Problem Description, and Plant Simulator

Our focus is a multi-zone building equipped with a VAV HVAC system, whose schematic is shown in Fig. 1. In such a system, part of the air exhausted from the zones is recirculated and mixed with outdoor air. This mixed air is sent through the cooling coil where the air is cooled and dehumidified to the conditioned air temperature (*T*_{ca}) and humidity ratio (*W*_{ca}). This conditioned air is then sent through the supply ducts to the VAV boxes, which have a damper to control airflow, and finally supplied to the zones. Some VAV boxes have reheat coils; they can change temperature of supply air but not humidity, i.e., *T*_{sa,i} ≥ *T*_{ca} and *W*_{sa,i} = *W*_{ca}, where *T*_{sa,i} and *W*_{sa,i} are the temperature and humidity ratio of supply air to the *i*th zone. If a VAV box is not equipped with a reheat coil (cooling only), then the temperature of air supplied by it to its zone will be at the conditioned air temperature, i.e., *T*_{sa,i} = *T*_{ca}.

*n*

_{z}zones (i.e., VAV boxes) are as follows:

*m*

_{oa}is the outdoor airflow rate,

*T*

_{ca}is the conditioned air temperature,

*m*

_{sa,i}is the supply airflow rate to the

*i*th zone, and

*T*

_{sa,i}is the supply air temperature to the

*i*th zone. Note that the humidity of conditioned air (

*W*

_{ca}) which is supplied to all the zones is indirectly controlled through

*T*

_{ca}. Of the

*n*

_{z}VAVs/zones in the building, $nzrh$ VAVs are equipped with a reheat coil and $nz\u2212nzrh$ VAVs do not have a reheat coil (cooling only). For the latter, the supply air temperature will be the same as the conditioned air temperature, i.e.,

*T*

_{sa,i}=

*T*

_{ca}.

The control commands in Eq. (1) are sent as set points to the low-level control loops which are typically comprised of proportional integral (PI) controllers. Control of the supply airflow rates *m*_{sa,i}, *i* = 1, …, *n*_{z}, is performed through coordination between VAV boxes and the fan-speed PI controller at the AHU. When the dampers of a VAV box are opened by its local controller, the duct static pressure *p*_{duct} decreases (see Fig. 1), and the fan-speed controller increases the fan’s speed to maintain the duct static pressure at its setpoint, in effect increasing the air flowrate. The PI controllers at the VAV boxes thus track their local supply airflow rate setpoints. The outdoor airflow rate *m*_{oa} is controlled by another PI loop that varies the position of outdoor air and return air dampers to maintain this setpoint. The conditioned air temperature *T*_{ca} is controlled by a PI loop that varies the chilled water valve position to maintain this setpoint. The supply air temperatures $Tsa,i,$$i=1,\u2026,nzrh$ are controlled by local PI loops at the VAV boxes that vary the reheat valve positions (or reheat powers).

The role of a climate control system is to vary the control commands in Eq. (1) so that three important and somewhat conflicting goals are satisfied: (i) ensure thermal comfort, (ii) maintain indoor air quality, and (iii) use minimum amount of energy/cost.

The paper uses a discrete time MPC setting, with *k* denoting discrete time. The time interval between two consecutive discrete time indices *k* and *k* + 1 is denoted by Δ*t* and is called the *model interval*. The control commands are updated less frequently, and the time interval between two discrete time indices in which the control commands are updated is denoted by Δ*T*, an integer multiple of Δ*t*, and is called the *control interval* [26].

### 2.1 Virtual Building (Simulator).

The virtual building (VB) is a high-fidelity model of a building’s thermal dynamics and its HVAC system that will act as the plant for the controllers. The VB is chosen to mimic part of the Innovation Hub building in Gainesville, FL, which is serviced by AHU-2 (among the two AHUs that serve Phase I). Figures 2 and 3 show photos of the building and the relevant floor plans, respectively. The rooms supplied by the same VAV box are grouped together to form one large space (zone); the zones are enclosed by dotted lines in Fig. 3. The first floor has 15 rooms that are grouped into nine zones, the second floor has 20 rooms which are grouped into 12 zones, and the third floor has 21 rooms which are grouped into 12 zones. In total, there are 56 rooms grouped into 33 zones. The virtual building thus consists of an air handling unit and 33 VAV boxes, of which 29 are equipped with reheat coils, and the remaining four do not have reheat coils (cooling only). The zones primarily consist of offices and labs.

We use the modelica library IDEAS (Integrated District Energy Assessment by Simulation) [27] to model the building’s thermal dynamics. The core of IDEAS library is the modelica IBPSA library [28] which is also used by other modelica building libraries such as the Buildings library [29] from LBNL (Lawrence Berkeley National Laboratory). We used the IDEAS library in this work since we found its graphical user interface (GUI) to be intuitive and simple to use to create a model which mimics the configuration of the Innovation Hub building.

Inputs to the building thermal dynamics portion of the VB are supply airflow rate (*m*_{sa,i}), supply air temperature (*T*_{sa,i}), and supply air humidity ratio (*W*_{sa,i}) for all the zones, and the exogenous disturbances, which are (i) solar irradiation (*η*_{sol}), outdoor air temperature (*T*_{oa}), and outdoor air humidity ratio (*W*_{oa}), (ii) internal sensible and latent heat loads due to occupants, which are computed based on the number of occupants provided to the zone block, and (iii) internal heat load due to lighting and equipment. Outputs of the simulator are temperature (*T*_{z,i}) and humidity ratio (*W*_{z,i}) of all the zones. Figure 4 shows floor 1 of the VB created in dymola using components from the IDEAS library [27]. We omit the details of the VB construction using modelica/dymola; the interested reader is referred to Ref. [30].

#### a Cooling and Dehumidifying Coil Model.

The cooling coil model has five inputs and two outputs. The inputs are supply airflow rate (*m*_{sa}), mixed air temperature (*T*_{ma}), humidity ratio (*W*_{ma}), chilled water flowrate (*m*_{w}), and chilled water inlet temperature (*T*_{wi}). The outputs are conditioned air temperature (*T*_{ca}) and humidity ratio (*W*_{ca}). We use a gray box data-driven model developed in our prior work [5]. The interested readers are referred to Sec. 2.1.2 of Ref. [5] for details regarding the model.

#### b Power Consumption Models.

*m*

_{sa}(

*k*) is the total supply airflow rate at the AHU [31].

*h*

_{ma}(

*k*) and

*h*

_{ca}(

*k*) are the specific enthalpies of the mixed and conditioned air, respectively;

*η*

_{cc}is the cooling coil efficiency, and

*COP*

_{c}is the chiller coefficient of performance. Since a part of the return air is mixed with the outside air, the specific enthalpy of the mixed air is as follows:

*h*

_{oa}(

*k*) and

*h*

_{ra}(

*k*) are the specific enthalpies of the outdoor and return air, respectively, and

*r*

_{oa}(

*k*) is the outside air ratio: $roa(k):=moa(k)/msa(k)$. The specific enthalpy of moist air with temperature

*T*and humidity ratio

*W*is given by Ref. [32]: $h(T,W)=CpaT+W(gH2O+CpwT)$, where $gH2O$ is the heat of evaporation of water at 0 °C, and

*C*

_{pa},

*C*

_{pw}are specific heat of air and water at constant pressure.

*i*th VAV box is modeled to be proportional to the heat it adds to the conditioned air stream:

*η*

_{reheat}is the reheating coil efficiency and

*COP*

_{h}is the boiler coefficient of performance.

#### c Overall Plant.

The overall plant, i.e., virtual building—consisting of the building thermal model, cooling and dehumidifying coil model, and power consumption models—is simulated using simulink and matlab^{Ⓒ}. The building thermal model is constructed in dymola 2021 and it is exported into an FMU (Functional Mockup Unit). It is then imported into simulink using the FMI Kit for simulink. The remaining models are constructed directly in simulink.

## 3 Proposed Multi-Zone Hierarchical Control

*MZHC*. The high-level controller is based on MPC and decides the control commands for the AHU: outdoor air flowrate (

*m*

_{oa}) and conditioned air temperature (

*T*

_{ca}). The low-level controller is a projection-based feedback controller and decides the control commands for each of the VAV boxes/zones: supply air flowrate (

*m*

_{sa,i}) and supply air temperature (

*T*

_{sa,i}). These controllers are described in detail next.

### 3.1 Model Predictive Control-Based High-Level Controller.

*n*

_{f}is the total number of floors/meta-zones. The set of all VAVs/zones in floor

*f*is denoted as

**I**(so $|\u222af\u2208FIf|=nz$), of which those equipped with reheat coils is denoted as

_{f}**I**(so $|\u222af\u2208FIrh,f|=nzrh$). The HLC decides on the following control commands based on the aggregate models:

_{rh,f}*f*and

*T*

_{sa,f}(

*k*) is the aggregate supply air temperature. Of the control commands computed in Eq. (6),

*m*

_{oa}(

*k*) and

*T*

_{ca}(

*k*) can be directly sent to the plant. The remaining information computed by the HLC including

*m*

_{sa,f}(

*k*) and

*T*

_{sa,f}(

*k*) are used by the LLC, described in Sec. 3.2, to decide on the supply airflow rate (

*m*

_{sa,i}(

*k*)) and supply air temperature (

*T*

_{sa,i}(

*k*)) for the individual zones/VAV boxes in each floor.

A comment on notation: all variables with a subscript *i* are for the individual zones, while the variables with a subscript *f* represent the aggregate quantities for each meta-zone.

For the MPC formulation, we use a model interval of Δ*t* = 5 min, a control interval of Δ*T* = 15 min, and a prediction/planning interval of *T* = 24 h. So, we have *T* = *N*Δ*T* and Δ*T* = *M*Δ*t*, where *N* = 96 (planning horizon) and *M* = 3. The control inputs for *N* time-steps are obtained by solving an optimization problem of minimizing the energy consumption subject to thermal comfort, indoor air quality, and actuator constraints. Then, the control commands obtained for the first time-step are sent to the plant and the LLC. The optimization problem is solved again for the next *N* time-steps with the initial states of the model obtained from a state estimator, which uses measurements from the plant. This process is repeated at the next control time-step, i.e., after an interval of Δ*T*.

*x*(

*k*) and the vector of control commands and internal variables

*v*(

*k*) as follows:

*T*

_{z,f}(

*k*),

*T*

_{w,f}(

*k*), and

*W*

_{z,f}(

*k*) are the aggregate zone temperature, wall temperature, and humidity ratio of floor/meta-zone

*f*, respectively;

*u*

^{HLC}(

*k*) is the control command vector defined in Eq. (6) and

*m*

_{w}(

*k*) is the chilled water flowrate into the cooling coil. The exogenous input vector is as follows:

*η*

_{sol}(

*k*) is the solar irradiance,

*T*

_{oa}(

*k*) is the outdoor air temperature,

*W*

_{oa}(

*k*) is the outdoor air humidity ratio,

*q*

_{int,f}(

*k*) is the aggregate internal heat load in floor/meta-zone

*f*due to occupants, lights, equipment, etc., and

*ω*

_{int,f}(

*k*) is the aggregate rate of water vapor generation in floor/meta-zone

*f*due to occupants and other sources. We denote the forecast of these exogenous inputs as $w^^$; in Sec. 5, we discuss how these forecasts are obtained. The vector of nonnegative slack variables $\zeta (k):=(\zeta T,flow(k),\zeta T,fhigh(k),\zeta W,flow(k),$$\zeta W,fhigh(k),\u2200f\u2208F)\u2208\u211c4\xd7nf,$ is introduced for feasibility of the optimization problem.

*j*is the following minimization problem subject to a number of constraints that will be described later:

*a*)

*P*

_{fan}(

*k*) is given by Eq. (2),

*P*

_{cc}(

*k*) is given by Eq. (3), $Preheat,f(k):=msa,f(k)Cpa[Tsa,f(k)\u2212Tca(k)]/\eta reheatCOPh,V:=[vT(j),$$vT(j+1),\u2026,vT(j+NM\u22121)]T,X:=[xT(j+1),$$xT(j+2),\u2026,xT(j+NM)]T,$ and $Z:=[\zeta T(j+1),\zeta T(j+2),\u2026\zeta T(j+NM)]T$. The last term,

*P*

_{slack}, penalizes the aggregate zone temperature and humidity slack variables:

*λ*s are penalty parameters. The total supply airflow rate

*m*

_{sa}(

*k*) used in

*P*

_{fan}(

*k*) and

*P*

_{cc}(

*k*) is given by $msa(k)=\u2211f\u2208Fmsa,f(k)=\u2211f\u2208F\u2211i\u2208Ifmsa,i(k)$. The optimal control commands are obtained by solving the minimization problem (10

*a*) subject to constraints (10

*b*) to (10

*r*), which are described next.

*f*are as follows:

*b*)

*c*)

*T*

_{z,f}) and wall temperature (

*T*

_{w,f}, a fictitious state). In constraint (10

*b*),

*q*

_{ac,f}(

*k*) is the heat influx due to the HVAC system and is given by $qac,f(k):=msa,f(k)Cpa(Tsa,f(k)\u2212Tz,f(k))$. The model has seven parameters {

*C*

_{z,f},

*τ*

_{zw,f},

*τ*

_{za,f},

*A*

_{z,f},

*τ*

_{wz,f},

*τ*

_{wa,f},

*A*

_{w,f}}. In the evaluation study, they are estimated using the algorithm presented in Ref. [20] and will be discussed later in Sec. 5.

*f*is as follows:

*d*)

*W*

_{z,f}is the aggregate zone humidity ratio,

*V*

_{f}is the volume of meta-zone

*f*,

*R*

_{g}is the specific gas constant of dry air,

*P*

^{da}is the partial pressure of dry air, and

*W*

_{ca}is the conditioned air humidity ratio [33].

*e*)

*f*)

*T*

_{ca}=

*T*

_{ma}and

*W*

_{ca}=

*W*

_{ma}, when

*m*

_{w}= 0. The interested readers are referred to Ref. [5, Section 3.1.1] for details regarding the model.

*g*)

*h*)

*i*)

*g*) and (10

*h*) are softened using slack variables $\zeta T,flow(k)$, $\zeta T,fhigh(k)$, $\zeta W,flow(k)$, and $\zeta W,fhigh(k)$; constraint (10

*i*) ensures that these slack variables are nonnegative. Imposing constraints directly on the relative humidity of zones (

*RH*

_{z}) is difficult, as relative humidity is a highly nonlinear function of dry bulb temperature and humidity ratio [32, Chapter 1]. So, we linearize this function which gives us

*a*

^{low},

*b*

^{low},

*a*

^{high}, and

*b*

^{high}in Eq. (10

*h*) and help in converting the constraints on relative humidity to humidity ratio (

*W*

_{z}).

*j*)

*k*)

*l*)

*m*)

*n*)

*o*)

*p*)

*q*)

*r*)

*k*)–(10

*l*) and (10

*o*)–(10

*p*) are to take into account the capabilities of the cooling coil and damper actuators, respectively. In constraints (10

*k*) and (10

*m*), the inequalities

*T*

_{ca}(

*k*+ 1) ≤

*T*

_{ma}(

*k*+ 1) and

*W*

_{ca}(

*k*) ≤

*W*

_{ma}(

*k*) ensure that the cooling coil can only cool and dehumidify the mixed air stream; it cannot add heat or moisture. Similarly, in constraint (10

*r*) the inequality

*T*

_{sa,f}(

*k*) ≥

*T*

_{ca}(

*k*) ensures that the reheat coils can only add heat; they cannot cool. Constraint (10

*q*) is to take into account the capabilities of the fan and aggregate capabilities of the VAV boxes. The limits $msa,flow$ and $msa,fhigh$ are computed using the VAV schedule from the mechanical drawings of a building as follows: $msa,flow:=\u2211i\u2208Ifmsa,ilow$ and $msa,fhigh:=\u2211i\u2208Ifmsa,ihigh$.

Overall, constraints (10*b*)–(10*d*), (10*g*)–(10*i*), and (10*q*)–(10*r*) are $\u2200f\u2208F$. Constraints (10*b*)–(10*f*), (10*i*)–(10*j*), (10*m*)–(10*n*), and (10*q*)–(10*r*) are for *k* ∈ {*j*, …, *j* + *NM* − 1}, constraints (10*g*) and (10*h*) are for *k* ∈ {*j* + 1, …, *j* + *NM*}, and constraints (10*k*)–(10*l*) and (10*o*)–(10*p*) are for *k* ∈ {*j* − 1, …, *j* + *NM* − 2}. The control commands remain the same for *M* timesteps, as the control interval Δ*T* = *M*Δ*t*, i.e., $uHLC(k)=uHLC(k+1)$ = … = $uHLC(k+M\u22121)$, $\u2200k\u2208{j,j+M,\u2026,j+NM\u22121}$.

Note that of the states *x*(*k*) defined in Eq. (7), *T*_{w,f} is a fictitious state that cannot be measured, while the other two states aggregate zone temperature (*T*_{z,f}) and aggregate zone humidity ratio (*W*_{z,f}) are measured. So, we estimate the current state $x^(k)$ using a Kalman filter.

*Comment 1*. How best to aggregate zones into meta-zones is an open question. Too many meta-zones negate the benefit from aggregation. Too few will likely cause poor control performance since the difference in thermal properties and internal disturbances among various regions of the building will be lost when such a severe aggregation is performed. Works on model reduction of multi-zone buildings such as Ref. [35] can offer guidelines here. In our case study, we aggregate each floor of a building into a meta-zone as we expect some mass transfer among zones within a floor because of open doors, but not as much among floors.

### 3.2 Projection-Based Low-Level Controller.

The role of the LLC is to appropriately distribute the aggregate quantities—such as the total supply airflow rate and reheat power consumption—computed by the HLC to individual zones/VAVs. The LLC needs to do so by capturing two important properties: (i) it should consider the needs of individual zones and distribute accordingly and (ii) it should act in coherence with the HLC, so that there is minimal mismatch for the MPC optimization in the next round.

*m*

_{sa,i}, $i\u2208If,\u2200f\u2208F$, and for

*T*

_{sa,i}, $i\u2208Irh,f,\u2200f\u2208F$. It decides these control commands by using the following information from the HLC: (i) total allowed supply airflow rate to all the zones $msa(k)=\u2211f\u2208Fmsa,f(k)$, (ii) total allowed reheat power consumption $Preheat(k)=\u2211f\u2208FPreheat,f(k)$, (iii) the temperature at which the zones in each meta-zone should be maintained at

*T*

_{z,f}(

*k*+ 1), and (iv) the conditioned air temperature

*T*

_{ca}(

*k*). Here on in this section, we will be using the superscript HLC ($\u2219HLC$) for these variables to make it clear that these are obtained from the high-level controller.

First, the needs of each zone are assessed based on the current measured temperature *T*_{z,i}(*k*) and the range it should be in $[Tz,ihtg(k),Tz,iclg(k)]$ and are translated into the desired supply airflow rate $msa,id(k)$ and supply air temperature $Tsa,id(k)$. Then, these desired values along with the information obtained from the HLC are used to solve a projection problem to compute the control commands for all the zones, *u*^{LLC}(*k*).

The procedure used to compute the desired values $msa,id(k)$ and $Tsa,id(k)$ is explained below. This is similar to the *Dual Maximum* control logic presented in Sec. 4; a schematic representation of it is shown in Fig. 6.

First the temperature range $[Tz,ihtg(k),Tz,iclg(k)]$ in which each zone should be is computed as follows: $Tz,ihtg(k)=max(Tz,fHLC(k+1)\u2212T~zdb/2,Tz,flow)\u2200i\u2208If$ and $Tz,iclg(k)=min$$(Tz,fHLC(k+1)+T~zdb/2,Tz,fhigh)\u2200i\u2208If$, where $Tz,fHLC(k+1)$ is obtained from the HLC, $T~zdb$ is a deadband, and $Tz,flow$ and $Tz,fhigh$ are the limits used in constraint (10

*g*).If the zone temperature is between the cooling and heating setpoints ($Tz,i(k)\u2208[Tz,ihtg(k),Tz,iclg(k)]$), then the controller is in deadband mode. The supply airflow rate is desired to be at its minimum and no heating is required, i.e., $msa,id(k)=msa,ilow$ and $Tsa,id(k)=TcaHLC(k)$.

If the zone temperature is warmer than the cooling setpoint ($Tz,i(k)>Tz,iclg(k$)), then the controller is in cooling mode. The supply airflow rate is desired to be increased as needed and no heating is required, i.e., $msa,id(k)=min(msa,ilow+Km,iclg(Tz,i(k)\u2212Tz,iclg(k)),msa,ihigh)$ and $Tsa,id(k)=TcaHLC(k)$.

If the zone temperature is cooler than the heating setpoint ($Tz,i(k)<Tz,ihtg(k$)), then the controller is in heating mode. Heating is required, and the supply airflow rate is desired to be increased only if additional heating is needed, i.e., $Tsa,id(k)=min(TcaHLC(k)+KT,ihtg(Tz,ihtg(k)\u2212Tz,i(k)),Tsahigh)$; if $Tsa,id(k)=Tsahigh$, then $msa,id(k)=min(msa,ilow+Km,ihtg(Tz,ihtg(k)$$\u2212Tz,i(k)),msa,ihigh,reheat)$; otherwise, $msa,id(k)=msa,ilow$.

- Finally, we impose the following rate constraints:where$msa,i(k\u2212M)\u2212msa,irate\Delta T\u2264msa,id(k)\u2264msa,i(k\u2212M)+msa,irate\Delta TTsa,i(k\u2212M)\u2212Tsa,irate\Delta T\u2264Tsa,id(k)\u2264Tsa,i(k\u2212M)+Tsa,irate\Delta T$
*m*_{sa,i}(*k*−*M*) and*T*_{sa,i}(*k*−*M*) are the supply airflow rate and supply air temperature from the previous control time-step.

*u*

^{LLC}(

*k*):

*a*)

*b*)

*c*)

*d*)

*e*)

**I**and

_{f}**I**are defined at the beginning of this section,

_{rh,f}*λ*s are weights, $msaHLC(k)=\u2211f\u2208Fmsa,fHLC(k)$, and $PreheatHLC(k)=$$\u2211f\u2208FPreheat,fHLC(k)$.

Constraints (11*b*) and (11*c*) are to ensure that the total supply airflow rate and reheat power consumption do not exceed the limits computed by the HLC. Constraints (11*d*) and (11*e*) are to take in to account the capabilities of the VAV boxes and reheat coils. In constraint (11*e*), the inequality *T*_{sa,i}(*k*) ≥ *T*_{ca}(*k*) ensures that the reheat coils can only add heat to the conditioned air and cannot cool. The upper limit on supply air temperature ($Tsahigh$) in constraint (11*e*) is to prevent thermal stratification [22].

## 4 Baseline Control (*BL*)

For zone climate control, we consider the *Dual Maximum* algorithm [22] as the baseline; a schematic representation of this algorithm is shown in Fig. 6. Even though *Single Maximum* is more commonly used, including in the Innovation Hub building, we choose *Dual Maximum* for the baseline, as it is more energy-efficient among the two [22,36]. The *Dual Maximum* controller operates in three modes based on the zone temperature (*T*_{z,i}): (i) cooling, (ii) heating, and (iii) deadband. The zone’s supply airflow rate (*m*_{sa,i}) and supply air temperature (*T*_{sa,i}) are varied based on the mode as explained below.

**Cooling mode:**If the zone temperature is warmer than the cooling setpoint, then the controller is in cooling mode. The supply airflow rate (*m*_{sa,i}) is varied between the minimum ($msa,ilow$) and maximum ($msa,ihigh$) as needed, and the supply air temperature (*T*_{sa,i}) is equal to the conditioned air temperature (*T*_{ca}), i.e., no reheat.**Heating mode:**If the zone temperature is below the heating setpoint, then the controller is in heating mode. First, the supply air temperature (*T*_{sa,i}) is increased up to the maximum allowed value ($Tsahigh$) as needed to maintain the zone temperature at the heating setpoint. If the zone temperature still cannot be maintained at the heating setpoint, then the supply airflow rate is increased between the minimum ($msa,ilow$) and the heating maximum ($msa,ihigh,reheat$) values.**Deadband mode:**If the zone temperature is between the heating and cooling setpoints, then the controller is in deadband mode. The supply airflow rate is kept at the minimum, and the supply air temperature is equal to the conditioned air temperature, i.e., no reheat.

In the case of VAV boxes that do not have reheat coils, the logic during cooling and deadband modes are the same. In heating mode, the supply airflow rate is at the minimum and the supply air temperature is equal to the conditioned air temperature, as the VAV box cannot heat.

For the AHU-level commands, the *BL* controller uses fixed conditioned air temperature that is determined based on expected thermal (sensible and latent) load, and fixed outdoor airflow rates based on ventilation requirements, e.g., ASHRAE 62.1 [34]. Another consideration in choosing outdoor airflow rate is building positive pressurization requirements [32].

## 5 Simulation Setup

Recall that the plant is based on an air handling unit serving 33 zones, of which 29 are equipped with reheat coils, and the remaining four do not have reheat coils (cooling only). Of the 29 VAV boxes with reheat, three of them serve laboratories which are equipped with fume hoods (209, 303, and 310), and one of them serve restrooms (103). The VAV boxes serving these labs need to be controlled to satisfy the negative pressurization requirements with respect to corridor, so we assume that they operate according to the existing rule based feedback control strategy. Therefore, *n*_{z} = 29 and $nzrh=25$; for *m*_{sa,i}, $i\u2208{I1:={101\u2013102,104\u2013109$}, $I2:={201\u2013208,210\u2013212}$, $I3:={301\u2013302,304\u2013309$, 311–312} and for *T*_{sa,i}, $i\u2208{Irh,1:={I1\u2216{106,107}}$, $Irh,2:={I2$$\u2216{205}}$, $Irh,3:={I3\u2216{307}}}$. The sets **I _{1}**,

**I**, and

_{2}**I**defined above are the VAVs/zones in floors 1, 2, and 3, respectively. The sets

_{3}**I**,

_{rh,1}**I**, and

_{rh,2}**I**exclude the VAV boxes which do not have a reheat coil.

_{rh,3}The outdoor weather data used in simulations is obtained from the National Solar Radiation Database^{2} for Gainesville, FL. As mentioned in Sec. 2.1, the internal heat load due to occupants are computed based on the number of occupants provided to the zone block. We assume that the zones are occupied from Monday to Friday between 8:00 a.m. to noon and 1:00 p.m. to 5:00 p.m., with the total number of occupants (*n*_{p,f}) in floor 1 as 24, in floor 2 as 26, and in floor 3 as 22. We assume a power density of 12.92 W/m^{2} (1.2 W/ft^{2}) for internal heat load due to lighting and equipment. For special purpose rooms like electrical and telecommunication, we use a higher power density of 53.82 W/m^{2} (5 W/ft^{2}). These heat loads from lighting and equipment are assumed to be halved during weekends.

The following zone temperature and humidity limits are used in the simulations: $Tzlow=21.1\u2218C(70\u2218F)$, $Tzhigh=23.3\u2218C(74\u2218F)$, $RHzlow=20%$, and $RHzhigh=65%$. The chosen thermal comfort envelope is shown in Fig. 7. Typically, the zone temperature limits during unoccupied mode (unocc) are relaxed when compared to the occupied mode (occ), i.e., $[Tzlow,occ,$$Tzhigh,occ]\u2286[Tzlow,unocc,Tzhigh,unocc]$. Due to its usage, the Innovation Hub building is always operated in occupied mode, so we assume the same in simulations. For the simulation results reported later, the zone temperature violation is computed as $max(Tz(k)\u2212Tzhigh,Tzlow\u2212Tz(k),0)$ and the zone relative humidity violation is computed as $max(RHz(k)\u2212RHzhigh,RHzlow\u2212RHz(k),0)$, with the upper and lower limits mentioned above.

The fan power coefficient *α*_{fan} in Eq. (2) is 14.2005 W/(kg/s)^{3}, which is obtained using a least squares fit to data collected from the building. The parameters of the cooling and dehumidifying coil model used in the plant are fit using the procedure explained in Sec. 2.1.2 of Ref. [5]. The root-mean-square errors for the validation data set are 0.25 °C (0.46 °F, 2%) for *T*_{ca} and 0.22 × 10^{−4} kg_{w}/kg_{da} (2.6%) for *W*_{ca}.

**MZHC parameters:** The optimization problems in HLC and LLC are solved using CasADi [37] and IPOPT [38], a nonlinear programming (NLP) solver, on a Desktop Windows computer with 16 GB RAM and a 3.60 GHZ × 8 CPU. As mentioned in Sec. 3.1, Δ*t* = 5 min, Δ*T* = 15 min, *T* = 24 h, *N* = 96, and *M* = 3. The number of decision variables for the HLC are 7008 and for the LLC are 54. On an average, it takes only 3.28 s to solve the optimization problem in the HLC and 0.018 s to solve the optimization problem in the LLC.

The parameters for the control-oriented cooling and dehumidifying coil model are fit using the procedure explained in Ref. [5]. For the validation data set, the root-mean-square errors are 0.97 °C (1.75 °F, 7.6%) for *T*_{ca} and 0.63 × 10^{−4} kg_{w}/kg_{da} (7.6%) for *W*_{ca}.

Since the Innovation Hub building has three floors, we aggregate it into three meta-zones, i.e., $f\u2208{1,2,3}=:F$. The parameters of the aggregate thermal dynamics model for each meta-zone are estimated using the algorithm presented in Ref. [20]. The interested reader is referred to Ref. [30] for the values of the parameters and out-of-sample prediction accuracy of the identified model.

For the aggregate humidity dynamics model, floor volumes used are *V*_{1} = 1036.6 m^{3}, *V*_{2} = 1504.1 m^{3}, and *V*_{3} = 1330.8 m^{3}, which are obtained from mechanical drawings of the building.

The following limits are used for the zone temperature constraint (10*g*): $Tz,flow=$21.1 °C (70 °F) and $Tz,fhigh=$23.3 °C (74 °F). The coefficients for the humidity constraint in (10*h*) are *a*^{high} = 0.000621 kg_{w}/kg_{da}/ °C and *b*^{high} = −0.173323 kg_{w}/kg_{da}, which corresponds to a relative humidity of 60%, and *a*^{low} = 0.000203 kg_{w}/kg_{da}/ °C and *b*^{low} = −0.056516 kg_{w}/kg_{da}, which corresponds to a relative humidity of 20%. We introduce a factor of safety by using a slightly tighter higher limit of 60% for the relative humidity of the zones when compared to the thermal comfort envelope presented in Fig. 7.

The minimum allowed value for the outdoor airflow rate ($moamin$) is 3.24 kg/s (5700 cfm), which is obtained from the AHU schedule in the mechanical drawings for the building. The maximum possible value for the outdoor airflow rate ($moamax$) is 8.52 kg/s (15 000 cfm). The various limits on the supply airflow rates are obtained using the VAV schedule for the building. The remaining limits used in the controllers are as follows: $roalow=0%$, $roahigh=100%$, $T~zdb=0.56\u2218C$ (1 °F), $Tcalow=11.67\u2218C$ (53 °F), $Tcahigh=17.2\u2218C$ (63 °F), and $Tsahigh=30\u2218C$ (86 °F). The higher limit on the conditioned air temperature ($Tcahigh$) is to introduce a factor of safety and make the controller robust.

The MPC controller requires predictions of the various exogenous inputs specified in Eq. (9). We compute the loads due to occupants in *q*_{int,f} and *ω*_{int,f} based on the occupancy profile used in simulating the plant. The outdoor weather related exogenous inputs are assumed to be fully known.

**BL parameters:** The cooling and heating setpoints are chosen to be 21.1 °C (70 °F) and 23.3 °C (74 °F), respectively. The minimum, maximum, and heating maximum values for the supply airflow rate of all the VAV boxes are obtained from the VAV schedule for the building. The maximum allowed value for the supply air temperature ($Tsahigh$) is 30 °C (86 °F). The conditioned air temperature (*T*_{ca}) is kept at a constant value of 11.67 °C (53 °F). Typically, *T*_{ca} is kept at 12.8 °C (55 °F), especially in hot-humid climates, to ensure humidity control [39], but we assume there is a 1.11 °C (2 °F) increase in temperature because of the heat from the draw-through supply fan in the AHU, so we keep it at 11.67 °C (53 °F) to compensate for it. The outdoor airflow rate is kept at 3.24 kg/s (5700 cfm), which is obtained from mechanical drawings for the building.

## 6 Results and Discussion

Performance of the controllers is compared using three types of outdoor weather conditions: hot-humid (Jul/06 to Jul/13), mild (Feb/19 to Feb/26), and cold (Jan/30 to Feb/06). The proposed controller reduces energy use significantly compared to *BL*, from approximately 11% to 68% depending on weather, see Fig. 8. The indoor climate control performance of *MZHC* and *BL* is similar. With *MZHC*, the RMSE (root-mean-square error) of zone temperature violation is 0.1 °C (0.18 °F) and the RMSE of zone relative humidity violation is 0.05%, while with *BL* they are 0.01 °C (0.02 °F) and 0%, respectively. The computational cost of the proposed *MZHC* is small, just a few seconds are needed to compute decisions at every control update. On an average it takes 3.28 s to solve the optimization problem in the HLC and 0.018 s to solve the optimization problem in the LLC.

Simulation results for the different weather conditions are discussed in detail next.

### 6.1 Hot-Humid Week.

Figure 9 shows the simulation time traces for a hot-humid week. Both controllers lead to negligible violations of aggregate zone temperature (*T*_{z,f}) and relative humidity (*RH*_{z,f}) constraints. Data for the three meta-zones are shown in Fig. 9(c), and for three individual zones, one from each floor, are shown in Fig. 10. *BL* ensures that dry enough air is supplied to the zones at all times by keeping the conditioned air temperature (*T*_{ca}) at a constant low value of 11.67 °C (53 °F), and hence, the humidity limit is not violated. In the case of *MZHC*, the humidity constraint is found to be active always. This can be seen in Fig. 9(c); recall that we use a tighter constraint of 60% instead of 65% to introduce a factor of safety. This active constraint limits the increase in *T*_{ca}, which can be seen in Fig. 9(d). One of the reasons reheating is required even during such a hot week (the outdoor air temperature is as high as 32.2 °C/90 °F) is because of this active humidity constraint, which requires dry, and thus, cold air to be supplied to the zones. This could also be one of the reasons *MZHC* decides to maintain the zone temperatures at the lower limit (see Fig. 9(c)). Keeping the zones at a higher temperature will require an increase in reheating energy.

Most of the prior works on using MPC for HVAC control ignore humidity and latent heat in their formulation. In an attempt to reduce energy/cost, such controllers are likely to make decisions during these hot-humid conditions which will lead to poor indoor humidity, as they are unaware of the factors mentioned above [5]. Thus, such controllers cannot be used particularly in hot-humid climates.

The energy savings by *MZHC* is because of two main reasons. One, *MZHC* increases the *T*_{ca} as long as the humidity constraints are not violated, while *BL* uses a conservatively designed value as explained above. This leads to a reduction in cooling energy consumption by *MZHC*, see Figs. 8 and 9(b)). Two, the warmer *T*_{ca} supplied to the VAV boxes requires lesser reheating in the case of *MZHC*. This leads to a reduction in the reheat energy consumption, which can be seen in Figs. 8 and 9(b). The decisions regarding the supply airflow rates are found to be the same for both the controllers, and thus, the fan energy consumptions are identical.

### 6.2 Mild and Cold Weeks.

As seen from Fig. 8, energy savings are higher than 60% during mild and cold weeks. This significant reduction in energy consumption can be attributed to three main reasons. Two of them are the same as those explained in Sec. 6.1, but, the effects here are more prominent. For instance, unlike the hot-humid week, the humidity constraint is only intermittently active since the outdoor weather is drier. This provides more room for optimizing the conditioned air temperature, which has two important implications: (i) reduction in the cooling energy consumption and (ii) minimal reheat energy consumption. The third is that, since the outdoor weather is cold and dry, *MZHC* also decides to use “free” cooling when possible by bringing in more than the minimum outdoor air required which leads to further reduction in cooling energy consumption.

We omit the detailed results for the mild and cold weeks here; the interested reader can find them in Ref. [30].

*Comment 2*. Recall that as mentioned in Sec. 4, the Innovation Hub building uses *Single Maximum* algorithm for zone climate control as opposed to the *Dual Maximum* algorithm presented here [22]. In the case of *Single Maximum* algorithm, the minimum allowed value for the supply airflow rate has to be high enough so that the heating load can be met with low enough supply air temperature to prevent thermal stratification [22]. While in the case of *Dual Maximum* algorithm, the airflow rate is varied during the heating mode; thus, the minimum allowed airflow rate is not limited by stratification. Therefore, using *Single Maximum* algorithm leads to higher fan, cooling, and reheating energy consumptions. This also implies that the energy savings by the proposed controller will be even higher.

## 7 Conclusion

The proposed control architecture is designed to address a number of limitations in the existing literature on multi-zone building control using MPC. The main one is the reliance on a high-resolution multi-zone model, which can be challenging to obtain. A low-resolution model of the building is more convenient since such a model can be identified in a tractable manner from measurements. The challenge then is to convert the MPC decisions, which are computed for the fictitious zones in the model, to the commands for the VAV boxes of the actual building. The proposed architecture does that by posing this conversion as a projection problem that uses not only what the MPC computes but also feedback from zones. The result is a principled method of computing VAV box commands that are consistent with the optimal decisions made by the MPC without needing dynamic models of individual zones. At the same time, the use of feedback from the zones ensures that zone climate states are also close to the aggregate climate states computed by the MPC. Additionally, our formulation takes into account humidity and latent heat, something that is often ignored in the literature on MPC for HVAC systems.

The positive simulation results provide confidence on the effectiveness of the proposed controller especially because of the large plant model mismatch. The simulation testbed mimics a real building closely, including the heterogeneous nature of the zones in the building. Another observation from the simulations that should be emphasized is the need to incorporate humidity and latent heat. The indoor humidity constraint is seen to be active when using the proposed controller, especially during hot-humid weather. Without humidity being explicitly considered, the controller is likely to have caused high space humidity in an effort to reduce energy use.

There are many avenues for further exploration, such as experimental verification, modifying the formulation to minimize cost instead of energy and to include demand charges, improving methods to forecast disturbances, etc.

## Footnote

## Acknowledgment

This research reported here has been partially supported by the NSF through award # 1934322 and the State of Florida through a REET (Renewable Energy and Energy Efficient Technologies) grant. We thank David Brooks for help in understanding the design and operation of Innovation Hub’s HVAC system.

## Conflict of Interest

There are no conflicts of interest.

## Data Availability Statement

Data provided by a third party listed in Acknowledgment.

## References

*A Unified Object-Oriented Language for System Modeling and Simulation*