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:

• Technical specifications
• 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.

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.

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

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.

KPIs on Field Trials

EC-KPI-01

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

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

EC-KPI-02

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

• 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

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

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