Competition description

Towards Foundation-Style Learning for Generalizable HVAC Control

One policy, operating the HVAC systems of commercial buildings across a range of layouts and weather, jointly minimizing energy cost and carbon while keeping occupants comfortable.

Overview

Learn one policy, not one controller

Participants develop a single control policy that operates the HVAC systems of commercial buildings across a range of layouts and weather conditions. The policy decides when to run each air handler and the hot-water pump, and sets their temperature and pressure setpoints, to jointly minimize energy cost and carbon emissions while maintaining occupant comfort.

The objective is deliberately not to tune a controller for one building. It is to learn one policy that generalizes across arbitrary floor plans, HVAC topologies, and weather. The same policy is deployed, unchanged, on buildings it has never encountered, differing in number of floors, geometry, room layout, zoning, equipment count, and climate. The policy must infer an effective strategy from the building description and live sensor stream it is given at runtime.

This portability across the entire distribution of buildings, rather than competence on a single instance, is the defining requirement of a building foundation model and the central scientific challenge of the competition.

At each control step, a five-minute interval over a one-day episode, the policy observes the building state and must simultaneously issue:

  • Discrete actions: an on/off command for each Air Handler Unit (AHU) and for the central Hot Water System (HWS), determining which equipment is actively conditioning the building.
  • Continuous setpoints: for each AHU, the supply-air temperature and duct static pressure; for the HWS, the boiler supply-water temperature and pump differential pressure.

Because the number of AHUs and zones differs from building to building, both the observation and action vectors change shape per building, and there is no fixed input or output mapping the policy can memorize. This hybrid, variable-dimensional action space, combined with the requirement to generalize to unseen buildings, makes the problem substantially harder than standard fixed-dimension RL benchmarks.

Building components

A coupled dynamical system

Changing one AHU's setpoint affects multiple zones; occupancy in one zone shifts the thermal load across the building.

AHU

Air Handler Units

Central systems that heat and cool air and distribute it via ducts. A building may have 3 to 8 AHUs serving different zones.

VAV

VAV Boxes

Terminal units in each zone that modulate airflow and mix conditioned air with recirculated room air, balancing comfort without running an AHU at full capacity.

HWS

Hot Water System

A central boiler and pump supplying heated water to AHU coils and zone terminals. The policy sets boiler setpoint and pump pressure to regulate heating capacity.

Zone

Zones

Individual rooms with independent temperature sensors and occupancy schedules. A building may contain 5 to 50 zones depending on size and layout.

A commercial office building with its principal HVAC devices: chiller, air handler, boilers, and meters.
Figure 1. The principal HVAC devices in a commercial building. Chillers and air handlers condition and distribute air, the boiler and hot-water system provide heating, and meters record the energy and carbon that the reward penalizes. The competition policy actuates this equipment through discrete on/off commands and continuous setpoints.

Buildings differ not only in equipment counts but in how equipment maps to physical space. Each AHU serves a distinct group of rooms, and this mapping is unique to every building.

Floor plan of building_0000 across three floors, colored by the AHU serving each room.
Figure 2. AHU-to-zone mapping for development building_0000: three floors, 37 rooms, 5 AHUs (serving 9, 9, 3, 7, and 9 rooms). Both the number of AHUs and the rooms each serves vary from building to building.
Three example generated buildings varying in footprint, floor count, and AHU grouping.
Figure 3. Example buildings of varying shape and HVAC system. Left: building_0005, four floors, six AHUs. Right, top to bottom: building_0008 (two floors, four AHUs) and building_0000 (three floors, five AHUs). Footprint, floor count, zone count, and AHU grouping all vary across generated buildings.

Observation & action spaces

Building-specific by design

Both spaces are determined by the floor plan, chiefly the number of zones and AHUs, and are not fixed across the competition.

State (observation)

Each observation's length scales with the building (it grows with zones and air handlers). It encodes:

  • Per zone: air temperature, current heating and cooling setpoints, supply-air damper position, airflow setpoint.
  • Per AHU: supply-air temperature, static pressure, and airflow (sensed and setpoint), a cooling-request count, and supply/exhaust fan run status.
  • Hot-water system: supply-water temperature (sensed and setpoint).
  • Occupancy & schedule: building-level occupancy count, plus comfort-mode flags for now and imminently.
  • Weather: outside-air temperature.
  • Time: time of day and day of week (cyclically encoded).

Optionally, the policy may also consume the static floor plan and the AHU-to-zone mapping, supplied through the building metadata at runtime.

Action space

The action is a hybrid, variable-dimensional dictionary. For a building with K AHUs:

  • the discrete component has shape (K+1), one on/off bit per AHU plus the Hot Water System;
  • the continuous component has shape (2K+2), two setpoints per AHU plus two for the HWS, each normalized to \([-1, 1]\).

These vary widely because the generator samples a broad configuration space: 2 to 4 floors; a 400 to 700 ft × 300 to 500 ft footprint; composite layouts; 30 to 60 ft rooms; 3 to 8 AHUs; and 1 to 2 occupants per zone. With 5 to 50 resulting zones, the discrete space spans 4 to 9 bits and the continuous space 8 to 18 values.

Development building_0000 (Figure 2), with 5 AHUs and 37 rooms, has a 6-bit discrete action space and a 12-value continuous action space.

Reward function

A regret-based, three-way tradeoff

At each step the policy receives a reward combining three competing, normalized quantities.

$$ r_t = \alpha_{\text{comfort}}\,\delta_t \;-\; \alpha_{\text{energy}}\,c_t \;-\; \alpha_{\text{carbon}}\,e_t $$
δₜ: normalized productivity regret (comfort), in [−1, 0]. cₜ, eₜ: energy cost and carbon, each in [0, 1].

The comfort term \(\delta_t\) equals 0 when occupied zones are perfectly comfortable and approaches −1 as comfort degrades, so higher is better. Energy cost \(c_t\) and carbon \(e_t\) enter as costs. The organizer-fixed weights are identical for every submission and sum to one, making the reward a weighted average:

0.6 comfort
0.2 energy
0.2 carbon

This makes comfort dominant while still charging materially for energy and carbon, and it creates the central tradeoff. Conditioning aggressively keeps comfort near its best value but drives energy and carbon high; switching equipment off eliminates energy and carbon but pushes comfort toward −1 whenever zones are occupied. Because comfort is scored only in occupied zones, the reward favors forward-looking, occupancy-aware control: precondition spaces before people arrive, then relax toward an energy-saving band once they leave.

A policy rollout showing zone temperatures, per-step and cumulative reward, and occupancy over day and night cycles.
Figure 4. A rollout of one policy over successive day and night cycles. Top: per-zone temperatures against the daytime comfort band (green) and the relaxed night-time eco band (blue), with outside-air temperature. Middle: per-step reward and its cumulative total. Bottom: occupancy. Comfort is scored only against the currently active band, so deviations are penalized during occupied hours but may drift within the wider eco band at night. Reward dips coincide with the largest comfort violations and periods of high consumption.