3. Heat networks can reduce cost and carbon…
(sharing larger, lower cost, lower carbon heat sources is a sound concept)
4. ...though many being deployed are a disaster
• Atrocious specifications and designs
– Accidental and willful
• Appalling installations
– Impossible designs and willful omissions
• Questionable financing models
– Developers, ESCOs, and proprietary hardware service fees
• Price gouging and outright refusal to supply
– Feasibility says yes but supply chain says no
(don’t under estimate how difficult these are in a commercial environment)
9. 4G: wet system performance a solved problem
4G heat network, Lystrup, 2010
http://www.danfoss.com/newsstories/heating/2015-whitepaper-creating-energy-efficient-heating-systems/?ref=17179887299#/
http://www.danskfjernvarme.dk/~/media/danskfjernvarme/gronenergi/projekter/eudp-lavtemperatur%20fjv/guidelines%20for%20ltdh-final_rev1.pdf
10. 5G: are smart heat grids cheaper and easier?
• Use more extensive control to:
– Load shift (reduce the capacity needed)
– Optimise operating strategy (increase efficiency)
– Automate system commissioning (idiot proof)
– Handle all retail operations (reduce overheads)
• Beat individual gas boilers on cost and carbon
– At 3,000-9,000 kWh/year and 20-250 home scale
(ASHP base load and gas boiler peaking on small networks but smart grid is agnostic)
11. Phase 1: What’s the baseline? What might 5G networks achieve?
(£28,650)
12. What capacity is required?
https://www.studentlitteratur.se/#9789144085302/District+Heating+and+Cooling
13. Which hot water recipe?
• Say 50 homes @ 70 m2 each with 3.5 occupants
• SDHA: 115 kW
– F101:2008 lookup table: 0.61 Litres/sec at 10/55C = 115 kW
– F101:2004 has the equation for deriving the table
• DS439: 210 kW
– 1.19*50+18.8*500.5+17.6 (kW)
– Note this is heat exchanger size not expected load. For standard (mansion) apartments…
• BS6700:2009: 450 kW
– ~450 kW if 32.3 kW per home.
– BS6700 is withdrawn/replaced by EN 806. The negligent still use it…
https://www.ds.dk/en
http://www.svenskfjarrvarme.se/In-English/District-Heating-in-Sweden/Technical-requirements-/
14. Take field data from Energy Saving Trust (2006)
https://www.gov.uk/government/publications/measurement-of-domestic-hot-water-consumption-in-dwellings
15. Perform statistical analysis to size network
• Blue columns
– “What % of the time
is spent at this power
output? (zero power
removed for clarity)
• Red curve
– “What % of the time
(when there is any
hot water use) is the
hot water power
lower than X kW per
home?
16. Calculate for a range of N and sample periods
N choose r, compute for selected N for a variety of sample periods
17. Plot power required for N homes
0.0
50.0
100.0
150.0
200.0
250.0
1 10 100
Power(kW)
Number of homes
DS439
EST 5-sec
REDAN
SDHA
EST 5-Min
21. Phase 2: Can it be implemented? Does it work as expected?
(£349,860)
22. We wanted to…
• Know what customers are asking for
• Know what the whole system is doing
• Know what customers are receiving
• Control how the whole system operates
39. Real time control
• What is the system being asked for now?
– Interrupt driven
– Integrated with service level policy
• Create a plan
– Quickly and reliably
– Handles constraints
• Implement the plan
– Delegates control authority as necessary
42. Predictive control
• Where am I now?
– Historic data, physics model, state estimator
• What am I being asked for next?
– Heating schedule, keep-hot schedule
• What else matters?
– Weather forecast
– Hot water demand forecast
– Cost model for consumer comfort / tapping delays
– Cost model for operating the network
• What should I do next?
– Calculate a plan for the real time planner to implement
– Share the plan with other services on the platform
47. 5G implications for sizing (small and cheap)
12 homes, 120 metres
20 mm ID, 500 kPa peak dP
Peak space heat @ 55/35
Peak DHW @ 55/25
48. 5G implications for performance (excellent)
Figure LCA-BAD LCA-OK LCA-GOOD Interim Full Year
Boiler
efficiency
92% 95% 98% 89.5% 92%
Heat pump
COP
3.5 4.0 4.5 3.6 3.8
Distribution
losses
45 kWh/m/yr
(412 kWh per
home per yr)
40 kWh/m/yr
(367 kWh per
home per yr)
35 kWh/m/yr
(320 kWh per
home per yr)
11% 14.7%
(457 KWh per
home per yr)
Pumping cost 1.6% 0.9% 0.2% 0.4% 0.6%
Typical usage 3,100 kWh per home per year (£186 at £0.06/kWh; actual cost <£0.03/kWh)
(caveat: very very low heat density site – 0.4 MWh per metre per year)
49. Key conclusions
• Smart heat networks worked exactly as expected
– Allow up to 50% reduction in installed capacity vs. dumb networks
– Can substantially reduce operating overheads and the expertise required to deploy and operate heat
networks; especially for small scale developments
• Low heat density is ok with smart heat networks
– The addressable market for heat networks could be larger than previously anticipated
• Low temperature heat networks work in retrofit
– These are viable for much of the existing housing stock not just new build
• Sizing remains an issue for designers
– Designing for intermittent heating at design condition is suboptimal…but encouraged by BREDEM (SAP) and
needs fixing by including time/rate of energy use in the model.
– Designing to accepted standards significantly overestimates hot water loads…we need a new national
standard derived from defensible primary data from a relevant sample of dwellings.
• Quality of Service needs further consideration
– There is a tradeoff between responsiveness and efficiency. This needs defining and considering when
evaluating heat network performance
(join https://groups.google.com/forum/#!forum/dhc-discussion to talk more)
50. Next Steps
• Produce citable national dataset/standard for sizing
– R&D call (£1.5m, 3 companies/projects, 1,500 homes total)
• Define ‘Quality of Service’ and build a reference base
– Could be an extension of the call for datasets. To include boilers.
• Revisit radiator control, balancing, and space heating control
– Radiator valves and space heating strategies need more work.
• COHEAT will commercialise this operating platform
– Use for retail first, then monitoring, then control when proven…
– …and there are interoperable, interchangeable, competitors
• Supply chain is already delivering compatible wet hardware
(don’t neglect the non-tech: the practicalities of mass retrofit are worth considering)
53. Why is competition important?
http://oms-group.org/en/
https://www.london.gov.uk/sites/default/files/renew_heat_metering_billing_presentation_final.pdf
Not openOpen
54. Open hardware prepayment (now)
Motorised valve
(230V)
Heat meter
(M-Bus)
Relay
(M-Bus)
One flat (of many)
56. Route to market
(create an interoperable ecosystem to reduce the cost, risk, and complexity of heat networks)
Image credit: DeviantArt artmanphil
Editor's Notes
COHEAT, a small tech company based in Cambridge providing Software-as-a-Service to help people operate energy infrastructure.
This SBRI call effectively created our company. It did it’s best to kill us too!
Soapbox
Aims and objectives
Fly through technical so those interested can ask questions and others can see you got value for money
Learnings and next steps
Heat source, distribution network, and wet hardware with the home.
Somebody then has to run this. It isn’t easy and the overheads of setting up such an operation are substantial and prohibitive on smaller networks. Keep in mind that the typical new build scheme is 50 homes and the typical heat network being reported to BEIS is about 50 homes too. District scale projects are rare.
The operation side of the business needs backoffice processes and infrastructure. Automated meter reading is now the norm. The UK is very prepayment happy for a number of legal reasons, which means we can’t simply copy what the rest of Europe does.
Heat networks have been around for a while and the world knows how to do these.
The world knows how to design efficient heat networks. The reputable manufacturers produce excellent materials and provide free training. The products you need are actually very simple and easy to use.
Commercial interests screw this up – wanton over-specification is rife yet suits contractors (installing more stuff that you don’t need), distributors (selling more stuff that you don’t need), and service providers (selling more stuff that you don’t need).
Hopefully as the industry grows it will also consolidate and the need to increase revenue will mean needing to increase the number of heat networks being deployed and this will incentivise the remaining players to prioritise growing the market rather than milking it.
Dumb networks are a good starting point.
Could we go to town on that data infrastructure that you’re going to have to deploy anyway and run a full blown smart heat grid?
Buy this book.
Note this is for 3.5 occupants not 1.
DS439 can be recalculated according to the number of occupants and fixtures but it’s an extremely rare consultant that can stand up and truthfully say ‘calculated in accordance with DS439’ – most don’t own a copy, have never read a copy, and blindly regurgitate misinformation they saw in a brochure once and were too sloppy to verify. Including very big names.
Thanks DEFRA.
Can’t get this from the majority of heat meters. Certainly can’t get it from commercial AMR systems.
Blue is for boiler rooms and buffer vessels.
Red is for pipes.
This tells us how frequent the data really needs to be in order to get an answer.
For 5 hones, 5 sec vs 5 minute is the diffrence between 8 and 12 kW per home. Big deal. There’s negligible difference by 40 homes though.
The design of the new Kamstrup 403 heat meter, with it’s M-Bus that can be read every 10 seconds, data link at 19.2 kbit/sec not 2.4 kbit/sec, and a special short technical M-Bus telegram, is pretty much spot on for capturing diversity.
This was helpful but work remains to make this citable
Note HIU losses excluded from useful heat delivered.
Some think that these are useful. A quick look at the facebook group of irate consumers should explain why we make these up as storage and distribution losses.
I’ve highlighted non-value-adding activities overheads that are disproportionately costly on smaller schemes
Big section in the report on the key assumptions behind this. Please play with the tool.
That cloud represents the most complex bit of what we did - building a smart grid that can see and control everything from the radiator back to the utility supply in real time.
We rolled our own because nothing suitable was available commercially at the time that was able to provide secure real time control.
Everything is built on internet technologies. The same authentication, encryption, messaging, load balancing, and database technologies that were developed and made freely available within the last decade by the likes of Google and facebook.
Unlike the SCADA systems in nuclear and chemical plants this is secure, extensible for interoperability with other services, and future proof.
You don’t need this any more. It’s just a webpage that can be served up on any internet connected devices.
Instrumenting and controlling radiators remotely isn’t a solved problem yet. We asked Danfoss and even they have nothing that could measure or control what we wanted. Rolling our own proved invaluable but painful.
Though we had to make these this time, we don’t have do make these yourself any more because more than one HIU manufacturer is making exactly what we asked for.
Much same spaghetti for the heat pump, boiler, and energy centre.
If the cloud represents everything that was complex then installing an experimental heat network on a construction site and the pleasures that come with this was the most brutally hard work I’ve ever done.
Chainsaws to clear the site. Incinerators and glyphosphate for the knotweed. Stihl saws and a towrope in the cover of darkness to take out some iron mine workings. And then the contractors arrived…
The cost overruns almost bankrupted us and the time overruns from the basic pipes on walls were never recovered.
This layout has a heat density equivalent to FEES specification properties at 35 homes/hectare. This is your archetypal suburban Barratt type newbuild.
Note hot water requests too.
Note non heat meter data
Secondary sensing
Radiator balancing. This is an absolute pig. Continentals mask the symptoms using TRVs and a continuous heating strategy. This isn’t an option here.
Privacy is something to consider. Usually at 19C but it’s 22C this Saturday night, the shower took longer than usual, the bedroom was more humid than usual, and there were two showers the following morning? Hmm. Stopping at the HIU and knowing that ‘all is ok’ or ‘something is wrong’ but not the details of each room might not be so daft for other reasons.
Folks with a duty of care all over this
Nothing happens by accident on a smart heat grid.
Instead of allowing the pipes to decide what happens when constrained, allow the system to decide, this makes hitting that constraint more acceptable and more acceptable to hit it more often.
Control and billing are an integrated system. The billing system will instruct the real time planner to restrict service levels (prepay) and can pass priority information to the real time planner. (granny is more important than students; but the pikey students on the economy tariff with a lower return temperature or flow limit and no keep-warm enjoy a lower tariff than the penthouse on the premium tariff; and the penthouse can have hot water at 50C but vulnerable granny is only allowed 43C by her social landlord)
Predictive control is about avoiding constraints in the first place. And about minimising the operating cost of the network.
Applying a fresh PhD thesis from Lund University in production resulted in the highest temperature we’ve ever recorded on this network – 82C on processor core 3. The student hadn’t checked how the problem scaled and the techniques proposed quickly became intractable. Cue some proper computation/scalability related software engineering.
Revising the architecture for tackling the problem allowed network-wide optimisation whilst scaling linearly in computation time with network size.
“You run this in production?” exclaim the academics.
“The result looks like optimum start with weather comp” note the operators.
The real time planner with some very basic algos gets very close. Probably only worthwhile on much larger networks.
This is an evolving industry.
There’s lots of miscellaneous kit out there that doesn’t work together and is a pig to operate at scale.
We’re working for the operators as benevolent administrators providing an open platform to run whatever kit was fashionable that year or the developers threw in because it was on special that week.
By making both the hardware - and ourselves - functionally interchangeable this will standardise how this industry operates so that the big corporates with access to capital can actually scale it and government can regulate it.
Some hardware vendors were very enthusiastic from the outset. Others are less keen but see the end game and would rather collaborate than compete. Some will fight to defend their gate fees tooth and nail. The journey to a regulated utility is going to be fun! :-)