How it Works

The OpenEEmeter calculates energy savings by comparing a building's energy consumption, before and after an energy efficiency upgrade or retrofit.
Baseline and reporting periods are defined by the endpoints of the project period.

The central question in measuring energy efficiency: how did energy consumption change from the baseline period to the reporting period?

Baseline period minus reporting period consumption.

The simplest approach to finding energy savings is to subtract the reporting period consumption from the baseline period consumption to get savings.

The modifications and modeling considerations necessary to make this simple approach viable are detailed in the next sections.

How the Software Works

The core open source software package primarily takes a single serialized input and returns a single serialized output. The input and output formats are all that is needed to run a meter. Both the input and output are structured as JSON, a machine- and human-readable format that is supported by almost every programming language. This helps facilitate taking OpenEEmeter inputs and outputs and using them as part of larger systems. The software is implemented in python and available on github.

Code
Software inputs and outputs.

Temperature Response

Accurately determining baseline and reporting period consumption requires accounting for an important exogenous factor: external temperature.

While other exogenous factors affect energy consumption, we focus on temperature because it has the largest and most consistent impact and because temperature data is widely available.

Once we have included temperature data, building energy usage can usefully be broken down into two temperature-related components (a heating and a cooling component) and one weather-independent component (base load).

Temperature-related building energy usage

This makes sense intuitively given the large impact of temperature on building energy use. During cold weather conditions, a building needs to be heated to achieve a comfortable temperature; similarly, hot conditions require cooling. Other elements, such as refrigeration and lighting, remain more consistent over the course of the year and can be represented in the base load.

This pattern often leads to energy consumption profiles with a strong relationship to the weather

The characteristics of the heating, cooling, and base load components vary by building and fuel type. For instance, generally only electricity (and not natural gas) is used in cooling loads.

Determining the extent of these heating, cooling, and base loads and their relationships to external weather is the essential task of the OpenEEMeter.

Building energy consumption broken into base, cooling, and heating loads.

Energy Modeling

Let's look at this data in the traditional way, with energy consumption plotted against external temperature. The basic intuition behind this model is readily visible: the more extreme the temperature, the more energy it takes to heat or cool the building to comfortable temperatures. This suggests a model like the one shown.

Building energy consumption plotted against external temperature.
Model suggested by pattern of building energy consumption.
OpenEEmeter candidate models.

But not all buildings line up exactly with this model. Given this reality, the EEmeter runs data against all four of the following models.  It then scores the results, and chooses the best fit. For more information on the fitting procedure and the exact model construction, see our additional documentation.

For more information on why these four are the models used, see model comparison in the additional documentation.

Additional Documentation [pdf]

Models are evaluated on how well they estimate the observed energy data. Model error is a summary of the divergence between the observed data and the fitted model. The model fitting process is applied independently to the energy data observed in the baseline period and the reporting period.

Model errors for (potentially different) reporting and baseline models.

Energy Savings Types

There are a few different ways to look at energy savings. The technique you use depends largely upon the question you want to ask. The two most common questions are:

  1. How much has energy consumption decreased since completion of the project?
  2. How do energy savings for this project compare to other similar projects in a typical year?

Gross Savings

We call the first quantity "total gross normalized metered savings." This is the total savings during the reporting period achieved by applying the baseline model to the observed reporting period weather data.

Gross normalized metered savings represents savings observed since project completion.

Annualized Savings

Annualized weather normalized savings represents as might be observed in a "typical" meteorological year.

We call the second quantity "annualized weather normalized savings." This is expected annual savings not over any observed period, but over a “normal” weather year. The “normal” weather year is an idealized, hypothetical year which is constructed by drawing from observed weather data.This effectively “normalizes” the data by removing some weather uncertainty, and allowing for comparison across projects.

Data Preparation

To enable replicability, the OpenEEmeter carefully defines the types of appropriate data used as inputs. The two types of data the OpenEEmeter takes as input are 1) energy data, and 2) project data.

Trace Data

In the OpenEEmeter, energy data are stored as “traces”. A trace is a single-dimensional time series of measurements tracked by a single physical meter or smart meter. For instance, many projects are broken into two traces: one natural gas trace, and one electricity trace. This is not a strict requirement, as the number of gas and electricity meters varies from building to building.

Traces are time-series collections of fuel consumption records. Records are identified by start date and, by convention, assumed to continue until the next occurring start date. The final end point and missing data are indicated with null values. Estimated records are indicated with a boolean value.

A single project can have multiple traces, each of which is a single time-series of energy measurement.

Project Data

The OpenEEmeter accepts only a few special fields of project data. These special fields are

  1. ZIP code
  2. Project start date
  3. Project end date

Additional diverse project data, including building data, measure and intervention data, or contractor data can be associated with OpenEEmeter results after analysis. We refer to this additional data as “project metadata.”

Weather station mapping by climate zone.

The ZIP code (1) is used for matching the project to nearby weather stations in the same climate zone.

The project dates (2), (3) define the project period, which is used for splitting traces into baseline and reporting periods. All traces which correspond to the same project use the same project dates.

More about ZCTAs

Data Sufficiency Requirements

Data sufficiency requirements must be met for each part (baseline and reporting) of each trace (gas and/or electric). If data sufficiency requirements are not met for a particular modeling step, the OpenEEmeter will not compute the results that depend on that modeling step, although it will proceed to calculate all other possible outputs.

The data sufficiency requirements for individual traces are as follows.

For a baseline period:

  1. At least twelve contiguous months of data immediately preceding project
  2. Each month must have at least 50% non-null data

For a reporting period:

  1. At least twelve contiguous months of data immediately following project
  2. Each month must have at least 50% non-null data
Data sufficiency requirements for each trace.

Outputs

After weather stations have been matched and models have been selected, the OpenEEmeter reports a series of outputs. These outputs include:

  1. Software version
  2. Data sufficiency status
  3. Matched weather station ID
  4. Fetched temperature data
  5. Model fits
  6. Meter derivatives (computed outputs)

Meter derivatives are the official high quality "savings" outputs of the OpenEEmeter and can be used in pay for performance programs, charting, and ad-hoc analysis. These include predicted and observed savings or usage values over baseline, reporting, and normal year periods in time series and as single-value summaries.