Internet of things e manutenzione predittiva dei ponti ferroviari: la creazione del data model

Per progettare l’architettura IoT necessaria a costruire e utilizzare un data model in grado di ampliare la conoscenza rispetto al fenomeno della stabilità dei treni e dei ponti e delle loro mutue interazioni nelle diverse condizioni di esercizio l’approccio teorico discusso nel precedente articolo risulta di fondamentale importanza.

L’approccio sottostrutturale

Infatti, una volta individuati i sistemi di equazioni differenziali in grado di modellare la risposta del ponte, sarà necessario raccogliere ulteriori dati (es: irregolarità del profilo delle rotaie, incidenza dei cicli di isteresi dei diversi materiali durante eventi sismici pregressi, ecc.) necessari al calcolo della risposta attesa e che potrebbero essere particolarmente destabilizzanti per la marcia del treno (es: variazioni impulsive delle forze verticali sono particolarmente dannose al moto di puro rotolamento e potrebbero ridurre la stabilità del treno).

È noto che al passaggio del veicolo il ponte venga eccitato generando quindi delle vibrazioni che si ripercuoteranno in maniera continuativa sul veicolo. Da qui la necessità di integrare informazioni provenienti da bordo treno e dal ponte, utilizzando un approccio sotto-strutturale che modellizzi questo comportamento di interazione di elevata complessità. In sostanza, come visto al paragrafo precedente, si intendono ricavare le equazioni del moto separatamente per il sottosistema ponte e per quello veicolo, e successivamente le stesse saranno oggetto di associazione e risoluzione mediante calcolo integrale [8].

I 5 domini di dati da integrare

Tali dati sono spesso provenienti da domini differenti ed in formati eterogenei, richiedendo quindi importanti azioni di estrazione, trasformazione e caricamento dei dati medesimi (ETL, Extract Transform & Load). Nel caso di specie, vi saranno almeno cinque distinti domini di dati da integrare: i dati raccolti sul campo e provenienti dai sensori del ponte e a bordo treno, i dati “ingegneristici” relativi alla progettazione del ponte e al calcolo dei parametri meccanici della risposta, i dati estratti dai sistemi di telecomando/comando remoto della circolazione, i dati provenienti da piattaforme IT tradizionali (gestione turni, storico manutenzioni, etc.), eventuali ulteriori dati esogeni quali bollettini meteo e coordinate GPS. Lo schema logico funzionale della soluzione IoT ipotizzata è riportato in figura 3.

Fig. 3 (elaborazione degli autori) – Schema logico-funzionale della soluzione IoT;

L’efficacia del paradigma proposto è funzione della capacità di integrazione delle diverse sorgenti di dati, spesso afferenti a domini operativi differenti, al fine di costruire un data model olistico in grado mettere a fattor comune basi di dati che, integrandosi, forniscano informazioni non ottenibili analizzando singolarmente i diversi silos di dati. Di seguito si riportano alcune considerazioni circa le fasi di acquisizione dei dati dalle diverse sorgenti:

• 1. dati di campo: in questo dominio rientrano i dati raccoglibili dai due elementi principali costituenti il sistema materiale treno-armamento-ponte e specificatamente dal Train Control & Management System (TCMS) per i rotabili, e dal gateway che funge da collettore dei sensori installati sul ponte. Nel primo caso, ipotizzando l’inserimento di appositi accelerometri sui carrelli e sulle casse, si potrebbero identificare gli spettri delle vibrazioni che si ripercuotono sul treno durante la risposta del ponte alla sollecitazione dinamica dovuta al proprio passaggio. Per raggiungere tale scopo, si dovrà utilizzare un’architettura costituita dai sensori a bordo treno ed un server edge collegato con i bus MVB ed Ethernet. Tutti i treni di ultima generazione, infatti, sono dotati di un elaboratore ad hoc che, da un lato si interfaccia con il TCMS per raccogliere i dati su un database locale ed analizzarli, dall’altro cura il trasferimento di segnali, contatori, ed eventi verso il sistema di terra. Un ruolo fondamentale è ricoperto dalla logica di veicolo che rappresenta la modellizzazione del rotabile in termini di sottosistemi, LRU, failure modes, eventi, segnali, contatori, etc. e relative relazioni. Il sottosistema di bordo, in funzione delle regole diagnostiche implementate e della configurazione della logica di veicolo, invierà dati diagnostici verso terra attraverso due distinti canali di comunicazione:
     1. comunicazione in near real time (quasi in tempo reale): variabili inerenti al funzionamento di specifici apparati vengono costantemente inviati a terra attraverso protocolli ad hoc (per esempio XMPP (Extensible Messaging and Presence Protocol) o più moderni broker MQTT (Message Queue Telemetry Transport)), consentendo di monitorare le flotte in esercizio;
     2. comunicazione “batch”: tutti i segnali raccolti in funzione dei vari eventi, vengono conservati e spediti ad intervalli regolari utilizzando appositi protocolli per il trasferimento di file di grosse dimensioni (per esempio FTP, file transfer protocol, o, anche in questo caso, più moderni broker MQTT).

Entrambi i canali sfruttano una rete VPN (Virtual Private Network, rete privata virtuale) adottando protocolli che provvedano a cifrare il traffico transitante sulla rete virtuale preservando l’integrità dei dati trasmessi.

Monitoraggio IoT: i 3 elementi del sistema

Tali dati verranno inviati al sottosistema di terra che è costituito da una soluzione IT convergente (cioè integrante uno strato computazionale, un database relazionale per la memorizzazione dei dati, spazio disco, e connettività), ridondata, ed utilizzabile anche in cloud. Tale soluzione, comunicando con il sottosistema di bordo, riceve i dati provenienti dai rotabili in linea, li rende fruibili a piattaforme IoT per l’analisi batch, la calibrazione e validazione di algoritmi diagnostici [1]. Il sistema di monitoraggio IoT del ponte, invece, consta di tre elementi distinti (sensori, gateway e piattaforma di data analytics) e si estende su altrettanti domini (vedi Fig. 4): il Machine-to-Machine domain (M2M), il network domain, e l’application domain. Di seguito si analizzano gli elementi cardine del sistema:

Fig. 4 – I domini caratterizzanti un sistema di monitoraggio IoT; [13-9]

1. sensori IoT: sono strumenti in grado di effettuare misurazioni con frequenza di campionamento definita a priori o attivabile mediante trigger, che saranno contestualmente inviate verso il gateway attraverso la M2M area network. Si ipotizzino, a titolo meramente esemplificativo e non esaustivo, due distinte tipologie di sensori applicate al ponte: un sensore per l’analisi vibrazionale basato su standard IEEE802.15.4, ed un sensore per la misura della temperatura basato su standard IEEE802.11b/g/n (comunemente conosciuto come Wi-Fi). Nel primo caso si avrà un accelerometro MEMS (Micro Electro-Mechanical Systems) in grado di calcolare la forza per unità di massa che sarà connesso ad un microcontrollore avente il compito anche di gestire il transceiver di comunicazione 802.15.4. Da un punto di vista applicativo, invece, il microcontrollore acquisisce i valori dall’accelerometro, può fare operazioni banali in loco (es.: peak-to-peak o un overall su uno o più assi). Nel secondo caso, invece, avremo un sensore termico connesso a microcontrollore che gestirà, a sua volta, un transceiver di comunicazione Wi-Fi. A livello applicativo, invece, il microcontrollore acquisisce da sensore e può fare un processing a bordo (es.: media aritmetica, ponderata) e detection di eventi (es.: temperatura sopra una certa soglia).
   In aggiunta ai sensori stand-alone discussi in precedenza, vi sono diverse altre soluzioni per il monitoraggio continuo delle opere civili. Tra le tecnologie emergenti in ambito Structural Health Monitoring (SHM), i sistemi di telerilevamento rappresentano uno stato dell’arte [9]. Tra le tecniche di telerilevamento più efficaci per lo SHM si cita l’Interferometria Radar Terrestre. Tale tecnica è rapidamente implementabile in situ, garantendo una elevata risoluzione spaziale e temporale di campionamento, misurando le frequenze proprie di vibrazione, le ampiezze di oscillazione, le forme modali, i fattori di smorzamento, ecc. Si nota quindi come tale tecnica si presti alla misurazione delle variabili di stato di ponti e viadotti, fornendo risultati del tutto paragonabili a quelli che si otterrebbero con altre tecniche “da contatto” come gli accelerometri descritti in precedenza. Nel caso di specie, la misurazione avviene sfruttando la naturale riflettività alle microonde degli elementi presenti nello scenario irradiato. In particolare, il sensore utilizzato è costituito da un radar interferometrico ad apertura reale “coerente” (in grado quindi di emettere impulsi radar a lunghezza d’onda nota), dotato di una o più antenne emittenti e riceventi. Le misurazioni avvengono lungo la linea di vista strumento-scenario mediante le analisi differenziali delle informazioni di fase dell’onda elettromagnetica emessa e riflessa nei diversi intervalli temporali. I potenziali spostamenti sono quindi identificati simultaneamente su svariati punti della struttura, come riportato in figura 5.

Fig. 5 – Principio interferometrico per il calcolo degli spostamenti;

Il principio interferometrico per il calcolo degli spostamenti è modellizzato dalla seguente espressione:

• s è lo spostamento misurato;
• è la lunghezza d’onda emessa;
• rappresenta la misura della fase grezza relativa ad ogni campionamento.

Ruolo dei sensori a fibra ottica

Fin qui sono stati descritti metodi applicabili ad opere già realizzate ed aperte all’esercizio. Ma volendo dotare nuove infrastrutture in corso di costruzione di sensoristica endogena in grado di effettuare misurazioni efficaci e a basso costo, i sensori a fibra ottica rappresentano una valida soluzione per monitorare spostamenti e deformazioni di membrature portanti, ma anche per eseguire un controllo sullo stato di deterioramento dei materiali avendo contezza degli sviluppi fisico-chimici. Tali soluzioni si prestano all’applicazione nei ponti ferroviari non solo per l’ampia gamma di parametri misurabili, ma anche per l’insensibilità ai campi elettromagnetici (treni, temporali, linee ad alta tensione) e alla corrosione. Nelle nuove costruzioni in calcestruzzo armato è possibile fissare i sensori alle barre delle armature e, una volta in esercizio, saranno in grado di identificare l’innesco di crisi statiche, la comparsa del fenomeno corrosivo, eventuali deformazioni nella geometria del costruito, ecc.

1. Gateway: si tratta di dispositivi multi-interfaccia radio che possono acquisire dati da sensori eterogenei garantendo scalabilità e modularità. Per i collegamenti short range (es: M2M area network) utilizzano protocolli Constrained Application Protocol su standard trasmissivo IEEE802.15.4 integrandosi perfettamente con http, tcp/ip, e protocollo

RESTful. Lo standard 802.15.4 può essere considerato uno strumento di comunicazione short range con bassi consumi ed una velocità di trasferimento fino a 250 kbps. Un’altra tecnologia per collegare a breve raggio gli smart meter a internet è il Bluetooth Low Energy, che raggiunge velocità fino a 1 Mbps. Per il collegamento da gateway verso server remoto si possono usare tecnologie e standard trasmissivi Wi-FI/WiMAX o 4G/5G.

1. Piattaforme IoT/Data Analytics: rappresentano l’ecosistema di applicativi dove i dati provenienti dal campo vengono raccolti, normalizzati, ed elaborati al fine di costruire basi di dati statisticamente rappresentative per calibrare modelli predittivi che garantiranno l’identificazione di future problematiche già dalla loro fase incipiente. Maggiori dettagli su tali piattaforme saranno forniti nel corso del paragrafo.

Nella tabella 1 si riportano il modello della pila OSI, il modello TCP/IP ed i relativi protocolli IoT usati in ognuna delle fasi di trasferimento dei dati. È possibile quindi ricostruire, da un punto di vista logico, il ciclo di vita del dato da quando questo viene campionato dal sensore, fino alla sua fruizione lato applicativo. Infatti, leggendo la tabella dal basso verso l’alto, l’ultimo step, l’application layer, rappresenta il punto di accesso del dato nell’ecosistema di analytics; consumando la misurazione tramite un gestore di code MQTT, ad esempio, il dato verrà inserito in un database/datalake diventando oggetto delle analisi necessarie.

• Dati ingegneristici: in questo dominio si trovano i dati relativi ai dettagli progettuali, costruttivi, e idrogeologici dei ponti oggetto di analisi, e lo storico dei difetti registrati per mezzo di visite ispettive generali nel corso degli anni. In Italia, ad esempio, ai sensi dell’Istruzione 44C [10], si richiede “il controllo sistematico delle condizioni statiche dei vari manufatti per i riflessi che le stesse hanno sulla sicurezza e regolarità dell’esercizio. Il controllo dovrà fornire probanti elementi di giudizio sulle condizioni di stabilità e di conservazione delle opere… integrando, all’occorrenza, con opportune verifiche e misure strumentali…”. La definizione e registrazione di eventuali difetti riscontrati durante le visite tecniche in situ avviene attraverso un codice che ne individua la tipologia, alcuni ulteriori coefficienti che esprimono l’importanza del difetto ed il relativo livello di intensità. Tali dati confluiscono in una base di dati ad hoc considerata come un supporto per l’espressione del giudizio finale come richiesto dalle normative vigenti. In Italia si utilizza il sistema DOMUS di Rete Ferroviaria Italiana (RFI) per la raccolta e catalogazione dei risultati delle visite ispettive, generando così una sorgente di dati strutturati (il DOMUS, mediante il proprio algoritmo, fornirà l’indice di difettosità dell’opera) fruibili per analisi e approfondimenti (vedi Fig. 6).

Fig. 6 – Interfaccia utente del sistema DOMUS di RFI;

Ulteriori dati ingegneristici necessitano di essere integrati e correlati al fine di identificare rischi collaterali, per esempio legati al dissesto idrogeologico o alle conseguenze relative ad azioni sismiche. Nel primo caso, in Italia si utilizza il portale GEOMEDIA di RFI, dal quale è possibile verificare la presenza di punti di dissesto idrogeologico; in aggiunta, all’occorrenza, potrebbero essere considerate anche altre fonti di dati esogene, quali, ad esempio, le mappe dell’autorità di bacino. Nel secondo caso, invece, potrebbe essere utile integrare le basi di dati presenti nell’Italian Accelerometric Archive (ITACA) [11].

• Dati provenienti dai sistemi di (tele)/controllo del traffico: collegarsi in sola lettura ai database dei sistemi di controllo e regolazione del traffico, previa “apertura” degli stessi da parte dei produttori, è di fondamentale importanza per raccogliere quelle informazioni che rappresentano alcune tra le condizioni al contorno da applicare ai sistemi di equazioni differenziali ottenuti dalle analisi descritte nel precedente paragrafo. Infatti, una volta modellizzato il comportamento delle strutture, i campi di spostamento attesi saranno ovviamente funzione anche del carico dinamico che andrà a sollecitare il ponte, e quindi informazioni quali la massa, la massa frenata, l’accelerazione, la velocità sono di fondamentale importanza per poter calcolare in near real time la risposta attesa (in termini di spostamenti, velocità e/o accelerazioni) e confrontarla, conseguentemente, con quella reale ricostruita mediante i sensori del ponte e/o quelli a bordo treno. Un ulteriore dato fondamentale è il numero dei veicoli (e quindi di assi), con relative grandezze dinamiche, che formano il convoglio in transito. Infatti, amplificazioni rilevanti possono verificarsi per carichi ripetuti disposti con periodicità spaziale dato che ognuno di essi, al suo ingresso ed alla sua uscita dal ponte, genera un treno d’onde che si somma a quello indotto dai carichi già transitati. S’intuisce che se ogni carrozza ferroviaria produce vibrazioni che hanno tutte la stessa fase, circostanza che si verifica per frequenze di oscillazione pari ad un multiplo della frequenza di transito, la vibrazione si rinforza nel tempo anche se i carichi che l’hanno generata sono già transitati, permanendo a lungo l’oscillazione libera in virtù del modesto smorzamento strutturale [12]. Le informazioni richieste possono essere reperite interfacciando, in funzione della linea, alternativamente o il Sistema di Comando e Controllo (SCC), o il Controllo Centralizzato del Traffico (CCT), o il Controllo Centralizzato Linee (CCL). SCC e CTC consentono il controllo e la gestione, anche remota via telecomando, della circolazione in linea e nelle stazioni. Il SCC ha la capacità di gestire non solo la circolazione, ma anche la diagnostica, la manutenzione, le informazioni al pubblico e la videosorveglianza. SCC (di cui esiste una variante dedicata alle linee ad alta velocità definita SCC-AV) è in grado di interfacciarsi sia con apparati periferici impresenziati (stazioni, posti di movimento, posti di comunicazione, ecc.) sia con apparati elettromeccanici lungo linea (scambi, segnalamento, ecc.). CCL, invece, pur non consentendo il telecomando della circolazione, garantisce funzioni di supervisione e gestione. Nel caso di specie, dal SCC saranno integrabili diversi valori, dei quali si riporta un estratto in tabella 2.

Tab. 2 – Estratto di alcuni dati integrabili dal Sistema di Comando e Controllo;

Opportunità di nuovi punti informativi

Un ulteriore sorgente di dati afferenti alla circolazione è rappresentata dal fascicolo di linea, il quale una volta digitalizzato in un database relazionale, potrà essere interrogato automaticamente per fornire dati utili quali chilometraggio, velocità massima in un tratto di linea definito (funzione della tipologia del veicolo in transito e delle caratteristiche della linea), posizione esatta del ponte, presenza di segnali virtuali o reali, ecc. Al fine di fornire informazioni puntuali ed accurate per il data model che si intende progettare, si potrebbe valutare anche l’opportunità, in taluni frangenti, di inserire nuovi punti informativi o tecnologici a ridosso degli impalcati che saranno oggetto di monitoraggio diretto (quindi con sensoristica sul ponte) e non solo indiretto, mediante le misurazioni effettuate dal treno.

1. 1. Dati IT enterprise: al fine di attivare workflow e azioni correttive, ma anche per garantire il ribaltamento dei costi, risulta necessario riuscire ad integrare informazioni inerenti alle turnazioni delle squadre di lavoro, agli interventi manutentivi sia passati che programmati nel futuro, e, in generale, interfacciarsi con sistemi ERP (Enterprise Resource Planning) che contengano informazioni circa ordini di lavoro, magazzino, costi di produzione, ecc. La possibilità di integrare anche variabili economiche consentirà la costruzione di un framework di supporto alle decisioni (DSS) in grado di indirizzare le scelte in funzione di indicatori sia di efficienza che di efficacia.
   2. Dati esogeni: nell’ambito di un approccio olistico multi-sorgente, al fine di rendere i modelli predittivi quanto più affidabili ed esaustivi, potrebbe essere necessario aggiungere alle condizioni al contorno anche variabili esterne quali dati meteo (temperature, intensità e direzione del vento, umidità, ecc.), posizioni GPS in cui si manifestino eventi puntuali in linea (es: irregolarità del profilo delle rotaie), piuttosto che la correlazione di dati strutturati (es: misurazione delle vibrazioni fatte da un accelerometro al passaggio del treno) con dati non strutturati (es: filmato video registrato da telecamera in linea) mediante la costruzione di metadati intelligenti e time-stamp; infatti attraverso moderne soluzioni di video analytics è possibile mettere in correlazione una misurazione numerica puntuale con un video registrato nell’intorno temporale in cui è stata effettuata la misurazione, consentendo quindi di dirimere situazioni di falsi positivi o fornendo dettagli visivi relativi alla misurazione effettuata, il tutto automatizzando la creazione e archiviazione del video con relativa chiave di ricerca che lo metta in correlazione con la misurazione avvenuta.

Configurare la piattaforma di data analytics

Una volta definite le sorgenti di dati necessarie a impostare il problema analitico, espletate le azioni necessarie alla loro fruizione dal layer di analisi dei dati (per esempio mediante la costruzione di specifici connettori e l’utilizzo di API, Application Programming Interface), risulta di fondamentale importanza configurare una piattaforma di data analytics che sia in grado di ricevere i dati in formati diversi e da sorgenti eterogenee, e che agevoli il lavoro dei data scientist/analyst nella “pulizia” degli stessi. Infatti, una volta stabilito un canale di data ingestion, sia esso batch e/o in real-time, risulta di fondamentale importanza riuscire ad orchestrare i vari flussi di dati che dovranno essere oggetto di svariate trasformazioni (es: rimozione outlier, applicazioni di funzioni matematiche, ecc.) prima di costituire un insieme statisticamente rappresentativo. Ultimata la fase di preparazione del campione, la piattaforma dovrà garantire l’integrazione con diverse librerie di algoritmi di Machine Learning (ML) e Artificial Intelligence (AI), così da rappresentare un incubatore per la calibrazione di modelli predittivi, consentendo anche la validazione degli stessi ed eventuali attività di fine tuning. La piattaforma in questione dovrà consentire anche l’orchestrazione dei modelli predittivi calibrati, al fine di effettuare analisi in real time, accertando early warnings utili a identificare problematiche incipienti. Nella definizione di regole e modelli predittivi, si possono utilizzare due approcci [1]:

• Knowledge-based: si basa sia sulle conoscenze acquisite da progettisti e manutentori nell’esercizio delle loro rispettive funzioni, sia sull’utilizzo di analisi FMECA (Failure Mode, Effects, and Criticality Analysis – analisi dei modi, degli effetti e della criticità dei guasti) e RAM (Reliability, Availability, Maintainability) – analisi di affidabilità, disponibilità, manutenibilità). Grazie a tali studi e alle esperienze pregresse acquisite, è possibile identificare a priori i comportamenti anomali a fronte di problematiche incipienti. Effettuando i campionamenti dei valori con frequenze opportune, note a priori le soglie di malfunzionamento, vengono inviati degli allarmi quando i valori soglia sono superati. In questo caso si tratta di un approccio supervisionato.
• Data-driven: grazie alla diffusione della digitalizzazione degli apparati, l’ingegneria di manutenzione dispone di una mole crescente di dati eterogenei e multi-sorgente. Sempre più spesso, tali dati risiedono su database distinti, creando dei veri e propri “silos” che li rendono poco fruibili ai fini delle analisi comparative. Per superare tale problematica, sempre più spesso si ricorrere all’utilizzo di file system distribuiti e piattaforme di data analytics, creando così data lake eterogenei e statisticamente rappresentativi contenenti dati strutturati, semi-strutturati e non strutturati, analizzabili nella loro interezza attraverso un approccio olistico, mediante tecniche di intelligenza artificiale, machine learning, e metodi predittivi. Si sono create dunque le condizioni per identificare delle relazioni tra dati apparentemente indipendenti e disgiunti, estraendo modelli causali e schemi ricorrenti precedentemente sconosciuti, e utilizzabili adesso per predire problematiche e comportamenti anomali. In questo caso si tratterà di metodi non supervisionati.

Ripartire il carico su un cluster distribuito

La piattaforma di data analysis deve essere in grado di interfacciarsi per il destaging dei dati con database relazionali (RDBMS o SQL) e non relazionali (NoSQL). Infatti, la scelta dei database è di fondamentale importanza ai fini della riuscita del progetto IoT, e va fatta tenendo conto delle differenze tra le due macro-categorie e delle diverse peculiarità dei DB NoSQL. I DB SQL utilizzano tabelle dove memorizzano i valori su righe e colonne, mentre i DB non relazionali possono utilizzare archivi costituiti da diversi formati (es: documenti, grafi, archivi valore-chiave, ecc.).

I DB relazionali hanno bisogno della costruzione di schemi ad hoc per accogliere i dati in ingresso, invece i DB NoSQL, ad eccezione di Cassandra DB, hanno un approccio schemaless, eliminando quindi la necessità di uno schema dati in partenza consentendo agli stessi di cambiare struttura al trascorrere del tempo. Ulteriore differenza, forse la più importante, i DB NoSQL possono ripartire il carico su un cluster distribuito, mantenendo quindi prestazioni notevoli garantendo la scalabilità orizzontale (quindi su più server) che i DB SQL non possono raggiungere.

Una volta definito anche il DB su cui verranno memorizzati i dati in ingresso e le relative trasformazioni, la piattaforma di data analytics dovrà abilitare la creazione di opportune dashboad e l’attivazione ed orchestrazione di specifici workflow in funzione degli output dei modelli predittivi, trasformando l’intero framework IoT in un grande e distribuito sistema di supporto alle decisioni.

Infatti, al verificarsi di determinati allarmi scaturiti dalle analisi descritte in precedenza, il DSS dovrà in autonomia mettere in atto tutte le azioni previste, che possono spaziare dall’invio di email o messaggi in tempo reale al Dirigente Movimento affinché valuti se interrompere/rallentare la circolazione, fino alla schedulazione automatica di ordini di lavoro per l’invio di squadre di manutentori in loco affinché verifichino de visu, nella prima data utile,  la veridicità dell’allarme scaturito. Mediante l’utilizzo di una tale architettura le ispezioni alle opere d’arte potrebbero essere schedulate con un approccio data-driven aggiornato in tempo quasi reale.

Azioni attese dalla soluzione IoT

Tutto ciò posto, poco prima del passaggio di un rotabile sull’impalcato, la soluzione IoT sarebbe in grado, in autonomia, di compiere le seguenti azioni:

1. acquisizione dei dati (statici e dinamici) inerenti al rotabile che sta per attraversare il ponte (traffic management data);
2. raccolta dei dati ingegneristici (engineering data) relativi a:
   1. ponte:

• numero di campate e relativa lunghezza;
• tipologia costruttiva e relativi dati tecnici;

1. 1. treno:

• numero di vagoni e relativa geometria e rodiggio;
• numero di assi per vagone;
• carico statico per asse;
• massa frenata;
• velocità;

1.  integrazione di eventuali dati esogeni (external data);
2. acquisizione della risposta strutturale attesa per quello specifico impalcato sollecitato da quel determinato carico dinamico (funzione dei dati acquisiti nei tre passaggi precedenti).

A fronte del passaggio del convoglio, invece, verranno realizzate ulteriori azioni:

1. raccolta dei parametri della risposta strutturale campionati sia dai sensori a bordo treno che da quelli eventualmente installati sull’impalcato (field data);
2. analisi comparativa tra quanto individuato al punto (d) e quanto ottenuto al punto (e). Tali analisi possono avvenire utilizzando metodi dynamic time warping (DTW), che permettono di misurare la distanza Δ(t) tra le sequenze allineate ricevute in input dal sistema (treno + ponte) rispetto alla serie target (calcolata al punto d in un approccio knowledge-based, oppure derivate da misurazioni in cui l’ampiezza del campione tenda a valori ampi). Posto che il valore previsto assunto dalla funzione Ψ_e(t) possa essere maggiore o minore rispetto a quello realmente misurato sul campo Ψ_r(t), definito a priori il valore soglia φ(t) al superamento del quale il comportamento dell’impalcato monitorato possa essere considerato anomalo, per ogni timestamp di campionamento, affinché il ponte operi in condizioni di esercizio ottimali, dovrà essere verificata la seguente disequazione [1]:

{32}

I metodi DTW vengono utilizzati per la fase finale della comparazione, ma risulta necessario approfondire come si possa giungere al valore della risposta strutturale target, nei due casi di specie analizzati nel precedente paragrafo, quello knowledge-based e quello data-driven.

1. Knowledge-based: trattandosi di contesti in cui si abbiano a disposizione analisi FMECA e RAM, e quindi in ambiti puntuali in cui si abbia un’ampia conoscenza delle condizioni al contorno e delle loro evoluzioni al trascorrere del tempo e dell’esercizio (ci si riferisce principalmente a ponti di recente installazione), ci si troverà di fronte a problemi supervisionati, in cui sono note le strutture delle variabili di input (perlopiù dati time series) e quelle di output. A questo punto diventa necessario identificare il sottoinsieme dei parametri della {27} in grado di generare una deriva dei parametri del moto misurati rispetto ai valori di target attesi. Al fine di predire un allarme preventivo (early warning), diventa fondamentale identificare quali siano, tra le n condizioni al contorno dell’equazione {27}, quelle maggiormente in grado di generare una deriva. Tutto ciò posto, si intendono porre all’attenzione tre diversi modelli: Long Short-Term Memory (LSTM), Auto-Regressive Integrated Moving Average (ARIMA), e Random Forest Regressor.
2. Data-driven: quando non si hanno sufficienti informazioni sulle condizioni al contorno del ponte e sulla storia delle stesse al trascorrere del tempo e degli eventi (per esempio sismi pregressi, cedimenti vincolari, cicli di gelo e disgelo, ecc.) risulta molto più complesso giungere analiticamente al calcolo della risposta dell’impalcato, proprio perché non è possibile computare correttamente tutte le variabili in gioco. In questi casi, quindi, l’insieme di spostamenti, velocità o accelerazioni target che saranno analizzati con il metodo DTW al passaggio di ogni treno, dovranno essere derivati indirettamente. Tale stima sarà tanto più accurata, quanto maggiore sarà il numero dei campionamenti. I modelli utilizzabili in questo frangente sono i medesimi descritti per l’approccio knowledge-based, con la differenza che, non potendo in questo caso computare analiticamente la risposta strutturale target, si dovrà procedere con una sua misurazione indiretta. Ricordando il teorema del limite centrale affermante che la somma (o la media) di un grande numero di variabili aleatorie indipendenti e dotate della stessa distribuzione è approssimativamente normale e indipendentemente dalla distribuzione soggiacente, si può ipotizzare che al crescere dell’ampiezza del campione analizzato, allora la distribuzione campionaria tenderà alla distribuzione della popolazione. Quindi ipotizzando di effettuare diverse migliaia di misurazioni al passaggio dei vari convogli sull’i-esimo ponte, si potrà tendere all’approssimazione  della risposta strutturale target funzione delle condizioni al contorno note (massa del veicolo, velocità di marcia, numero di assili, lunghezza dell’impalcato, geometria costruttiva, ecc.), derivando, con un approccio di ingegneria inversa, gli eventuali effetti, nel loro complesso, di condizioni al contorno non note a priori (cedimenti vincolari, degradazione delle proprietà meccaniche dei materiali, ecc.) e ovviamente non identificabili singolarmente.

Alert in caso di rischi per la sicurezza

Tutto ciò posto, qualora la disequazione {32} fosse soddisfatta, la soluzione IoT si limiterebbe a salvare ed indicizzare le grandezze campionate e tutte le variabili al contorno, registrando il soddisfacimento delle condizioni di sicurezza. In caso contrario, invece, potrebbe inviare un alert al Dirigente Centrale Operativo (DCO), permettendo di visualizzare tutte le grandezze necessarie su un cruscotto aggiornato in tempo pressoché reale. In aggiunta, il sistema potrebbe inviare in una mail tutti gli allegati documentali (dati ingegneristici, variabili campionate, deformate, velocità di vibrazione, dati di linea, eventuali immagini video se disponibili da telecamere nei paraggi, ecc.) al fine di agevolare rapide ed efficaci contromisure atte a minimizzare il rischio per i convogli successivi, dirimendo anche eventuali falsi positivi.

Sinergie fra ingegneria ferroviaria e IT

In conclusione, grazie ad una profonda conoscenza ingegneristica, utilizzando nuove tecnologie IoT per il campionamento, la raccolta, la trasmissione e l’analisi dei dati, è possibile creare framework manutentivi data-driven in cui le variabili di stato dei ponti vengono monitorate in tempo quasi reale sia mediante sensori installati sugli impalcati, sia grazie al passaggio di treni commerciali in grado di agire come sensori in movimento. La possibilità di individuare risposte strutturali critiche e/o di identificare loro derive al trascorrere del tempo e dell’esercizio, rappresenta il driver di scelta per indirizzare le ispezioni sul campo con un approccio just-in-case, estendendo la vita utile delle opere d’arte, effettuando interventi manutentivi “su misura” e solo quando strettamente necessari.

La costruzione di uno strumento di supporto alle decisioni automatizzato e data-driven potrebbe rappresentare, nel dominio delle manutenzioni, quella funzione obiettivo in grado di garantire il miglioramento degli indicatori sia di efficienza che di efficacia, minimizzando, al contempo, i rischi per la circolazione ferroviaria. Nell’era dell’Industrial Internet of Things sta prendendo piede una cross fertilization tra l’ingegneria ferroviaria e l’Information Technology, richiedendo l’utilizzo di conoscenze verticalmente integrate che tendono a completare, estendere e superare i limiti dell’ingegneria ferroviaria classica.