A district heating network must meet a heat demand that depends on weather and behaviour, with a mix of CHP units, boilers, heat pumps and storage whose economics change hourly with power and gas prices. ML forecasts the heat load; a mathematical solver (MILP) picks the cheapest, lowest-CO2 plant schedule; and temperature optimisation lowers network losses and makes room for waste and renewable heat. Pilots report better forecasts and lower fuel use, but gains depend heavily on data quality.
Problem & value
- Today: dispatch is often planned by experienced dispatchers using rules of thumb, static temperature curves and day-ahead spreadsheets. CHP units are run for heat, while power-market prices and storage are only partly exploited. Operators in Germany are also under pressure to decarbonise and integrate heat pumps, solar thermal and waste heat.
- AI value: more accurate heat-load forecasts reduce reserve margins and start/stop cycles; optimisation across heat, power and gas prices improves margins; lower supply/return temperatures cut losses and enable low-temperature sources.
- Evidence: the dena project "KI in Fernwärme" (with Stadtwerke Norderstedt and RAUSCH Technology) reports that an LSTM heat-load forecast reduced the average forecast error by up to 25 % versus conventional methods, and fed a (non-AI) mathematical optimisation of the generator mix [1][2]. Treat vendor claims on savings as site-specific and verify with your own baseline.
- Regulatory driver: the German Wärmeplanungsgesetz (WPG) requires municipal heat plans and sets shares of renewable/unavoidable waste heat in heating networks over time (to be climate neutral by 2045); the EU Energy Efficiency Directive (EU) 2023/1791 promotes efficient district heating and waste-heat use [3][4].
Variants
- Small Stadtwerk: forecast plus a simple optimiser for a few plants and one storage.
- Large urban network: multi-plant, multi-temperature-level network with hydraulic constraints, power-market participation and heat pumps.
- Low-temperature / 4th-5th generation networks and neighbourhood grids: control of heat pumps and prosumer feed-in.
- Temperature optimisation only: reduce flow temperature via forecasts and substation monitoring without changing plant dispatch (quickest start).
How it works
- SCADA / heat meters / weather forecast / prices
- data cleaning + gap filling (time-series store)
- heat-load forecast (24-72 h, per zone) + price/RES forecasts
- network model (simplified thermal-hydraulic, storage, transport delay)
- MILP / MPC dispatch: unit commitment, storage charging, supply temperature
- dispatcher review & approval (setpoints or schedule)
- control system (SCADA/PLC) or market interface
- monitoring: forecast error, deviations, KPIs
- retraining
- Forecasting: gradient-boosting, LSTM/temporal fusion or hybrid physical-statistical models using temperature, solar radiation, time-of-day, holidays and lagged load. Network inertia (hours of delay) means the supply-temperature decision must be forward-looking.
- Optimisation: mixed-integer linear programming with minimum run times, ramps, part-load efficiency, storage losses and market prices; rolling-horizon (model predictive control) with forecast updates. The solver stays deterministic and auditable; ML supplies inputs.
- Reinforcement learning is researched for supply-temperature control but mostly used in simulation or as an advisor.
- Human-in-the-loop: the control room approves schedules at first; closed-loop control only for bounded setpoint ranges with fall-back to the previous strategy.
Data preparation
Needed: heat-load and flow/return temperature history from the SCADA or process control system, plant data (efficiency curves, start-up costs, minimum run times), weather data, power and gas prices, contracts, and maintenance schedules. Sources: SCADA/historian, energy-trading and billing systems (ERP), engineering documents, and Excel files kept by plant engineers.
Typical gaps: sensor drift and missing values, differing time resolutions, plant characteristics only in PDFs or in operators' heads, undocumented operating restrictions, and manual overrides that are not logged.
Preparation steps: (1) inventory and owners (PREP-001, PREP-004); (2) export historian data and align time stamps (PREP-005, PREP-011); (3) digitise plant data sheets and contract terms from PDF/paper (PREP-006, DOC-014); (4) write down operating rules and restrictions with experienced operators, a form of knowledge capture (PREP-016, PREP-013); (5) build a replay test set of past days (PREP-018). Tools: historian export, pandas, time-series database.
Rough share of effort: about 30 % of the project; the plant model and restrictions often cost more than the data cleaning. See GUIDE-003.
Implementation paths
Which path for whom
- enterprise: Path B, because dispatch is core to a heat supplier and has to reflect own plants, contracts and the fuel and power portfolio; Path A tools are an option for utilities without in-house data science.
- public: Path B, because Stadtwerke can combine a German or EU cloud with their own plant and market data, while keeping control and respecting procurement rules.
- developer: Path C, because open MILP solvers (HiGHS, OR-Tools) and forecasting libraries run on HW1 and are fully transparent.
Path A — Buy (off-the-shelf)
- Specialised energy software: e.g. Kisters (DE), Danfoss Leanheat (DK, network monitoring), Siemens, AVEVA and ABB. Verify each product's current district-heating modules and references.
- Choose A when: you have SCADA access, a few plants and no in-house optimisation team.
Path B — Build on cloud APIs
- Time-series stores and ML on EU regions (Azure, AWS Frankfurt, Google Cloud EU, STACKIT, IONOS).
- Weather inputs from DWD open data (via Open-Meteo or Brightsky) or ECMWF open data; market data from ENTSO-E Transparency Platform.
- LLMs only as a layer for dispatcher reports and what-if queries, calling the solver as a tool (see OPT-018); never let an LLM set setpoints.
- Choose B when: you have a data team and want to integrate with existing IT/OT.
Path C — Self-host (open source)
- Forecasting: scikit-learn, LightGBM, Darts, NeuralForecast, Prophet; foundation models for time series (Chronos, TimesFM, Moirai) as zero-shot baselines.
- Optimisation: Pyomo, PuLP, OR-Tools, HiGHS (open solver) or commercial Gurobi/CPLEX; energy-system frameworks such as oemof, PyPSA, and TESPy for thermal components.
- Platform: TimescaleDB/InfluxDB, Airflow/Dagster, MLflow, OPC UA gateways.
- Hardware: HW1 (CPU server) is sufficient; solving and forecasting are not GPU-bound.
Path D — Custom training
Train site-specific forecasting models on 2-3 heating seasons of data; fit surrogate models of the network to speed up optimisation; RL agents for temperature control after validation in a digital twin. Needs hourly or finer metering history, sufficient substation coverage and well-labelled outage events.
State of the art (2026)
- Forecast + optimiser remains the proven architecture; the dena guide describes the same split (ML forecast, classical optimisation) rather than end-to-end AI [1].
- Time-series foundation models give quick baselines but typically need fine-tuning or feature engineering (weather, calendar) to beat tuned site models on heat load.
- Digital twins and MPC link hydraulic simulation with dispatch to optimise supply temperature and storage use; AI-based substation monitoring (e.g. smart meters at customer stations) identifies poorly performing substations that raise return temperature.
- Integration of heat pumps, large thermal storage and data-centre waste heat is increasing the scope of the optimisation; the dena guide notes AI data-centre waste heat as a heating source [5].
- Limits: poor sensor data, missing substation metering, structural breaks (new customers, building refurbishments), extreme weather and hydraulic bottlenecks reduce accuracy. Optimisers depend on price forecasts, and gains are sensitive to market spreads. Safety-critical limits (pressure, temperature, legionella-related hot-water rules) must be hard constraints.
Shared resources & combinations
- Same stack (time-series + optimization-solver): OPT-007 (building HVAC), OPT-011 (battery dispatch), OPT-022 (grid congestion), OPT-032 (home energy), OPT-039 (power trading).
- Inputs: PRED-007 (energy load & RES forecasting), PRED-008 (price forecasting).
- Monitoring: ANOM-008 (grid anomalies) for leak and substation fault detection.
- Planning link: PRED-048 (building energy performance) for long-term demand trends in heat plans.
- LLM layer: OPT-018 for natural-language what-if analysis on the optimiser.
Effort, cost & KPIs
- Path A: 3-9 months for rollout including SCADA connection; licence plus integration cost.
- Path B/C: 6-12 months for a small team (data engineer, energy engineer, OR specialist); data cleaning is the largest effort.
- Cost drivers: OT integration, metering retrofit, model maintenance, solver licences.
- KPIs: heat-load MAPE (day-ahead), fuel and CO2 per MWh heat, CHP full-load hours and start/stop count, average flow/return temperature, network losses (%), storage utilisation, contribution margin, share of dispatcher overrides.
People & change
Involve management and the head of generation/heat supply first; the control-room operators and shift leaders are daily users and the best source for operating rules. IT and the information-security officer must be included early (OT connection, GUIDE-013); data owners (SCADA, trading, billing) and legal/compliance (supply contracts, market rules) follow in the pilot design.
Works council: no for the optimisation as such, as it uses plant and market data and does not evaluate employees. Nevertheless inform the works council timely under §90(1) no. 3 BetrVG because shift work processes change, and check §87(1) no. 6 if operator actions are logged per person. Public utilities involve the Personalrat. See GUIDE-004. Little personal data, so a DPIA is rarely needed; the DPO confirms (GUIDE-005).
AI literacy: a short training for operators on how the forecast and schedule come about and how to read uncertainty (GUIDE-006; AI Act Art. 4 requires measures supporting staff literacy). Run a pilot in advisory mode on one network, compare recommendations with real decisions (GUIDE-009). Typical concerns: "the algorithm does not know the plant" and loss of operator expertise. Address them by building operators' rules into the model, letting them overrule any schedule and reviewing deviations together (GUIDE-008).
Risks, regulation & compliance
- EU AI Act: depends. Heating networks can be critical infrastructure; the Annex III item for critical infrastructure covers AI used as safety components in the management and operation of critical digital infrastructure, road traffic, and supply of water, gas, heating and electricity. An optimiser that only advises on economics is likely not a safety component, but one that directly controls supply may be: assess case by case, keep safety limits in conventional control [6].
- NIS2 / KRITIS: district heating operators may fall under NIS2 (energy sector includes district heating); secure OT/IT segmentation, access control and supplier management [7].
- GDPR: network-level data is not personal; per-customer consumption from smart meters is personal data. Aggregate or pseudonymise, and avoid profiling individual households.
- Sector rules: WPG, EED, price-transparency rules for Fernwärme (AVBFernwärmeV), emissions trading (EU ETS, nEHS) and CHP subsidies (KWKG).
- Mitigations: hard safety constraints outside the model, fall-back strategy, drift monitoring, dispatcher override logging, forecast-uncertainty buffers.
Getting started
- Audit data: metering coverage, SCADA history (min. 2 heating seasons), plant parameters.
- Build a day-ahead heat-load forecast and benchmark against the current method (MAPE).
- Model the plants and storage in a simple MILP and run it in shadow mode against historical days.
- Add supply-temperature recommendations; have the control room accept or reject suggestions.
- Move gradually to rolling-horizon operation with bounded automatic setpoints.
Sources
- dena — Leitfaden "KI in Fernwärme" (2024) — https://www.dena.de/fileadmin/dena/Publikationen/PDFs/2024/Leitfaden_KI_in_Fernwaerme.pdf
- dena Future Energy Lab — project KI in Fernwärme — https://future-energy-lab.de/projects/ki-in-fernwaerme/
- dena — Künstliche Intelligenz in der Fernwärmeversorgung — https://www.dena.de/infocenter/kuenstliche-intelligenz-in-der-fernwaermeversorgung/
- Directive (EU) 2023/1791 (Energy Efficiency Directive) — https://eur-lex.europa.eu/eli/dir/2023/1791/oj
- Solarserver — dena-Leitfaden KI in Fernwärme — https://www.solarserver.de/2024/11/08/dena-bringt-leitfaden-ki-in-fernwaerme-heraus/
- Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
- HiGHS open-source solver — https://github.com/ERGO-Code/HiGHS
- PyPSA — https://github.com/PyPSA/PyPSA