Costruire un database stradale ad alta fedeltà per simulazioni automotive traffic-in-the-loop
Elia Grano and Zihao Guo
IEHV Research Group, Polytechnic University of Turin
September 1, 2026
I cicli di guida standard di laboratorio non riescono a riflettere appieno la complessità della guida nel mondo reale. Questo può limitare l'accuratezza delle simulazioni veicolari e delle analisi delle emissioni.
Per creare scenari di test più realistici, i ricercatori dell'IEHV Group del Politecnico di Torino hanno processato un workflow di acquisizione ed elaborazione di dati stradali ad alta risoluzione per la loro piattaforma di simulazione Traffic-in-the-Loop basata su MATLAB (M-TIL).
Utilizzando la strumentazione GNSS/IMU di Dewesoft e un'annotazione stradale dettagliata, il team ha costruito un database di oltre 1.300 elementi reali di strade e intersezioni. M-TIL utilizza questi dati per generare percorsi di guida realistici e conformi agli standard RDE per la simulazione, la ricerca e la validazione automotive.
Perché i dati stradali reali sono importanti per la simulazione automotive
L'Innovative Electric and Hybrid Vehicles (IEHV) Group fa parte del Dipartimento di Ingegneria Meccanica e Aerospaziale (DIMEAS) del Politecnico di Torino, in Italia. Fondato nel 2013 dalla Prof.ssa Massimiliana Carello, il gruppo lavora su meccanica applicata, guida autonoma, modellazione di batterie e celle a combustibile, e dinamica avanzata del veicolo. Contribuisce inoltre a progetti di ricerca automotive regionali ed europei.
I cicli di guida standardizzati come il Worldwide Harmonized Light Vehicle Test Procedure (WLTP) svolgono un ruolo importante nella certificazione dei veicoli. Tuttavia, i cicli di laboratorio non riescono a riprodurre pienamente le condizioni che i conducenti sperimentano su strade reali.
Fattori come la pendenza stradale, la densità del traffico, le intersezioni e il comportamento di guida cambiano costantemente nella guida quotidiana. Di conseguenza, il consumo di carburante e le emissioni misurati durante i test standardizzati possono differire significativamente dai risultati nel mondo reale [1].
La Commissione Europea ha introdotto il test Real Driving Emissions (RDE) per contribuire a colmare questo divario [2]. Il test RDE richiede che le emissioni dei veicoli vengano misurate su strade pubbliche in condizioni di guida e ambientali definite.
Tuttavia, i test su strada reale introducono un'ulteriore sfida. I ricercatori hanno anche bisogno di scenari controllati e ripetibili per confrontare in modo coerente modelli di veicoli e strategie di controllo. Un singolo percorso RDE non può rappresentare l'intera gamma di condizioni che i veicoli possono incontrare nella guida reale [3].
Una ricerca dell'ICCT ha dimostrato che le differenze tra i consumi di carburante e le emissioni di CO₂ ufficiali e quelli reali si verificano nei principali mercati automotive, come illustrato nella Figura 1 [4].
Questo genera la necessità di metodi di simulazione automotive che combinino il realismo dei dati stradali misurati con la ripetibilità e la flessibilità della simulazione.
Per rispondere a questa esigenza, i ricercatori dell'IEHV Group hanno sviluppato la piattaforma Traffic-in-the-Loop (M-TIL) basata su MATLAB. La sua architettura è mostrata nella Figura 2.
M-TIL crea scenari di guida completi combinando segmenti stradali reali memorizzati in un database dedicato. Ogni segmento contiene informazioni come geometria stradale, altitudine, curvatura, limiti di velocità e topologia delle intersezioni.
Un algoritmo stocastico seleziona e collega questi segmenti per creare percorsi che soddisfano i requisiti RDE, rimanendo al contempo geometricamente coerenti e fisicamente percorribili. Questo approccio consente ai ricercatori di generare un'ampia varietà di scenari di guida realistici per la simulazione e la validazione dei veicoli.
L'accuratezza di queste simulazioni dipende in gran parte dalla qualità e dal livello di dettaglio del database stradale sottostante. In particolare, M-TIL richiede dati spaziali ad alta risoluzione per riprodurre accuratamente la geometria stradale e calcolare parametri come la curvatura.
I servizi di mappatura commerciali possono fornire le coordinate stradali, ma la loro risoluzione spaziale è generalmente troppo bassa per questo scopo. Il calcolo accurato della curvatura stradale richiede punti GPS distanziati di pochi metri l'uno dall'altro [5], un livello di dettaglio che le esportazioni cartografiche standard non offrono.
Per questo motivo, i ricercatori hanno scelto di misurare direttamente le strade reali, creando il dataset ad alta risoluzione necessario per una generazione di scenari automatizzata e geometricamente accurata.
Raccolta ed elaborazione di dati stradali GNSS/IMU ad alta risoluzione
La campagna di raccolta dati stradali è stata condotta con il supporto di Dewesoft d.o.o., che ha fornito un sistema di navigazione inerziale Navion i2 per le misure. La Figura 3 mostra la configurazione completa del sistema di acquisizione dati.
Raccolta di 400 km di dati stradali reali
Il Navion i2 è stato montato magneticamente sul tetto di un furgone per garantire una visuale libera del cielo. Era collegato a un laptop tramite LAN, mentre il software di acquisizione dati DewesoftX è stato utilizzato per configurare il sistema, monitorare le misure in tempo reale e memorizzare continuamente i dati registrati.
Nell'arco di due giorni, il team ha percorso circa 400 km nell'area di Torino, includendo strade urbane, strade extraurbane, autostrade e rampe.
La visualizzazione in tempo reale in DewesoftX ha permesso di verificare la qualità del segnale GNSS durante tutta la campagna. Ha inoltre consentito ai ricercatori di identificare le aree interessate da una ricezione satellitare più debole, in particolare le strade circondate da edifici alti o vegetazione fitta. Queste sezioni potevano quindi essere prioritizzate per la revisione manuale durante il post-processing.
Elaborazione dei dati GNSS per la curvatura e la pendenza stradale
Il Navion i2 ha registrato i dati a 100 Hz. Durante il post-processing, il dataset è stato sottocampionato a una spaziatura uniforme di 2 m tra i punti.
Questo ha fornito una risoluzione spaziale sufficiente per calcolare la curvatura e la pendenza stradale, mantenendo al contempo il dataset gestibile. Ha inoltre eliminato i punti quasi duplicati registrati quando il veicolo era fermo.
La curvatura stradale è stata calcolata dalle coordinate registrate utilizzando metodi standard di geometria differenziale [5], mentre la pendenza stradale è stata ricavata dal profilo di elevazione corretto.
I dati di latitudine, longitudine ed elevazione sono stati convertiti in coordinate cartesiane locali utilizzando una proiezione equirettangolare [6]. I segnali di curvatura e pendenza sono stati quindi lisciati per ridurre il rumore residuo del GNSS, preservando al contempo le principali caratteristiche geometriche della strada.
Il team ha inoltre corretto gli errori di misura causati da condizioni GNSS difficili. Gli effetti multipath dovuti agli edifici potevano introdurre variazioni improvvise nel profilo di elevazione, mentre la perdita temporanea del segnale in aree come i sottopassi poteva generare errori di posizione laterale. Questi punti interessati sono stati corretti utilizzando coordinate affidabili registrate prima e dopo la sezione disturbata.
La Figura 4 mostra le strade percorse durante la campagna di misura. La mappa a sinistra distingue tra strade urbane, strade extraurbane, autostrade e rampe, mentre la mappa a destra mostra la corrispondente elevazione stradale.
Classificazione di strade e intersezioni
A ciascun punto registrato è stato assegnato un tipo di strada basato sulla segnaletica stradale fisica osservata durante la guida, classificato secondo le categorie stradali RDE.
I ricercatori hanno inoltre aggiunto una classificazione secondaria per distinguere in modo più dettagliato gli ambienti stradali, come le principali strade urbane, le strade minori e le strade che attraversano centri abitati più piccoli.
La geometria delle intersezioni è stata identificata sovrapponendo la traccia GNSS misurata a un riferimento cartografico. Le intersezioni sono state suddivise in due tipologie principali:
Single-Point Intersections (SPI) per gli incroci semplici
Multiple-Point Intersections (MPI) per aree più estese come semafori, rotatorie e punti con obbligo di stop o dare precedenza.
Per le posizioni MPI, i singoli punti sono stati ulteriormente classificati in base al loro ruolo nel flusso del traffico. Gli Injection points indicano dove i veicoli simulati possono immettersi sulla strada del veicolo ego, mentre gli ejection points identificano dove i veicoli possono lasciarla.
I ricercatori hanno inoltre registrato il tipo di controllo del traffico e il tipo e la categoria stradale di ciascuna strada che si interseca. Queste informazioni consentono a M-TIL di simulare interazioni più realistiche con il traffico circostante.
L'elevata risoluzione spaziale delle misure del Navion i2 è stata particolarmente importante per questa fase. I dati GNSS/IMU originali a 100 Hz hanno fornito una nuvola di punti densa, mentre la spaziatura di 2 m dei dati elaborati è risultata sufficiente per identificare chiaramente i confini delle intersezioni e la geometria stradale.
La Figura 5 illustra come i segmenti stradali e le intersezioni vengono separati all'interno di un percorso urbano.
Costruzione del database stradale M-TIL e generazione di percorsi conformi RDE
La pipeline di acquisizione dati ha tratto grande beneficio dalle capacità di DewesoftX, che si è dimostrata una piattaforma potente e versatile per la gestione di flussi di dati eterogenei rilevati su strada.
Come illustrato nella Figura 6, il software registra e visualizza simultaneamente più canali fisici, tra cui la velocità nel sistema di riferimento del body-frame, pitch, roll, heading e raw GNSS grezza, sovrapponendo al contempo la traccia GPS live del veicolo su una mappa interattiva.
Questa stretta integrazione tra registrazione multicanale dei segnali e visualizzazione di navigazione in tempo reale, all'interno di un unico ambiente, ha semplificato notevolmente il post-processing: tutti i canali condividono una base temporale, e i segmenti di dati di interesse possono essere identificati spazialmente prima dell'inizio di qualsiasi analisi offline, riducendo sia lo sforzo che il rischio di errori di sincronizzazione nelle fasi successive.
È necessaria una certa manipolazione dei dati. In primo luogo, le coordinate di latitudine, longitudine ed elevazione vengono convertite in coordinate cartesiane locali sugli assi x, y e z tramite la proiezione equirettangolare [6], come mostrato nell'Equazione.
dove:
𝑥 è il vettore dell'asse x locale.
𝑦 è il vettore dell'asse y locale.
𝑧 è il vettore dell'elevazione locale.
𝜆 è il vettore della longitudine.
𝜆1 è il primo elemento del vettore della longitudine.
𝜑 è il vettore della latitudine.
𝜑1 è il primo elemento del vettore della latitudine.
𝑍 è il vettore dell'elevazione globale.
𝑍1 è il primo elemento del vettore dell'elevazione globale.
𝑅 è il raggio terrestre, pari a 6371 km.
Una volta completata la conversione in coordinate cartesiane, è possibile calcolare la curvatura stradale. Grazie alla densa nuvola di punti fornita dalla frequenza di campionamento a 100 Hz del Navion i2, che produce una spaziatura tra i punti di 2 m sufficiente a risolvere la geometria delle intersezioni alla scala degli attraversamenti pedonali, il calcolo si basa sull'Equazione ricavata da [5].
dove:
𝜚 è il vettore della curvatura con segno.
𝑥 è il vettore dell'asse x locale.
𝑦 è il vettore dell'asse y locale.
𝑠 è il vettore della distanza cumulativa.
Il database è composto da una cartella per ciascun tipo di strada. All'interno di ciascuna, viene creata una cartella dedicata per ogni categoria. Ogni combinazione di tipo e categoria di strada dispone quindi di una propria cartella specifica. All'interno di ciascuna, vengono creati due repository, uno per raccogliere i file dei link di intersezione e l'altro per i file dei link stradali.
Le informazioni chiave sono codificate nel nome del file, in modo da non dover caricare tutti i file in memoria per decidere quali selezionare durante la creazione degli scenari. La convenzione di denominazione differisce tra i link di intersezione e i link stradali.
Il nome dei file dei link stradali contiene la loro lunghezza e le variazioni di elevazione assoluta. Il nome dei file dei link di intersezione contiene la loro lunghezza, il tipo (semaforo, rotatoria, ecc.), se si tratta di SPI o MPI, e il tipo e la categoria di strada a cui consentono il collegamento. I nomi dei file delle rampe, che costituiscono un'eccezione alla convenzione di denominazione dei link stradali, contengono informazioni sulla loro lunghezza, il tipo di strada e le categorie di origine e destinazione. La struttura del database e il numero totale di file sono specificati nella Tabella 1.
| Tipo di strada | Link stradali | Link di intersezione | Total |
|---|---|---|---|
| Urban major | 206 | 229 | 435 |
| Urban minor | 29 | 22 | 51 |
| Urban town | 125 | 113 | 238 |
| Rural major | 99 | 87 | 186 |
| Rural minor | 9 | 7 | 16 |
| Motorway major | 190 | 197 | 387 |
| Ramp | 6 | — | 6 |
| Totale | 664 | 655 | 1,319 |
Il processo completato di etichettatura e segmentazione ha prodotto un database di 1.319 elementi stradali e di intersezione, organizzati per tipo e categoria di strada in una directory strutturata che l'algoritmo di generazione degli scenari di M-TIL interroga in fase di esecuzione.
Ogni file codifica gli attributi chiave nel proprio nome: lunghezza, tipo di strada e variazione di elevazione per i link stradali; lunghezza, tipo di intersezione, classificazione SPI/MPI e categorie di strade collegate per i link di intersezione. Questo consente all'algoritmo di generazione di selezionare i segmenti appropriati senza dover caricare ogni file in memoria.
Con questo database a disposizione, M-TIL è in grado di generare percorsi di guida geometricamente coerenti e statisticamente rappresentativi, di lunghezza e composizione arbitrarie, offrendo un ambiente rigoroso e flessibile per la ricerca di simulazione e validazione automotive.
L'algoritmo di generazione degli scenari di M-TIL assembla i segmenti stradali del database in percorsi di guida completi, selezionando e collegando iterativamente i segmenti secondo un insieme di regole probabilistiche.
La generazione del percorso inizia sempre su un segmento urbano, come previsto dalla normativa RDE. A ogni passaggio, l'algoritmo decide se proseguire con il tipo di strada corrente o cambiarlo, e seleziona il segmento successivo in base a quanto la composizione attuale del percorso si discosta dalle proporzioni target.
I vincoli di connettività logica impediscono transizioni non realistiche, e i segmenti di rampa vengono inseriti automaticamente a ogni ingresso e uscita autostradale. Ogni nuovo segmento viene allineato geometricamente al punto finale del percorso esistente, per garantire continuità posizionale e tangenziale.
Un esempio di percorso generato è mostrato nella Figura 7. I segmenti urbani, extraurbani, autostradali e di rampa sono rappresentati rispettivamente in arancione, blu, verde e rosso. Il percorso risultante soddisfa i requisiti compositivi RDE, comprendendo circa il 34% di guida urbana, il 33% extraurbana e il 33% autostradale, con ciascun tipo di strada che supera la soglia minima di 16 km.
Dati stradali reali per una simulazione automotive più realistica
La collaborazione tra l'IEHV Group e Dewesoft ha dimostrato come le misure GNSS ad alta frequenza e un software di acquisizione dati integrato possano fornire la risoluzione spaziale necessaria per una modellazione stradale realistica.
Il progetto ha prodotto un database di 1.319 elementi stradali e di intersezione annotati, fornendo alla piattaforma M-TIL una base concreta e realistica per generare scenari di guida realistici e conformi RDE, di lunghezza e composizione praticamente arbitrarie.
A differenza dei dati cartografici commerciali, il dataset misurato fornisce il livello di dettaglio necessario per riprodurre con precisione sufficiente per la simulazione e la validazione automotive la geometria stradale, l'elevazione, la curvatura e le strutture delle intersezioni.
Il database può inoltre essere ampliato nel tempo con l'aggiunta di nuove città, tipi di strada e requisiti di ricerca, rendendolo una base scalabile per i futuri studi di Traffic-in-the-Loop.
Bibliografia
G. Fontaras, N.-G. Zacharof, B. Ciuffo, "Fuel consumption and CO2 emissions from passenger cars in Europe: Laboratory versus real-world emissions," Progress in Energy and Combustion Science, vol. 60, pp. 97-131, 2017.
J. Dornoff, V. Valverde Morales, and U. Tietge, “On the way to 'real-world' CO2 values? The European passenger car market after 5 years of WLTP”, Jan. 2024. Accessed: Oct. 27, 2025. [Online].
J. Claßen, S. Krysmon, F. Dorscheidt, S. Sterlepper, and S. Pischinger, “Real Driving Emission Calibration—Review of Current Validation Methods against the Background of Future Emission Legislation”, Appl. Sci., vol. 11, no. 12, p. 5429, Jan. 2021, doi: 10.3390/app11125429.
U. Tietge, S. Díaz, Z. Yang, and P. Mock, “From laboratory to road international: A comparison of official and real-world fuel consumption and CO2 values for passenger cars in Europe, the United States, China, and Japan”, May 2017.
R. Goldman, “Curvature formulas for implicit curves and surfaces”, Comput. Aided Geom. Des., vol. 22, no. 7, pp. 632–658, Oct. 2005, doi: 10.1016/j.cagd.2005.06.005.
“Equirectangular projection”, Wikipedia. Aug. 31, 2025. Accessed: Nov. 22, 2025. [Online].