Skip to main content
Technical

How HEM Calculates Energy Performance

Last updated: |Verified against GOV.UK
12 min read
By Guy Smith β€” DEA, SAP & SBEM Assessor

The Home Energy Model (HEM) calculates the energy performance of a dwelling by running a half-hourly dynamic thermal simulation across an entire year β€” 17,520 timesteps in total. At each timestep, HEM solves heat balance equations for every user-defined thermal zone, accounting for fabric heat loss, ventilation, solar gains, internal gains, and thermal mass effects. The calculation is grounded in BS EN ISO 52016-1:2017, the European standard for hourly energy calculation, which HEM extends with UK-specific modules for hot water, heat pumps, PV generation, and battery storage. Developed by a BRE-led consortium commissioned by DESNZ, HEM replaces SAP's monthly steady-state method with a physics-based simulation capable of accurately representing how modern low-carbon homes actually perform.

Why Half-Hourly Timesteps Matter

SAP calculates energy performance using 12 monthly timesteps. Each month is treated as a single, averaged period: average outdoor temperature, average solar radiation, average internal gains. This monthly resolution was adequate in 1993 when SAP was designed for pen-and-paper use, but it cannot capture the dynamics that define modern building performance.

HEM's half-hourly resolution (17,520 timesteps per year) changes what the calculation can see. Consider a January day where the temperature drops to –5Β°C overnight but rises to 8Β°C by mid-afternoon. A monthly calculation sees only the January average of roughly 4Β°C. HEM sees every half-hour of that cold snap, modelling the heat pump working harder as the source temperature falls, the thermal mass of the building releasing stored heat overnight, and the solar gains through south-facing glazing contributing free heating in the afternoon.

This granularity matters for several critical reasons:

  • Heat pump performance: A heat pump's coefficient of performance (COP) varies significantly with outdoor temperature. At 7Β°C, an air source heat pump might achieve a COP of 3.5; at –5Β°C, it might fall to 2.0. Monthly averaging obscures these variations, systematically overestimating heat pump performance during cold periods. HEM calculates variable COP at every timestep, capturing the real energy consumption profile.
  • Solar PV and self-consumption: PV panels generate electricity during daylight hours, but household demand peaks in mornings and evenings. The mismatch between generation and demand determines how much electricity is self-consumed versus exported. Monthly calculations cannot model this β€” HEM's half-hourly resolution can, including battery charge and discharge behaviour.
  • Thermal mass interaction: Heavy building elements absorb heat during the day and release it at night. This smoothing effect reduces peak heating demand but only manifests over hours, not months. HEM's dynamic thermal mass modelling captures this behaviour at each timestep.
  • Overheating detection: A room that reaches 35Β°C for several afternoons in July but averages an acceptable temperature over the month would pass SAP's summer check. HEM flags it.
  • Occupancy and controls: Real heating systems do not run constantly β€” they follow schedules, respond to thermostats, and interact with occupancy patterns. Half-hourly resolution allows HEM to model these control interactions realistically.

The Zone Model

One of the most significant departures from SAP is HEM's approach to thermal zoning. SAP divides every dwelling into exactly two zones: the β€œliving area” (typically the main living room, heated to 21Β°C) and the β€œrest of dwelling” (heated to a lower demand temperature). This two-zone model is the same whether the dwelling is a one-bedroom flat or a five-bedroom detached house.

HEM replaces this with a user-defined zone model. The assessor defines thermal zones that reflect the actual layout and heating patterns of the dwelling. Each zone is a discrete thermal volume with its own:

  • Heating setpoint and schedule β€” different rooms can have different target temperatures and operating hours
  • Building elements β€” the specific walls, floors, ceilings, windows, and doors that form the zone boundary, each with their own U-values and thermal properties
  • Thermal mass β€” the effective heat capacity of the fabric elements within and bounding the zone
  • Ventilation rate β€” the air exchange rate for the zone, calculated through the pressure-driven ventilation model
  • Internal gains β€” heat from occupants, lighting, appliances, and cooking within the zone
  • Solar gains β€” direct and diffuse solar radiation entering through the zone's glazed elements

The heat balance equation is solved independently for each zone at every timestep. Zones interact through internal partition elements β€” if a heated living room shares a wall with an unheated garage, the heat flow through that partition is calculated based on the temperature difference between the two zones.

This flexibility has significant practical implications. A three-storey townhouse can have zones for each floor, reflecting the reality that upper floors are often warmer due to stack effect. A home with an unheated conservatory can model the buffer space it provides. A dwelling with underfloor heating in the ground floor and radiators upstairs can have each system modelled in its correct zone with the appropriate emitter characteristics.

Heat Balance Methodology

HEM's heat balance calculation is based on BS EN ISO 52016-1:2017, the European standard that defines the hourly calculation method for heating and cooling energy needs and internal temperatures of buildings. HEM extends this standard from hourly to half-hourly resolution.

The Resistor-Capacitor Network Model

At its core, ISO 52016-1 models each building element (wall, floor, roof, window) as a series of thermal resistances and capacitances β€” an RC network. Thermal resistance represents how well an element resists heat flow (the inverse of thermal conductance), while thermal capacitance represents how much heat the element can store (its thermal mass). This is analogous to an electrical circuit where voltage represents temperature, current represents heat flow, resistors represent insulation, and capacitors represent thermal storage.

For each building element, the standard defines a discretisation into nodes. Opaque elements (walls, floors, roofs) are divided into up to five nodes across their thickness, with resistances between nodes and capacitances at each node. Glazed elements are treated as single-node elements with negligible thermal mass but specific solar transmission properties. This node-based approach captures the dynamic response of the fabric β€” how quickly or slowly heat moves through a wall and how much heat is stored along the way.

The Heat Balance Equation

At each half-hourly timestep, for each zone, HEM solves a heat balance equation of the form:

Qheating/cooling = Qfabric + Qventilation βˆ’ Qsolar βˆ’ Qinternal Β± Qthermal mass

Where:

  • Qfabric is the conductive heat loss through the opaque and glazed elements of the zone envelope, calculated from U-values, areas, and the temperature difference between the zone and the external environment (or adjacent zones). This includes linear and point thermal bridges.
  • Qventilation is the heat loss due to air exchange β€” both intentional ventilation (mechanical or natural) and unintentional infiltration. HEM uses a pressure-driven ventilation model based on BS EN 16798-7:2017, which calculates air flow rates from wind pressure, stack effect, and mechanical system characteristics.
  • Qsolar is the solar heat gain through glazed and opaque elements, calculated from direct and diffuse irradiance on each surface at the specific timestep, accounting for orientation, tilt, shading, and glass properties (g-value).
  • Qinternal is the heat gain from occupants, lighting, appliances, and cooking β€” applied using half-hourly profiles that reflect typical domestic schedules.
  • Qthermal mass is the heat absorbed into or released from the building fabric. When the zone temperature rises, thermal mass absorbs heat (reducing the rate of temperature increase). When the zone temperature falls, stored heat is released (slowing the rate of cooling). This term is what makes the calculation truly dynamic.

If the resulting Qheating/cooling is positive, the zone requires heating to maintain its setpoint temperature. If negative, the zone requires cooling (or excess heat is removed by ventilation). The magnitude determines how much energy the heating or cooling system must supply.

The Core Calculation Loop

For each of the 17,520 half-hourly timesteps in a year, HEM executes a structured sequence of calculations. This loop is documented in HEM-TP-01 (the general calculation summary) and HEM-TP-04 (space heating and cooling demand). The sequence is as follows:

Step 1: Hot Water Demand

The loop begins by calculating domestic hot water (DHW) demand for the current timestep. Unlike SAP, which derives monthly DHW demand from floor area, HEM models individual tapping events β€” specific draw-off patterns representing showers, baths, basin use, and kitchen use. The energy required to heat this water is calculated from the cold water inlet temperature, the delivery temperature, and the volume drawn. Cylinder losses (from stratified storage modelling), pipework losses, and primary circuit losses are all included.

The heating system energy consumed to meet this demand is determined β€” for a heat pump, this depends on the hot water delivery temperature (the sink temperature) and the heat source temperature at the current timestep. Any waste heat from the DHW system that contributes to space heating (such as cylinder losses into a heated space) is recorded for use in the next step.

Step 2: Space Heating and Cooling Demand

This is the most computationally intensive step. For each thermal zone, HEM solves the heat balance equation described above, incorporating:

  • External conditions from the weather data for this timestep (temperature, wind, solar irradiance)
  • Fabric heat loss through all building elements, including thermal bridges
  • Ventilation heat loss from the pressure-driven model
  • Solar gains through each glazed element, using the calculated sun position and irradiance for this specific half-hour
  • Internal gains from the occupancy profile
  • Thermal mass state carried forward from the previous timestep
  • Any incidental gains from DHW system losses (from Step 1)

The result is the net heating or cooling demand for each zone. The heating system (heat pump, boiler, or other) is then simulated to determine the energy consumed to meet this demand. For a heat pump, the COP is calculated from the source temperature (outdoor air or ground temperature) and the sink temperature (flow temperature to the emitter system), using test data mapped according to EN 14825.

Step 3: Multi-Service System Interactions

Where a single heating system serves both space heating and hot water (such as a combi boiler or a heat pump with a diverter valve), additional calculations resolve the interactions between these services. This includes priority logic (some systems prioritise hot water over space heating), capacity limitations (a heat pump may not be able to serve both simultaneously at full output), and efficiency variations depending on the operating mode.

Step 4: Electricity Balance

HEM calculates the electricity balance for the timestep. This includes:

  • PV generation β€” calculated from the panel specification, orientation, tilt, and the solar irradiance at this timestep
  • Total electricity demand β€” from the heating system (heat pump compressor, fans, pumps), lighting, ventilation fans, and other fixed building services
  • Self-consumption β€” the proportion of PV generation consumed within the dwelling at this timestep
  • Battery charge/discharge β€” if battery storage is present, the model determines whether to charge (when PV generation exceeds demand) or discharge (when demand exceeds generation), subject to battery capacity and charge/discharge rate limits
  • Grid import and export β€” the remaining electricity drawn from or fed to the grid after self-consumption and battery interactions

Step 5: Results to Wrapper

The final step returns the timestep results to the active policy wrapper for post-processing. The wrapper aggregates results across all 17,520 timesteps and applies policy-specific calculations:

  • FHS wrapper: Compares the dwelling against the notional building specification, calculates the Target Emission Rate (TER) and Target Primary Energy Rate (TPER), and determines compliance with the Future Homes Standard
  • EPC wrapper (under development): Generates the metrics required for Energy Performance Certificates, including the proposed new metrics such as energy cost rating and carbon emission rating

Module Interaction Sequence

The core calculation loop described above relies on data flowing between HEM's modular calculation components. The principal modules and their interaction order within each timestep are:

  1. External conditions (HEM-TP-03): Reads the weather data for the current timestep and calculates the sun position (altitude and azimuth) using standard solar geometry algorithms. This provides the foundational inputs for all subsequent modules.
  2. Solar gains (HEM-TP-08): Uses the sun position and irradiance data to calculate direct and diffuse solar radiation incident on every building surface, then determines the solar heat gain through each glazed and opaque element.
  3. Ventilation (HEM-TP-06): Calculates air flow rates through the dwelling using the pressure-driven model from BS EN 16798-7:2017, considering wind pressure on each facade, stack effect from indoor-outdoor temperature difference, and mechanical ventilation system operation (MVHR, extract fans, etc.).
  4. Hot water demand (HEM-TP-09, HEM-TP-11): Determines the energy required to meet DHW demand, including storage and distribution losses.
  5. Space heating/cooling (HEM-TP-04, HEM-TP-05, HEM-TP-07): Solves the heat balance for each zone using fabric properties, ventilation rates, gains, and thermal mass state.
  6. Heating systems (HEM-TP-12, HEM-TP-16, HEM-TP-17): Determines the energy consumed by the heating system to meet the calculated demand, accounting for heat pump COP, emitter performance, and controls.
  7. Electricity balance (HEM-TP-18): Resolves PV generation, self-consumption, battery storage, and grid exchange.

This sequential structure ensures that upstream calculations (weather, solar gains) are complete before downstream calculations (heat balance, system energy) that depend on them. The thermal mass state at the end of each timestep is carried forward to the next, creating the continuous dynamic simulation.

Input Data Requirements

HEM requires substantially more input data than SAP. While SAP can complete a calculation from a relatively small set of standardised inputs, HEM's half-hourly dynamic simulation needs detailed information about the building, its systems, and external conditions. The principal input categories are:

Building Geometry and Fabric

  • Zone definitions β€” the number and extent of thermal zones
  • Building element areas, orientations, and tilts for every external wall, floor, roof, window, and door
  • U-values for each building element (or layer-by-layer construction details from which U-values are derived)
  • Thermal mass properties β€” density, specific heat capacity, and thickness of each material layer for opaque elements
  • Window properties β€” g-value (solar factor), frame factor, and shading devices
  • Thermal bridge details β€” linear thermal transmittance (ψ-values) for junctions, or default values from approved details
  • Airtightness test result (air permeability in mΒ³/(hΒ·mΒ²) at 50 Pa)

Heating and Hot Water Systems

  • Heating system type and specification (heat pump model data, boiler efficiency, etc.)
  • Heat pump test data mapped to EN 14825 conditions (capacity and COP at multiple source/sink temperature combinations)
  • Emitter type and design conditions (radiator sizing, underfloor heating pipe spacing)
  • Hot water cylinder specification (volume, insulation, heat exchanger performance)
  • Controls specification (thermostat type, heating schedules, smart control capabilities)

Renewable Energy Systems

  • PV panel specification (peak power, orientation, tilt, efficiency characteristics)
  • Battery storage specification (capacity, charge/discharge rates, round-trip efficiency)

Ventilation System

  • Ventilation strategy (natural, mechanical extract, MVHR)
  • MVHR specification (specific fan power, heat recovery efficiency at different flow rates)
  • Air paths β€” openable window areas, trickle vent specifications, extract fan locations

Weather Data Handling

Weather data is a foundational input to the HEM calculation. The model accepts hourly weather files in two formats:

  • CIBSE Test Reference Year (TRY) β€” statistical composites of real weather data compiled by CIBSE for specific UK locations, representing a β€œtypical” year
  • EnergyPlus Weather (EPW) β€” a widely used international format compatible with multiple simulation tools

Each hourly weather record includes dry bulb temperature, relative humidity, wind speed, wind direction, direct normal solar irradiance, diffuse horizontal solar irradiance, cloud cover, and atmospheric pressure. HEM interpolates these hourly values to half-hourly resolution to match its timestep.

The solar calculation module uses the weather data together with standard solar geometry algorithms to determine:

  • Sun position (altitude and azimuth) at each timestep
  • Direct solar irradiance on each building surface, accounting for its orientation and tilt
  • Diffuse solar irradiance on each surface, using an isotropic or anisotropic sky model
  • Ground-reflected solar radiation contributing to each surface

This approach is fundamentally different from SAP, which uses regional monthly average solar radiation values applied uniformly across all surfaces of a given orientation. HEM's half-hourly weather data captures the full variability of UK weather β€” cloudy mornings, clear afternoons, windless nights, and stormy days β€” all of which affect building energy performance.

SAP vs HEM β€” Calculation Approach

The table below summarises the key differences in calculation approach between SAP and HEM. For a non-technical comparison, see SAP vs HEM.

Calculation AspectSAP 10.2HEM
Timestep resolutionMonthly (12 timesteps per year)Half-hourly (17,520 timesteps per year)
Thermal zoning2 fixed zones (living area + rest)User-defined zones (unlimited)
Heat balance methodSimplified monthly steady-stateDynamic simulation based on BS EN ISO 52016-1:2017
Thermal massSimplified thermal mass parameterFull RC network modelling per element per timestep
Ventilation modelSimplified wind and shelter factorsPressure-driven model based on BS EN 16798-7:2017
Solar gainsMonthly mean radiation, windows onlyHalf-hourly direct + diffuse, through glazing and fabric
Weather dataRegional monthly averagesHourly CIBSE TRY or EPW files, interpolated to half-hourly
Heat pump modellingSimplified seasonal performance factorVariable COP from EN 14825 test data at each timestep
Hot water demandMonthly total from floor area formulaIndividual tapping events with stratified cylinder modelling
PV and batteryMonthly PV generation; no battery modellingHalf-hourly generation, self-consumption, and battery behaviour
Carbon factorsHistorical factors (2012 vintage)Forward-looking factors (2025–2029 projected average)
Calculation timeNear-instantaneous (< 1 second)5–10 minutes per full-year simulation
Software deliveryMultiple third-party calculation enginesCentralised ECaaS API (single canonical engine)

Calculation Time and Computational Demands

A full HEM calculation takes approximately 5–10 minutes to complete, depending on the complexity of the dwelling (number of zones, number of building elements, system configuration). This is a significant change from SAP, which runs in under a second.

The increased computation time is a direct consequence of the model's physics fidelity. Solving the RC network heat balance for every zone, at every timestep, with dynamic thermal mass tracking, pressure-driven ventilation, and variable-COP heat pump modelling is inherently more computationally demanding than SAP's simplified monthly arithmetic.

To manage this, the government delivers HEM through the ECaaS (Energy Calculation as a Service) cloud platform. The Rust implementation, maintained by MHCLG on GitHub, is optimised for performance and runs on scalable cloud infrastructure. Software providers submit calculation inputs through the API and receive results asynchronously β€” assessors do not need to wait at their screens for results.

The Python reference implementation, maintained by BRE on Azure DevOps, is used for ongoing development and validation rather than production calculations. It prioritises code clarity and maintainability over execution speed.

Standards and Technical Papers

HEM's calculation methodology draws on several European and international standards:

  • BS EN ISO 52016-1:2017 β€” Energy performance of buildings: calculation of the building's energy needs for heating and cooling, internal temperatures, and sensible and latent heat loads. This is the primary basis for HEM's heat balance calculation.
  • BS EN 16798-7:2017 β€” Energy performance of buildings: ventilation for buildings, calculation methods for the determination of air flow rates. This underpins HEM's pressure-driven ventilation model.
  • BS EN ISO 52010-1 β€” Conversion of climatic data for energy calculations. Used for the solar irradiance calculations on tilted surfaces.
  • EN 14825 β€” Air conditioners, liquid chilling packages, and heat pumps: testing and rating at part load conditions. Used for heat pump COP mapping.

The full calculation methodology is documented in the HEM Technical Paper series (HEM-TP), published alongside the HEM technical documentation on GOV.UK. Key papers referenced in this guide include:

  • HEM-TP-01 β€” General summary of the core calculation
  • HEM-TP-03 β€” External conditions and weather data
  • HEM-TP-04 β€” Space heating and cooling demand
  • HEM-TP-05 β€” Fabric heat loss
  • HEM-TP-06 β€” Ventilation and infiltration
  • HEM-TP-07 β€” Thermal mass
  • HEM-TP-08 β€” Solar gains
  • HEM-TP-09 β€” Domestic hot water
  • HEM-TP-11 β€” Hot water storage tanks
  • HEM-TP-12 β€” Heat pump methodology
  • HEM-TP-16 β€” Heat emitters
  • HEM-TP-17 β€” Controls
  • HEM-TP-18 β€” PV generation and self-consumption

For a complete reference of all standards underpinning HEM, see the Standards Reference page.

Frequently Asked Questions

Why does HEM use half-hourly timesteps instead of monthly?

HEM uses half-hourly timesteps (17,520 per year) because monthly averages cannot capture how modern technologies actually perform. Heat pump efficiency varies with outdoor temperature throughout the day. Solar PV output fluctuates with cloud cover. Battery storage charges and discharges within hours. Monthly calculations average all of this away, making it impossible to model self-consumption, peak demand, or true heat pump performance in cold snaps. The half-hourly resolution also aligns with electricity settlement periods and smart meter data.

How long does a HEM calculation take to run?

A full HEM calculation typically takes 5–10 minutes, compared to SAP which runs almost instantaneously. This is because HEM solves heat balance equations for every zone, every building element, and every system across 17,520 half-hourly timesteps. The calculation runs on MHCLG's ECaaS cloud platform using the Rust implementation, which is optimised for performance. Assessors do not need to wait β€” calculations are queued and processed in the background through the API.

How does HEM's zone model differ from SAP's two zones?

SAP divides every dwelling into exactly two zones: the living area (heated to 21Β°C) and the rest (heated to a lower temperature). HEM allows any number of user-defined zones, each with its own heating schedule, setpoint, thermal mass, ventilation rate, and internal gains. A three-storey townhouse can have different zones per floor, a home office can be modelled separately, and unheated spaces such as garages are properly represented. See our SAP vs HEM comparison for a broader overview.

What weather data does HEM use?

HEM uses hourly weather data in CIBSE Test Reference Year (TRY) or EnergyPlus Weather (EPW) format. This includes hourly dry bulb temperature, humidity, wind speed and direction, direct and diffuse solar irradiance, cloud cover, and atmospheric pressure. The data represents typical meteorological years for specific UK locations and is interpolated to half-hourly values. This is a substantial improvement over SAP's regional monthly averages.

What is BS EN ISO 52016-1 and how does HEM use it?

BS EN ISO 52016-1:2017 is the European standard for calculating building energy needs for heating and cooling. It defines an hourly method based on a resistor-capacitor (RC) network model of the thermal envelope. HEM adopts this as its heat balance foundation, extending it to half-hourly resolution and adding UK-specific modules for ventilation, hot water, heat pumps, and renewables. The standard provides the mathematical framework for conductive heat transfer, solar and internal gains, thermal mass, and resulting heating or cooling demand.

This topic is evolving

Get notified when HEM guidance changes β€” regulation updates, compliance deadlines, and industry analysis from a practising assessor.

No spam. Unsubscribe at any time.