MEPS Estimation Tool | Knowledge Base

Overview

A pre-testing optimisation tool that simulates a product’s performance under the AS/NZS 5125.1 Appendix H MEPS test protocol before physical testing occurs. The user uploads an existing 5125.1 report (or enters product parameters manually), runs the simulation, and receives estimated results for the three Appendix H test sequences at the three required ambient conditions. Based on results, the tool suggests parameter adjustments to improve performance. The user can adjust variables, re-run, and compare iterations in a logged table. The primary value proposition is reducing or eliminating failed MEPS test cycles. A single avoided retest at a Chinese laboratory (testing fees, shipping, delays) is worth multiples of the subscription cost. This feature sits on the premium tier. Access is gated accordingly.

User Stories

As a manufacturer preparing for MEPS testing, I want to simulate my product’s Appendix H results before committing to a physical test so I can identify likely failure modes and optimise the design first. As a product engineer, I want to adjust compressor size, tank volume, and control settings and immediately see the simulated impact on first hour delivery, recharge, and 24-hour COP so I can make informed design decisions. As a user managing multiple design iterations, I want all simulation runs logged to a comparison table so I can track what I changed and what effect it had. As a manufacturer close to the MEPS threshold, I want the tool to tell me what changes are most likely to lift my result above the threshold so I don’t have to guess.

Context: The Appendix H Test Protocol

the developer will not be familiar with this. Alastair to provide a detailed briefing document before build begins. Summary for spec purposes: Appendix H of AS/NZS 5125.1 defines the MEPS test method for heat pump water heaters. It comprises three test sequences:

First hour delivery test: measures how much hot water the system can deliver in the first hour from a defined starting condition Recharge test: measures the time and energy required to recover to setpoint after a draw-off 24-hour simulated use test: measures energy consumption and COP over a full 24-hour simulated usage cycle

Each sequence is conducted at three ambient temperature conditions (exact temperatures to be confirmed by Alastair - likely 5°C, 20°C, and 35°C or similar as per the standard). The MEPS threshold is a minimum 24-hour COP value. Products below the threshold cannot be sold in AU/NZ after the MEPS commencement date. The Python simulation engine already implements this test protocol. the developer’s job is the web wrapper, not the simulation logic.

Inputs

Route 1: Upload existing 5125.1 report

User uploads a 5125.1 PDF
System extracts product parameters using the same extraction pipeline as the 5125.1 Analyser feature
Extracted parameters pre-populate the input form
User reviews and adjusts before running

Route 2: Manual parameter entry

User enters product parameters directly without uploading a report
Useful for hypothetical or future products not yet tested

Product parameters (pre-populated from report or entered manually): Heat pump performance characteristics:

COP vs ambient temperature curve (input as table of data points) Heating capacity vs ambient temperature curve Minimum and maximum operating ambient temperature (°C) Refrigerant type (informational, for display)

Tank characteristics

Tank volume (litres) Number of nodes / stratification model (Alastair to confirm what the Python engine requires) Insulation heat loss coefficient (W/K or equivalent) Setpoint temperature (°C)

Resistive boost element

Element power (kW) Element position in tank (upper / lower / both) Boost enable/disable toggle

Control settings

Thermostat cut-in differential (°C below setpoint) Boost activation conditions (time, temperature threshold, or both) Compressor lockout settings if applicable

Test conditions (fixed per standard, not user-adjustable)

Ambient temperatures: per Appendix H specification Draw-off profile: per Appendix H specification Starting condition: per Appendix H specification These are locked in the UI with a note that they are defined by the standard

Simulation Outputs

Per test sequence, per ambient condition (3 sequences x 3 conditions = 9 result sets): First hour delivery:

Delivered volume of hot water at or above minimum acceptable temperature (litres) Time-series chart: tank temperature vs time, flow rate vs time Pass / fail indicator against MEPS threshold where applicable

Recharge test

Recharge time (minutes) Energy consumed during recharge (kWh) Time-series chart: tank temperature vs time, HP operating status vs time

24-hour simulated use test

Total energy consumed (kWh) 24-hour COP Time-series chart: tank temperature, HP capacity, COP, boost activity over 24 hours MEPS pass/fail indicator: clear visual showing whether the simulated 24-hour COP meets the threshold, and by what margin

Summary results table (all conditions at a glance)

Test5°C ambient20°C ambient35°C ambientPass/FailFirst hour delivery (L)Recharge time (min)24-hour COPMEPS threshold Margin to threshold:

For each ambient condition, show how far above or below the MEPS threshold the simulated COP sits If below threshold: highlight in red with margin value (e.g. “0.12 below threshold”) If above threshold: highlight in green with margin (e.g. “0.18 above threshold”) Thin margin above threshold (within 0.1) flagged amber as a warning - real test variability could push result below

Improvement Suggestions Engine

When a simulation result is at or below the MEPS threshold, the tool generates ranked suggestions for improvement. This is a rules-based engine, not an LLM - the logic is deterministic based on which parameters are most sensitive to the result. Suggestion categories: Compressor sizing:

If heating capacity at low ambient is the binding constraint: suggest increasing compressor capacity Quantify: “Increasing heating capacity at 5°C by 15% is estimated to improve 24-hour COP by approximately X”

Tank volume

If thermal storage is insufficient for the draw-off profile: suggest increasing tank volume Note trade-off with heat loss

Control settings suggestion

If boost element is activating frequently and degrading COP: suggest adjusting cut-in differential or boost lockout settings Specific suggested values where possible

Insulation

If standby heat loss is a significant contributor to energy consumption: flag insulation improvement

Setpoint

If setpoint is higher than required: suggest minimum viable setpoint noting legionella requirements

Suggestion format

Each suggestion shown as a card: parameter, recommended change, estimated COP impact, confidence (high/medium/low) Confidence reflects how directly the simulation can predict the impact vs how much depends on physical factors outside the model Suggestions ranked by estimated COP impact, highest first “Apply this suggestion” button pre-populates the parameter in the input form for immediate re-run

Design Iteration Comparison

Every simulation run is automatically logged to a session table. The user does not need to manually save runs. Iteration log table columns:

Run number Timestamp Key parameter changes from previous run (auto-detected, e.g. “Tank volume: 250L → 300L”) 24-hour COP at each ambient condition MEPS pass/fail at each condition Notes field (user-editable) “Restore this configuration” button

Comparison view

User can select any two runs from the log and see a side-by-side parameter diff and results comparison Chart overlay: plot 24-hour COP curves from two selected runs on the same axes

Session persistence

Iteration log persists within a session User can save a named session (e.g. “Model XYZ optimisation - June 2026”) to their account Saved sessions retrievable from account history

UI / UX Direction

Three-panel layout: inputs (left), results (centre/right), iteration log (bottom or right sidebar) Input panel remains visible and editable after running - no need to navigate back to change a parameter “Run simulation” button prominent; disabled until minimum required inputs are present Results update in place on re-run without losing the iteration log MEPS pass/fail status shown as a persistent header indicator so it’s never off-screen Improvement suggestions shown in a collapsible panel below results - not forced on the user but easy to access Amber/red/green threshold margin colouring consistent throughout Mobile: not a priority for this feature given the complexity of the input form and the likely desktop use context the developer to produce wireframe before building

Out of Scope (v1)

Automated parameter optimisation (the tool suggests, the user decides - no auto-optimise in v1) Multi-product batch simulation Integration with laboratory booking or submission workflows Sensitivity analysis / tornado chart showing which parameters have the most impact (v2 candidate) Export of simulation inputs as a structured laboratory test brief CO2 / natural refrigerant variants if they require a different simulation model

Data Model (indicative)

Simulation sessions table:

session_id user_id product_name (user-entered label) created_at last_run_at source_report_id (nullable, if populated from 5125.1 upload)

Simulation runs table

run_id session_id (foreign key) run_number run_timestamp input_parameters (JSON blob) output_summary (JSON: COP per condition, pass/fail per condition) output_timeseries (JSON array per test sequence and condition) suggestions_generated (JSON array) user_notes (text)

Acceptance Criteria

The feature is done when:

Open Questions (resolve before build starts)

Alastair to provide a technical briefing document on Appendix H test protocol for the developer before build begins. the developer should not be expected to interpret the standard himself. What are the exact ambient temperature conditions specified in Appendix H? Alastair to confirm. What is the MEPS threshold COP value, and does it vary by product category or capacity? Alastair to confirm. Does the Python simulation engine currently implement all three Appendix H test sequences, or only the 24-hour test? Alastair to confirm scope of existing engine before the developer begins. The improvement suggestions engine requires rules mapping parameter changes to COP outcomes. Alastair to draft these rules based on simulation knowledge before the developer builds the suggestions logic - this is domain knowledge the developer cannot be expected to derive himself. Per-run pricing vs subscription: if a credits model is offered alongside the subscription, how should run limits and credits be tracked? Decide pricing model before building access control logic.

A Note on Verification (Acceptance Criterion 15)

This is the most important acceptance criterion on the list and the one most likely to be skipped under time pressure. The simulation outputs need to be validated against real physical test results before any paying customer uses this tool. You have access to historical test reports where you know both the input parameters and the actual test outcome. Running the simulation against those known cases and checking the outputs match is the only way to have confidence in the tool’s suggestions. A manufacturer who optimises their product based on a miscalibrated simulation and still fails the physical test has a legitimate grievance. Do this check before launch, not after.