RTF New Homes Subcommittee February 11, 2016 Next Step Homes Update

Protocol Objective Give builders and home-energy professionals the ability to develop energy efficient new homes without constraining them to a prescriptive path Protocol used to estimate energy savings and to provide guidance for measure selection and trade-off – REMRate combined with NEEA’s Axis database will help estimate energy savings claim – NEEA’s Axis database will track Program homes in the region facilitating future research 2

NEEA’s Role and High Level Objective 3 NEEA Provides: Modeling Protocol and support docs Axis New Home Database Rater & Builder Training M&V Support

Presentation Objectives In this presentation we are looking to: Present the structure of the Protocol in development Get buy in from the subcommittee that this Provisional Protocol in development is: – Useful for the region – Feasible – Devolop-able into a Proven Protocol with research 4

Three Components to the Proposed Protocol Model Inputs: Emphasis on consistency, completeness, physical accuracy Energy Modeling: Emphasis on reasonableness of building-level annual end-use energy consumption estimates Realization Rate: Emphasis on program-level savings, how fast the meter spins (on average) 5

6 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

7 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

Model Inputs: Emphasis on Consistency Model inputs are Standardized via Modeling Guidelines, through which user is instructed on how audit data should be input to REMRate to meet Protocol requirements; NEEA is taking the lead in development of these guidelines. E.g., a specific heating system category for DHP does not exist – Modeling guidelines will instruct how to input the properties of the DHP using the REMRate ASHP options by manipulating HSPF, % load served, capacity and other required fields Limitations of the software will help clarify Protocol applicability 8

Model Inputs: Emphasis on Completeness Fairly complete audit level description of home and all equipment not limited by modeling engine capability Those details that do not fit in the REM/Rate model ecosystem will be captured for future use (as deemed necessary) Useful information required to calculate accurate energy savings will not be lost E.g., For DHP, manufacturer information including size and efficiency of the equipment will be captured 9

Model Inputs: Emphasis on Physical Accuracy QA/ QC supported by broad industry effort HERS certified raters develop building plans and collect site level audit data HERS certified verifiers inspect and test homes QC’ed site audit data informs REMRate model Using the DHP example, the DHP details captured in Rater notes will be physically verified by HERS certified verifiers for accuracy 10

Model Inputs: Baseline For each program home, a similar reference baseline home is constructed (automatically) by REMRate Exact specification of the baseline homes is in development – WA and OR offer multiple paths to code compliance, details on how to execute these are being worked out – ID and MT do not pose this problem, there is a single specification to meet code 11

Model Inputs: Baseline (cont.) Heating system choice for baseline home: Assume a like for like heating system baseline and efficient pair E.g. Heat pump for Heat Pump, Gas FAF for Gas FAF, etc. – As long as baseline and efficient options exist for each heating system type; this assumption should usually suffice Details on how the baseline for DHP will be handled is a more complex question that is still being worked out – E.g., should the baseline be zonal electric, or DHP? Note - per WA and OR state code, choice of heating system may impact shell components of code compliant home 12

13 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

14 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

Energy Modeling: Current Engine is REMRate NEEA wants to leverage a tool that most of the building industry is already familiar with (REMRate) Annual end-use energy consumption per home estimated by REMRate makes physical sense – This will be accomplished via back end adjustments to REMRate output as required (next slide) 15

Energy Modeling: Back-End Adjustments Currently plan to make back-end adjustments to REMRate outputs of 4 broad end use categories: (1) Lighting, (2) Heating and Cooling, (3) Water Heating, and (4) Other end use End use annual energy consumption estimate adjusted to match RTF accepted outputs where possible; engineering adjustments made using accepted existing data where not (e.g., building America) Examples of how this may work: Lighting: Adjust REMRate estimate to represent annual lighting energy use as dictated by RTF approved Residential Lighting measure Heating and Cooling: Billing analysis adjustment based adjustment (VBDD) using (available) ETO’s REMRate files and billing data. SEEM another possibility 16

Energy Modeling: Back-End Adjustments Desired result is an estimate of annual building energy consumption by end-use that makes sense based on physics and existing knowledge. – The realization rate (next) corrects for the difference between what we expect based on physics (achieved by back-end adjustments) and what happens/ reality – This piece of the protocol is under development. Question for the subcommittee: What level of detail is required to get the protocol to Provisional status? – Can we get to “good enough” before crossing the too- complicated-to-implement threshold? Want to avoid making back-end adjustment process too complicated 17

18 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

19 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

Realization Rate: Emphasis on Accurate Program Level Savings A-priori realization rate applied to back-end adjusted energy modeling output for both baseline and efficient home – Savings is calculated as the difference between realization rate-adjusted (and back end-adjusted) baseline and efficient home consumption The estimated realization rate will be a coarse adjustment meant to be right on average. – Emphasis on accurate program level savings 20

Realization Rate (Contd.) Provisional realization rate for future participants will be estimated a-priori using data received from ETO – Proven realization rate will be trued up on a regular basis; every 2-3 years Likely need more data from colder climates and better representation of electric heat sources down the road Analysis conducted during this phase may help develop the back-end adjustment factor for heating (and maybe cooling) – The exact details of this step are in development 21

22 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average)

23 Model inputs Standardized via Modeling Guidelines Limitations help clarify protocol applicability Fairly complete description of home/equipment Not limited by modeling engine capability QA/QC supported by broad industry effort Baseline: a similar “code home” automatically generated for each efficient home modeled Energy modeling NW REM/Rate : Engine embedded in current effort This may change some day Back-end adjustments used to adjust raw model outputs Will account for patchable engine deficiencies Realization rate Based on comparison with billing data Adjustments likely to be pretty coarse VBDD to attempt separate true-ups for heating, baseload, and (maybe) cooling May also inform some “back-end adjustments” under Energy Modeling Emphasis on consistency, completeness, physical accuracy Emphasis on reasonableness of building-level annual end- use energy consumption estimates Emphasis on program-level savings, how fast the meter spins (on average) Three basic options for handling modelling difficulties

Subcommittee Recommendation and Discussion Recommendation from the subcommittee that this Provisional Protocol in development is/ isn't: Useful for the region – When answering this question, subcommittee should consider if there are other alternatives for developing new construction programs given the recent improvements in building code. Feasible – Is this getting too complex to implement? Develop-able into a Proven Protocol with research 24

Extra Slide: What is a Provisional Standard Protocol? A Standard Protocol method is appropriate when savings from a measure are widely varying, e.g., variable frequency drives and transformer de- energizing, but can be determined by a standardized procedure for data collection and analysis that is applicable to many different end use sites Provisional UES savings and Standard Protocol methods requires a funded research plan, approved by the RTFs. 25