ECaaS Platform — Energy Calculation as a Service Technical Guide

ECaaS (Energy Calculation as a Service) is the centralised cloud-based API run by MHCLG that delivers all official Home Energy Model (HEM) calculations for regulatory purposes. Rather than each software provider building its own calculation engine — as was the case under SAP — ECaaS provides a single, authoritative HEM engine hosted in the cloud. Every provider submits inputs via the API and receives identical, deterministic results. When the HEM compliance route is used, ECaaS will be the only valid means to confirm compliance with Part L of the Building Regulations. This represents a fundamental shift in how energy performance calculations are delivered across the UK construction industry.

Why ECaaS Was Created

Under the SAP regime, the government published a specification document describing the calculation methodology, and approved software providers each wrote their own implementation of that specification. Assessors then chose from competing software packages — Elmhurst, Stroma, NHER, and others — each of which interpreted the SAP rules independently. This model operated for over 30 years, but it produced several well-documented problems.

Problems With the Old SAP Delivery Model

The government's October 2025 consultation response documented the core issues:

• Inconsistencies between providers — different software packages could produce different results for the same dwelling, because each provider interpreted ambiguous parts of the SAP specification differently
• Slow methodology updates — when the SAP methodology changed, every provider had to update their own engine independently, leading to delays and version fragmentation
• Limited accountability — with the calculation logic distributed across multiple proprietary engines, it was difficult for government to audit or verify that implementations were correct
• Barriers to innovation — the closed, specification-based model made it harder for the wider industry to scrutinise, test, or contribute to the methodology

Of the 84 consultation responses received, 49 explicitly supported the assessment that these were genuine issues with the SAP delivery model. ECaaS was designed as the direct solution to all of them.

ECaaS Architecture

ECaaS follows a straightforward client–server model. Software providers act as clients, submitting structured input data to the ECaaS API. The API runs the HEM calculation on MHCLG's cloud infrastructure and returns structured results. The calculation engine itself is the Rust implementation of HEM, performance-optimised for the demands of a production cloud service.

Input Format

Providers submit dwelling data to the ECaaS API as a structured JSON payload. The input schema covers the full building description required by HEM, including:

• Building geometry — zone definitions, floor areas, volumes, and orientations
• Fabric specification — U-values for walls, floors, roofs, windows, and doors, plus thermal bridging data (psi-values and linear lengths)
• Ventilation details — air permeability, ventilation system type (natural, MEV, MVHR), and specific product data including heat recovery efficiency
• Heating systems — heat pump or boiler specifications, emitter types, control strategies, and hot water system details including cylinder volume, insulation, and pipework lengths
• Renewable systems — PV array specifications (peak power, orientation, tilt, inverter data) and battery storage parameters
• Hot water outlets — individual tapping point specifications including flow rates, temperatures, and usage profiles

The input schema is considerably more detailed than the SAP data format, reflecting HEM's more granular modelling approach. Testing during the consultation period showed that a standard house type takes approximately 1 hour 40 minutes to input in HEM, compared to around 20 minutes in SAP — a consequence of the additional data points required.

Output Format

The API returns a structured JSON response containing energy performance results at multiple levels of detail:

• Annual summary metrics — total energy consumption, carbon emissions, primary energy, and the compliance metrics required by the active policy wrapper (e.g. the FHS target emission rate and target primary energy rate)
• Monthly breakdowns — energy flows aggregated by month for reporting and analysis
• Timestep-level data — the full half-hourly results for each zone and system, available for detailed analysis and diagnostics

The output includes pass/fail compliance indicators when a policy wrapper (such as the FHS wrapper) is applied, enabling providers to display clear compliance status in their user interfaces.

Authentication and Access

Access to the ECaaS API requires authentication. Software providers must register with MHCLG to receive API credentials. The authentication model ensures that only approved software can submit calculations for statutory purposes, maintaining the integrity of the compliance process.

Calculation Time and Performance

One of the most significant practical differences between SAP and ECaaS-delivered HEM is calculation time. A SAP calculation completes near-instantaneously — typically in under a second — because it performs just 12 monthly steady-state calculations. An ECaaS/HEM calculation takes approximately 5–10 minutes per assessment, because HEM runs a full dynamic simulation across 17,520 half-hourly timesteps for each thermal zone.

This extended run time is an inherent consequence of the physics-based modelling approach. At each of the 17,520 timesteps, HEM solves heat balance equations, calculates ventilation flows, determines solar gains, models heating system performance (including variable heat pump COP), and balances electricity generation against demand. The computational workload is orders of magnitude greater than SAP.

The choice of Rust for the production engine — rather than Python — is directly motivated by this challenge. Rust's compiled nature and zero-cost abstractions deliver significantly faster execution than interpreted languages, keeping calculation times within a practical range for commercial use. The MHCLG development team continues to optimise the engine's performance as the codebase matures.

HEM Implementations: Rust and Python

The Home Energy Model exists in two official implementations, each serving a distinct purpose within the ECaaS ecosystem.

Rust Implementation (MHCLG, GitHub)

The Rust implementation is maintained by MHCLG and published on GitHub under the MIT Licence (Crown Copyright). This is the performance-optimised build that powers the ECaaS production service. Rust was selected for its combination of execution speed, memory safety, and concurrency support — qualities that are essential for a cloud service handling thousands of computationally intensive calculations.

Key characteristics of the Rust codebase:

• Compiled execution — Rust compiles to native machine code, delivering performance comparable to C and C++ without the memory safety risks
• Zero-cost abstractions — high-level code constructs compile down to efficient machine instructions with no runtime overhead
• Memory safety without garbage collection — Rust's ownership model prevents common memory errors at compile time, reducing the risk of production bugs in the calculation engine
• Concurrency — safe concurrent processing enables efficient handling of multiple simultaneous calculations on cloud infrastructure

Python Implementation (BRE, Azure DevOps)

The Python implementation is maintained by BRE (Building Research Establishment) and hosted on Azure DevOps. It serves as the reference methodology — the canonical expression of the HEM calculation logic against which the Rust implementation is validated.

The Python codebase is used for:

• Methodology development — new calculation modules and updates are typically prototyped in Python first, where the more expressive syntax makes rapid iteration easier
• Validation and testing — the Python version generates reference results that the Rust implementation must match, ensuring both codebases produce identical outputs
• Research and analysis — BRE and academic researchers use the Python version for detailed investigation of calculation behaviour, sensitivity analysis, and methodology refinement

Both implementations are open source under the MIT Licence. For detailed guidance on exploring the code, building locally, and contributing, see the Open Source Guide.

Old SAP Delivery Model vs ECaaS Model

The table below summarises the structural differences between how SAP was delivered and how HEM is delivered through ECaaS:

Software Provider Integration Model

Under ECaaS, the role of software providers changes fundamentally. Instead of building and maintaining their own calculation engines, providers focus entirely on the user-facing aspects of the assessment workflow:

• Data collection interfaces — building intuitive forms and workflows that guide assessors through the comprehensive data requirements of HEM
• Input validation — checking data quality and completeness before submission to the ECaaS API, reducing failed calculations and improving the user experience
• Results presentation — displaying compliance outcomes, energy performance breakdowns, and diagnostic information in a clear and actionable format
• Workflow management — managing assessment queues, tracking progress across multiple dwellings, and handling the asynchronous nature of 5–10 minute calculations
• Added-value features — tools for design optimisation, scenario comparison, reporting, and integration with other construction industry software

This model shifts competition from “who implements the calculation most accurately” to “who provides the best user experience and workflow tools”. The government's position is that this benefits the industry by ensuring consistent results while allowing providers to differentiate on quality of service.

Benefits of the Centralised Model

The centralisation of calculations through ECaaS delivers several structural advantages over the distributed SAP model:

Guaranteed Consistency

Every assessment — regardless of which software provider submitted it — runs through the identical calculation engine. There is no room for divergent interpretations of the methodology. This eliminates one of the most persistent criticisms of the SAP system and strengthens the regulatory integrity of the compliance process.

Rapid Methodology Updates

When the HEM methodology is updated — whether to correct an error, refine a calculation module, or incorporate new technology types — the change is deployed once to the ECaaS service and immediately takes effect for all users. Under SAP, the same update would require each software provider to independently modify, test, and release a new version of their proprietary engine, a process that could take months.

Open Source Transparency

Because the ECaaS engine is open source, the entire industry can inspect the calculation logic, report issues, and suggest improvements. The government's October 2025 consultation response noted strong support for collaboration, with 68 of 80 respondents providing suggestions for engagement methods — including workshops, industry forums, working groups, and hackathons.

Future-Proofing

The modular architecture of HEM, combined with the centralised delivery through ECaaS, makes it straightforward to add new calculation modules (for emerging technologies) or new policy wrappers (for different regulatory uses) without disrupting existing integrations. The core API contract remains stable while the underlying engine evolves.

Current Status and Timeline

As of early 2026, the ECaaS platform is in an advanced stage of development:

• Test environment — available since mid-2025 for software providers and stakeholders to begin integrating with the API and validating their workflows
• Basic web frontend — under development by MHCLG to provide a simple browser-based interface for stakeholder familiarisation with HEM inputs and outputs, independent of any third-party software
• Rust engine — actively maintained on GitHub with regular updates and performance improvements
• Python reference — continuing development on Azure DevOps, with ongoing methodology refinement and validation work by BRE
• Production launch — aligned with the Future Homes Standard implementation timeline, with the government confirming a dual methodology period allowing both SAP 10.3 and HEM for FHS compliance

Practical Considerations for Integration

Software providers and other stakeholders preparing for ECaaS should be aware of several practical factors:

Asynchronous Workflow Design

The 5–10 minute calculation time means that traditional synchronous request–response patterns are not practical. Providers should design their integrations around asynchronous workflows: submit a calculation request, receive an acknowledgement with a job identifier, then poll for completion or receive a callback notification when results are ready. This affects the entire user experience design of assessment software.

Managing Input Complexity

The HEM input schema is substantially more detailed than SAP's data requirements. Providers will need to invest in intelligent form design, progressive disclosure, sensible defaults, and robust validation to manage this complexity. Where data is not available, HEM applies punitive default values — making it critical that provider interfaces encourage comprehensive data collection rather than relying on defaults.

Error Handling and Diagnostics

ECaaS returns structured error responses when input data is invalid or inconsistent. Providers should implement clear error messaging that helps assessors identify and correct data issues before resubmitting. Given the multi-minute calculation time, minimising failed submissions is important for user satisfaction and workflow efficiency.

Network Dependency

Unlike SAP software that could run calculations locally, ECaaS requires a network connection to the cloud API. Providers should consider offline data entry capabilities (collecting all input data locally, then submitting when connectivity is available) and appropriate handling of network failures or timeouts.

Frequently Asked Questions

Related Pages