Rationalising KPI‑08 (VWATD) Data Requirements Under HNTAS

From Heatweb Wiki
Revision as of 17:37, 23 May 2026 by Rhg (talk | contribs)
Jump to navigationJump to search
      1. A Technical, Economic and Regulatory Case for Adopting the Correct VWATD Methodology and Daily‑Frequency Data Collection
    • Prepared for:**
  • Department for Energy Security & Net Zero (DESNZ)*
  • Office of Gas and Electricity Markets (Ofgem)*
    • Date:** May 2026

---

    1. = Executive Summary =

The Heat Network Technical Assurance Scheme (HNTAS) introduces a regulatory framework intended to ensure minimum performance standards across UK heat networks. A central metric within this framework is **KPI‑08**, which measures **volume‑weighted average temperature difference (VWATD)** at consumer connections.

This white paper demonstrates that:

  • **The correct VWATD calculation requires only cumulative energy and cumulative volume**, meaning **two readings per period** (e.g., monthly) are mathematically sufficient.
  • **Daily readings are more than adequate** for regulatory assurance.
  • **30‑minute data provides no additional accuracy** for KPI‑08 and therefore cannot be justified as a regulatory requirement.
  • Mandating 30‑minute data would impose **£0.5–£1.2 billion** in national infrastructure upgrade costs, compared to **<£3 million** over 10 years for a daily‑data regime.
  • A 30‑minute requirement would be **legally vulnerable** under UK administrative law on grounds of irrationality, disproportionality, and anti‑competitive effect.
  • The presence of **commercial ties between Fairheat (HNTAS technical author) and Guru Systems (a vendor of high‑frequency metering systems)** creates a **perceived conflict of interest**, increasing the importance of demonstrable technology neutrality.

Recommendation: DESNZ and Ofgem should adopt the **correct VWATD methodology** and explicitly specify that **daily cumulative readings satisfy KPI‑08**, ensuring proportionality, legal defensibility, and technology neutrality.

---

    1. = 1. Background: KPI‑08 and the Purpose of HNTAS =

HNTAS is designed to provide **minimum regulatory assurance**, not operational optimisation. KPI‑08 measures the **return temperature performance** of consumer connections, a key determinant of network efficiency.

The KPI is intended to:

  • Identify persistently poor ΔT performance
  • Support fair comparison across networks
  • Provide a regulatory baseline for compliance

It is *not* intended to:

  • Optimise real‑time control
  • Provide granular operational diagnostics
  • Mandate specific metering architectures

Therefore, the data requirements must be **proportionate to the regulatory purpose**.

---

    1. = 2. The Correct VWATD Calculation =

VWATD is defined as:

``` ΔT_VWATD = E / (ρ · c · V) ```

Where:

  • E = total energy delivered over the period
  • V = total volume over the period
  • ρ = density of water (constant)
  • c = specific heat capacity (constant)

Because both E and V are **cumulative meter registers**, KPI‑08 can be computed from:

  • Start cumulative energy and end cumulative energy
  • Start cumulative volume and end cumulative volume

Thus:

Only two readings per period are required.

Daily readings are therefore **more than sufficient**, and 30‑minute readings provide **no improvement** in KPI accuracy.

---

    1. = 3. Data Frequency Requirements: Daily vs 30‑Minute =
      1. == 3.1 Mathematical sufficiency ==
  • Monthly readings → fully sufficient
  • Daily readings → more than sufficient
  • 30‑minute readings → no additional regulatory value
      1. == 3.2 Regulatory principle ==

Under the Regulators’ Code and Better Regulation Framework, DESNZ must ensure:

  • Proportionality
  • Minimal burden
  • Technology neutrality
  • No unnecessary cost to consumers

A 30‑minute requirement fails these tests.

---

    1. = 4. UK‑Wide Cost Impact Assessment =

Assuming **2 million consumer connections**.

      1. == 4.1 Data platform cost difference ==
Frequency Annual Data Volume 7‑Year Storage Annual Cost 10‑Year Cost
Daily ~0.07 TB ~0.5 TB ~£5k ~£50k
30‑minute ~3.5 TB ~24.5 TB ~£245k ~£2.4m

Incremental cost of 30‑minute regime: ~£2.3m over 10 years.

      1. == 4.2 Infrastructure upgrade cost ==

To deliver reliable 30‑minute telemetry, legacy systems require:

  • New gateways/head‑ends
  • New backhaul communications
  • Meter rewiring or replacement
  • Engineering, commissioning, documentation

Indicative costs:

  • Capex per connection: **£150–£400**
  • UK‑wide capex: **£300–£800 million**
  • Opex: **£20–£40 million/year** → **£200–£400 million** over 10 years

Total 10‑year cost of 30‑minute requirement:

    • £500 million – £1.2 billion**

Total 10‑year cost of daily‑data regime:

    • <£3 million**

Cost multiplier:

    • 30‑minute requirement is 200–400× more expensive** with no improvement in KPI‑08 accuracy.

---

    1. = 5. Legal Vulnerability of Mandating 30‑Minute Data =

A 30‑minute requirement would be vulnerable to Judicial Review on several grounds.

      1. == 5.1 Irrationality ==
  • KPI‑08 can be calculated from monthly data
  • 30‑minute data does not improve accuracy
  • Cost impact is £0.5–£1.2bn
  • Therefore the requirement is irrational
      1. == 5.2 Disproportionality ==

Fails the Regulators’ Code because:

  • Burden is excessive
  • No regulatory benefit
      1. == 5.3 Ultra vires ==

HNTAS is for **minimum assurance**, not operational optimisation.

      1. == 5.4 Anti‑competitive effect ==

A 30‑minute requirement:

  • Favours specific vendors
  • Disadvantages legacy systems
  • Is not technically necessary
      1. == 5.5 Procedural unfairness ==

If DESNZ fails to:

  • Consult adequately
  • Consider cost evidence
  • Publish an impact assessment

…the requirement is challengeable.

---

    1. = 6. Conflict‑of‑Interest Considerations =
      1. == 6.1 Documented ties ==
  • Fairheat’s Managing Director is a **co‑founder, director and shareholder** of Guru Systems.
  • Guru Systems sells high‑frequency, encrypted metering systems.
      1. == 6.2 Relevance ==

A 30‑minute requirement would **commercially advantage** systems aligned with Guru’s architecture.

      1. == 6.3 Perception of regulatory capture ==

Even without improper influence, the perception matters:

  • Appears vendor‑aligned
  • Undermines confidence in HNTAS
  • Increases legal risk
      1. == 6.4 Importance of neutrality ==

Adopting the correct VWATD methodology ensures:

  • Technology neutrality
  • Market fairness
  • Regulatory legitimacy

---

    1. = 7. Recommendations =
      1. == 1. Adopt the correct VWATD methodology ==
  • Use cumulative energy and volume
  • Daily readings are sufficient
  • 30‑minute data not required
      1. == 2. Ensure proportionality ==
  • Avoid premature replacement of metering
  • Maintain neutrality
  • Minimise consumer cost
      1. == 3. Publish an impact assessment ==
  • Quantify national cost
  • Compare daily vs 30‑minute regimes
      1. == 4. Address conflict‑of‑interest concerns ==
  • Ensure transparent governance
  • Separate technical authorship from commercial interests
      1. == 5. Provide clear operator guidance ==
  • Daily cumulative readings are compliant
  • Monthly readings are mathematically sufficient
  • 30‑minute data is optional for operational optimisation

---

    1. = 8. Conclusion =

KPI‑08 (VWATD) can be calculated accurately from **two readings per period**. Daily readings are more than sufficient. A 30‑minute requirement would impose **hundreds of millions of pounds** in unnecessary cost, provide **no improvement** in KPI accuracy, and expose DESNZ and Ofgem to **significant legal risk**.

Adopting the correct VWATD methodology ensures:

  • Proportionality
  • Technology neutrality
  • Legal defensibility
  • Consumer protection
  • Confidence in HNTAS governance

This approach aligns with the statutory purpose of HNTAS and the principles of good regulation.

---

If you want, I can also generate:

  • A **Confluence‑optimised version**
  • A **GitHub‑flavoured Markdown version**
  • A **short ministerial briefing**
  • A **diagrammatic summary**