The central question in measuring energy efficiency: how did energy consumption change from the baseline period to the reporting period?
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.
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.
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).
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.
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.
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.
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.
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:
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.
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.
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.
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.
The OpenEEmeter accepts only a few special fields of project data. These special fields are
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.”
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.
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:
For a reporting period:
After weather stations have been matched and models have been selected, the OpenEEmeter reports a series of outputs. These outputs include:
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.
Was this guide useful to you? Was there anything that needed more explanation or that seemed incorrect? Please let us know.