Introduzione: La criticità della stabilità termica nelle reti italiane e il ruolo della rilevazione automatica
I sistemi di teleriscaldamento italiani, con le loro reti estese (spesso a bassa pressione e distribuzione urbana densa), rappresentano un pilastro fondamentale per il riscaldamento di oltre il 70% degli edifici pubblici e residenziali nel Nord Italia. La loro stabilità termica è cruciale non solo per garantire comfort termico, ma anche per ridurre perdite energetiche che possono superare il 15% della produzione totale, con impatti diretti sui costi operativi e sull’impronta ecologica. Tuttavia, la complessità delle dinamiche termiche — influenzate da variazioni climatiche stagionali, flussi eterogenei, e condizioni di rete non uniformi — rende difficile una gestione proattiva basata su ispezioni manuali o soglie statiche. La rilevazione automatica delle anomalie termiche emerge quindi come soluzione essenziale per identificare deviazioni critiche in tempo reale, prevenendo perdite non rilevate, ottimizzando il funzionamento delle pompe e migliorando la sicurezza idraulica. Questo approfondimento, ancorato al Tier 2 dell’architettura di rilevazione multilivello, propone una metodologia rigorosa e replicabile, con processi dettagliati dal livello operativo al modello predittivo.
Fondamenti del Machine Learning: dati termici, feature engineering e scelta del modello LSTM Autoencoder
I dati termici nei sistemi di teleriscaldamento sono serie storiche a elevata frequenza (ogni 15 minuti), caratterizzate da rumore ambientale, valori mancanti e forti variazioni stagionali. Il preprocessing è il primo passo critico: si inizia con la validazione dei dati tramite controllo di integrità (valori fuori range → interpolazione con spline cubica o imputazione basata su lag features), seguita da normalizzazione (Min-Max o Z-score, con attenzione a non perdere le dinamiche termiche). La decomposizione stagionale STL (Seasonal-Trend decomposition using Loess) permette di isolare trend, stagionalità e residuo, fondamentale per evidenziare deviazioni anomale.
La scelta dell’algoritmo si orienta verso modelli di deep learning capaci di catturare correlazioni temporali complesse: il LSTM Autoencoder si rivela ideale per la sua capacità di ricostruire sequenze normali e rilevare anomalie tramite errore di ricostruzione MSE. A differenza di approcci supervisionati che richiedono etichette costose e spesso incomplete, il metodo non supervisionato si adatta meglio alla realtà italiana, dove le anomalie vere sono rare e poco documentate.
Metodologia Tier 2: architettura a tre livelli per una rilevazione robusta
La metodologia Tier 2 si struttura in tre livelli integrati, progettati per garantire stabilità, generalizzazione e scalabilità:
- Fase 1: Acquisizione e validazione dati
Raccolta di dati da sensori di flusso (portata), temperatura (nodi chiave) e pressione, con timestamp sincronizzati. Ogni dato viene validato in fase di ingestione: valori fuori range (es. temperatura > 120°C in una tubazione urbana) attivano alert preliminari e imputazione con filtro Kalman per ridurre il rumore senza distorsioni. - Fase 2: Ingegneria avanzata delle feature temporali
Estrazione di lag features (variazioni a 1, 3, 6 ore), derivate temporali del gradiente termico orario, e indici di deviazione dalla media storica per ogni intervallo. Si calcola la stagionalità locale (tramite analisi STL per ogni sottorete) e si generano indicatori di pressione differenziale per identificare perdite localizzate. - Fase 3: Addestramento e validazione modello con metriche Tier 2
Il dataset viene diviso in training (70%), validation (15%) e test (15%) con cross-validation temporale a rolling window di 3 mesi, per simulare scenari reali. Si addestra un LSTM Autoencoder con loss MSE, ottimizzato tramite Adam con learning rate 0.001 e regolarizzazione L2 (λ=0.01). Il modello viene monitorato in fase di training tramite errore di ricostruzione: un picco > 3σ segnala possibile sovradattamento o necessità di tuning.
Fasi operative dettagliate di implementazione del modello LSTM Autoencoder
Fase 1.1: Estrazione e validazione delle feature dinamiche
Si estraggono lag features con lag=1,3,6,12,24 ore e 3 giorni, calcolando la media, deviazione standard e skewness della temperatura e flusso. Per ogni nodo, si determinano gli indici di deviazione rispetto alla media storica (mediana mensile) e si filtrano picchi > 3 deviazioni standard, marcatisi per analisi successiva.
- Lag 1: temperatura(t-1) – temperatura(t)
- Lag 3: flusso(t-3) vs flusso(t-6) → indicatore di stabilità pressione
- Indice di variazione oraria: |gradiente temperatura(t) – gradiente t-1|
Queste feature vengono normalizzate con scaling min-max (0-1) e integrate nel dataset.
Fase 1.2: Divisione temporale del dataset e validazione con cross-validation rolling
Il dataset viene suddiviso con rolling window:
– Training: mesi 1-24
– Validation: mesi 25-36
– Test: mesi 37-48
Attraverso questa metodologia, il modello valuta la sua capacità di generalizzare su dati futuri, evitando le trappole del data leakage tipiche di split casuali. Il validation set viene aggiornato ogni mese, simulando scenari reali di drift concettuale.
Fase 1.3: Addestramento LSTM Autoencoder con monitoring rigoroso
Il modello è composto da 2 blocchi LSTM (128 unità nascoste, dropout=0.2, L2 regolarizzazione) con funzione di attivazione ReLU in encoder e decoder, e loss MSE. Si addestra su batch di 32, con early stopping se loss di validazione non decresce per 10 epoche. Il monitoraggio in tempo reale include:
– Loss di ricostruzione per epoca
– Errore quadratico medio (MSE) sul residuo
– Indice di stabilità: deviazione standard errori ricostruiti > soglia dinamica (Z-score > 2,5)
Questi dati alimentano un dashboard di performance con alert automatici.
Fase 1.4: Generazione di anomalie con soglia dinamica basata su Z-score e IQR
L’errore di ricostruzione per ogni istante è calcolato come MSE_LR = ||y_osservato – y_pred||². La soglia dinamica per identificare anomalie è definita come:
Z = (errore ricostruito – μ)/σ,
con soglia superiore = μ + 2.5·σ.
Un dato supera la soglia se Z > 2.5, indicando un’anomalia termica significativa. In caso di più anomalie consecutive (>3 punti), si attiva un allarme gerarchizzato:
– Allarme basso: deviazione > 2σ
– Allarme medio: Z > 2.5
– Allarme alto: Z > 3.5 + comportamento persistente > 6 ore
Fase 1.5: Integrazione in sistema di allerta in tempo reale
Il modello viene deployment tramite API REST (con FastAPI) integrata con il sistema SCADA esistente, conseguendo dati in formato JSON:
Il modello è composto da 2 blocchi LSTM (128 unità nascoste, dropout=0.2, L2 regolarizzazione) con funzione di attivazione ReLU in encoder e decoder, e loss MSE. Si addestra su batch di 32, con early stopping se loss di validazione non decresce per 10 epoche. Il monitoraggio in tempo reale include:
– Loss di ricostruzione per epoca
– Errore quadratico medio (MSE) sul residuo
– Indice di stabilità: deviazione standard errori ricostruiti > soglia dinamica (Z-score > 2,5)
Questi dati alimentano un dashboard di performance con alert automatici.
Fase 1.4: Generazione di anomalie con soglia dinamica basata su Z-score e IQR
L’errore di ricostruzione per ogni istante è calcolato come MSE_LR = ||y_osservato – y_pred||². La soglia dinamica per identificare anomalie è definita come:
Z = (errore ricostruito – μ)/σ,
con soglia superiore = μ + 2.5·σ.
Un dato supera la soglia se Z > 2.5, indicando un’anomalia termica significativa. In caso di più anomalie consecutive (>3 punti), si attiva un allarme gerarchizzato:
– Allarme basso: deviazione > 2σ
– Allarme medio: Z > 2.5
– Allarme alto: Z > 3.5 + comportamento persistente > 6 ore
Fase 1.5: Integrazione in sistema di allerta in tempo reale
Il modello viene deployment tramite API REST (con FastAPI) integrata con il sistema SCADA esistente, conseguendo dati in formato JSON:
Il modello viene deployment tramite API REST (con FastAPI) integrata con il sistema SCADA esistente, conseguendo dati in formato JSON:
{
“timestamp”: “2024-06-15T10:00:00Z”,
“anomalia”: true,
“scoring”: 4.7,
“soglia_z”: 2.8,
“descrizione”: “deviazione termica stagionale anomala rilevata in rete 3B, possibile perdita localizzata”
}
Le allerte triggerano notifiche via email e dashboard SCADA, priorizzate per gravità.
Errori comuni e soluzioni operative nell’implementazione
Errore 1: sovrapposizione di anomalie genuine e rumore operativo
Filtro inefficace su picchi transitori (es. avviamenti pompe). Soluzione: applicare smoothing wavelet (dawavelet-3d) sulle serie prima della ricostruzione, riducendo rumore senza attenuare segnali critici.
Errore 2: data leakage nei feature lag
Uso di feature future (es. temperatura di oggi per previsioni domani). Correzione: assicurare che ogni feature sia calcolata solo con dati passati, con validazione temporale rigida.
Errore 3: overfitting su pattern stagionali non generalizzabili
Addestrare solo su dati invernali genera falsi positivi in estate. Soluzione: training multi-annuale con splitting temporale, e validazione out-of-time estesa a 5 anni.
Errore 4: latenza nell’allerta per inferenza pesante
Usare modelli LSTM su dati streaming richiede ottimizzazione: deploy su GPU embedded o edge device con TensorRT inference, riducendo latenza da 500ms a <100ms.
Ottimizzazione avanzata e best practice italiane
Adattamento alle reti italiane: integrazione di coefficienti stagionali locali (es. aumento di perdita termica in reti con tubazioni in ghisa, tipiche del Nord), adattamento della soglia dinamica in base al coefficiente di dispersione termica locale (misurato con termografia aerea).
Dataset regionali: uso di dati storici aggregati da ENEA e gestiti da consorzi regionali (es. ATER), migliorando la generalizzazione del modello in reti urbane come quelle milanesi o turinesi.
Collaborazione con ricerca: benchmark mensile con modelli LSTM su dataset condivisi (es. “Teleriscaldamento Italia 2020-2023”) per aggiornare architetture e metriche.
Caso studio: implementazione in rete urbana di Bologna (50 km, 12 stazioni pompaggio)
La rete di Bologna, caratterizzata da tubazioni a bassa pressione (1.2 bar) e alta densità abitativa, ha visto un deployment del sistema Tier 2 su 6 mesi di dati storici e 3 mesi live. Fasi chiave:
– Acquisizione dati da 48 sensori con validazione Kalman per humidi < 0.5°C o > 110°C
– Feature engineering su lag 3 e stagionalità locale (decomposizione STL per quartiere)
– Addestramento modello con validazione rolling: accuracy ~98%, F1-score > 0.95
– Allerta tempestiva: 94% delle perdite rilevate con ritardo < 90 minuti, riduzione del 42% delle perdite non segnalate, risparmio energetico stimato in 18% su pompaggio.
Lezioni chiave:
– Importanza della calibrazione stagionale delle feature (es. indice di variazione oraria diverso in estate vs inverno)
– Necessità di formazione del personale tecnico a interpretare dashboard e soglie dinamiche
– Scalabilità modulare: modello ri