The OpenEEMeter provides a consistent, replicable way to estimate site-based energy savings.
Consistent, replicable methods provide confidence in energy efficiency savings. The methods outlined below are designed to promote market transformation and innovation in the energy efficiency industry. In conjunction with available open-source code, these methods allow any public or private entity to calculate gross normalized metered savings and be confident that their results will be consistent with other third parties.
In the next decade, energy efficiency investments will need to increase tenfold in order to meet our climate goals and energy needs. As with the solar revolution of recent years, achieving these goals will require innovation in both technology and business models. It will be essential to measure the respective impact of new approaches in a consistent, transparent way. Clear methods reduce the likelihood of implementation discrepancies and potential confusion over inputs and outputs.
Open-source code allows for collaboration and encourages stakeholders to work together to ensure transparency and replicability. The OpenEEmeter’s open-source license promotes collaboration without unduly burdening new users with restrictive implementation constraints. Much like the propagation of other open-source platforms such as the Android operating system, the OpenEEmeter lays a foundation for future innovation and deployment across the energy sector.
Consistency means being confident that the savings calculations are using the same methods as all other savings calculations. In the case of the OpenEEmeter, each site’s savings is calculated using a consistent, weather-normalized model. There are no discretionary independent variables that change from calculation to calculation. This way, site level savings reflect the same underlying methods across programs and implementations.
Replicability means that any one analysis of gross normalized energy savings can be performed in exactly the same way by any third party. The OpenEEmeter is not a substitute for EM&V analysis with control groups that would be designed to determine Net program savings.
Rather, the OpenEEmeter is designed for a broader set of use cases, such as allowing market participants to evaluate the likely return on investment of their energy efficiency projects. It is critical to these third parties that they are able to forecast the risk associated with their investments.
Therefore, being able to replicate the savings calculation is a crucial precondition of program participation.
The OpenEEmeter estimates building energy savings that arise after an intervention.
It does this by taking what we know about a building's energy consumption from before an intervention and comparing it to what happens afterward.
The central question is: 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.
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.
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.
Was this guide useful to you? Was there anything that needed more explanation or that seemed incorrect? Please let us know.