CP1 Compliance

From Heatweb Wiki
Revision as of 20:20, 21 September 2019 by Rhg (Talk | contribs) (Sheet 1)

Jump to: navigation, search

This article covers the process of handing over a development fitted with HIUs to CP1 requirements.

CP1.1 is now (September 2019) in final draft stage, with no more adjustments to be made other than typos. So we are in a position to tackle our first fully CP1.1 compliant heat network, and nail down the requirements, documents and processes involved.

Our goal is to use our network of IoT connected HIUs (the computer, as referred to throughout this article) to simplify the process, embedding as much of the donkey work as we can into software in order to reduce the labour requirements and remove human error from the scene if possible.

CP1.1 Documents

Some of the documents referred to have not been released just yet.

  • CP1.1 Code of Practice
  • CP1.1 Checklists

However, as the checklist for HIUs is guidance - a minimum standard - we can get to work without hesitation.

HIU Commissioning Checklists

The entire compliance process is driven through the use of checklists. Checklists are provided in CP1.1 for all stages of a heat network design and build, however we are concerned here with the final pre-handover checklists that prove an installation is working to design.

As we are using connected HIUs with realtime data analysis, we will be updating the current example checklist into an active document, that can be read by both humans and computers without confusion. Where the current checklist is designed to be A4 printable, we will dispense with that limitation as computers have the ability to reformat reports as seen fit (i.e. we could generate the bog standard checklist sheet automatically if needed).

The first change will be to split the sheet based on who fills it in. So there will be sheets for

  • the designer
  • the installer
  • the commissioning engineer
  • those responsible for operation and maintenance
  • and potentially the client (GDPR, satisfaction, contact details for alarms)

Further sheets will be generated by the computer arriving at a final simplfied checklist (in A4 format) that combines all properties in a building.

We need to know more information that the current checklists call for:

  • design settings
  • all equipment settings
  • operational limits
  • alarm routes (email addresses and telephone numbers)
  • plot numbers
  • serial numbers
  • usernames and passwords for the computer

Data in Hand

Before commissioning starts we have some cross-referenced data provided during the HIU manufacturing process:

  • HIU serial number
  • HIU controller id
  • heat meter serial number
  • factory contract settings

This data comes in handy for a number of reasons, with the main one been locating kit whilst allowing for engineers making mistakes in recording serial numbers.

You rarely see a long list (i.e. hundreds) of serial numbers recorded by hand that don't have typos. 6 as b, 0 as O, 3 as E, or one missing. Such errors usually require some effort to isolate (from missing known ids) however it is possible to overcome by cross referencing two known serial numbers, namely the HIU serial number and the meter number. Both the factory and the commissioning engineers record both, alongside the plot number, meaning that a commisisoning engineer has room for one typo per system. In the first use of the system on 170 properties, 8 typos were recorded, however 100% of systems were linked automatically by the computer.

Documents and The Protocol

We use two key documents.

  1. An Excel Spreadsheet in .xls/.xlsx formats that contains the human input. This is based on plot numbers, and is used as a tracker document by site managers. The workbook can be emailed to the computer to update records.
  2. An Excel Spreadsheet in .xls/.xlsx formats that contains the factory (manufacturer) input.

We have found that spreadsheets are already the most common tool for such things, and if formatted in a computer friendly way (with the first row containing defined field names) then the human and computer systems can keep track of each others work without further effort.

This is where The Protocol comes in, or more specifically the Heatweb Heat Network Open Protocol on GitHub. This open source library defines the tags (first row in the spreadsheet) to be used for various elements in a heat network. The protocol is designed for this very purpose, and has grown to cover HIUs, sub-stations, and energy-centres already in the field.

The project can be found at https://github.com/heatweb/heat-network

Generally speaking, however, the tags need not every be seen, and can sit in the first row of template spreadsheets provided for human use. One just needs to know they are there, and not to delete them. Note that managers can add their own columns, which are not pre-defined, and they will simply carry through into the commissioning database held in the computer.

Sheet 1

The following sheet template is provided to the designer for completion.


This sheet provides a comprehensive set of default and custom settings for every property, using default types to reduce the number of entries (and potential errors) required.

It is imported into the computer, the gaps are filled in using default settings, and as HIUs come online they can be automatically be setup to these requirements. An entry on our final checklist will represent correct setting of all systems to this schedule.