Dall'asfalto al dato: come funziona l'architettura Edge-Cloud di RENEW

Monitorare in modo continuo le pavimentazioni di una città significa raccogliere ogni giorno una quantità enorme di dati: immagini ad alta frequenza, vibrazioni, posizione. Inviare tutto a un server centrale sarebbe costoso, lento e poco rispettoso della privacy. È per questo che la prima scelta progettuale di RENEW, definita da Key4 insieme al Dipartimento di Informatica dell'Università di Bari, è stata superare il modello "tutto nel Cloud".

Perché non basta il Cloud

In un'architettura cloud-centrica il veicolo è solo un registratore: acquisisce e trasmette. Su una flotta di mezzi urbani questo approccio si scontra con tre limiti concreti: la banda necessaria per trasferire flussi video continui, la latenza che ritarda le segnalazioni, la gestione di immagini che possono ritrarre persone e targhe.

RENEW ribalta la prospettiva: ogni veicolo diventa un nodo intelligente della rete. Le elaborazioni che devono essere tempestive avvengono a bordo; al Cloud spettano le analisi più pesanti, l'aggregazione nel tempo e il supporto alle decisioni.

Quattro livelli, un'unica catena

L'architettura è organizzata su quattro livelli:

• Sensori a bordo: camera, unità inerziale, GNSS e pneumatici sensorizzati acquisiscono e sincronizzano i dati.
• Nodo Edge: il Data Collection Device esegue la pre-elaborazione e la detection preliminare dei dissesti in tempo reale.
• Cloud: classifica il tipo di danno, ne stima la severità e aggrega i dati provenienti da tutta la flotta.
• PMS/DSS: visualizza lo stato della rete e supporta le decisioni di manutenzione.

Il distress_event: viaggia solo ciò che serve

Il concetto chiave dell'architettura è il distress_event: quando il nodo Edge rileva un possibile dissesto, genera un evento georeferenziato che contiene solo le informazioni significative per la manutenzione, a partire da posizione e tipo di dissesto rilevato.

Questo approccio basato su eventi riduce drasticamente la banda necessaria. La stima della severità è sempre accompagnata da confidenza e incertezza, perché il gestore deve sapere quanto fidarsi di ogni segnalazione.

Il Data Collection Device: un piccolo data center su due ruote

Il DCD è stato progettato da Key4 e IAT per lavorare in condizioni reali, su un veicolo esposto a vibrazioni, pioggia e polvere:

• Calcolo: modulo NVIDIA Jetson Orin NX 16 GB, dedicato all'inferenza dei modelli di AI.
• Sensori: camera RGB, unità inerziale a 6 assi (accelerometro e giroscopio), ricevitore GNSS con antenna attiva esterna, storage NVMe a bordo.
• Meccanica: contenitore in alluminio pressofuso con tenuta IP67, guarnizioni e pressacavi, staffe antivibranti e viti antimanomissione.

Perché il Jetson Orin NX

La scelta del modulo di calcolo è nata da una campagna di prove comparative su diverse piattaforme GPU, embedded e da data center, con i modelli di object detection della famiglia RF-DETR. Sul Jetson Orin NX 16 GB i tempi di inferenza sono risultati compresi tra circa 9 e 40 millisecondi per immagine, a seconda della dimensione del modello e della modalità di alimentazione: valori compatibili con l'elaborazione in tempo reale. La generazione precedente, Jetson Xavier NX, si fermava tra 65 e 93 millisecondi.

Il risultato è un compromesso equilibrato tra prestazioni, consumi, ingombri e costo, indispensabile per un dispositivo pensato per essere installato su una flotta.

Pensato per la strada: resilienza di rete

Un veicolo urbano attraversa gallerie, zone d'ombra e aree con copertura debole. Il DCD gestisce queste situazioni con buffering locale e logica store-and-forward: gli eventi vengono conservati a bordo e trasmessi appena la connessione lo consente, secondo regole di priorità e di retention. Se un componente non risponde, il firmware passa in modalità degradata invece di fermarsi.

Software moderno, dall'Edge al Cloud

Sia sul veicolo sia nel Cloud i servizi sono containerizzati e orchestrati con K3s, una distribuzione leggera di Kubernetes. Questo permette di aggiornare i modelli di AI e i servizi in modo uniforme su tutta la flotta e di far crescere l'infrastruttura Cloud da un singolo nodo a più nodi, al crescere dei veicoli e dei territori serviti.

Nel Cloud, un data warehouse georeferenziato conserva ogni evento con la sua provenance: quale dispositivo l'ha generato, dove, quando e con quale versione del modello di AI. È la base per costruire uno storico affidabile del degrado e per verificare nel tempo le decisioni prese.

Dalla tecnologia alla decisione

L'ultimo livello è quello che vede il gestore. L'Application Layer è stato progettato a partire dai profili degli utenti: 11 casi d'uso, tra cui stato della rete, trend di degrado, alert, piano manutentivo, report e segnalazioni. L'obiettivo è che l'ufficio tecnico di un Comune non debba interpretare dati grezzi, ma riceva indicazioni chiare su dove e quando intervenire.

Prossimi passi

La progettazione dell'architettura e del Data Collection Device è conclusa. Sono in corso i test funzionali e di integrazione dei prototipi, l'implementazione dei layer software e l'addestramento dei modelli. La fase finale del progetto, entro gennaio 2027, prevede la validazione dell'intera catena in un caso pilota urbano.

Per Key4 è l'applicazione alle infrastrutture pubbliche di competenze maturate in anni di lavoro su IIoT, Edge Computing e sistemi MES per l'industria.

Progetto "RENEW – Sensor-based and data-driven framework for safe and efficient PMS" – CUP B67H24001820007 – Codice pratica XF4UNN8. PR Puglia FESR FSE+ 2021-2027 (fondo FESR) – Azione 1.5 "Interventi per il rafforzamento del sistema innovativo regionale e sostegno alla collaborazione tra imprese e strutture di ricerca" – Avviso "Reti". Progetto cofinanziato dall'Unione europea.