Heatweb Wiki - User contributions [en]

Rationalising KPI‑08 (VWATD) Data Requirements Under HNTAS

2026-05-23T16:40:58Z

Rhg:

''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

---

= 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. 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**.

---

= 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.

---

= 3. Data Frequency Requirements: Daily vs 30‑Minute =

== 3.1 Mathematical sufficiency ==
* Monthly readings → fully sufficient
* Daily readings → more than sufficient
* 30‑minute readings → no additional regulatory value

== 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.

---

= 4. UK‑Wide Cost Impact Assessment =

Assuming **2 million consumer connections**.

== 4.1 Data platform cost difference ==

{| class="wikitable"
! 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.

== 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.

---

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

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

== 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

== 5.2 Disproportionality ==
Fails the Regulators’ Code because:

* Burden is excessive
* No regulatory benefit

== 5.3 Ultra vires ==
HNTAS is for **minimum assurance**, not operational optimisation.

== 5.4 Anti‑competitive effect ==
A 30‑minute requirement:

* Favours specific vendors
* Disadvantages legacy systems
* Is not technically necessary

== 5.5 Procedural unfairness ==
If DESNZ fails to:

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

…the requirement is challengeable.

---

= 6. Conflict‑of‑Interest Considerations =

== 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.

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

== 6.3 Perception of regulatory capture ==
Even without improper influence, the perception matters:

* Appears vendor‑aligned
* Undermines confidence in HNTAS
* Increases legal risk

== 6.4 Importance of neutrality ==
Adopting the correct VWATD methodology ensures:

* Technology neutrality
* Market fairness
* Regulatory legitimacy

---

= 7. Recommendations =

== 1. Adopt the correct VWATD methodology ==
* Use cumulative energy and volume
* Daily readings are sufficient
* 30‑minute data not required

== 2. Ensure proportionality ==
* Avoid premature replacement of metering
* Maintain neutrality
* Minimise consumer cost

== 3. Publish an impact assessment ==
* Quantify national cost
* Compare daily vs 30‑minute regimes

== 4. Address conflict‑of‑interest concerns ==
* Ensure transparent governance
* Separate technical authorship from commercial interests
== 5. Provide clear operator guidance ==
* Daily cumulative readings are compliant
* Monthly readings are mathematically sufficient
* 30‑minute data is optional for operational optimisation

---

= 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.

Rationalising KPI‑08 (VWATD) Data Requirements Under HNTAS

2026-05-23T16:37:56Z

Rhg:

### ''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

---

## = 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. 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**.

---

## = 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.

---

## = 3. Data Frequency Requirements: Daily vs 30‑Minute =

### == 3.1 Mathematical sufficiency ==
* Monthly readings → fully sufficient
* Daily readings → more than sufficient
* 30‑minute readings → no additional regulatory value

### == 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.

---

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

Assuming **2 million consumer connections**.

### == 4.1 Data platform cost difference ==

{| class="wikitable"
! 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.

### == 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.

---

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

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

### == 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

### == 5.2 Disproportionality ==
Fails the Regulators’ Code because:

* Burden is excessive
* No regulatory benefit

### == 5.3 Ultra vires ==
HNTAS is for **minimum assurance**, not operational optimisation.

### == 5.4 Anti‑competitive effect ==
A 30‑minute requirement:

* Favours specific vendors
* Disadvantages legacy systems
* Is not technically necessary

### == 5.5 Procedural unfairness ==
If DESNZ fails to:

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

…the requirement is challengeable.

---

## = 6. Conflict‑of‑Interest Considerations =

### == 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.

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

### == 6.3 Perception of regulatory capture ==
Even without improper influence, the perception matters:

* Appears vendor‑aligned
* Undermines confidence in HNTAS
* Increases legal risk

### == 6.4 Importance of neutrality ==
Adopting the correct VWATD methodology ensures:

* Technology neutrality
* Market fairness
* Regulatory legitimacy

---

## = 7. Recommendations =

### == 1. Adopt the correct VWATD methodology ==
* Use cumulative energy and volume
* Daily readings are sufficient
* 30‑minute data not required

### == 2. Ensure proportionality ==
* Avoid premature replacement of metering
* Maintain neutrality
* Minimise consumer cost

### == 3. Publish an impact assessment ==
* Quantify national cost
* Compare daily vs 30‑minute regimes

### == 4. Address conflict‑of‑interest concerns ==
* Ensure transparent governance
* Separate technical authorship from commercial interests

### == 5. Provide clear operator guidance ==
* Daily cumulative readings are compliant
* Monthly readings are mathematically sufficient
* 30‑minute data is optional for operational optimisation

---

## = 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**

Rationalising KPI‑08 (VWATD) Data Requirements Under HNTAS

2026-05-23T16:37:09Z

Rhg: Created page with "Absolutely — here is the full white paper rendered cleanly in **MediaWiki‑style markup**, ready for a wiki, Confluence, GitLab/GitHub wiki, or any other platform that supp..."

Absolutely — here is the full white paper rendered cleanly in **MediaWiki‑style markup**, ready for a wiki, Confluence, GitLab/GitHub wiki, or any other platform that supports standard wiki syntax.

---

# **White Paper: Rationalising KPI‑08 (VWATD) Data Requirements Under HNTAS**
### ''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

---

## = 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. 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**.

---

## = 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.

---

## = 3. Data Frequency Requirements: Daily vs 30‑Minute =

### == 3.1 Mathematical sufficiency ==
* Monthly readings → fully sufficient
* Daily readings → more than sufficient
* 30‑minute readings → no additional regulatory value

### == 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.

---

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

Assuming **2 million consumer connections**.

### == 4.1 Data platform cost difference ==

{| class="wikitable"
! 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.

### == 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.

---

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

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

### == 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

### == 5.2 Disproportionality ==
Fails the Regulators’ Code because:

* Burden is excessive
* No regulatory benefit

### == 5.3 Ultra vires ==
HNTAS is for **minimum assurance**, not operational optimisation.

### == 5.4 Anti‑competitive effect ==
A 30‑minute requirement:

* Favours specific vendors
* Disadvantages legacy systems
* Is not technically necessary

### == 5.5 Procedural unfairness ==
If DESNZ fails to:

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

…the requirement is challengeable.

---

## = 6. Conflict‑of‑Interest Considerations =

### == 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.

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

### == 6.3 Perception of regulatory capture ==
Even without improper influence, the perception matters:

* Appears vendor‑aligned
* Undermines confidence in HNTAS
* Increases legal risk

### == 6.4 Importance of neutrality ==
Adopting the correct VWATD methodology ensures:

* Technology neutrality
* Market fairness
* Regulatory legitimacy

---

## = 7. Recommendations =

### == 1. Adopt the correct VWATD methodology ==
* Use cumulative energy and volume
* Daily readings are sufficient
* 30‑minute data not required

### == 2. Ensure proportionality ==
* Avoid premature replacement of metering
* Maintain neutrality
* Minimise consumer cost

### == 3. Publish an impact assessment ==
* Quantify national cost
* Compare daily vs 30‑minute regimes

### == 4. Address conflict‑of‑interest concerns ==
* Ensure transparent governance
* Separate technical authorship from commercial interests

### == 5. Provide clear operator guidance ==
* Daily cumulative readings are compliant
* Monthly readings are mathematically sufficient
* 30‑minute data is optional for operational optimisation

---

## = 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**

EMBED

2025-10-21T13:36:00Z

Rhg: /* Documents */

The Energy Saving Trust’s EMBED hub is an interactive online resource of building energy performance data, collated from energy monitoring field trials and various other studies.
What EMBED offers

*A single place to store and organise project information, documents and data.
*In-depth monitoring data from past and current trials in a standard format.
*Search and filter options for similar buildings and quick visualisation of large data sets.
*Easy data sharing with other users for collaboration and dissemination.
*Options to keep sensitive information and documents private and secure from other users.
*A web API to extract data for your own online tools.
*Secure online transfer of live monitoring data from any device using the Energy Saving Trust's open data format.
Taken from: [http://www.energysavingtrust.org.uk/businesses/embed-building-performance-platform http://www.energysavingtrust.org.uk/businesses/embed-building-performance-platform]

===Can the data be saved so that no-one other than the home owner knows where the data originated?===
Yes, data can either be saved with full details of the property (this was the main requirement for retrofit for the future) or it can be saved anonymously so that householders could look at their own data. There are also different levels of access so that a landlord could see the data from all of their properties but a tenant would only see their property for example.

===How much data can the system handle, and is it prepared for the inclusion of thousands of properties, each feeding data at up to 10 second resolution, from up to 10 sensors? Where are the limits?===
Embed is a cloud-based solution so can be expanded almost infinitely as demand grows. It is a [https://en.wikipedia.org/wiki/Apache_Cassandra Cassandra database] meaning scale is not a problem. It can accept and easily process very high volumes of high frequency data. It is also an open source platform, keen for contributors to get involved in the project.

===Is EMBED free to use ?===
Currently EMBED will be made available for free to projects that are happy to share data publicly. All public data are anonymised before being made available, some of this is automated but some of it relies on the data originator.

==Potential uses for EMBED==
*Manufacturers who want performance data and alarms.
*Landlords and ESCOs to extract meter data for billing.
*Heat network managers, to monitor and alarm system inefficiencies.
*Ofgem, to confirm RHI system efficiencies.
*DECC, to monitor the effectiveness of research projects.
*Installers, to commission systems.
*Service engineers, to see whats up before arriving on site.
*Occupants, to save money through improved management and efficiency, and have more effective backup.
*As the database behind browser or app ENE3 Home Display Systems.

==Thermal Integrations Intentions==
As a manufacturer of HIUs, we are focused on supplying a superior product at a competitive price. We have had our systems installed alongside most billing systems on the market, and on a number of contracts we have been called upon to design and supply the network infrastructure required to get data from heat meters off-site, typically through Ethernet.

Our new generation of HIUs and Heat Banks make use of our [//www.heatweb.com/wiki/index.php?title=IHIU_Control_Systems IHIU Control Systems], a small Linux controller with Ethernet and Wifi connectivity, with M-Bus functionality in development. They are connected to a number of system sensors covering domestic hot water, central heating, and the primary operation. We fit Heat Meters into our HIUs, and as such, a host of sensor data and meter data is available from our system.

As detailed in the section above, the uses for this data are numerous, however we feel the potential for making use of a single database for domestic energy use can only be realised if the industry as a whole contributes to the data set. We have used remote sensor data for years now, in the study of how custom made heating systems perform, and on numerous occasions we have identified, and fixed, inefficiencies that would go unnoticed without the data. The knowledge is often transferable to improving systems of a similar type elsewhere. The use of common database and data visualisation tools, will allow the industry as a whole to ensure equipment runs as expected, rather that mysteriously costing significantly more to run as originally planned. Systems that perform to exceptional levels of performance can educate everyone.

It is in our interest to design systems to work with a standard non-commercial database as a minimum, and we feel it is in the interests of service companies to be able to access data from both heat meters and HIUs via a standard portal. It is certainly in the interests of our product users to have their data held in a single secure public database where they control access rather than an array of private companies.

It is our intention to be completely open about the process of connecting equipment to the EMBED system, and how data can then be visualised and analysed. This page will be updated and examples published as we progress.

See our own [//www.heatweb.com/wiki/index.php?title=Compact_35_Pellet_Boiler_Test_Rig Compact 35 Pellet Boiler Test Rig] system, used as a development and demonstration platform for advancing the control of pellet boilers, as well as testing Embed connectivity.

==Documents==

https://heatweb.co.uk/w/images/2/2d/Embed_slides.pptx

==EMBED Webs Pages==
* [http://www.getembed.com www.getembed.com]
* [https://github.com/MastodonC/kixi.hecuba/blob/master/doc/help/embed.md GitHub Main Project Page and Help]
* [https://github.com/MastodonC/kixi.hecuba/blob/master/doc/api.md GitHub API]
* [https://github.com/mastodonc/amon AMON Data Format]
To access the system you first need to register at [http://www.getembed.com www.getembed.com], and from there you can view public data.

==Connecting an IHIU controller to EMBED==
This is a record of the process involved in sending data to the EMBED site. We already have a [//www.heatweb.com/wiki/index.php?title=Compact_35_Pellet_Boiler_Test_Rig fully functioning pellet boiler test rig] in the factory that is providing a stream of sensor and operational data to our own servers, via an [//www.heatweb.com/wiki/index.php?title=IHIU_Control_Systems IHIU controller]. The IHIU controller is itself a Linux web server, running PHP, so has all the required connectivity to talk to any web site. We aim to initially send data to our own server, and from then forwards the necessary data to EMBED. Once this is achieved, we will also get the IHIU talking directly to EMBED - which should be straightforward as both the IHIU and our web servers run using the same software infrastructure - PHP.

===Programmes===
Programmes are areas within the EMBED system under which projects and properties are organised. They are assigned by the EMBED Administrator. For the purposes of this development, we have obtained a programme called Heatweb.

===Projects===
Projects are filed under programmes. They are created through the [http://www.getembed.com getembed.com website], once logged on. We have created a Project called MMSP, representing the Monitoring and Metering Service Package on offer by DECC and Ofgem for takers of the RHI (Renewable Heat Incentive). In brief, a small financial incentive is provided to install full monitoring alongside a renewable installation. Although the scheme has been running for over a year, there have been no takers - mainly because the task of setting up a monitoring system backed by online services, is something plumbers do not understand, and are not yet engaged with. If anything they are fearful of having customers phone them every time they spot something on a graph they don't understand. That and the fact there are no decent monitoring packages that do not cost hundreds of pounds. Linking a low cost general purpose controller to the EMBED database, is a perfect solution.

For some devices, such as pellet boilers, there is a need for manufacturer specific data to analyse data from installations. In our case, the ratio of auger rotation to volumetric delivery of pellets is a figure that can be determined through a test, or over time, but a simple connection to an online database would speed up and simplify the process. It also allows us to check that the boiler delivers pellets as expected by the manufacturer, and could give an indication of a faulty auger, or variations in fuel quality. As part of this project we will create a web page on our server to send the boiler specific data (once obtained) to the IHIU controller.

Question: Is there already a central public database of manufacturer/model specific data presented via an API ?

When inputting projects, you also need to provide a Project Code of your own choosing, as well as a description of the type of project, and the project itself.

===Properties===
Properties are filed under projects. They are created through the [http://www.getembed.com getembed.com website], once you have created a project. Our test rig is located in the Thermal Integration factory in Sudbury, Suffolk. This will be the property. We have given it a code of TIL1.

===Devices===
A Device is a piece of monitoring equipment that feeds back data. This is where it starts to get more involved. It is easiest to start by describing what we know about our device, or rather what data it provides:

* Temperature and pressure from the boiler flow
* Temperature and flow from the boiler return
* 5x temperature readings from the buffer store
* Run signals from the pump, auger motor, fan, and pellet delivery system
* Percentage run time of auger (averaged over one minute)
* Air velocity in flue (not yet connected)
* Heat Meter data
* Fault Codes
We have selected these inputs as our aim is to obtain via EMBED the heat meter readings, and a confirmation the pellet boiler is working to expected efficiencies. It should be noted that we could just as easily be monitoring the efficiency of a gas boiler, HIU, or entire district heating network. The basic idea at this stage is to send the data to an online database, where software can analyse it automatically, and alarm any variations from the norm.

From these raw values, we also wish to obtain some calculated values. These can be be calculated in the IHIU controller and then sent to EMBED, or potentially calculated on EMBED.

* Calculated values for Power, and Total Generation - will act as a check to the heat meter data
* Calculated valued for Volumetric Fuel Use - calculated from auger rate
* Calculated values for Boiler Efficiency (averaged over 5, 30, and 60 minutes, and per day)
As sensors can be expensive, part of our aim is to ascertain the minimum number of sensors required to determine correct function. Temperature is very cheap to measure, followed by pressure, and between them a host of other problems can be determined. However, you need to first match patterns in the data to known events (such a pump failure), that in future could remove the need for a more expensive sensor (such as a relay to pick up pump signal).

The first round of testing highlighted the benefits of using properly calibrated heat meter data when calculating energy flow over using off the shelf sensors. A tiny inaccuracy in either flow or temperatures is exaggerated at low temperature differences, and hard to confirm without comparing to heat meter data.

The system now incorporates acts as an M-Bus Master and can read heat meter data via the M-Bus connections, or an RS232 connection. This data is MID approved, and required for MMSP.

{{IMG|embedsensors.png|640}}

==Making a Connection to EMBED==
[https://github.com/MastodonC/kixi.hecuba/blob/47b6813cc2aea047f00d22ed0be11e250b88aa4e/doc/api-examples.http Github EMBED examples.]

The following python script (courtesy of the Embed developers) is used to send data.
Note that the entity id is the 3rd id code in the url when on the property page of the Embed site.

The code is run by the command:

python /mnt/sda1/arduino/www/python/embed_upload_measurements.py username password

<syntaxhighlight lang="python" highlight="1,5-7">
#!/usr/bin/python
import sys
import requests
import time
import json
from requests.auth import HTTPBasicAuth

## Info on this script refer to a testing instance on getembed.com

## Embed url
#URL = "https://www.getembed.com/4/"
URL = "http://www.getembed.com/4/"

## Add entity and device ids for properties you want to upload measurements to:
## Example:
## [{"entity1": ["device1.1", "device1.2"]}, {"entity2": ["device2.1", "device2.2"]}]
entities = [
{"d0a91ad4-dd99-4ad1-8b6f-ad97c54a6aae": ["b4149ec6-7264-4f5c-b62a-09d3baff7808"]}
]

measurements = {"measurements": [
{
"value": "0.87",
"timestamp": "2015-08-24T10:30:00Z",
"type": "Pressure",
}
]}

## To run if you want to check device info
def check_device(entity_id, device_id, user, pwd):
"Check device exists and device info."
auth = HTTPBasicAuth(user, pwd)
url = URL + "entities/" + entity_id + "/devices/" + device_id
r = requests.get(url=url, auth=auth)
print r.status_code
print r.json()

## To run to upload measurements device per device
# NOTE: Update measurements content and make sure "type" matches current sensor type
def post_measurements(entity_id, device_id, user, pwd):
"Post measurements for a device."
auth = HTTPBasicAuth(user, pwd)
url = URL + "entities/" + entity_id + "/devices/" + device_id + "/measurements/"
data = json.dumps(measurements)
try:
r = requests.post(url=url, data=data, auth=auth)
time.sleep(2)
print r.status_code, r.reason
if r.status_code == 202:
print "Measurements uploaded for device ", device_id, " in property ", entity_id
except requests.ConnectionError as e:
print "Connection error. ", e
except requests.ConnectTimeout as e:
print "Connection timed out. ", e

## To run to upload measurements to several devices
def upload_all_measurements(user, pwd):
"Add measurements for multiple devices."
for entity in entities:
for device in entity:
post_measurements(entity, device, user, pwd)

if __name__ == "__main__":
post_measurements("d0a91ad4-dd99-4ad1-8b6f-ad97c54a6aae", "b4149ec6-7264-4f5c-b62a-09d3baff7808", sys.argv[1], sys.argv[2])

# check_device("45f93880-df89-4565-acd1-6a1d6c22792c", "d434ec0e-210f-4937-9873-6c42eddd3936", sys.argv[1], sys.argv[2])
</syntaxhighlight>

This code results in the following response:

{{IMG|Embedscreen1.png|800}}

==The Output on Embed==
One a successful connection has been made, one can view the output on the Embed website in various ways, including detailed graphs.

{{IMG|Embedg1.png|800}}

EMBED

2025-10-21T13:33:49Z

Rhg: /* Documents */

The Energy Saving Trust’s EMBED hub is an interactive online resource of building energy performance data, collated from energy monitoring field trials and various other studies.
What EMBED offers

*A single place to store and organise project information, documents and data.
*In-depth monitoring data from past and current trials in a standard format.
*Search and filter options for similar buildings and quick visualisation of large data sets.
*Easy data sharing with other users for collaboration and dissemination.
*Options to keep sensitive information and documents private and secure from other users.
*A web API to extract data for your own online tools.
*Secure online transfer of live monitoring data from any device using the Energy Saving Trust's open data format.
Taken from: [http://www.energysavingtrust.org.uk/businesses/embed-building-performance-platform http://www.energysavingtrust.org.uk/businesses/embed-building-performance-platform]

===Can the data be saved so that no-one other than the home owner knows where the data originated?===
Yes, data can either be saved with full details of the property (this was the main requirement for retrofit for the future) or it can be saved anonymously so that householders could look at their own data. There are also different levels of access so that a landlord could see the data from all of their properties but a tenant would only see their property for example.

===How much data can the system handle, and is it prepared for the inclusion of thousands of properties, each feeding data at up to 10 second resolution, from up to 10 sensors? Where are the limits?===
Embed is a cloud-based solution so can be expanded almost infinitely as demand grows. It is a [https://en.wikipedia.org/wiki/Apache_Cassandra Cassandra database] meaning scale is not a problem. It can accept and easily process very high volumes of high frequency data. It is also an open source platform, keen for contributors to get involved in the project.

===Is EMBED free to use ?===
Currently EMBED will be made available for free to projects that are happy to share data publicly. All public data are anonymised before being made available, some of this is automated but some of it relies on the data originator.

==Potential uses for EMBED==
*Manufacturers who want performance data and alarms.
*Landlords and ESCOs to extract meter data for billing.
*Heat network managers, to monitor and alarm system inefficiencies.
*Ofgem, to confirm RHI system efficiencies.
*DECC, to monitor the effectiveness of research projects.
*Installers, to commission systems.
*Service engineers, to see whats up before arriving on site.
*Occupants, to save money through improved management and efficiency, and have more effective backup.
*As the database behind browser or app ENE3 Home Display Systems.

==Thermal Integrations Intentions==
As a manufacturer of HIUs, we are focused on supplying a superior product at a competitive price. We have had our systems installed alongside most billing systems on the market, and on a number of contracts we have been called upon to design and supply the network infrastructure required to get data from heat meters off-site, typically through Ethernet.

Our new generation of HIUs and Heat Banks make use of our [//www.heatweb.com/wiki/index.php?title=IHIU_Control_Systems IHIU Control Systems], a small Linux controller with Ethernet and Wifi connectivity, with M-Bus functionality in development. They are connected to a number of system sensors covering domestic hot water, central heating, and the primary operation. We fit Heat Meters into our HIUs, and as such, a host of sensor data and meter data is available from our system.

As detailed in the section above, the uses for this data are numerous, however we feel the potential for making use of a single database for domestic energy use can only be realised if the industry as a whole contributes to the data set. We have used remote sensor data for years now, in the study of how custom made heating systems perform, and on numerous occasions we have identified, and fixed, inefficiencies that would go unnoticed without the data. The knowledge is often transferable to improving systems of a similar type elsewhere. The use of common database and data visualisation tools, will allow the industry as a whole to ensure equipment runs as expected, rather that mysteriously costing significantly more to run as originally planned. Systems that perform to exceptional levels of performance can educate everyone.

It is in our interest to design systems to work with a standard non-commercial database as a minimum, and we feel it is in the interests of service companies to be able to access data from both heat meters and HIUs via a standard portal. It is certainly in the interests of our product users to have their data held in a single secure public database where they control access rather than an array of private companies.

It is our intention to be completely open about the process of connecting equipment to the EMBED system, and how data can then be visualised and analysed. This page will be updated and examples published as we progress.

See our own [//www.heatweb.com/wiki/index.php?title=Compact_35_Pellet_Boiler_Test_Rig Compact 35 Pellet Boiler Test Rig] system, used as a development and demonstration platform for advancing the control of pellet boilers, as well as testing Embed connectivity.

==Documents==
{{Embed_slides.pptx|Embed_slides}}

==EMBED Webs Pages==
* [http://www.getembed.com www.getembed.com]
* [https://github.com/MastodonC/kixi.hecuba/blob/master/doc/help/embed.md GitHub Main Project Page and Help]
* [https://github.com/MastodonC/kixi.hecuba/blob/master/doc/api.md GitHub API]
* [https://github.com/mastodonc/amon AMON Data Format]
To access the system you first need to register at [http://www.getembed.com www.getembed.com], and from there you can view public data.

==Connecting an IHIU controller to EMBED==
This is a record of the process involved in sending data to the EMBED site. We already have a [//www.heatweb.com/wiki/index.php?title=Compact_35_Pellet_Boiler_Test_Rig fully functioning pellet boiler test rig] in the factory that is providing a stream of sensor and operational data to our own servers, via an [//www.heatweb.com/wiki/index.php?title=IHIU_Control_Systems IHIU controller]. The IHIU controller is itself a Linux web server, running PHP, so has all the required connectivity to talk to any web site. We aim to initially send data to our own server, and from then forwards the necessary data to EMBED. Once this is achieved, we will also get the IHIU talking directly to EMBED - which should be straightforward as both the IHIU and our web servers run using the same software infrastructure - PHP.

===Programmes===
Programmes are areas within the EMBED system under which projects and properties are organised. They are assigned by the EMBED Administrator. For the purposes of this development, we have obtained a programme called Heatweb.

===Projects===
Projects are filed under programmes. They are created through the [http://www.getembed.com getembed.com website], once logged on. We have created a Project called MMSP, representing the Monitoring and Metering Service Package on offer by DECC and Ofgem for takers of the RHI (Renewable Heat Incentive). In brief, a small financial incentive is provided to install full monitoring alongside a renewable installation. Although the scheme has been running for over a year, there have been no takers - mainly because the task of setting up a monitoring system backed by online services, is something plumbers do not understand, and are not yet engaged with. If anything they are fearful of having customers phone them every time they spot something on a graph they don't understand. That and the fact there are no decent monitoring packages that do not cost hundreds of pounds. Linking a low cost general purpose controller to the EMBED database, is a perfect solution.

For some devices, such as pellet boilers, there is a need for manufacturer specific data to analyse data from installations. In our case, the ratio of auger rotation to volumetric delivery of pellets is a figure that can be determined through a test, or over time, but a simple connection to an online database would speed up and simplify the process. It also allows us to check that the boiler delivers pellets as expected by the manufacturer, and could give an indication of a faulty auger, or variations in fuel quality. As part of this project we will create a web page on our server to send the boiler specific data (once obtained) to the IHIU controller.

Question: Is there already a central public database of manufacturer/model specific data presented via an API ?

When inputting projects, you also need to provide a Project Code of your own choosing, as well as a description of the type of project, and the project itself.

===Properties===
Properties are filed under projects. They are created through the [http://www.getembed.com getembed.com website], once you have created a project. Our test rig is located in the Thermal Integration factory in Sudbury, Suffolk. This will be the property. We have given it a code of TIL1.

===Devices===
A Device is a piece of monitoring equipment that feeds back data. This is where it starts to get more involved. It is easiest to start by describing what we know about our device, or rather what data it provides:

* Temperature and pressure from the boiler flow
* Temperature and flow from the boiler return
* 5x temperature readings from the buffer store
* Run signals from the pump, auger motor, fan, and pellet delivery system
* Percentage run time of auger (averaged over one minute)
* Air velocity in flue (not yet connected)
* Heat Meter data
* Fault Codes
We have selected these inputs as our aim is to obtain via EMBED the heat meter readings, and a confirmation the pellet boiler is working to expected efficiencies. It should be noted that we could just as easily be monitoring the efficiency of a gas boiler, HIU, or entire district heating network. The basic idea at this stage is to send the data to an online database, where software can analyse it automatically, and alarm any variations from the norm.

From these raw values, we also wish to obtain some calculated values. These can be be calculated in the IHIU controller and then sent to EMBED, or potentially calculated on EMBED.

* Calculated values for Power, and Total Generation - will act as a check to the heat meter data
* Calculated valued for Volumetric Fuel Use - calculated from auger rate
* Calculated values for Boiler Efficiency (averaged over 5, 30, and 60 minutes, and per day)
As sensors can be expensive, part of our aim is to ascertain the minimum number of sensors required to determine correct function. Temperature is very cheap to measure, followed by pressure, and between them a host of other problems can be determined. However, you need to first match patterns in the data to known events (such a pump failure), that in future could remove the need for a more expensive sensor (such as a relay to pick up pump signal).

The first round of testing highlighted the benefits of using properly calibrated heat meter data when calculating energy flow over using off the shelf sensors. A tiny inaccuracy in either flow or temperatures is exaggerated at low temperature differences, and hard to confirm without comparing to heat meter data.

The system now incorporates acts as an M-Bus Master and can read heat meter data via the M-Bus connections, or an RS232 connection. This data is MID approved, and required for MMSP.

{{IMG|embedsensors.png|640}}

==Making a Connection to EMBED==
[https://github.com/MastodonC/kixi.hecuba/blob/47b6813cc2aea047f00d22ed0be11e250b88aa4e/doc/api-examples.http Github EMBED examples.]

The following python script (courtesy of the Embed developers) is used to send data.
Note that the entity id is the 3rd id code in the url when on the property page of the Embed site.

The code is run by the command:

python /mnt/sda1/arduino/www/python/embed_upload_measurements.py username password

<syntaxhighlight lang="python" highlight="1,5-7">
#!/usr/bin/python
import sys
import requests
import time
import json
from requests.auth import HTTPBasicAuth

## Info on this script refer to a testing instance on getembed.com

## Embed url
#URL = "https://www.getembed.com/4/"
URL = "http://www.getembed.com/4/"

## Add entity and device ids for properties you want to upload measurements to:
## Example:
## [{"entity1": ["device1.1", "device1.2"]}, {"entity2": ["device2.1", "device2.2"]}]
entities = [
{"d0a91ad4-dd99-4ad1-8b6f-ad97c54a6aae": ["b4149ec6-7264-4f5c-b62a-09d3baff7808"]}
]

measurements = {"measurements": [
{
"value": "0.87",
"timestamp": "2015-08-24T10:30:00Z",
"type": "Pressure",
}
]}

## To run if you want to check device info
def check_device(entity_id, device_id, user, pwd):
"Check device exists and device info."
auth = HTTPBasicAuth(user, pwd)
url = URL + "entities/" + entity_id + "/devices/" + device_id
r = requests.get(url=url, auth=auth)
print r.status_code
print r.json()

## To run to upload measurements device per device
# NOTE: Update measurements content and make sure "type" matches current sensor type
def post_measurements(entity_id, device_id, user, pwd):
"Post measurements for a device."
auth = HTTPBasicAuth(user, pwd)
url = URL + "entities/" + entity_id + "/devices/" + device_id + "/measurements/"
data = json.dumps(measurements)
try:
r = requests.post(url=url, data=data, auth=auth)
time.sleep(2)
print r.status_code, r.reason
if r.status_code == 202:
print "Measurements uploaded for device ", device_id, " in property ", entity_id
except requests.ConnectionError as e:
print "Connection error. ", e
except requests.ConnectTimeout as e:
print "Connection timed out. ", e

## To run to upload measurements to several devices
def upload_all_measurements(user, pwd):
"Add measurements for multiple devices."
for entity in entities:
for device in entity:
post_measurements(entity, device, user, pwd)

if __name__ == "__main__":
post_measurements("d0a91ad4-dd99-4ad1-8b6f-ad97c54a6aae", "b4149ec6-7264-4f5c-b62a-09d3baff7808", sys.argv[1], sys.argv[2])

# check_device("45f93880-df89-4565-acd1-6a1d6c22792c", "d434ec0e-210f-4937-9873-6c42eddd3936", sys.argv[1], sys.argv[2])
</syntaxhighlight>

This code results in the following response:

{{IMG|Embedscreen1.png|800}}

==The Output on Embed==
One a successful connection has been made, one can view the output on the Embed website in various ways, including detailed graphs.

{{IMG|Embedg1.png|800}}

ISO14068

2025-10-03T08:14:03Z

Rhg:

ISO 14068 is a 2023 international standard from the ISO 14000 environmental management series that provides a framework for achieving and claiming carbon neutrality. It replaces PAS 2060, offering a more comprehensive, science-based approach that emphasizes reducing greenhouse gas (GHG) emissions, using credible offsetting methods, ensuring transparency, and aligning with international frameworks like the GHG Protocol.

Key Aspects of ISO 14068.

# Carbon Neutrality: The standard outlines the principles, requirements, and guidance for an organization to be carbon neutral, meaning its net GHG emissions are reduced to zero.
# Quantification and Reduction: It requires organizations to quantify all direct and indirect GHG emissions, with a clear focus on reducing emissions first before resorting to offsetting.
# Offsetting: It specifies the use of credible GHG removal or compensation measures, ensuring that offset projects are validated and that their use is transparent.
# Transparency and Integrity: A core aim is to prevent greenwashing by providing clear, verifiable claims of carbon neutrality through robust accounting and disclosure.
# Alignment: The standard is aligned with broader international frameworks, including the Science-Based Targets initiative (SBTi) and the Paris Agreement, and builds on the requirements of the ISO 14064 series for GHG accounting.
# Replacement for PAS 2060: As of late 2023 and into 2025, ISO 14068-1 has replaced the PAS 2060 standard for carbon neutrality claims.

Benefits of Implementing ISO 14068.

# Verifiable Claims: Enables organizations to make credible claims of carbon neutrality to stakeholders.
# Reduced Emissions: Provides a clear pathway and guidance to reduce an organization's carbon footprint.
# Enhanced Reputation: Strengthens brand image and builds customer confidence in sustainability initiatives.
# Regulatory Compliance: Helps organizations meet current and future environmental regulations.
# Improved Operations: Encourages resource efficiency, potentially leading to cost savings.

https://files.sciencebasedtargets.org/production/files/Net-Zero-Standard.pdf

https://ghgprotocol.org/sites/default/files/standards/Scope3_Calculation_Guidance_0.pdf

ISO14068

2025-10-03T08:07:52Z

Rhg: Created page with "ISO 14068 is a 2023 international standard from the ISO 14000 environmental management series that provides a framework for achieving and claiming carbon neutrality. It replac..."

Pipework Calculation Examples

2025-09-17T11:18:17Z

Rhg: /* Excel */

{{#ev:youtube|https://www.youtube.com/watch?v=WBUh2Xfj4f4&list=PLBJhGFZAtRPp5pj1HKNYR5zphrHzr0NYb|480|right|Pipe Sizing in District Heating, Episode 1|frame}}

{{#ev:youtube|https://www.youtube.com/watch?v=kajwJr5SaEQ&list=PLBJhGFZAtRPp5pj1HKNYR5zphrHzr0NYb|480|right|Pipe Sizing in District Heating, Episode 2|frame}}

We believe the best way to learn is via examples. It is also one of the key problems with current guidance - they lack any full examples. If they had a few then the holes in the logic would quite quickly become apparent.

Some of the calculations are editable. This is for 3rd party input, so feel free to add to the sheets any notes or calculations that are helpful to others.

Please contact us with any requests for new example calculations.

==Pipe Selection==

This section is dedicated to providing a best practice example of pipework for 480 properties split into 10 risers (or buildings). Known calculations and standards are combined with results from EST studies on water consumption. Calculations included:

*Domestic hot water (DHW) diversity
*Central heating (CH) diversity
*Pressure drops
*Thermal losses
*Erosion rates
*Buffer sizing
*Boiler sizing
*Carbon footprint

[[Pipework Calculations|Main Technical Article on Pipework Calculations]]

===Excel===

* https://www.heatweb.co.uk/w/index.php?title=File:Pipework8.xlsx
* https://www.heatweb.co.uk/w/index.php?title=File:Pipework7.xlsx
* https://www.heatweb.co.uk/w/index.php?title=File:Pipework3.xlsx
* https://www.heatweb.co.uk/w/index.php?title=File:Pipework3_poor_performance.xlsx.xlsx

===Google Sheets===

* [https://docs.google.com/spreadsheets/d/1FY01wiDbl6Ew4NVKuTaQ3lkNNBJ3zTxKJ-F_togdvBI/edit?usp=sharing Spreadsheet of Pipe Sizing]
* [https://docs.google.com/spreadsheets/d/1aI_SJEkYkZwXCkzOFbaraPMxQrppNJYd6xzswKmjaJs/edit?usp=sharing Editable version]

==Diversity==

The following spreadsheet is currently editable by anyone.

* [https://docs.google.com/spreadsheets/d/1TtprDWpiO6NmWu6S8g5v00gYaIJC5v9B30qqNb8nUSw/edit?usp=sharing Editable Diversity Spreadsheet]

HNTAS

2025-09-12T00:46:45Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (not incorporating any of the peer review alterations from by working group feedback in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

Given these do not incorporate any of the significant working group corrections, one would hope to see a further release that includes working group feedback prior to public consultation. Releasing old documents and claiming they have been peer reviewed is inaccurate and misleading, especially if the intention is to go to consultation with these uncorrected versions.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

[[File:Vwatdcalc.png|600px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD (CC-KPI-08) calculation, there is no need for complex AMR or data analysis.'''

[[File:Hntas-consumer-vwart.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-09-12T00:25:03Z

Rhg: /* CC-KPI-08 (Incorrect VWATD Calculation) */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (not incorporating any of the peer review alterations from by working group feedback in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

Given these do not incorporate any of the significant working group corrections, one would hope to see a further release that includes working group feedback prior to public consultation. Releasing old documents and claiming they have been peer reviewed is misleading, especially if the intention is to go to consultation with these (unreviewed) versions.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

[[File:Vwatdcalc.png|600px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD (CC-KPI-08) calculation, there is no need for complex AMR or data analysis.'''

[[File:Hntas-consumer-vwart.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-09-12T00:18:40Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (not incorporating any of the peer review alterations from by working group feedback in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

Given these do not incorporate any of the significant working group corrections, one would hope to see a further release that includes working group feedback prior to public consultation. Releasing old documents and claiming they have been peer reviewed is misleading, especially if the intention is to go to consultation with these (unreviewed) versions.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

[[File:Vwatdcalc.png|600px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD (CC-KPI-08) calculation, there is no need for complex AMR or data analysis.'''

[[File:Hntas-consumer-vwart.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-09-11T23:58:18Z

Rhg: /* CC-KPI-08 (Incorrect VWATD Calculation) */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

[[File:Vwatdcalc.png|600px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD (CC-KPI-08) calculation, there is no need for complex AMR or data analysis.'''

[[File:Hntas-consumer-vwart.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-09-11T23:57:57Z

Rhg: /* CC-KPI-08 (Incorrect VWATD Calculation) */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

[[File:Vwatdcalc.png|600px|left]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD (CC-KPI-08) calculation, there is no need for complex AMR or data analysis.'''

[[File:Hntas-consumer-vwart.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

File:Vwatdcalc.png

2025-09-11T23:57:32Z

Rhg:

VWATD Calculation

HNTAS

2025-08-17T13:05:20Z

Rhg: /* VWART, VWAFT & VWATD */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD (CC-KPI-08) calculation, there is no need for complex AMR or data analysis.'''

[[File:Hntas-consumer-vwart.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T13:04:49Z

Rhg: /* CC-KPI-08 (Incorrect VWATD Calculation) */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis.'''

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T13:04:19Z

Rhg: /* VWART, VWAFT & VWATD */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

'''It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis.'''

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T13:02:06Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis other than to calculate the VWAFT. Given that VWAFT at the consumer connection is meaningless for quality control (the common VWAFT at block/substation/EC is what counts), HNTAS only requires the removal of the consumer connection VWAFT KPI to be compatible with existing (slow) AMR systems.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:58:32Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

Any feedback on drafting errors is more than welcome - for example, thank you for picking up item 3 below, we will correct this in the next release of these documents. I would, however, like to flag that we are not seeking wider feedback or change proposals at this time, given that the documents have already been through an extensive technical market engagement process.

DESNZ

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis other than to calculate the VWAFT. Given that VWAFT at the consumer connection is meaningless for quality control (the common VWAFT at block/substation/EC is what counts), HNTAS only requires the removal of the consumer connection VWAFT KPI to be compatible with existing (slow) AMR systems.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:58:14Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

Any feedback on drafting errors is more than welcome - for example, thank you for picking up item 3 below, we will correct this in the next release of these documents. I would, however, like to flag that we are not seeking wider feedback or change proposals at this time, given that the documents have already been through an extensive technical market engagement process.
DESNZ

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis other than to calculate the VWAFT. Given that VWAFT at the consumer connection is meaningless for quality control (the common VWAFT at block/substation/EC is what counts), HNTAS only requires the removal of the consumer connection VWAFT KPI to be compatible with existing (slow) AMR systems.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:56:47Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

Note there are a number of technical errors in the published documents. Heatweb are notifying DESNZ & Ofgem regarding these.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis other than to calculate the VWAFT. Given that VWAFT at the consumer connection is meaningless for quality control (the common VWAFT at block/substation/EC is what counts), HNTAS only requires the removal of the consumer connection VWAFT KPI to be compatible with existing (slow) AMR systems.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:53:32Z

Rhg: /* VWART, VWAFT & VWATD */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

It should be noted that CC-KPI-07 states that either VWART or VWATD will suffice. This means that by using the correct VWATD calculation, there is no need for complex AMR or data analysis other than to calculate the VWAFT. Given that VWAFT at the consumer connection is meaningless for quality control (the common VWAFT at block/substation/EC is what counts), HNTAS only requires the removal of the consumer connection VWAFT KPI to be compatible with existing (slow) AMR systems.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:42:06Z

Rhg: /* Incorrect VWATD Calculation */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===CC-KPI-08 (Incorrect VWATD Calculation)===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:02:33Z

Rhg: /* Incorrect VWATD Calculation */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===Incorrect VWATD Calculation===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

The calculation for VWATD in HNTAS actually calls for both the VWAFT and VWART to be first calculated. This is very long winded mathematically and completely unnecessary.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T12:00:07Z

Rhg: /* VWART, VWAFT & VWATD */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===Incorrect VWATD Calculation===

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

Indeed, comparing the actual VWATD to the estimated VWATD (in HNTAS) will provide an indication of how accurate the estimated calculation is.

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost. The use in HNTAS KPIs of a more difficult to calculate estimation, rather than a simple to calculate exact answer, would indicate that the methodology is designed to benefit AMR systems that can read meters rapidly, when the reality is this is not needed.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-17T11:54:09Z

Rhg: /* VWART, VWAFT & VWATD */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost.

It should be noted that the HNTAS calculation for VWATD is incorrect mathematically. The given equation calls for a summation of flow temperature minus the return temperature multiplied by the flow rate. This will only provide an approximation, that will approach the correct figure as time slots used in the calculation reduce. However, it is far easier to calculate the precise WVATD using the totals for volume and energy provided by the heat meter.

VWATD = (KWh * 3600) / (4.2 * Litres)

[[File:Hntas-consumer-vwart.png|900px|none]]

[[File:Hntas-consumer-vwatd.png|900px|none]]

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

File:Hntas-consumer-vwatd.png

2025-08-17T11:46:18Z

Rhg:

VWATD

File:Hntas-consumer-vwart.png

2025-08-17T11:45:34Z

Rhg:

VWART

HNTAS

2025-08-16T12:39:50Z

Rhg: /* The Core Principals of Peer Review */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===VWART, VWAFT & VWATD===

Operational quality control relies on key KPIs in order to flag problems. The easier these KPIs are to calculate, the easier it is to implement quality control.

WVARTs and VWAFTs are very useful, however are difficult to calculate, requiring rapid data processing. For example, the average tap use lasts 10 seconds, so to calculate an accurate VWART requires processing (reading a heat meter) faster than this. However this is impossible, due to meter limitations and battery life, so we settle for inaccuracy. VWART calculations are best performed by the meters themselves on a second by second basis.

VWATD, by contract, is easy to calculate given just 2 meter readings (from the basic equation E = M x C x dT) and will flag the same operational defects as a VWART calculation.

To insist on VWARTs as part of HNTAS initially, will technically force a change of meters and AMR systems, when it is not a necessity. If HNTAS were to base its KPIs on VWATD then they would be compatible with existing metering systems and enable HNTAS to operate far quicker and at a much lower cost.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-13T17:14:00Z

Rhg: /* The Core Principals of Peer Review */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-13T16:59:13Z

Rhg: /* D-KPI-06 */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

===The Core Principals of Peer Review===
In the current proposals, it will be allowed for the same organisation to perform all roles, from designing a network, through to acceptance testing. It has been stated that 'peer review' can be performed by different departments within the same organisation, which not only makes a mockery of the meaning of the term peer review, but opens the door for errors in design to be waived through acceptance testing. If HNTAS is to operate as designed, it must be updated to introduce a clear separation (no commercial ties / common shareholders etc) between those involved in the design and delivery of a site, and those acceptance testing it. Proper quality control, by its nature, relies on a fresh set of eyes and in some cases specialist knowledge.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

Main Page

2025-08-06T22:32:07Z

Rhg:

{{IMGSL|ComparisonVWART.png | Lowest VWART in the first ever UK HIU Independent Tests|200|The DATA HIU}}
{{IMGSL|mbspage.png|Over 30 Years at the Cutting Edge|200|History of Heatweb Solutions Limited}}
{{IMGSL|The_DATA.png|The DATA Twin Plate HIU...quite simply the best HIU ever made|200|The DATA HIU}}
{{IMGSL|SPLIT.jpg|The DATA SPLIT Twin Plate HIU...taking the DATA and splitting it into two, to make installation easier|200px|The DATA SPLIT HIU}}
{{IMGSL|DIGI Hi Res.png|The DIGI Single Plate Direct HIU...following in the footsteps of the best HIU ever made|200|The DIGI HIU}}
{{IMGSL|Slim2.jpg|The SLIM DHW Only HIU...the DATA's little brother with a big punch. Possibly the smallest hi-output HIU ever made|200|The SLIM HIU}}
{{IMGSL|Ihiupic1.png|The IHIU Controller delivers a low cost, open-source controls solution for the Internet of Things|200|IHIU Control Systems}}
{{IMGSL|ImageWall2.jpg|The Cupboard HIU brings together all the domestic services in a modern modular approach|200|The Cupboard HIU}}
{{IMGSL|ImageADIS12.png|An in depth technical study of storage systems vs HIUs vs plant|200|Communal Heating and Hot Water Cylinders}}
{{IMGSL|Bmcamp.jpg|Our multi-purpose BoilerMaster range of HIUs now come with options for fiberglass external enclosures|200|The Boilermaster Range}}

This website is designed to be a repository for all information relating to the products and services, as well as a general resource for technical information. If you would like to become a contributor, with rights to edit and add articles, please contact the Administrator at rhg@heatweb.co.uk.

{{#ev:youtube|https://www.youtube.com/watch?v=6JpOmly38ao|900}}

The main sales website can be found here [[image:g12749.png|125px|www.heatweb.co.uk|link=http://www.heatweb.co.uk]]

[[Sign up to our newsletter]]

<big>'''[[HNTAS|HNTAS is here...]]'''</big>

<big>'''The [[Heatweb BEMS Controller]] - Available from January 2022'''</big>

[[File:laptopheatweb.PNG]] [[File:Hcon26a.PNG|500px]]

<pre>
Heatweb Solutions Limited (Registered Address).
61 Station Road,
Sudbury,
CO10 2SP
Tel: 0345 2411441
Email: enquiries@heatweb.co.uk
</pre>
<pre>
Heatweb Solutions Limited (Head Office).
Unit H1A Drury Drive,
Woodhall Business Park,
Sudbury,
CO10 1WH
Tel: 0345 2411441
Email: enquiries@heatweb.co.uk
</pre>
<gallery>
File:g12749.png|<div style="text-align: center">Heatweb Solutions Limited|link=https://www.heatweb.co.uk
File:Thermal-Integration.png|<div style="text-align: center"> Our History: Heatweb was formed in 2023 by former employees of Thermal Integration Limited, Part of the Specflue Group|link=https://www.heatweb.co.uk
File:dps3d.gif|<div style="text-align: center"> Our History: Dedicated Pressure Systems was bought by Thermal Integration in 2009|link=History of our business
File:ukdea.jpg|<div style="text-align: center"> A member of The UK District Energy Association|link=http://ukdea.org.uk
File:mehna logo website.jpg|<div style="text-align: center"> A member of MEHNA, Manufacturers of Equipment for Heat Networks Association|link=https://www.mehna.org.uk
File:Approved Product Logo.png|<div style="text-align: center"> WRAS Approved Products|link=http://wras.co.uk

</gallery>

'''<big><big>[[History of Heatweb Solutions Limited]]</big></big>'''

'''<big><big>[[Products]]</big></big>'''

'''<big><big>[[HIU Monitor Application Software]]</big></big>'''

'''<big><big>[[Service requirements]]</big></big>'''

'''<big><big>[[Guarantees and After Sales Backup for HIUs]]</big></big>'''

'''<big><big>[[Guarantees and After Sales Backup for Stainless Steel Cylinders]]</big></big>'''

'''<big><big>[[Product Datasheets]]</big></big>'''

'''<big><big>[[Standard Storage Data Sheets]]</big></big>'''

'''<big><big>[[Heatweb Online Store]]</big></big>'''

'''<big><big>[[HIU Testing Standards]]</big></big>'''

'''<big><big>[[Heat Network Calculator]]</big></big>'''

'''<big><big>[[Support]]</big></big>'''

'''<big><big>[[Special:AllPages|Index]]</big></big>'''

==Literature==
We have launched a system to pull articles together into booklets on a particular subject and generate them in a PDF format. Some of them are shown below:

----
'''<big><span style="color:darkblue">Brochures</span></big>'''
----
{{PDFsum|Thermal Integration Product Range|EB17Cover.jpg|A summary of our main products.|http://www.heatweb.co.uk/w/images/7/79/TIL_Thermal_Integration_District_and_Renewable_Systems.pdf}}
----
{{PDFsum|The Amazon District|Cover_azd1.jpg|Unvented hot water storage fitted within a pre-fabricated frame.|http://www.systemdesigner.co.uk/wikiPDFs/TIL_Amazon_District__Product_Manual_AD1.pdf}}
----
{{PDFsum|The HIU Revolution|Cover_data.jpg|How our HIU technology managed to beat all the competition by a country mile.|http://www.systemdesigner.co.uk/wikiPDFs/TIL_PDF_Binders__The_HIU_Revolution.pdf}}
----
{{PDFsum|IHIU Systems|Cover_binary1.jpg|Information on our IHIU technology used to provide electronic control and monitoring of domestic services.|http://www.systemdesigner.co.uk/wikiPDFs/TIL_IHIU_Systems__IHIU_General_Information.pdf}}
----
{{PDFsum|Monitoring Applications|Cover_binary1.jpg|Information on technologies used to provide remote monitoring of domestic services.|http://www.systemdesigner.co.uk/wikiPDFs/TIL_IHIU_Systems__Monitoring_Applications.pdf}}
----
'''<big><span style="color:darkred">Installation Instructions</span></big>'''
----
{{PDFsum|Installation Instructions for the Data HIU|Cover_data.jpg|Comprehensive installation manual for the twin plate DATA HIU.|http://www.heatweb.co.uk/w/images/5/55/TIL_PDF_Binders_Installation_Instructions_D3.pdf}}
----
{{PDFsum|DIGI User and Installation Manual|DIGI_UI_Manual.png|Comprehensive installation manual for the single plate DIGI HIU.|https://www.heatweb.co.uk/w/images/f/f4/DIGI_Installation_Instructions_Rev2.pdf}}
----
{{PDFsum|SLIM User and Installation Instructions|SLIM_IU_Manual.png|Comprehensive installation manual for the DHW Only SLIM HIU.|http://www.heatweb.co.uk/w/images/d/d3/SLIM_User_and_Installation_Instructions.pdf}}
----
{{PDFsum|SLIM Extra User and Installation Instructions|cover_SLIM_Extra.jpg|Comprehensive installation manual for the SLIM Extra HIU.|http://www.heatweb.co.uk/w/images/7/71/The_SLIM_Extra_HIU_Installation_Instructions_SE2.pdf}}
----
{{PDFsum|DATA SPLIT User and Installation Instructions|Cover_DATA_SPLIT.jpg|Comprehensive installation manual for the twin plate DATA SPLIT HIU.|http://www.systemdesigner.co.uk/wikiPDFs/TIL_The_DATA_SPLIT_HIU__Installation_Instructions_DS2.pdf}}
----
{{PDFsum|HEATBANK Xcel Installation Instructions|multifuel.jpg|Comprehensive installation manual for the HEATBANK Xcel thermal Store.|https://www.heatweb.co.uk/w/images/b/ba/Xcel_Instructions_Rev3.pdf}}
----
'''<big><span style="color:darkgreen">General</span></big>'''
----
{{PDFsum|Thermal Integration Guarantees and After Sales Backup for HIUs|Warranty Front Page.jpg|Warranty Terms and Conditions.|http://www.heatweb.co.uk/w/images/f/f4/Guarantees_and_After_Sales_Backup_for_HIUs_0617.pdf}}
----
*[https://www.heatweb.co.uk/w/index.php?title=PDF_Binders All PDF Binders]
----
*[http://www.systemdesigner.co.uk/wikiPDFs All Thermal Integration Wiki PDF's]

==Useful Pages==
*[//www.heatweb.com/wiki/index.php?title=Product_Documentation_Links Product Documentation Links]
*[//www.heatweb.com/wiki/index.php?title=Special:NewPages New Pages]
*[//www.heatweb.com/wiki/index.php?title=Special:PopularPages Popular Pages]
*[http://www.heatweb.com/wiki/index.php?title=Special%3AAllPages&from=&to=&namespace=0&hideredirects=1 All Pages]
*[//www.heatweb.com/wiki/index.php?title=Special:Categories Pages by Category]
*[//www.heatweb.com/wiki/index.php?title=Special:Preferences Personal Preferences]
*[//www.heatweb.com/wiki/index.php?title=Editing_the_Heatweb_Wiki The basics of editing the Heatweb Wiki] (for Administrators)
==Web Sites==
* [//www.heatweb.com Heatweb]
* [//www.heatweb.com/frontlogo2.html Old Heatweb site]
* [//www.systemdesigner.co.uk System Designer]
* [//www.heatweb.com/wiki Heatweb Wiki]
* [//www.specflue.com Specflue - partner site]

HNTAS

2025-08-06T22:29:21Z

Rhg: /* HNTAS Evaluation */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Heatweb and HNTAS==

Heatweb provide a number of services related to HNTAS and general Quality Assurance:

* Fault and non-compliance identification.
* Acceptance testing
* Database hosting with ingest of data from both BMS and ARMS
* Data visualisation and an extended HNTAS set of KPI functions
* Alarm routing
* System optimisation
* Commissioning services
* Preventative maintenance

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-06T22:05:47Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks. If will be enforced by Ofgem, as a legal requirement on construction and network operators to meet all targets (KPIs).

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member, representing manufacturers in the DHC industry under MEHNA (Manufacturers of Equipment for Heat Networks Association).

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-06T22:00:11Z

Rhg: /* Key Points */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks, most notable the ''Quality Assurance Inspections of Installations'', where the most valuable inspections will be the first completed properties with heat on, or any other critical moments where errors in the design and/or installation can be caught before it is too late.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-06T21:54:49Z

Rhg: /* Key Points */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments. Indeed, the assessment process diagram includes boxes (white) for these constructor-side quality checks.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-06T16:57:16Z

Rhg: /* Key Points */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* In order for a final assessor to be confident enough to accept lower levels of acceptance testing, the constructor must be passing all checks first time. This highlights the benefits of having one's designs, processes and works checked in advance by an independent expert who is unconnected to the design or final assessments.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T22:49:16Z

Rhg: /* Critique on Draft Release */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T22:45:13Z

Rhg: /* Key Points */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies and bias, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T22:40:21Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed by working group in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T22:39:34Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents (peer reviewed in June 2024) have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T17:43:03Z

Rhg: /* Implementation of Heatweb MQTT Protocol */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T16:28:15Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as follows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Implementation of Heatweb MQTT Protocol==

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Schema_id / Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

my_schema/chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
my_schema/chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T16:27:52Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents reference the body of work generated in working groups, soon to be released.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Implementation of Heatweb MQTT Protocol==

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Schema_id / Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

my_schema/chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
my_schema/chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T16:25:39Z

Rhg: /* About HNTAS */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents lack the body of technical work generated in working groups, some of which remains contentious.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Implementation of Heatweb MQTT Protocol==

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Schema_id / Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

my_schema/chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
my_schema/chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T13:02:45Z

Rhg: /* Implementation of Heatweb MQTT Protocol */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications are late to be released, and contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents lack the body of technical work generated in working groups, some of which remains contentious.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Implementation of Heatweb MQTT Protocol==

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Schema_id / Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

my_schema/chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
my_schema/chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T13:00:39Z

Rhg: /* Implementation of Heatweb MQTT Protocol */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications are late to be released, and contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents lack the body of technical work generated in working groups, some of which remains contentious.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Implementation of Heatweb MQTT Protocol==

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T13:00:09Z

Rhg: /* Schematics of Meter Locations */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications are late to be released, and contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents lack the body of technical work generated in working groups, some of which remains contentious.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

===Implementation of Heatweb MQTT Protocol===

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T12:59:12Z

Rhg: /* Point Naming for MQTT and PostgreSQL */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications are late to be released, and contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents lack the body of technical work generated in working groups, some of which remains contentious.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location. Data can then be operated on, and visualised in Grafana or Power BI using a standard SQL statement.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.

HNTAS

2025-08-05T12:53:17Z

Rhg: /* Point Naming for MQTT and PostgreSQL */

==About HNTAS==

The Heat Network Technical Assurance Scheme is the new quality control scheme for regulating heat networks.

Heatweb have sat on the HNTAS technical group contributing to material. Our technical director is listed as a working group member.

HNTAS is at a point where a set of draft KPIs are listed in detail, and a large number of technical points have been discussed in working groups with agreement on a large portion of the suggested requirements.

As of August 2025, 2 sets of documents have been released as f0llows:

* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-technical-specifications Technical specifications]
* [https://www.gov.uk/government/publications/heat-network-technical-assurance-scheme-hntas-assessment-procedures Assessment procedures]

The technical specifications are late to be released, and contain general information, meter point definitions, KPIs relating to metering, and tolerances on KPIs.

These documents lack the body of technical work generated in working groups, some of which remains contentious.

==Key Points==

* Whilst this release contains very little of the technical material supporting HNTAS, it spells out clearly the form of quality control to be implemented in heat networks moving forwards, with a heavy reliance on metering, data, and staged checking that parties are complying to the current technical standards (i.e. Meter regs, CP1 etc.). This is a giant leap with wide reaching implications for the industry.

* The levels of assessment is decided by the assessor, based on a classification of how well constructors are doing. A minimum percentage of properties will need to be fully acceptance tested if commissioning processes and outcomes are all up to par.

* A full change-log and evidence trail must be kept. There has never been a better time to review your paperwork processes, especially those that sub-contractors are using for commissioning and tracking snags.

* You need to get your metering reviewed, will the listed meters in the listed places (so secondary and primary meters on substations etc).

* You need to make sure your AMRS provider is feeding you ALL meter data, so you can perform calculations such as secondary pipework losses. At the same time you need specific BMS data points, such as gas meter data, or DPs. Then you need to combine this data, from different sources (100% error free), to perform KPI calculations.

* Be wary of vendor lock, whereby crucial data points from either BMS or AMRS can be held to ransom. KPI reporting generally needs to be submitted monthly. Open metering protocols such as wireless or Lorawan M-Bus will satisfy both encryption of data and open-protocols, or it should be terms of any AMR contract to provide for unrestricted access to live meter data by the network operator.

* You need your BMS controlling to setpoint, and handling changeovers without going out of the 3C tolerances.

* There are quality control and assessment stages required to be performed by the constructor, and by the client (and Ofgem). These are shown below. For HNTAS to function in the public interest, at least two independent and suitable qualified assessment providers must be used. There is already with CP1 assessments examples of inconsistencies in the assessment of works and equipment linked to commercial partners versus others, so it is important for DESNZ and Ofgem to enforce the rules of impartiality and peer-review in a far more robust and transparent way than they have to date.

[[File:Hntas assessments.png|900px|none]]

==Critique on Draft Release==

As a listed working group contributor in these documents, it is disappointing that this first release was not first checked with the working group for errors or opinions, both of which are listed below.

===Tolerances===
The KPIs, with crude tolerances of “3C” most commonly, are open to abuse, whereby reasonable fluctuations in temperatures could be interpreted as a failure by one acceptance tester and be seen as perfectly acceptable by another. While training will help increase knowledge regarding acceptable modes of operation, it cannot protect against deliberate abuse.

There will need to exist a process for a fully independent second opinion and a route to appeal against poor decisions by acceptance testers. As part of the standard process, stakeholders should be able to review and question the acceptance processes prior to application, and to witness any acceptance tests.

===CC-KPI-03===
CC-KPI-03 should be explicit in the requirement that operating as expected includes “All points read by the ARMS are also readable, in a timely fashion, by the network operator, typically via a controls head end, API or publish/subscribe transport layer.”

Where an AMRS provider fails to make meter data available it will be impossible to perform client-side calculations of all HNTAS KPIs, including distribution pipework losses. In turn this could make it very difficult to combine metering services from different providers on district networks.
The emphasis should be on the provider to ensure that data is made available to the owner-operator, in a recognised format of the operators choosing, without delay, and that there are no barriers, technical or financial, to the [secure] transport of all required data.

I would like to draw attention to the implications of a 100% KPI requirement, whereby every single data point must be error free to comply with HNTAS. If a single point gets through out of limits, then this KPI has failed. With a potential of thousands of meter points in a network, there will inevitably be component failures or human error by service personnel. Networks are at peril of technically being in a state of continuous failure to meet HNTAS KPIs. Errors in data will drive remedial works, and 100% of errors should be attended to in a timely fashion. A caveat may be added to permit erroneous data points a maximum of one month [out of limits] before triggering a KPI failure.

===CC-KPI-10===
CC-KPI-10, regarding primary return temperature during DHW operation, erroneously refers to space heating operation.

===D-KPI-06===
D-KPI-06, regarding communal pipework losses, requires the combination of data from both bulk meters and from residential meters, and as such may be incompatible with certain ARMS providers who do not facilitate the transport of live meter data to the owner-operator. This may render KPI calculations impossible where data from multiple ARMS providers needs to be combined, forcing a vendor lock and monopolistic position to an incumbent provider.
In order to protect consumers best interests, a situation should not be permitted to exist where an ARMS provider can withhold meter data that may result in an owner-operator unable to perform and submit a full set of HNTAS KPI calculations as required, or to operate their own operational alarming.

==Monitoring Points==

===Schematics of Meter Locations===
[[File:ECpoints.png|640px]]

[[File:Districtboundaries.png|640px|none]]

[[File:Hntas ss.png|640px|none]]

[[File:Hntas communal.png|640px|none]]

[[File:Hntas consumer.png|640px|none]]

==Point Naming for MQTT and PostgreSQL==

The published meter point identities can be implemented in the Heatweb MQTT standard as follows:

Topic:

Network_guid / location_id / device[-component]_id / data_grouping / data_key_name = data_value

E.g. Substation 1 for block A will require 2 meters. The return temperatures (used in the KPI calculation for approach temperature) will work on the following points:

chessington_dhc_12/block_A/subSt-SS1/hmeter/temp_return
chessington_dhc_12/block_A/subSt-SS2/hmeter/temp_return

These points will be ingested into an SQL database as a latest reading, and in a time-series table unique to the location.

Latest value:

SELECT * FROM schema.readings WHERE network='chessington_dhc_12' AND node='block_A' device LIKE 'subSt-SS%' AND vargroup='hmeter' AND varkey='temp_return';

Time series:

SELECT * FROM schema.chessington_dhc_12_block_a WHERE device LIKE 'subSt-SS%' and varkey LIKE 'temp_return';

==HNTAS Evaluation==

Heatweb have started to run field trials on existing networks in order to implement HNTAS KPIs through the existing BMS, with a view:

* Proving HNTAS KPIs can be implemented using existing technology and open protocols.
* Evaluating the effectiveness of KPI calculations on real world data, where for example, reporting by exception (change of value) is common.
* Providing open-source libraries for implementing HNTAS and quality control processes.
* Extending HNTAS to include a great deal that is missing due to the silo nature of the working groups, and a lack of time for proper peer review and expertise contributions from outside the working groups.

The following is a screenshot from a live HNTAS Extended dashboard. It shows calculated on-the-fly HNTAS KPIs, as well as other KPIs that highlight system problems.

If readers are interested in test driving HNTAS KPIs, the following system can be setup via Trend IQ Vision. If remote access can be provided, there may be no need for site attendance.

[[File:Hntaskpis1.jpg|1200px]]

== KPIs on Field Trials==

===EC-KPI-01===
<pre>
Automatic remote monitoring system (ARMS) connectivity
Total number of days where monitoring points has connected to the ARMS system within 24 hours of last connection.
(Number of monitoring point days) / (total monitoring points * total days in period)
Number of monitoring point days = Σ number of days each monitoring point has connected to the ARMS system within 24 hours of last connection.
Assessed KPI
Commissioning stage: 100% O&M stage: ≥ 99%.
Monthly
</pre>

* 100% over 1 month is meaningless. Same as 100% over any time period.

===EC-KPI-02===
<pre>
Energy Centre monitoring point data completeness
Number of total reads received in comparison to the total reads expected within the given [time period] for each monitoring point.
(Total number of reads recorded across [time period] / total reads expected across [time period]) x 100
Total reads expected = Σ (monitoring point x frequency of monitoring point x [time period])
Assessed KPI
≥ 95%.
Monthly
</pre>

* Reads will often be faster than expected, which as a threshold for failure will be slower than actual capability. As a result, KPI does not allow for gaps in data - incomplete data. This has been adjusted to work in the same way as EC-KPI-01, except with the time period set to 5 minutes, rather than 24 hours. As such, at least one reading needs to be seen each time slot.
* When reporting by exception on change of value, certain values will not change when circuits are at rest. This drops the KPI rating when there is no problem. For heat meters, for example, as long as temperature data is coming through reasonably often one knows the reading processes are in order, and a lack of flow rate data should not imply a system failure. Instead, we would base completeness on temperature data at least every15 minutes (as 0.1C fluctuation is always seen over 15 minutes). A failure on flow data, such as a failure in flow rate reading, is better caught through stale data for a day or more, or large steps in values. Reporting by exception may result in gaps (as one would hope) but any actual readings then get caught when values change, and providing the change in value is minimum expected change of value, all is good. This requires more a complex KPI function, however allows standard reporting by exception to be used without resulting in misleading HNTAS KPI failures.

===EC-KPI-03===
<pre>
Energy Centre monitoring points operational
Of the monitoring points which are connected to the ARMS system (as per EC-KPI-1) and have complete data (as per EC-KPI-2), the number of which are operating as expected.
Monitoring points that are operating as expected will have (dependent on type of monitoring point):
1. No error codes (meters)
2. No negative readings (meters)
Verification that each monitoring point is operating as expected.
Measurement will be dependent on ARMS and may be automated.
Assessed KPI
100% of monitoring points, which are connected to ARMS (as per EC-KPI-1) and have complete data (as per EC-KPI-2)
Monthly
</pre>
* What does an error code that is fixed then imply? What does a month mean - is a month of complete healthy data required to pass? As soon as any error code is seen there is a fail, regardless of timescales.