The end-use disaggregation function separates bulk energy consumption into its major constituent end-uses and calculates its energy use intensities.

Inputs

Energy Meter

The end-use disaggregation function requires energy meter data. These data record a building's measured energy consumption at regular intervals. For this function, energy consumption must already be segregated into heating, cooling, and electricity consumption and must be represented in kilowatts only (kW). Electricity use should include energy use for only lighting, plug-in loads, distribution equipment (fans and pumps), and chillers. Cooling energy use should include energy use for only the AHUs' cooling coils. Heating energy use should include energy use for only the AHUs' heating coils, perimeter heating devices, and domestic hot water. The data must be formatted as seen in Figure 1.

A generic square placeholder image with rounded corners in a figure.
Figure 1: Example of energy meter input data format. Note the measured energy consumption must be represented in kilowatts (kW).

This function requires hourly energy meter data. The first column should contain the timestamp at which energy consumption is measured. The timestamp must include the numerical date and time and in the following format: [yyyy-mm-dd hh-mm]. The second column should contain the measured power consumption for heating use only. The third column should contain the measured power consumption for cooling use only. The fourth column should contain the measured power consumption for electricity use only.

Only one (1) CSV file containing energy meter data for the whole building must be supplied to this function.

NOTE: This function may not be suitable for buildings with other significant electricity end-uses such as elevators and data centers, unless such end-uses are separated from the energy meter data prior to using the function.

AHU-level HVAC Control Network Trends

The end-use disaggregation function also requires AHU-level HVAC control network trend data. These data are a record the various actuator and sensor measurements pertaining to the air handling units (AHUs) and can typically be extracted from a building automation system (BAS). For this analysis, ten unique trend data are required for each AHU; they are as listed with units and range in Table 1 and formatted as in Figure 2.

Required trend data Abbreviation Unit Range
Supply air temperature tSa oC -
Return air temperature tRa oC -
Outdoor air temperature tOa oC -
Supply air pressure pSa Pa -
Outdoor air damper position sOa % 0(closed) - 100(open)
Heating coil valve position sHc % 0(closed) - 100(open)
Cooling coil valve position sCc % 0(closed) - 100(open)
Supply fan state sFan % 0(closed) - 100(open)
Supply air temperature setpoint tSaSp oC -
Supply air pressure setpoint pSaSp Pa -
Table 1: Required AHU-level HVAC control network trend data for each AHU.

A generic square placeholder image with rounded corners in a figure.
Figure 2: Example of AHU-level HVAC control network trend data input format.

This function requires hourly trend data. The first column must contain the timestamp at which the measurement was recorded. The timestamp must include the numerical date and time and in the following format: [yyyy-mm-dd hh-mm]. The timestamp must be consistent with the timestamp in the energy meter data. Each subsequent column must contain the trend log data as listed in Table 1 in descending order (i.e., second column contains supply air supply temperature, third column contains return air temperature, etc.)

A minimum of one (1) CSV file containing AHU-level HVAC control network trend data must be supplied to this function, where each CSV file represents a unique AHU. If multiple files are inputted, a separate energy load intensity value will be calculated for the heating and cooling coil for every AHU. Visuals plotting weekly energy use intensity will also differentiate between different AHUs. See outputs for more information about the generated KPIs and visuals. Note that the timestamps must be consistent between multiple files and with the timestamps in the energy meter data.

Zone-level HVAC Control Network Trends

The end-use disaggregation function also requires zone-level HVAC control network trend data. Like AHU-level HVAC control network trend data, these data are a record of various actuator and sensor measurements, but pertain to variable air volume (VAV) terminals units which regulate airflow and sometimes re-condition supply air from the AHUs to specific thermal zone(s). For this analysis, four unique trend data are required for each thermal zone/VAV terminal unit; they are as listed in Table 2 and formatted as seen in Figure 3.

Required trend data Abbreviation Unit Range
Indoor air temperature tIn oC -
Supply airflow qFlo m3/s -
Supply airflow setpoint qFloSp m3/s -
State of perimeter heating device(s) sRad % 0(inactive) - 100(fully active)
Table 2: Required zone-level HVAC control network trend data for each VAV/thermal zone.

A generic square placeholder image with rounded corners in a figure.
Figure 3: Example of zone-level HVAC control network trend data input format.

This function requires hourly trend data. Like AHU-level HVAC control network trend data, the first column must contain the timestamp, which must include the numerical date and time and in the following format: [yyyy-mm-dd hh-mm]. The timestamp must be consistent with the timestamp in the energy meter data. Each subsequent column should contain the trend log data as listed in Table 2 in descending order (i.e., second column contains indoor air temperature, third column contains supply airflow, etc.)

A minimum of one (1) CSV file containing zone-level HVAC network trend log data must be supplied to this function, where each CSV file represents a unique VAV terminal or thermal zone. Note that the timestamps must be consistent between multiple files and with the timestamps in the energy meter and AHU-level HVAC network trend data.

Wi-Fi Device Count

The end-use disaggregation function also requires Wi-Fi device count data. These data count the number of actively recognized, but not necessarily connected, devices by a building's Wi-Fi access points. The function uses device count data as a proxy for occupant count by equating 1.2 devices per occupant. These data must be formatted in a spreadsheet seen in Figure 4 below.

A generic square placeholder image with rounded corners in a figure.
Figure 4: Example of Wi-Fi device count input data format.

This function does not requires hourly trend data (i.e., measurements taken at 15-minute interval are OK). The first column must contain the timestamp at which the device count is measured. The timestamp must include the numerical date and time and in the following format: [yyyy-mm-dd hh-mm]. The second column must contain the number of devices recognized by a Wi-Fi access point. This column must contain only whole numbers (i.e., 2.4 is not an acceptable entry).

A minimum of one (1) CSV file containing Wi-Fi device count data must be supplied to this function. However, if there is greater certainty amounting in floor-level device count data (i.e., you have device count data for each floor of the building), you may input several CSV files whereby each file contains the data pertaining to a different floor. If the function recognizes that more than one CSV file is provided, occupant-count will be taken as the sum of all supplied files. Note that timestamps must be consistent between multiple files.

Actively in development, an open-source project by the Data-driven Building Operation and Maintenance team within Carleton University's Building Performance Research Center.