Note operative Tecnica

La soglia di allarme è una voce di capitolato, non un’impostazione

7 min di lettura

Muro di sostegno in gabbioni metallici riempiti di pietrame lungo una scarpata boschiva, fotografia in bianco e nero
La struttura che sostiene la scarpata è quella che, cedendo, si porta dietro il cavidotto.

Avete sensori installati su una tratta, o qualcuno ve li sta proponendo. Prima di firmare, sapreste rispondere a quattro domande: a quale valore scatta l’allarme? quante volte al secondo — o al giorno — si misura? chi ha deciso quei numeri? e quando sono stati rivisti l’ultima volta? Se la risposta onesta è che non sono scritti da nessuna parte, non avete un sistema di monitoraggio. Avete un preventivo con dei sensori dentro.

La Raccomandazione ITU-T L.391 (11/2025), «Monitoring systems for outside plant facilities», seconda edizione approvata il 29 novembre 2025 dallo Study Group 15 — sostituisce la L.391/L.81 del 2009 — parte da questo punto, e lo scrive in una tabella che ogni capitolato di monitoraggio dovrebbe citare per nome.

La soglia, non il sensore

Il passaggio che regge questo pezzo sta nell’Appendice I, sull’esperienza coreana — non parte integrante della Raccomandazione, avverte il testo stesso: «This appendix does not form an integral part of this Recommendation». Nella tabella sulle scelte di progetto (I.1): «Monitoring system performs early warning. Real-time data gathered by WSN are analysed and an alarm is issued if the data exceed prescribed thresholds.»

Segue il problema vero: «If the threshold is set too low, there will be too many false warnings, and genuine warnings will not be heeded. On the contrary, if the threshold is set too high, events that may cause accidents will be missed.» Soglia bassa, troppi falsi allarmi, e — la conseguenza che conta — «genuine warnings will not be heeded»: gli allarmi veri non vengono più ascoltati, il sistema si spegne nella testa di chi lo guarda prima che nei fatti. Soglia alta, e l’evento vero passa inosservato.

Una riga sola, e vale come architrave: «This activation threshold should be set case by case for outside plant facilities.» Non esiste una soglia di default da comprare a scatola chiusa: è un dato di progetto, quindi una voce di capitolato, con dentro chi la fissa, su quale base, e con quale procedura di revisione.

Due ordini di grandezza

Stessa tabella, la riga sulla frequenza di campionamento: «The sampling rate determines how often sampling takes place. A faster sampling rate acquires more data in a given time, and therefore often forms a better representation of the original signal.» E l’esempio che fissa la scala: «earthquake monitoring needs at least a 200-Hz data sampling rate, whereas […] some samples per day may be enough.»

Duecento misurazioni al secondo per il sisma, poche al giorno per temperatura e umidità: due ordini di grandezza. Non è un’opzione di menu di default — è un requisito contrattuale, specifico per ogni parametro, da scrivere a fianco della soglia.

Perché non basta il giro di ispezione

Il § 7.1 spiega perché non basta mandare qualcuno a guardare: «The objective of the monitoring system is to detect defects at an early stage, and to deliver warning messages to disaster managers rapidly when the defects are not tolerable.» E il limite del solo occhio umano: «small defects that may cause great disasters are apt to be overlooked by only manual inspection.»

Il § 6.4 descrive il flusso manuale — pattugliamento, ispezione visiva, indagine di dettaglio se emergono difetti. I sistemi a sensori «omit some of these stages and thus make it labour-saving and efficient» e «allow facility staff members to quickly find critical data». Non sostituiscono l’ispezione a vista — la trovate nella nostra nota sulle frequenze della L.330, uscita questa mattina — ma coprono il punto cieco dei difetti che l’occhio umano, su impianti grandi e sparsi, non incontra quasi mai.

Vedi il servizio · Parlane con un tecnico

I sette requisiti, uno per uno

Il § 7.2 elenca sette requisiti, e ognuno è già una riga di capitolato:

  • risposta rapida in emergenza;
  • tecnologia affidabile e comprovata, per evitare falsi allarmi;
  • funzionamento in tempo reale o quasi;
  • allerta senza ritardo per il personale;
  • interoperabilità con i sistemi nazionali di gestione delle emergenze, dove applicabile;
  • sicurezza che garantisca autenticazione, cifratura e integrità dei dati;
  • valutazione e verifica prima dell’applicazione, con controllo periodico.

L’ultimo — «evaluated and verified before application and regularly checked» — è la clausola di verifica in accettazione scritta dentro la norma: si prova che l’allarme scatta prima dell’esercizio, e poi periodicamente, non si installa e si spera. Il penultimo è il ponte NIS2: un sistema con requisiti di autenticazione, cifratura e integrità dei dati è un sistema informativo — e per un soggetto NIS un suo malfunzionamento è un incidente da valutare, non un guasto qualunque.

Push, non pull

Il § 7.3.3 distingue il pull, che interroga i sensori a intervalli fissi, dal push, che trasmette solo quando un evento supera un livello prefissato: «proactively transmits sensed data only when an event exceeds a predetermined level». La raccomandazione è netta: «It is recommended that a push model be used for disaster monitoring systems. Hybrid models […] may be used to enhance system resilience.» Un dato da scrivere in capitolato, non una configurazione di fabbrica.

Cablato, radio, e la fibra che sente

Al § 7.3.1.1 la raccomandazione arriva dove lavoriamo ogni giorno: «For the application of distributed fibre optic sensing (DFOS) technique, the optical fibre itself is used as sensor.» La fibra smette di portare solo il segnale e diventa il sensore stesso — deformazione, vibrazione, sforzo da gelo, secondo la Tabella 3 — lo stesso principio della nostra nota sull’identificazione dei cavi per vibrazione, la L.316.

La Tabella 2 confronta cablato e radio. Il cablato è «stable and proven technology» ma «expensive to install», con cavi che «can fail due to exposure to the environment» e degradano il segnale su lunghe distanze. Il radio riduce i costi, ma «power and communication bandwidth available on the node are very limited» e ogni nodo ha «limited battery life». Il § 7.3.1 riassume: «Wired systems generally provide higher reliability, while hybrid wired/wireless solutions may offer improved redundancy and resilience.»

La Tabella 1 dedica alla frana la riga che vale l’immagine di questo articolo: «Duct bursts and disconnection of cables» e «Failure of earth retaining structures» — il cedimento della struttura di sostegno che porta con sé il cavidotto che le passa accanto. Misure: «Periodic inspection», «Monitoring by measurement», «Installation of monitoring system». Stessa logica per il crollo, col vincolo sulle costruzioni adiacenti — il principio del nostro coordinamento sugli scavi — e per l’allagamento delle gallerie cavo, dove la misura è un piezometro o un monitoraggio del livello dell’acqua.

Ciò che la L.391 non copre

Due precisazioni. La L.391 esclude gli incendi: «disasters due to fire are not considered in this Recommendation because disaster management concerning fire is described in [b-ITU-T L.20], [b-ITU-T L.21], [b-ITU-T L.22] and [b-ITU-T L.23]» — la compartimentazione delle penetrazioni cavi sta su un’altra serie di raccomandazioni.

E, come ogni raccomandazione ITU-T, non è una legge: «Compliance with this Recommendation is voluntary. […] The words “shall” or some other obligatory language such as “must” […] are used to express requirements.» Acquista forza solo quando un committente la scrive per nome in un capitolato, con soglia, frequenza e modello di comunicazione specificati riga per riga.

I due assi, applicati

Primo asse: soglia, frequenza di campionamento, modello push e i sette requisiti del § 7.2 diventano righe verificabili del capitolato — e l’ultimo requisito diventa un punto di collaudo scritto, con prova documentata e datata: si dimostra che l’allarme scatta al valore previsto, non si prende per buono che scatterà.

Secondo asse: le letture dei sensori e le soglie impostate non restano un dato chiuso nel portale del fornitore. Diventano, con CSIDIA, l’altra società del gruppo, una mappa unica della rete su cui un’AI fa la diagnosi e la squadra chiude il guasto — insieme al catasto as-built: un allarme di inclinometro su una scarpata vale poco da solo, vale molto se il sistema sa già che lì sotto passa quel cavidotto, con quelle giunzioni. Nel perimetro del cliente: on-premise su macchine autonome senza integrazione profonda, oppure cloud dedicato con data center in Italia, sempre con gestione condivisa.

Sapreste dire, in questo momento, a quale valore esatto scatta un allarme sul vostro impianto — e chi ha firmato quel numero, e quando? Parlatene con un tecnico: il sopralluogo è senza costi, e ne esce l’elenco dei punti monitorati della tratta con, per ciascuno, la soglia, la frequenza di campionamento, chi l’ha decisa e quando è stata provata l’ultima volta — comprese le caselle che restano vuote. È vostro anche se non proseguiamo insieme.

Fonti