Energy Performance of Buildings (Scotland) Regulations 2025: stock model research

8 Appendix: RdSAP to FHS Assumptions

In general, there is a fairly close relationship between the input fields for SAP and for HEM. As described in Section 4: Methodology, RdSAP (‘Reduced Data SAP’, the format used for the analysis input dataset) is the data format used by a surveyor to collect EPC survey data for existing homes, and RdSAP works by taking this reduced dataset and extrapolating it to the full SAP dataset using a complex set of standard assumptions.

Because the input data for HEM is broadly similar to the input data for SAP, we were able to modify our existing engine to produce a HEM dataset from a combination of the RdSAP input data and the expanded SAP data. However, as HEM includes a number of new fields that aren’t present in either RdSAP or SAP, a number of further assumptions were needed. These are listed below.

Note that most of these observations and limitations do not affect the calculation of the primary EPC rating (Heat Retention Rating).

8.1 General

• HEM introduces the concept of zones, which are somewhat similar to the “main + extensions” paradigm used in SAP to separate out parts of the dwelling with differing thermal performance, but with much greater flexibility as heating systems can be assigned to specific zones. However, the analysis was limited to one zone per property.
• Cold water can be supplied from the mains or a header tank. Cold water was always assumed to come from the mains.
• HEM requires external conditions to be provided in a supplied file of weather data, similar to how SAP carries out regional weather calculations for metrics other than the Energy Cost Rating. This replaces actual location used in RdSAP for each of the SHCS cases. For consistency and to save calculation time, it was agreed to use a standardised location and weather file ("GBR_Leuchars.031710_IWEC.epw", downloaded from EnergyPlus^[5], and an altitude of 45 metres above sea level) for the calculation of all Scottish EPC metrics. Therefore, to ensure comparability with the analogous SAP metrics like the space heating demand, a standardised location (postcode KY16) was likewise used for the SAP calculations on the same properties.
• A number of dual-rate electricity tariffs are available in Scotland, but only one was available in the wrapper that wasn’t a variable time of day tariff, Economy 8.5 (see “Scotland_EPC_fuel_costs_variable_grid_model.csv”). This was therefore used for all dual-rate properties. As Economy 8.5 is not an available tariff in RdSAP 10, the 7-hour tariff was used instead for the “RdSAP 10 Energy Cost Rating” metric. This is not a metric output by the Scottish EPC wrapper by default, but added by us to allow comparison with our SAP-calculated RdSAP 10 Energy Cost Rating.
• For the same reason, the “SAP 10.2 Energy Cost Rating” metric output by the wrapper uses the Scottish EPC tariffs for electricity, whereas other fuels use the SAP 10.2 tariffs. As the former tariffs are much more recent, this makes the cost ratio artificially high between electricity and other fuels, so we believe this metric to be of very limited use.
• Even though dual rate tariffs are accounted for in the above Energy Cost Rating metrics, the Space Heating System Cost Rating always uses the standard tariff for electricity. This metric represents the cost per kWh of heat delivered, so will be artificially high for properties that do most of their heating at a lower unit rate, such as storage heaters.

8.2 Lighting

• It was unknown whether low energy lighting in the SHCS dataset represented CFL or LED lighting, so we assumed an average wattage between the two, similar to RdSAP 10 where the type of low energy lighting cannot be determined.

8.3 Fabric

• The orientation of the property, used for e.g. solar gains and ventilation, was not present in the SHCS data. Therefore, the orientation was randomly selected between 0 and 360 degrees.
• For the same reason, whether a party wall was on the left or right side of the building was randomly selected.
• Although the SHCS dataset included construction data for alternative walls, it did not include the dimensions needed to calculate these. As such, these were disregarded for both SAP and HEM calculations.
• The mass distribution class for each element was assumed given construction type, insulation type and the age of the property.
• The areal heat capacity for each element was taken from RdSAP 10 6.16. Under RdSAP, this is calculated for the dwelling as a whole based on the main building construction and insulation, so the same value was applied to all fabric elements, including internal walls, floors and ceilings.
• The thermal resistance to an unheated space was taken from SAP 10 3.3.
• Walls facing unheated corridors were accounted for in our calculations, however the areas of walls facing heated corridors were not, as this is not collected in an RdSAP survey. However, as there is assumed to be no heat loss to a heated space, this only represents an insignificant reduction in thermal mass. This is the same behaviour as in SAP.
• We assumed medium colours (brick/concrete) for walls, dark colours (brown/grey) for roofs, and black front doors.
• Broadly speaking, properties in urban areas were assumed to be shielded from the wind, suburban were average, and rural were exposed.
• Floors:
  • Floor to wall junction psi values were taken from SAP 10 table R2.
  • It was not possible to include slab edge insulation (more commonly seen in new builds after the introduction of Part L 2010), as the input schema provided didn’t include the necessary fields required when this was the case. It was therefore always assumed that solid floors did not have slab edge insulation, though standard floor insulation was still considered.
• Rooms in roof:
  • Due to a lack of specific data, rooms in the roof were all assumed to be type 1, aka true rooms in roof, with no common wall.
  • The floor area of a room in roof was taken as 70% of the floor below. This is a standard assumption that we use in our own large-scale modelling.
  • Assumptions were made for gable types based on the built form of the property:
    • Detached: both gables exposed
    • Semi-detached, end-terrace, enclosed end-terrace: one gable exposed, one party wall gable
    • Mid-terrace, enclosed mid-terrace: both party wall gables
  • Gable lengths, given the assumed floor area, were calculated as (0.7 * floor area)/sqrt(floor area).
• Windows:
  • Window areas were derived using the RdSAP 9.94 methodology, which is based on the property type and floor area. They were distributed evenly over external walls and storeys, split by the proportions that were multiple and single glazed, and by whether they were draughtproofed or not.
  • We assumed an average reveal depth of 8cm.
• Distant shading:
  • In urban areas, we assumed that there are two rows of properties of the same height as our property, each located 10 metres from the front and 10 metres from the rear. We assumed no shading in rural areas.
  • We assumed PV and solar hot water arrays are unshaded.
• Conservatories:
  • Due to time constraints, we were unable to include these in the HEM input data.

8.4 Heating

• The greatest caveat is that HEM only supports a very minimal set of fuels: mains gas, electricity, LPG, and custom (which can only be used for heat networks in the Scottish EPC wrapper). Furthermore, for boilers, only mains gas and LPG are supported, so e.g. electric boilers are not possible. See Modelling boilers within the Home Energy Model ^[6] page 20 for background.
• Electric underfloor heating doesn’t seem to be possible to model in HEM. Instant electric heaters or storage heaters would be closest, so we treated these as if they were instant electric heaters. This loses the impact of thermal mass and the ability to preheat at a lower night rate, so these properties would perform worse than they would in reality.
• Non-electric room heaters (e.g. open fires, solid fuel stoves, range cookers) cannot be modelled in HEM. Where the fuel restrictions noted above allowed, we modelled these as regular boilers with radiators. We only included electricity use for a circulation pump if the room heater had a back boiler (i.e. would be supplying rads/hot water cylinder anyway), and only included electricity consumption whilst running if the flue was fan-assisted.
• Warm air heating, except for air-to-air heat pumps, cannot be modelled in HEM. Electricaire systems (electric warm air) could be modelled as storage heaters (though none were present in the data), but the gas warm air heating systems in the SHCS could not be modelled at all.
• Any CHPs present were modelled like boilers, as there doesn’t seem to be any way to account for the electricity generated in HEM at present.
• As a result of the above limitations, we were unable to calculate any metrics except for the Heat Retention Rating for 1,070 properties in the SHCS dataset. The Heat Retention Rating could still be calculated for these properties, as it replaces the heating and hot water systems with standardised direct electric heating and immersion to remove the impact of the heating system itself on the HRR.
• Boilers:
  • HEM expects full and part load efficiencies from EN15502-1 test data, which it corrects following section 3 of HEM technical paper 14⁶. Boiler efficiencies in SAP, whether from SAP tables or the PCDB, have already had this correction applied (see CALCM-02), so we applied the reverse of this correction before entering efficiencies to ensure it was not applied twice, i.e. once by SAP and again by HEM. We used winter and summer efficiency as a proxy for full and part load efficiency, where available.
  • All boilers are considered to be condensing in HEM, and permanent pilot lights are not considered.
• Heat pumps:
  • HEM differs from SAP in that a set of EN14825 test data must be provided for a model. SAP uses the DHAPSE method described in CALCM-01 to generate PCDB entries or SAP table defaults given this test data, and this same method is used for the HEM calculations.
  • As we only had the final space heating efficiencies to work with (at various Plant Size Ratios for PCDB entries; or a flat % efficiency for default RdSAP models that varies by flow temperature, controls and MCS certification), it was not possible to reverse engineer EN14825 test data from this as most of the known assumptions were missing.
  • There is one set of EN14825 test data for one heat pump model in the HEM demo files. Presumably this is a modern model, as demo files mostly seem to represent new dwellings, so will perform too well compared to the fairly pessimistic assumptions that SAP table heat pumps make.
  • To resolve this, we implemented a minimal set of the DHAPSE calculations to generate a SAP space heating efficiency from a set of EN14825 test results, and wrote a solver to reverse this, generating a set of EN14825 test results from a given space heating efficiency. This is unlikely to be perfectly accurate but will be better than using the single demo model, thus avoiding properties with heat pumps scoring artificially high in HEM compared to SAP.
  • The input data also requires the kW capacity of the heat pump. It was too early in the calculations to select an appropriate capacity based on the peak heat loss of the property so instead, we gave each property an arbitrarily-large heat pump of 16kW capacity, and allowed it to modulate down to 1kW so it suits both low and high heat loss properties.
• Storage heaters:
  • All types of storage heater had the same performance characteristics (i.e. minimum output when not heating, and maximum output when heating, both depending on charge level), but manual/auto/high heat retention charge control are all modelled appropriately. We added the charging schedules to the input file as these were not added by the wrapper.
• Community heating and heat networks:
  • For community heating and heat networks, we were unable to calculate the building-level distribution losses. In SAP, this is a factor based on the age of the property, whereas in HEM a continuous figure in watts is required. As the peak heat loss of the property is not calculated until later in the HEM calculations, we were unable to come up with a sensible estimate for this field. As such, we took this value from the notional FHS dwelling.
  • Community heating systems can only be entered in HEM as a heat interface unit (HIU) for building-level distribution losses to be considered, although in reality most community-heated properties with e.g. a shared boiler won’t use one.
  • Daily HIU losses were also taken from the notional FHS dwelling.
  • Flat rate charging doesn’t seem to be possible in HEM, so charging was always based on use.
• Secondary heating:
  • Not modelled in HEM, except for ventilation purposes (i.e. open fires).
• Ecodesign controller data is always required for a space heating system, but the worst category is 1 which is an on-off thermostat. Some heating control options in SAP do not have a thermostat so these properties will likely perform a little better than they should.

8.5 Water heating

• Solar water heating
  • This is supported by HEM but wasn’t included in the input schema for the wrapper. We added this to be able to calculate SHW systems, so technically our input files did not match the schema supplied with the wrapper.
  • We were unsure whether a combined store is possible in HEM at present (usually the case if a property has a regular boiler, i.e. with cylinder), so we always assumed a separate 75 litre pre-heat cylinder. This is the same as the default SAP assumptions for a combi boiler or a heat pump.
  • Solar water heating (and WWHRS) is only possible in HEM when the pre-heat cylinder is feeding a normal hot water cylinder: so it doesn’t work for combis, instantaneous hot water, HIUs, heat batteries etc. For these properties we did not add the solar water heating, so the HEM calculations could still be run, but as a result they will score lower on metrics other than Heat Retention Rating.
• Range cookers for hot water only
  • As noted above these can’t be modelled in HEM, so, if the fuel limitations allowed, we treated these as a regular boiler providing hot water only. In SAP, the heat emitted from the unit itself (if a database model was selected) would be accounted for by reducing the space heating demand; this would have been missed in the HEM calculations.

8.6 Ventilation

• To match assumptions made in SAP (see SAP 10.2 specification, 2.2), we did not add trickle vents or air bricks to properties.
• For properties treated in SAP as having natural ventilation (as opposed to continuous MEV, or MVHR), we added intermittent extractor fans following RdSAP 10 table 5.
• For properties with continuous MEV, we assumed this was a decentralized system, using SAP assumptions for fan power.
• For properties with MVHR, we again used SAP assumptions for fan power and heat recovery efficiency, but made assumptions about the ductwork as this was not included in the SHCS dataset.
• The air pressure test result follows SAP 10 assumptions for structural and other infiltration (e.g. doors and windows).
• We added an open fireplace per open chimney listed in the data, fuelled by wood unless specified otherwise in secondary heating data.

8.7 Wrapper issues

• To match SAP assumptions, we did not add unregulated appliances to properties, which meant that the wrapper added default appliances and their uses based on assumed occupancy. This triggered a bug in the Future Homes Standard wrapper, causing the calculations to crash, but we proposed and agreed on an interim fix as the FHS wrapper is not the responsibility of the Scottish government.
• The SAP 10.2 variable grid costs are unused as noted in the General section.
• All community fuels use the same price/carbon factor, no matter the fuel
• Suspended floors required additional data that was not present in the supplied schema, so we added this.
  • Likewise for solid floors with slab edge insulation, as noted above, but we were unable to add it in this case.
• We added some heat pump and boiler information that was missing from the supplied schema.
• As noted above, pre-heated water sources were missing from the schema, but required for solar hot water, so we added these.

8.8 HEM issues

• Non-electric room heaters cannot be modelled for heating – e.g. open fireplaces, wood stoves (see Heating). They are considered for ventilation.
• Warm air systems, except for air-to-air heat pumps, cannot be modelled in HEM (see Heating).
• Likewise many other uncommon systems: range cookers, electric ceiling heating, electric underfloor heating.
• Likewise for any boiler that does not use mains gas or LPG as fuel.
• Solar water heating is incompatible with any instantaneous hot water source, so has been excluded from these properties.
• For a small number of properties with a very small floor area, a HEM bug related to too-low hot water demand was triggered, and so we were unable to calculate results for these properties.