Predicting failures in heating networks: where time is lost
A pipeline rupture is almost never sudden. Weeks before it, a pinhole leak is forming in the pipe body, an expansion joint is sagging, makeup water is rising due to a leak through a loose seal. There are signs, but each one individually looks like normal noise.
Rounds of heating chambers give a snapshot once every few days: a specialist sees an already manifested leak, steaming, or soil subsidence. Internal corrosion and fatigue cracks give no sign at this stage — by the time they are visible, the section’s life is already exhausted.
The causes of pipeline ruptures most often add up from accumulated factors: seasonal expansion cycles, water hammer during filling, the nature of past repairs.
Data on heating network condition is collected — in round logs, archives of metering units, supply and return parameters, notes on past work. They lie in different systems and are not brought into one picture for a specific section.
Failure forecasting in a heating network begins where these series are compared and linked to the pipe, not to the facility as a whole.
Bursts during the heating season hurt most: the network runs at maximum temperature and differential, and repair happens after the fact — with excavation, disconnecting blocks, and over-supply of heat in frost. Monitoring network condition in such a mode turns into remedying consequences, not risk management.
We explain how this is addressed: how section degradation is visible earlier than a round and how this produces a work plan before cold weather.
What changes in operation with early warning
Early failure warning relies on data that the heating network already collects: pressure, temperature, and flow at nodes and in chambers, dispatch logs, subscriber requests, hydraulic test results.
The model learns from this history and calculates the deviation of the current mode from the normal section profile — adjusted for outdoor air temperature, switching scheme, and seasonal water draw-off. Deviation accumulates slowly, and this time margin is what gives value.
The key metric is not general forecast accuracy, but the window between the first sign and dispatch. Previously the signal came after the fact: pressure dropped, wet soil appeared, complaints poured in.
Now leak growth is visible hours before rupture, repair crew reaction time is reduced from days to one shift, and some work is done without disconnecting subscribers.
The second shift is failure structure. The share of sudden failures falls by moving damage into the known category: a section enters the plan before it bursts.
Repair planning goes by residual life — pipe wear is assessed per section, not as an average figure for the entire network.
The picture is refined by external data: pipeline passports, acts of past repairs, information from GIS ZhKH. Comparison with telemetry removes the main error — a section that is listed as normal but has actually exhausted its life.
Organizationally, the work mode changes. Emergency scrambles are replaced by planned windows: crews, materials, and equipment are distributed in advance, and the dispatcher receives not a stream of alarms but a prioritized list of sections with time estimates.
Approaches to risk identification: rules, statistics, model
There is no single method that works equally well on any heating network. The choice depends on three things: how densely the section is covered by telemetry, how many documented failures have accumulated, and how uniform the pipe is by diameter and year of installation. Below are working options and where each of them hits limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Threshold rules based on telemetry | The section has pressure, flow, and temperature sensors; quick start is needed without accumulated history | The signal comes from actual mode deviation, not a precursor; many false alarms during seasonal fluctuations |
| Failure statistics by section | There are repair and failure logs for several seasons; dates and causes are known | Relies on the past and does not see current pipe condition; for new sections there is simply no data |
| Model based on historical data | History is dense, there is labeling by modes and repairs, and enough sections for training | Requires regular retraining and quality control of labeling; errs on rare scenarios |
| Hybrid approach | Network data is heterogeneous: some sections have history, others only telemetry | Harder to maintain — need to monitor consistency of rules and model |
In practice, they almost always arrive at a hybrid: rules give instant reaction where little data exists, and the model refines risk where history has accumulated.
We honestly fix boundaries immediately: the forecast does not cancel scheduled tests and does not guarantee that a section will survive the season. It ranks sections by probability and gives time to prepare a crew, materials, and excavation.
Therefore we assess quality not on average across the network, but by the share of correctly identified sections and the number of missed accidents.
How a risk model for a heating network is built
The order of work here is rigid: each next step relies on the previous one, and skipping it is pointless. Until it is clear what sensors actually record and how sections are connected, any heating network risk model remains guessing on correlations.
-
Data audit. We analyze archives of the dispatch service and metering units: history depth, polling uniformity, gaps, stuck values, sections without telemetry at all. The output is a map of where data is sufficient and where a round or sensor installation is needed.
-
Network diagram and sensor mapping. We restore topology: sections, chambers, diameters, material, year of installation, repair history — checking against as-built documentation and Rules for Technical Operation of Thermal Power Installations.
Each sensor gets an address on the diagram, otherwise the model finds connections that do not exist in the pipe.
-
Sensor data preparation. We bring pressure, supply and return temperature, flow, outdoor air temperature, and heating mode to a single time step, and clean outliers. We add features: operating time after repair, number of past failures on the section.
-
Validation on historical data. We run the model through past seasons so that at each moment only earlier data is visible. We look at what share of real accidents fell into the top of the risk list and how many false alarms occur per dispatcher shift.
-
Alert setup. We select the threshold for crew capacity: how many addresses they can cover per day. Risk is ranked, with priority to sections with high probability and severe consequences.
-
Handover of the system to operation. We provide model update regulations, drift control, the procedure for alerts, and the retraining cycle on new accidents.
What we hand over with the system: documentation and regulations
A heating network failure forecasting system does not live on its own: the model signal must reach the shift with a clear procedure, otherwise the forecast will remain a beautiful report.
Therefore, along with the working loop, the customer receives a full documentation package — from data flow diagrams to regulations by which the dispatcher works in a normal shift and during low temperatures. Below is what exactly remains with your team and what we go over with it at handover.
- Data flow diagram — from sensors and metering units through telemetry gateways to storage and model, with failure points, delays, and the procedure for loss of communication with a section.
- System documentation — model passport, list of input features, periods and sections on which it was trained, and where the forecast is least confident.
- Dispatcher regulations — what to do on a signal: how to confirm, what dispatch priorities are, for which risk classes a round is sufficient, and to whom the decision is escalated.
- Model check log — dates of control runs, quality metrics, comparison of forecast with actual incidents and accidents, and recorded conclusions.
- False alarm review procedure — who revises thresholds, within what timeframes, and what share of false signals is considered the working norm.
- Instructions for connecting new sections — how to add sensors and blocks, what is needed for calibration, and how long onboarding into the forecast takes.
- Shift handover regulations — what is recorded in the report, and how the history of signals and decisions on them is stored.
- Responsibility matrix — who owns the model, who owns the data, and whom to contact when the forecast diverges from fact.
We hand over the package along with shift training: engineers go over real signals with dispatchers, not abstract examples. Describe your network and current dispatching — we will return with an assessment and handover plan.
Case study: how the number of sudden ruptures on a section was reduced
The section — 46 km of heating networks, five pumping stations, a third of the pipeline has served its standard life. Ruptures occurred during frosts, as usual: the dispatcher learned about them from residents, the crew went to search, and excavation was done after the fact.
During the heating season, 14 sudden ruptures were recorded here, and the average time from first signal to shutoff — almost three hours.
What was changed on the section
No sensors were added — we worked with what was already installed on the network. The model used round logs, failure history, telemetry from metering units and pumping stations, operating time, and seasonality.
The forecast is built on precursors: slow pressure drop, makeup water growth, flow discrepancy between neighboring nodes. The output is a morning list of high-risk sections that the shift handles by a round, not emergency dispatch.
The solution was deployed under the working name Prognoz Seti and integrated directly into the dispatcher shift, not into a separate report.
Metrics before and after
Over a comparable period, sudden ruptures became 8 instead of 14, and five of them gave warning 6–30 hours before failure. Average response time reduced from 2 h 50 min to 50 min: the crew goes to a known address, not searching for the location by thermal contours. The share of work completed as planned during the day shift grew from about a quarter to half.
The figures were collected not from the model report, but from exports of round and failure logs, verified against the dispatcher log.
The comparison was made on the same section for the same season and recalculated per kilometer of network and degree-days — so that a mild winter would not be credited to the forecast.
How does risk forecast differ from a signal to the dispatcher?
A signal to the dispatcher is a reaction to an already started event: a pressure or flow sensor exceeded the setpoint, and the accident is recorded at the moment when water is already going into the soil.
Risk forecast is fundamentally different — it assesses section condition before the event, by weak signs that a single sensor will not show.
The risk forecast model relies on accumulated history: pipe operating time, number of past repairs, seasonal and temperature fluctuations, network operating modes. The output is not accident / no accident, but a probability distribution by section for the next day or weeks.
The dispatcher receives not a stream of identical alarms, but a short ranked list — where to go first.
At the same time, no one cancels the signal to the dispatcher: it remains the lower protection loop and triggers when the forecast did not have time or was inaccurate.
Risk forecast works a level higher — it relieves the duty shift from false alarms and increases the share of events caught in advance.
The practical difference is visible in the work scenario. Warning instead of statement — planned replacement or repair of a section by work order, not urgent dispatch with excavation and disconnecting blocks.
Early notification goes to the section manager together with the dispatcher, so the decision is made based on network condition, not the leak fact.
Technical doubts: data, false alarms, communication
Heating network failure forecasting rests not on the algorithm, but on input data and how the signal reaches the dispatcher. A broken sensor, weekly gaps in telemetry, or a section without metering devices devalue the most accurate model. We explain how this is addressed.
What to do if telemetry is incomplete or sensors lie?
Each channel gets a quality score: gap frequency, drift relative to neighboring nodes, physical consistency. We fill gaps by interpolation from neighboring sections and the seasonal profile, but mark an event on such a node as less reliable. The dispatcher sees not a single number, but a signal with a note on what data it is built from.
How are false alarms filtered out?
A single threshold for pressure or temperature produces a stream of triggers that the dispatcher stops reading. The forecast is built on joint deviation of several features — supply temperature, differential across the section, makeup dynamics — and ranked by priority. A shift receives a few signals instead of dozens, and pre-emergency modes are not lost.
How is forecast connected to dispatch control?
The model is integrated into the existing loop rather than replacing it: the result goes to the dispatch system, and an event log and feedback on fact are maintained.
The decision to stop or switch is made by a person; the model highlights the section and the margin before failure. Reliability is checked on a holdout period: the share of caught accidents and the number of false ones, then retraining on confirmed cases.
Let's discuss your task: where we start work
To return with an assessment and work plan, not general words, we need access to actual data on your network. The more specific the source data, the more accurately we can say which sections will give effect first and for what horizon forecasting is realistic.
- Export of accident and outage history for several heating seasons: date, section, nature of damage, repair time.
- Heating network diagram with breakdown by section: pipe material and diameter, year of installation, laying type, presence of channels.
- Telemetry from nodes — pressure, flow, supply and return temperature, including periods before and after accidents.
- Round regulations, pit logs, and leak repair logs: the more often condition was recorded, the more reference points.
- Pilot section boundaries: one or two problem sections or an entire district, with a clear process owner.
- Contact of dispatch and operating service — for reviewing disputed cases when the model diverges from reality.
When you describe the task, we compare the data with the network behavior model and return an assessment and work plan: list of modes by which we calculate risk, quality metrics on your history, and implementation scheme.
Next is a pilot on a section with a control group, where the forecast is compared with actual accidents. If the pilot results confirm accuracy, we move to start of work across the entire network: real-time telemetry connection, response regulations, and dispatcher training. Describe the task — we will return with an assessment and plan.
