Studio ed approfondimento del modello di traffico SUMO. Applicazione alle citta di Piombino e Vado Ligure

(1)

Università di Pisa

Corso di laurea magistrale in ingegneria idraulica, dei trasporti e

del territorio

Studio ed approfondimento del modello di traffico SUMO.

Applicazione alle città di Piombino e Vado Ligure

Relatori:

Prof. Ing. Marino Lupi

Ing. Alessandro Farina

Candidato:

Alessio Amadei

(2)

STUDIO ED APPROFONDIMENTO DEL MODELLO DI TRAFFICO SUMO.

APPLICAZIONE ALLE CITTÀ DI PIOMBINO E VADO LIGURE 2

Sommario

INTRODUZIONE ... 6

CAPITOLO 1 - IL SOFTWARE SUMO ... 7

1.1 Requisiti per eseguire una simulazione con SUMO ... 7

1.2 Rete ... 8

1.2.1 Estrazione della rete... 10

1.2.2 Il pacchetto NetEdit per la creazione del modello di rete ... 11

1.2.3 Modellazione dei parcheggi ... 17

1.2.4 Creazione dei centroidi ... 19

1.3 Domanda di trasporto ... 19

1.3.1 Introduzione ... 19

1.3.2 Creazione del file di domanda ... 20

1.3.3 Determinazione delle trips ... 20

1.4 Simulazioni di traffico ... 22

1.4.1 Microsimulazione ... 22

1.4.2 Modelli Macroscopici ... 23

1.4.3 Modelli Mesoscopici ... 24

1.4.4 Modelli Microscopici ... 24

1.4.4.1 Teoria dell’inseguitore - Car Following ... 25

1.4.4.2 Teoria del cambio corsia - Lane Change ... 27

1.4.4.3 Teoria dell’intervallo minimo di accesso - Gap Acceptance ... 29

1.5 Algoritmi di assegnazione ... 31

1.5.1 Dynamic User Assignment – algoritmo di Gawron ... 32

1.5.2 Assegnazione con l’algoritmo di Dijkstra ... 34

1.5.3 One-shot routing ... 34

1.5.4 Assegnazione incrementale ... 35

1.5.5 Assegnazione stocastica di equilibrio (Stochastic user equilibrium assignment) ... 35

1.5.5.1 Modello c-Logit ... 36

1.5.5.2 Modello Lohse-Logit ... 36

1.5.6 Confronto fra i modelli ... 37

1.6 Assegnazione della domanda di trasporto alla rete: definizione degli itinerari (routes) ... 40

1.6.1 Dynamic User Assignment con SUMO ... 40

1.6.2 Duarouter ... 40

1.6.3 DFRouter ... 44

(3)

1.6.5 DuaIterate ... 53 1.6.6 One-Shot Router ... 55 1.6.7 Assignment Router ... 56 1.6.8 MARouter ... 57 1.6.9 Cadyts Iterate ... 60 1.7 Rerouting ... 65

1.7.1 Chiusura temporanea di uno o più archi ... 67

1.7.1.1 Comportamento dei veicoli alla chiusura di un arco ... 68

1.7.1.2 Variable speed signs ... 70

1.7.2 Chiusura di una o più corsie ... 71

1.7.3 Cambio di destinazione ... 71

1.7.4 Assegnazione di una nuova route ... 72

1.7.5 Reindirizzamento ad una parking area alternativa ... 73

1.8 Risultati della simulazione... 75

1.8.1 Emissioni sonore... 77

CAPITOLO 2 – CASO DI STUDIO DI PIOMBINO ... 80

2.1 Inquadramento territoriale ... 80

2.2 Il porto di Piombino ... 85

2.3 Rilievi di traffico ... 89

2.3.1 Studio del traffico nel periodo di morbida primaverile ... 90

2.3.2 Studio del traffico nel periodo estivo di non congestione ... 92

2.4 Costruzione del grafo di rete di Piombino ... 94

2.5 Simulazione di traffico in condizioni di non congestione ... 97

2.6 Simulazione di traffico negli scenari critici: sabato estivo ordinario, sabato estivo eccezionale ... 99

2.6.1 Modellizzazione della domanda ... 101

2.6.2 Costruzione delle matrici O/D dello scenario di un ordinario sabato estivo ... 103

2.6.3 Simulazione dello scenario di un ordinario sabato estivo... 107

2.6.4 Costruzione delle matrici O/D dello scenario estivo eccezionale (maggiore congestione) - caso di soppressione improvvisa di una nave ... 108

2.6.5 Simulazione dello scenario estivo eccezionale (maggiore congestione) ... 113

2.7 Interventi di mitigazione della congestione ... 115

2.7.1 Modellazione dell’area polmone con SUMO ... 122

2.7.2 Modellazione dei PMV con SUMO ... 123

2.7.3 Confronto fra gli scenari ... 125

(4)

CAPITOLO 3 – CASO DI STUDIO DI VADO LIGURE ... 134

3.1 Il porto di Vado Ligure ... 134

3.2 Oggetto dello studio della simulazione su Vado Ligure ... 135

3.3 Rilievi di traffico ... 135

3.3.1 Studio di traffico nel periodo di morbida invernale ... 139

3.3.2 Studio di traffico nel periodo di punta estivo ... 141

3.4 Itinerari osservati fra casello autostradale e porto ... 144

3.5 Costruzione del grafo di rete in SUMO ... 146

3.6 Simulazione del periodo di morbida invernale ... 149

3.6.1 Costruzione della matrice O/D nel periodo di morbida invernale ... 149

3.6.1.1 Matrice O/D per la simulazione del mattino ... 150

3.6.1.2 Matrice O/D per la simulazione del pomeriggio ... 151

3.6.2 Simulazione dello scenario di morbida invernale ... 151

3.6.2.1 Distribuzione dei flussi sugli itinerari... 151

3.6.2.2 Individuazione delle criticità del sistema nello scenario di morbida invernale ... 152

3.6.2.3 Emissioni acustiche nello scenario di morbida invernale ... 152

3.7 Simulazione del periodo di punta estivo ... 152

3.7.1 Costruzione della matrice O/D nel periodo di punta estivo ... 152

3.7.1.1 Matrice O/D per la simulazione del mattino ... 153

3.7.1.2 Matrice O/D per la simulazione del pomeriggio ... 153

3.7.2 Simulazione dello scenario di punta estivo ... 154

3.7.2.1 Distribuzione dei flussi sugli itinerari... 154

3.7.2.2 Individuazione delle criticità del sistema nello scenario di punta estivo ... 154

3.7.2.3 Emissioni acustiche nello scenario di punta estivo ... 154

3.8 Simulazione di uno scenario critico ... 155

3.8.1 Confronto fra i pacchetti SUMO nello scenario critico ... 156

3.8.2 Confronto con il pacchetto DFRouter... 157

3.8.3 Emissioni acustiche nello scenario critico ... 161

3.9 Interventi per la riduzione della congestione e dell’inquinamento acustico sulla Vecchia Aurelia nel centro di Vado ... 162

3.9.1 Posizionamento dei PMV e delle telecamere ... 166

3.9.1.1 PMV 1 ... 167

3.9.1.2 PMV 2 ... 168

3.9.1.3 Telecamere... 169

3.9.2 Modellazione degli interventi con SUMO ... 171

3.9.3 Risultati della simulazione ... 172

3.9.3.1 Confronto fra lo scenario critico attuale e lo scenario di progetto ... 172

(5)

CONCLUSIONI... 177

Riferimenti ... 179

Indice delle figure ... 180

(6)

INTRODUZIONE

La presente Tesi vuole studiare le principali funzionalità del software di pianificazione e simulazione del traffico stradale SUMO (Simulation of Urban MObility), sviluppato dall’Institute of Transportation Systems del DLR (German Aerospace Center). Uno dei pregi principali del software suddetto è il fatto di essere open source.

Nel capitolo 1, viene svolta una analisi delle principali funzionalità del software.

Dapprima, sono presentati i pacchetti e i comandi principali per la costruzione del modello di rete di trasporto. In particolare, sono presentati i comandi per l’importazione di una rete di trasporto da OpenStreetMap; inoltre viene descritto nel dettaglio il pacchetto Netedit, ossia il pacchetto di SUMO per la creazione e la modifica del modello di rete.

Successivamente, vengono descritti i principali comandi per la creazione di matrici O/D in SUMO e per la generazione delle trips dei veicoli. In SUMO la domanda di trasporto può essere: fornita in input da matrici O/D; creata a partire da rilievi di traffico in sezioni stradali ed intersezioni.

Vi è una trip per ogni veicolo simulato, e, per ogni veicolo, la trip riporta: origine, destinazione e istante di partenza del veicolo dall’origine.

Quindi, sono stati presentati i principali modelli di simulazione del traffico, in particolare il modello microscopico di tipo car following, che viene utilizzato da SUMO per la simulazione dei veicoli.

Successivamente, sono descritti gli algoritmi di assegnazione implementati nei pacchetti di SUMO: la banale assegnazione “tutto o niente”; la cosiddetta “assegnazione dinamica intraperiodale” richiamata mediante il comando DuaIterate, nelle sue due forme deterministica (algoritmo di Gawron) e stocastica (ad ogni passo del procedimento iterativo viene utilizzato il modello Logit); l’assegnazione incrementale; l’assegnazione di equilibrio stocastico, richiamata mediante Marouter.

Infine, vengono presentati i comandi per il rerouting: ossia, è possibile modificare la rete di trasporto “in dinamico” durante la simulazione, ad esempio chiudendo temporaneamente alcuni archi o alcune corsie, oppure modificando temporaneamente le route di alcuni veicoli.

Da ultimo, viene presentata la GUI della simulazione di SUMO e i dati di output della simulazione stessa, con un focus particolare sulle emissioni sonore.

Il software SUMO viene utilizzato nel progetto LIST Port (Limitazione dell’Inquinamento Sonoro da Traffico nei Porti commerciali) per svolgere gli studi di traffico in quattro realtà portuali: Piombino, Vado Ligure, Olbia e Bastia. Nella presente Tesi, sono studiati gli scenari di Piombino e di Vado Ligure.

Nel capitolo 2 è presentato il caso di studio di Piombino. Nel periodo invernale, a Piombino non vi sono problemi di viabilità. Nel periodo estivo invece, soprattutto nei sabati da metà giugno a metà agosto, si formano lunghe code, che hanno origine nel porto e “si propagano” verso l’area urbana; queste code sono dovute principalmente: ai ritardi delle navi (per cui i veicoli devono attendere anche per lungo tempo prima di potersi imbarcare), e la insufficiente capacità dei piazzali antistanti i moli. Il 22 giugno 2019, a causa della cancellazione di una nave, la coda conseguente ha paralizzato l’intera circonvallazione di Piombino.

Nel progetto LIST Port si prevede la realizzazione di un’“area polmone”, atta ad accogliere i veicoli che si devono imbarcare sulle navi. Nella presente tesi, sono stati simulati gli scenari di maggiore congestione del porto di Piombino, e lo scenario di progetto, che prevede l’utilizzo dell’area polmone.

Nel capitolo 3 è presentato il caso di studio di Vado Ligure. Il problema principale di Vado Ligure è il fatto che i veicoli sbarcati dalle navi in genere attraversano il centro di Vado Ligure, percorrendo la “Vecchia Aurelia”. Nel progetto LIST Port, si propone di “spostare” i veicoli diretti al porto, o provenienti da esso, sulla Strada a Scorrimento Veloce, e questo scenario viene studiato in Tesi.

Infine, siccome la rete di Vado Ligure è più articolata di quella di Piombino, sono stati confrontati tra loro le diverse assegnazioni, ossia: l’assegnazione tutto o niente (comando Duarouter); l’assegnazione dinamica intraperiodale (comando DuaIterate), l’assegnazione di equilibrio stocastico (comando Marouter). Inoltre, è

(7)

stato applicato il comando DFRouter, che consente di calcolare le route dei veicoli (e quindi di effettuare l’assegnazione) creando una domanda di trasporto a partire dai conteggi di traffico.

CAPITOLO 1 - IL SOFTWARE SUMO

SUMO (Simulation of Urban MObility) è un software di pianificazione e di simulazione del traffico stradale, open source, altamente portabile (cioè che non necessita di installazione all'interno del sistema operativo su cui viene eseguito), microscopico e continuo, progettato per gestire grandi reti stradali.

La piattaforma di simulazione offre molte funzionalità, come la simulazione microscopica, l'interazione online e simulazione del traffico multimodale.

I cicli semaforici possono essere importati o generati automaticamente, e non ci sono limitazioni sulle dimensioni della rete e sul numero di veicoli simulati.

SUMO utilizza alcuni specifici formati di file per le reti di traffico, ma è in grado di importare mappe codificate in molti formati disponibili al pubblico, come OpenStreetMap, VISUM, VISSIM e NavTeq. SUMO è implementato in C ++ e utilizza solo librerie portatili.

Il software è stato utilizzato in diversi progetti reperibili in letteratura, cercando di rispondere a una grande varietà di problematiche di ricerca; fra queste:

- Valutazione delle prestazioni dei semafori, dalla valutazione di algoritmi moderni fino alla valutazione dei piani semaforici settimanali.

- Studio della scelta del percorso del veicolo, incluso lo sviluppo di nuovi metodi, la valutazione del routing ecocompatibile basato sull'emissione di inquinanti e le indagini sulle influenze a livello di rete della scelta del percorso autonomo.

- È stato utilizzato per fornire previsioni di traffico per le autorità della città di Colonia durante la visita del Papa nel 2005, e durante la coppa del mondo di calcio 2006.

- È stato utilizzato per studiare il comportamento simulato sulla base di informazioni ricavate dai sistemi di telefonia di bordo, per la valutazione delle prestazioni della sorveglianza del traffico basata su GSM.

- È ampiamente utilizzato per fornire i tracciati reali dei veicoli e confrontarli con i risultati di simulazioni di rete.

1.1 Requisiti per eseguire una simulazione con SUMO

Esistono due modi per eseguire una simulazione SUMO: il primo è tramite una serie di comandi impartiti in ambiente DOS, il secondo tramite una “GUI”.

La differenza tra loro è che con il primo si esegue la simulazione senza un'interfaccia utente grafica: tutta la simulazione viene eseguita in background.

Utilizzando invece una “GUI” (Graphical User Interface), all'utente è presentata un'interfaccia grafica che mostra la simulazione di esecuzione, in modo da consentirgli di interagire con essa attraverso tale interfaccia. Ci sono sostanzialmente due diverse informazioni necessarie per iniziare una simulazione SUMO:

(8)

1) Una rete di trasporto

Comprende una rete di strade, ferrovie, percorsi pedonali o altri mezzi per spostare automobili, autobus, tram, camion, treni o persone.

2) Una domanda di trasporto

Una domanda di trasportocomprende auto, autobus, tram, camion, treni o persone, che si muovono secondo un determinato schema lungo la rete.

Questi due requisiti possono essere unificati in termini di una configurazione, che deve essere definita per eseguire una simulazione; tale configurazione può essere definita in SUMO attraverso un file XML.

Fig 1. 1: Esempio di file XML di configurazione

Tale file di configurazione è scaricabile da http://sumo.dlr.de/wiki/Demand/Dynamic_User_Assignment ed è inserito in un pacchetto di file compressi (estensione “.rar”) che devono essere preventivamente inseriti nella cartella di lavoro; il pacchetto contiene:

 Configuration_file.sumo.cfg (è il file di configurazione desiderato)  example.add.xml

 Vari files Python (estensione “.py”).

Oltre a un file di rete, che descrive la topologia di rete (*.net.xml) e uno o più routes files, che descrivono il modello di traffico in termini di veicoli (*.rou.xml), è possibile specificare anche file aggiuntivi (*.add. xml). Questi file aggiuntivi sono facoltativi e descrivono componenti aggiuntivi per la simulazione, come ad esempio un'immagine di sfondo contenente la fotografia aerea della regione interessata, che fornisce una visualizzazione più precisa dell'ambiente; dei POI (Points Of Interest, punti di interesse), come nomi di edifici, negozi o altri punti di riferimento che si desidera includere nella visualizzazione della simulazione; aree di forma poligonale che si desidera rappresentare nella visualizzazione della simulazione.

1.2 Rete

Un file di rete SUMO (*.net.xml) rappresenta e descrive la mappa di un territorio urbano solo in termini di traffico: viene estratto un grafo rappresentativo delle strade e degli incroci, che i veicoli simulati percorrono. La rete risulta modellizzata come segue: ai vari tronchi stradali, compresi fra 2 intersezioni, vengono

(9)

Fig 1. 2: Esempio di rete dell’area adiacente al porto di Piombino

La rete SUMO contiene le seguenti informazioni:

 Archi (edges) che rappresentano segmenti di strade, ferrovie o percorsi pedonali.

Un arco può avere più corsie, ed è caratterizzato da informazioni come la posizione, la forma e il limite di velocità di ogni corsia.

Fig 1. 3: Esempio di arco visualizzato in XML; si possono osservare le informazioni caratteristiche: il suo “id”, i nodi di origine e destinazione, la priority (una misura dell’”appetibilità” di tale arco nel contesto di rete), la forma, la lunghezza e la velocità

 Nodi (nodes), caratterizzati da informazioni che specificano il diritto di precedenza per ogni intersezione.

Fig 1. 4: Esempio di nodo visualizzato in XML; si possono osservare le informazioni caratteristiche: il suo “id”, la tipologia, le sue coordinate ecc...

 Semafori (traffic lights), collegati a specifiche intersezioni, caratterizzati da informazioni riguardo il loro ciclo e i tempi e le modalità con le quali le varie manovre consentite sulle diverse corsie degli archi convergenti nel nodo si susseguono nel tempo.

(10)

Fig 1. 5: Esempio di semaforo visualizzato in XML; si possono osservare le informazioni caratteristiche, come il suo “id” e la durata delle varie fasi del ciclo.

Inoltre, a seconda dei formati di input utilizzati e delle opzioni di elaborazione impostate, si possono anche definire centroidi (sui quali si tornerà in seguito, essendo tali elementi definiti in modo molto differente rispetto alla teoria classica della pianificazione dei trasporti) e rotatorie.

1.2.1 Estrazione della rete

È possibile creare reti geometricamente semplici manualmente, con software dedicati, come Netgenerate; in alternativa, si può effettuare l’estrazione della rete di trasporto di un’area urbana dal sito

www.openstreetmaps.org

OpenStreetMap (OSM) è un progetto collaborativo finalizzato a creare mappe del mondo a contenuto libero, che punta ad una raccolta mondiale di dati geografici, con scopo principale la creazione di mappe e

cartografie.

La caratteristica fondamentale dei dati geografici presenti in OSM è che vengono distribuiti con una licenza libera, la Open Database License: è cioè possibile utilizzarli liberamente per qualsiasi scopo, anche

commerciale, con il solo vincolo di citare la fonte e usare la stessa licenza per eventuali lavori derivati dai dati di OSM.

Le mappe sono create usando come riferimento i dati registrati da dispositivi GPS portatili, fotografie aeree ed altre fonti libere.

È possibile esportare una mappa da OpenStreetMap, ottenendo un file formato “.osm” (file GIS utilizzati da sistemi operativi come Windows 10, Windows 7, Windows 8 / 8.1, Windows Vista, Windows XP).

Per poter lavorare sul modello di rete acquisito, si hanno 2 moduli:

 NetEdit: consente di generare e modificare il modello di rete di trasporto; è caratterizzato da una GUI (Graphical User Interface) con molte funzionalità.

 NetConvert: per poter trasformare un file di rete generato con OpenStreetMap, in un formato leggibile da Sumo.

Netconvert non ha una GUI, ma è utilizzato scrivendo comandi specifici nel prompt dei comandi di DOS.

Quindi, dal prompt del DOS, si entra nella cartella di lavoro e con il comando

netconvert –-osm <nome file>.osm

(11)

1.2.2 Il pacchetto NetEdit per la creazione del modello di rete

La rete può essere visualizzata e studiata, come già visto, con il pacchettoNetEdit.

Selezionando un arco della rete, in modalità “Inspect”, vengono fornite le sue informazioni (editabili):

Fig 1. 6: Informazioni relative all’arco selezionato.

Le informazioni visualizzate sono:

Informazione Tipo Descrizione

id Stringa di testo Indica l’identificativo (il suo nome) dell’arco selezionato from Stringa di testo Indica l’id del nodo di partenza, da cui diparte l’arco in esame

to Stringa di testo Indica l’id del nodo di arrivo (destinazione) dell’arco in esame

speed Numero

positivo Indica la velocità massima di percorrenza dell’arco, espressa in [m/s] priority Numero intero

Indica la “precedenza” dell’arco in esame, è una misura della sua importanza: archi con priority alta avranno una maggior probabilità di essere scelti per gli itinerari

numLanes Numero intero

positivo Indica il numero di corsie dell’arco in esame

type Stringa di testo Indica a quale tipo (fra quelli previsti da SUMO) appartiene l’arco in esame

allow Lista di classi di veicoli

Indica le tipologie di veicoli a cui è consentito transitare sull’arco in esame (ai veicoli non indicati in questa lista non è consentito il transito) disallow Lista di classi

di veicoli

Indica le tipologie di veicoli a cui non è consentito transitare sull’arco in esame (ai veicoli non indicati in questa lista è consentito il transito) shape Elenco di

coordinate

Data una forma dell’arco, sono indicate le coordinate dei nodi di origine e destinazione dello stesso

length Numero

positivo Indica la lunghezza dell’arco in esame in [m] spreadType Elenco a

(12)

name Stringa di testo Nome della strada (opzionale)

width Numero

positivo Indica la larghezza delle corsie dell’arco in esame in [m] endOffset Numero

positivo

Sposta la linea di arresto (lo “Stop”) a monte dell’intersezione fino alla distanza indicata

shapeStart Posizione Posizione di partenza, all’interno dell’arco, dei veicoli (opzionale; di default si assume il nodo di partenza)

shapeEnd Posizione Posizione di arrivo, all’interno dell’arco, dei veicoli (opzionale; di default si assume il nodo terminale dell’arco)

bidiRail Variabile

booleana Mostra se l’arco è bidirezionale

Tab 1. 1: Informazioni visualizzabili su un arco in modalità inspect (NetEdit)

Le classi di veicoli menzionate a proposito dei comandi allow/disallow sono: - Pedestrian: pedoni (per modellare l’utenza che si muove a piedi)

- Emergency: veicoli di soccorso (ambulanze, vigili del fuoco…) - Authority: veicoli delle autorità (polizia…)

- Passenger: è la classe di default, che corrisponde ai normali veicoli dell’utenza privata

- Army: veicoli militari

- Vip: veicoli con permessi speciali

- Hov: acronimo di “High Occupancy Vehicles”, veicoli ad alta capienza - Taxi

- Bus

(13)

- Delivery: veicoli dei mezzi di consegna (poste, corrieri…) - Truck: mezzi pesanti

- Trailer: mezzi pesanti con rimorchio

- Motorcycle: moto

- Moped: mezzi motorizzati a due ruote che non possono transitare in autostrada (scooter/moto di cilindrata insufficiente al traffico autostradale)

- Bicycle: biciclette

- Evehicle: auto elettriche ed altri mezzi che potrebbero ottenere permessi speciali di transito (es nei centri storici)

- Tram

- Rail_urban: metrotram ibridi come LTR (Light rail transit) e S-Bahn (Stadtschnellbahn, cioè city rapid railway, sistema simile al Bus Rapid Transit)

- Rail: treni a trazione elettrica o diesel - Rail_electric: treni a trazione elettrica

(14)

- Rail_fast: treni ad alta velocità - Ship: navi

(15)

Selezionando un nodo della rete, in modalità “Inspect”, vengono fornite le sue informazioni (editabili):

Fig 1. 7: Informazioni relative al nodo selezionato.

Le informazioni visualizzate sono:

Informazione Tipo Descrizione

id Stringa di testo Indica l’identificativo (il suo nome) del nodo selezionato pos Coordinate Indica le coordinate X-Y-Z del nodo in esame, nel sistema di

riferimento della rete, in [m]

type Elenco a

discesa Indica la tipologia di intersezione (a precedenza, semaforizzata ecc…) shape Coordinate Indica la forma dell’intersezione (opzionale)

radius Numero

positivo Indica l’angolo compreso fra gli archi convergenti nel nodo (opzionale) keepClear Variabile

booleana

Indica se l’intersezione in esame è soggetta ad un blocco euristico (non viene considerata nella simulazione)

rightOfWay Elenco a

discesa Indica la regolazione del diritto di precedenza sull’intersezione fringe Elenco a

discesa Indica se l’intersezione si trova ai margini o all’interno della rete tlType Elenco a

discesa

Indica la tipologia di semaforo posto sull’intersezione (a ciclo continuo, attuato o semiattuato)

tl Stringa di testo Indica l’id del piano semaforico adottato (opzionale) Tab 1. 2: Informazioni visualizzabili su un nodo in modalità inspect (NetEdit)

Nel box inferiore è riportato un riassunto degli elementi collegati dall’intersezione, con indicate le corsie impegnate per ogni manovra consentita.

(16)

È possibile anche inserire manualmente un semaforo per regolare l’intersezione:

Fig 1. 8: Creazione di un Traffic Light su NetEdit.

Una volta inserito un semaforo (Traffic Light, TLS) sull’intersezione, si può regolare il ciclo andando ad indicare i tempi di verde (G – green), giallo (Y – yellow) e rosso (R – red).

Fig 1. 9: Classificazione gerarchica delle corsie che hanno la precedenza sull’intersezione.

In assenza di semaforo, le precedenze sull’intersezione sono regolate dalla priority: in modalità inspect, il pannello inferiore dell’intersezione mostra la “gerarchia delle corsie”, ossia elenca in ordine le corsie che hanno la precedenza (vengono ordinate da quella che ha la priority più alta alla più bassa).

(17)

I comandi della GUI sono, in ordine da sinistra a destra:

Fig 1. 10: Comandi della GUI di NetEdit

1) Inspect (la modalità appena descritta) 2) Delete (elimina nodo/arco)

3) Selection (seleziona nodi/archi)

4) Comando che nasconde il menu a tendina di sinistra 5) Crea arco

6) Edit connection (modifica i collegamenti fra archi alle intersezioni) 7) Prohibitions (permette di regolare le precedenze agli incroci)

8) Edit Traffic Light (edita le caratteristiche delle intersezioni semaforizzate) 9) Additional (aggiunge elementi puntuali, es. fermate autobus, sulla rete) 10) Crossings (crea attraversamenti pedonali)

11) TAZs (crea le Traffic Assignment Zones, ossia le zone di origine/destinazione della domanda di trasporto, simili ai “centroidi” della pianificazione dei trasporti)

12) Shapes (crea elementi shapes poligonali)

1.2.3 Modellazione dei parcheggi

All’interno del modello di rete, è possibile definire aree destinate a parcheggio (parking areas).

Non disponendo di un apposito comando sulla GUI di SUMO, tali aree devono essere definite all’interno del file xml di rete, con il comando “parkingArea”.

Si possono definire due tipologie di parcheggio:

 Parcheggio al lato della strada (road-side parking) Si definisce come

<parkingArea id="id area" lane="id corsia" startPos="numero" endPos="numero" roadsideCapacity="capacità in [veicoli]" angle="angolo in [gradi]" length="numero"/>  Area parcheggio (car parking)

Sono aree più vaste, la cui capacità dipende dallo spazio occupato; si definiscono come <parkingArea id="id area" lane="id corsia" startPos="numero" endPos="numero" roadsideCapacity="0" width="numero" length="numero" angle="angolo in [gradi]"> <space x="853" y="623"/>

(18)

Gli attributi della parking area sono

Attributo Descrizione

id Si indica l’id (univoco) dell’area parcheggio

lane Si indica l’id della corsia lungo la quale si sviluppa l’area parcheggio

startPos Si fornisce la posizione in [m] del punto di inizio dell’area parcheggio, misurata come distanza dall’inizio della corsia

endPos Si fornisce la posizione in [m] del punto finale dell’area parcheggio, misurata come distanza dall’inizio della corsia; dev’essere un valore maggiore rispetto a quello indicato in “startPos”

roadsideCapacity Si indica la capacità dei parcheggi road-side, ossia il numero di veicoli che possono parcheggiarsi lungo la strada

width Si indica la larghezza del parcheggio in [m]; di default SUMO assume 3.2 m length Si indica la lunghezza del parcheggio in [m]; di default SUMO la calcola come

(𝑒𝑛𝑑𝑃𝑜𝑠 − 𝑠𝑡𝑎𝑟𝑡𝑃𝑜𝑠) 𝑟𝑜𝑎𝑑𝑠𝑖𝑑𝑒𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦⁄

angle Si indica l’inclinazione degli stalli rispetto alla corsia, misurata in [gradi] (senso orario positivo)

x Per aree parcheggio, si indicano le ascisse dei vertici dell’aera y Per aree parcheggio, si indicano le ordinate dei vertici dell’area

Tab 1. 3: Attributi delle parking areas

Definite le parking areas, la possibilità per i veicoli di accedervi per una sosta dev’essere definita all’interno del loro itinerario; la definizione degli itinerari con SUMO verrà approfondita nei prossimi capitoli, qui ci si limita a dare un esempio di estratto di file degli itinerari con riportato il comando di “stop” per la sosta:

<vehicle id="0" depart="0"> <route edges="e1 e2 e3"/>

<stop parkingArea="pa0" duration="20"/> </vehicle>

Il veicolo, caratterizzato dal suo id, che percorre l’itinerario (route) definito dagli archi (edges) indicati nell’esempio (e1 e2 e3), si ferma (stop) al parcheggio (parkingArea) “pa0” ed effettua una sosta di 20’ (duration).

(19)

1.2.4 Creazione dei centroidi

La domanda viene (da SUMO) ripartita fra gli archi contenuti nella TAZ in maniera proporzionale alla lunghezza e al numero di corsie di ciascun arco.

A partire dal file di rete (estensione “.net.xml”) su NetEdit, quindi, si seleziona il comando “TAZ” visto in precedenza e si tracciano i poligoni corrispondenti ai centroidi, assicurandoci che questi comprendano almeno un arco (per i motivi appena descritti).

Completato il tracciamento, si salva la rete e si chiude NetEdit; alla chiusura, il software chiederà di salvare le shapes create, e rispondendo affermativamente, verrà creato un file di estensione “.add.xml” contenente i poligoni delle TAZ create, con indicazione dei loro id e delle coordinate dei loro vertici.

Per rendere a tutti gli effetti i poligoni creati delle TAZ, sarà necessario rinominare il file degli elementi addizionali con estensione “.taz.xml”.

È possibile modificare l’id delle TAZ create aprendo tale file con il bloc notes di windows (di default, il software utilizza una nomenclatura progressiva del tipo “taz_0”, “taz_1” ecc…).

1.3 Domanda di trasporto

1.3.1 Introduzione

Trip: Una trip è uno spostamento di un veicolo (o persone) da un luogo a un altro, definito da tre elementi:

- arco di partenza - arco di destinazione

- istante di ingresso nel sistema

Route: Una route è un itinerario, ossia una trip estesa, il che significa che una route contiene non solo il

primo e l'ultimo arco, ma tutti gli archi attraversati dal veicolo, dalla sua origine fino alla destinazione finale. A partire da, in alternativa:

 matrici O/D aggiornate per i vari periodi di simulazione

 flussi misurati sulle diverse sezioni stradali,

 percentuale di utenti su ciascuna manovra delle intersezioni stradali, SUMO determina:

 il numero di veicoli da simulare,

 la composizione del parco veicolare (percentuale di veicoli pesanti, di autobus, di motocicli)

 per ogni veicolo da simulare, la trip.

I centroidi come entità tal quali non esistono in SUMO; l’origine della domanda avviene sugli archi (in particolare nel punto centrale degli archi) compresi in aree chiamate Traffic Assignment Zones (TAZ), da definire su Netedit.

La domanda avente origine o destinazione in una data TAZ (ossia avente origine o destinazione nei centroidi contenuti nella TAZ) verrà da SUMO assegnata agli archi contenuti nella TAZ.

(20)

1.3.2 Creazione del file di domanda

La matrice di domanda data deve essere riportata nel file di domanda secondo una modalità precisa: si scrive un file di testo (estensione “.txt”) di questo tipo

1.3.3 Determinazione delle trips

Per la determinazione delle trips sono disponibili i seguenti pacchetti:

 OD2Trips: Riceve in input da una matrice O/D una domanda valida in un certo periodo temporale (per es. 7-9): all’interno del periodo, l’istante di partenza viene determinato mediante estrazione da distribuzione uniforme.

 DFRouter: Determina le trips dei veicoli a partire da misurazioni di traffico nelle sezioni stradali (riceve in input il “detector file”, in cui è riportata la localizzazione delle sezioni stradali di rilievo, e il “measure file”, in cui sono riportati, per ogni sezione di rilievo, i flussi rilevati, la composizione del parco veicolare, e gli istanti di inizio e fine del rilievo).

 JTRRouter: Determina le trips a partire dalle percentuali di veicoli su ogni manovra di ciascuna intersezione della rete (come nel caso precedente, riceve in input un “detector file”, in cui è riportata la localizzazione delle intersezioni stradali di rilievo, e un “measure file”, in cui sono riportati, per ogni manovra dell’intersezione, i flussi rilevati, la composizione del parco veicolare, e gli istanti di inizio e fine del rilievo).

Questi pacchetti, che verranno descritti in dettaglio successivamente, non possiedono una propria interfaccia ma devono essere utilizzati mediante specifici comandi in ambiente DOS.

Per l’impiego di OD2Trips, dal prompt dei comandi del DOS, dopo essere entrati nella cartella contenente i file di rete, delle TAZ e della domanda, si inserisce il comando

od2trips -n <nome file>.taz.xml -d <domanda>.txt -o <nome file>.trips.xml --verbose

Dove

Comando Descrizione

-n Indica il file di rete (il file TAZ contiene, oltre alle TAZ, anche la rete) -d Indica il file da cui considerare la domanda

-o Indica l’output, ossia il file da generare

--verbose È un comando che fa sì che ogni passaggio dell’elaborazione venga scritto, in modo da avere un controllo su eventuali errori.

Tab 1. 4: Comandi di OD2Trips

0.00 è l’istante di inizio e 1.00 quello di fine, in ore, del periodo della simulazione a cui la domanda si riferisce.

Ciò significa che tutti i veicoli qui riportati inizieranno il loro spostamento nella prima ora di simulazione.

Dopo la scritta “* comments”, il testo è organizzato su tre colonne. La prima colonna indica l’id della TAZ di origine della domanda; la seconda colonna indica l’id della TAZ di destinazione; la terza colonna indica il numero di veicoli che si sposta dalla TAZ di origine alla TAZ di destinazione.

(21)

Si ottiene, come prodotto dell’elaborazione, il file di estensione “.trips.xml”

Aprendo il file con blocco note, si possono osservare gli spostamenti dei veicoli, che appaiono espressi nella forma:

<trip id="63" depart="0.79" from="-135430562#1" to="235483368" fromTaz="1" toTaz="2" departLane="free" departSpeed="max"/>

Dove:

Nomenclatura Descrizione

trip id È il codice id assegnato alla trip

depart È l’istante di partenza del veicolo dalla TAZ origine from Indica l’id dell’arco (rappresentativo della TAZ) di origine to Indica l’id dell’arco (rappresentativo della TAZ) di destinazione fromTaz Indica l’id della TAZ di origine

toTaz Indica l’id della TAZ di destinazione

departLane Indica la corsia, dell’arco di origine, dalla quale il veicolo parte (con “free” si intende che il veicolo non è vincolato a partire da una specifica corsia fra quelle appartenenti all’arco origine)

departSpeed Indica la velocità con la quale il veicolo parte (con “max” si intende la massima consentita sull’arco origine)

(22)

1.4 Simulazioni di traffico

1.4.1 Microsimulazione

I modelli di microsimulazione sono in grado di rappresentare in maniera puntuale e specifica il traffico e la sua evoluzione istante per istante, prendendo in considerazione gli aspetti geometrici dell'infrastruttura e il comportamento reale dei conducenti, legato alle caratteristiche del veicolo e del guidatore.

I modelli di simulazione permettono una rappresentazione su scala ridotta e, quindi, ad un costo relativamente basso, degli effetti e delle conseguenze relativi allo sviluppo di un nuovo progetto.

In generale, la modellazione e la simulazione matematica si sono rivelate uno strumento valido, sempre più utilizzato, per l'analisi di un numero sempre maggiore di problemi.

L’obiettivo della simulazione matematica è quello di proporre modelli che rappresentino la condotta del traffico e che restituiscano informazioni e risultati sull'andamento delle principali grandezze coinvolte:

 Numero di veicoli per unità di tempo;

 Velocità dei veicoli;

 Tempo di percorrenza tratto di strada di lunghezza nota;

 Densità;

 Distanziamento veicolare;

Quindi, un modello di microsimulazione è in grado di analizzare ed elaborare, istante per istante, il movimento di ogni singolo veicolo presente sulla rete, in conformità a leggi legate al moto del veicolo e al comportamento del conducente (accelerazione-decelerazione, distanziamento veicolare, cambio corsia, manovre di svolta, precedenze, stop, semaforizzazioni ecc...).

Gli strumenti di microsimulazione, sono utilizzati per analisi di dettaglio, effettuate su aree ristrette, in fase di progettazione; in realtà, la concezione di microsimulazione può essere più realisticamente associata anche a criteri di gestione specifica delle reti infrastrutturali di trasporto, a prescindere dall'entità dell'area

interessata.

La microsimulazione fornisce una visione dinamica del fenomeno, poiché sono prese inconsiderazione le caratteristiche del moto dei singoli veicoli (flusso, densità, velocità, ecc.) non più medie, come accade nei macrosimulatori, bensì reali e variabili istante per istante durante tutta la simulazione.

Attraverso la microsimulazione è possibile rappresentare più gruppi di spostamenti, ognuno caratterizzata da differenti parametri comportamentali (accelerazione, decelerazione, aggressività, tempo di reazione, tipo di utente ecc..) e da diverse tipologie di veicolo (velocità massima, dimensioni, prestazioni, parametri di emissione, ecc..).

I modelli sono utilizzati in ambito progettuale, per effettuare valutazioni sia in fase di realizzazione e sia in fase di collaudo.

Storicamente, il primo approccio al problema del traffico è stato di tipo continuo.

Le prime ricerche si basavano sull’assunzione che il moto dell’insieme dei veicoli presenti su un tronco stradale potesse essere rappresentato assimilandolo al moto di un fluido continuo monodimensionale; quest’assunzione permise di definire alcune variabili di stato, funzioni del tempo e dello spazio, quali il flusso, la densità e la velocità veicolare.

La rete stradale è considerata come una rete d’incanalamenti percorsa dai flussi di traffico.

Le caratteristiche dei tronchi della rete (capacità, velocità medie, ecc..) e la domanda di mobilità (volume di traffico, origine destinazione dei veicoli, ecc..) determina il modo con cui la rete viene percorsa da tali flussi. I tradizionali modelli statici di rete nei sistemi di trasporto non riescono però a rappresentare alcuni fenomeni rilevanti, quali la formazione delle code e la loro successiva dissipazione.

(23)

Tali modelli si basano, infatti, su delle ipotesi di stazionarietà e non consentono di simulare tipi di sistemi di trasporto come le reti stradali urbane molto congestionate.

Gli esperti di mobilità, quindi, da diversi anni si stanno dedicando a modelli di comportamento dinamico, ma solo negli ultimi tempi la ricerca nell’ambito della modellizzazione e assegnazione del traffico si è

indirizzata verso il comportamento dinamico del traffico nell’intero sistema di rete, proponendo dei modelli dinamici di assegnazione del traffico: Dynamic Traffic Assignment (DTA).

I modelli DTA servono a determinare il modello di traffico della rete nel tempo come conseguenza delle interazioni dinamiche dell’offerta e della domanda.

Le proprietà di questi modelli hanno implicazioni importanti sulla pianificazione del traffico e dipendono fortemente dalla scelta del percorso da parte dell’individuo, con tutto ciò che ne consegue, come orario di partenza, destinazioni, percorsi da seguire, e dalla componente traffico e come esso si propaga nel tempo. L’interesse per la creazione di applicazioni matematiche, cioè modelli e algoritmi che descrivano l’ambiente operativo (rete e offerta), e l’utenza con le sue esigenze (domanda), ha portato allo sviluppo di diverse teorie con risultati anche discordi, e in conformità a queste, alla realizzazione e implementazione di svariati software di simulazione a supporto delle diverse strategie di pianificazione dei trasporti.

Questi modelli variano per approccio teorico, metodo di assegnazione, gestione delle casualità e interfaccia grafica.

In base alla grandezza del sistema da simulare e in base al livello di dettaglio che si vuole perseguire, abbiamo in tre differenti modelli.

1.4.2 Modelli Macroscopici

I modelli macroscopici, mirano a descrivere il traffico nel suo complesso, in termini di alcune grandezze tipiche della fluidodinamica quali il campo di velocità, la densità di veicoli o il flusso.

Il traffico veicolare è trattato come un fluido monodimensionale incomprimibile, considerando le seguenti ipotesi di partenza:

1) Il flusso di traffico si conserva, e come tale sarà regolato da una legge di conservazione così come i fluidi;

2) C’è una corrispondenza biunivoca tra velocità e densità e tra flusso e densità, che si concretizza in un’equazione di stato.

Il modello di traffico macroscopico più antico, ma ancora il più famoso, risale al 1955 ed è attribuito a Lighthill e Whitman.

Pur risultando meno precisi, essi permettono di scrivere il problema in una forma compatta e consentono una facile interpretazione dei fenomeni stradali in funzione di parametri globali indipendenti dal comportamento dei singoli guidatori.

In questo caso le variabili d’interesse sono la densità dei veicoli e la velocità media, che sono funzione del tempo e della posizione.

I modelli macroscopici sono quindi caratterizzati da sistemi di equazioni alle derivate parziali che permettono di prevedere il comportamento del traffico in funzione delle condizioni iniziali e di alcune caratteristiche macroscopiche della strada, quali flusso entrante e flusso uscente.

Per modellizzare completamente la rete stradale è necessario prescrivere anche un comportamento agli incroci: tale obiettivo può essere raggiunto tramite un opportuno modello di Riemann Solver, che gestisce il flusso di traffico nell’incrocio.

(24)

In questo tipo di modellazione non viene seguito direttamente il singolo veicolo come avviene nei modelli microscopici, dove si valutano direttamente le traiettorie veicolari, ma semplicemente l’evolversi continuo dell’intero flusso veicolare.

I modelli possono essere: A) Spazio continuo

Si basano su variabili definite in ogni punto dello spazio; soluzioni analitiche di questi modelli sono state fornite per schemi molto semplici, mentre situazioni più complesse richiedono una soluzione numerica attraverso una discretizzazione spazio/temporale.

B) Spazio discreto

Sono più prossimi ai modelli statici: le variabili di base che influenzano la prestazione del ramo (densità e velocità) sono definite a livello dell’intero ramo; la loro soluzione richiede solitamente una discretizzazione temporale.

1.4.3 Modelli Mesoscopici

L’approccio mesoscopico ricorre ad un modello che si ispira alla teoria cinetica di gas, e incorpora anche aspetti probabilistici; per contro, le equazioni che ne derivano comportano difficoltà d’implementazione non indifferente.

Prevedono un livello di rappresentazione più dettagliata rispetto ai modelli macroscopici, simulando le prestazioni della rete a livello aggregato.

La principale differenza consiste nel fatto che per la determinazione delle traiettorie spazio-temporali, è utilizzato un approccio basato sulla teoria dei pacchetti di veicoli: tale approccio consente di rappresentare lo spostamento di un veicolo fino alla sua destinazione.

Attraverso l’utilizzo dei suddetti modelli, è possibile rappresentare numerosi fenomeni di tipo dinamico tra cui formazione e propagazione di code, sovra saturazione ecc… ma non consentono di simulare alcuni fenomeni come sorpassi, cambio di corsia, ecc..

I risultati che si ottengono sono riferiti a gruppi di utenti e non a singoli veicoli; i modelli mesoscopici si applicano, infatti, per studiare il flusso veicolare ipotizzando che lo stesso si muova nel tempo tramite un definito gruppo di utenti con caratteristiche omogenee.

Ogni singolo insieme è composto da veicoli che hanno la stessa origine, la stessa destinazione ed hanno la stessa strategia di scelta (percorso, velocità, ecc..) durante il loro movimento.

1.4.4 Modelli Microscopici

I modelli di simulazione microscopica sono in grado di rappresentare in maniera puntuale il traffico e la sua evoluzione istantanea, prendendo in considerazione gli aspetti geometrici di dettaglio dell’infrastruttura e le caratteristiche del veicolo e del guidatore.

Essi sono in grado di analizzare ed elaborare, istante per istante, il movimento di ogni singolo veicolo presente sulla rete, in conformità a leggi legate al moto del veicolo e al comportamento del conducente. Consentono inoltre di determinare per ogni mezzo alcune grandezze quali posizione, velocità e

accelerazione.

La scelta del percorso, le decisioni di accelerare o di cambiare corsia, il comportamento alle intersezioni di ogni singolo veicolo, vengono esplicitamente modellate.

Ogni veicolo inoltre possiede le proprie caratteristiche relative, ad esempio, alle prestazioni dei singoli mezzi (es. l’accelerazione massima o la velocità) o alle caratteristiche dei guidatori (es. il tempo di reazione o la

(25)

velocità desiderata); infatti in questi modelli, si considera che la posizione del veicolo al tempo t+Δt dipenda dalla posizione e dalla velocità tenuta dal guidatore al tempo t.

Quest’ultima grandezza, invece, è definita da ulteriori fattori, che dipendono dal veicolo considerato e da quello immediatamente davanti; fattori significativi sono perciò la distanza, la velocità relativa, il tempo di percezione e reazione dell’autista in relazione al gap dal veicolo che lo precede e alla velocità di

quest’ultimo, e infine la presenza di altri veicoli nelle corsie adiacenti.

Tutti questi elementi fanno sì che il modello si avvicini il più possibile alla realtà.

I modelli microscopici solitamente considerano la coppia formata dal veicolo e dal suo guidatore come un unico elemento, e non separano quindi il processo decisionale del guidatore dal controllo del veicolo. La ragione principale alla base di questa scelta è dovuta al fatto che questi modelli sono stati preparati, e vengono tuttora utilizzati, principalmente con lo scopo di analizzare i sistemi di traffico.

Di solito il comportamento dei flussi di traffico viene riprodotto come risultato dell’interazione tra i

guidatori, in maniera tale da ottenere una rappresentazione realistica delle dinamiche del deflusso veicolare. Anche se i modelli sono disaggregati, poiché riproducono il moto dei singoli veicoli, sono spesso utilizzati per analisi aggregate (flussi, lunghezze di coda, tempi di percorrenza, ecc.).

Le possibilità di applicazione di un modello microscopico sono molteplici: la progettazione di nuove

infrastrutture (strade, rotatorie, svincoli, ecc.), sistemi di controllo semaforico, corsie riservate, sensi unici di marcia, zone a traffico limitato, ecc.

Questi modelli inoltre, sono in grado di simulare eventi eccezionali (incidenti, cantieri di lavoro, ecc.) i quali provocando una temporanea limitazione della capacità delle sezioni stradali, e potrebbero limitare in modo assai rilevante le condizioni del traffico veicolare.

L’approccio utilizzato da questi modelli è di tipo “micro”, poiché durante tutto l’intervallo di analisi, il comportamento di ogni singolo veicolo viene simulato sulla base di algoritmi decisionali di tipo

comportamentale, i quali stabiliscono, di volta in volta, il cambio di corsia, regolano la distanza dal veicolo che precede l’immissione nelle corsie di accelerazione e decelerazione, i sorpassi, ecc..

Durante la simulazione, a ogni veicolo sono associate caratteristiche dimensionali e comportamentali. Le caratteristiche dimensionali riguardano: lunghezza, larghezza, velocità massima, accelerazione dei veicoli; le caratteristiche comportamentali, invece riguardano la guida dei conducenti: rispetto dei limiti di velocità, aggressività, ecc.

L’aggressività e lo stile di guida dei conducenti possono influenzare l’andamento della simulazione, poiché i guidatori, “molto abili” o “aggressivi”, hanno tempi di reazione più brevi degli altri; essi possono guidare vicino ai veicoli precedenti, trovare intervalli di accesso più rapidamente e facilmente, accelerare e frenare repentinamente.

I microsimulatori basano il loro funzionamento su modelli in grado di rappresentare singolarmente il movimento di ciascun veicolo sulla base del comportamento del conducente, che segue le regole dettate da tre metodi.

1.4.4.1 Teoria dell’inseguitore - Car Following

I modelli car following si basano sull’idea che ogni veicolo si muove lungo una strada seguendo il veicolo che lo precede, perciò la sua dinamica è funzione solo di quel veicolo.

Questa ipotesi è di semplice modellazione matematica, anche se è relativamente poco complessa se confrontata con la totalità dei comportamenti che si tengono durante la guida.

(26)

Fig 1. 11: Rappresentazione del funzionamento dei modelli car following

I modelli car following sono introdotti per la prima volta attorno alla metà del secolo; in essi si assume che ogni guidatore tende a muoversi con la stessa velocità del veicolo che lo precede (veicolo “leader”). Se si considera, quindi, un tratto di strada fissato, ogni macchina occuperà una posizione xi(t) e una

lunghezza Li.

Fra i modelli car following c’è il modello di Gipps, che consiste in due componenti separati di accelerazione e decelerazione.

La prima componente di velocità, espressa dalla prima equazione, rappresenta l’obiettivo di un dato veicolo di raggiungere una velocità desiderata v*_{in accordo con le caratteristiche del veicolo stesso, perciò modella}

la dinamica del veicolo in condizioni di flusso libero; la seconda equazione riproduce la limitazione sulla velocità imposta dal veicolo immediatamente precedente, modellando quindi l’interazione con il veicolo che lo precede.

Si ottiene il seguente sistema:

{ 𝑣𝑎(𝑛, 𝑡 + 𝑇) = 𝑣𝑎(𝑛, 𝑡) + 2.5𝑎(𝑛)𝑇 ∙ (1 − 𝑣(𝑛, 𝑡) 𝑣∗_(𝑛)) ∙ √0.025 + 𝑣(𝑛, 𝑡) 𝑣∗_(𝑛) 𝑣𝑏(𝑛, 𝑡 + 𝑇) = 𝑑(𝑛, 𝑡) + {𝑑(𝑛)2𝑇2+ 𝑑(𝑛) ∙ {2[𝑥(𝑛 − 1, 𝑡) − 𝑠(𝑛 − 1) − 𝑥(𝑛, 𝑡)] − 𝑣(𝑛, 𝑡)𝑇 𝑣(𝑛 − 1, 𝑡)2 𝑑(𝑛 − 1) }} 1 2 Nel quale:

n Indica l’n-esimo veicolo

v∗_(n) _{È la velocità desiderata dell’n-esimo veicolo (condizioni di flusso libero)}

a(n) È la massima accelerazione possibile per il veicolo d(n) È la massima decelerazione possibile per il veicolo

d(n-1) È la massima decelerazione per il veicolo che precede l’n-esimo x(n − 1,y) È la posizione al tempo t del veicolo (n-1)-esimo

x(n, t) È la posizione al tempo t del veicolo n-esimo v(n − 1,t) È la velocità al tempo t del veicolo (n-1)-esimo v(n, t) È la velocità al tempo t del veicolo n-esimo

T È il tempo di campionamento dal quale derivano le prestazioni del modello Da queste relazioni, si ricava un modello dinamico:

(27)

{𝑣(𝑛, 𝑡 + 𝑇) = 𝑚𝑖𝑛{𝑣𝑎(𝑛, 𝑡 + 𝑇), 𝑣𝑏(𝑛, 𝑡 + 𝑇)} 𝑥(𝑛, 𝑡 + 𝑇) = 𝑥(𝑛, 𝑡) + 𝑣(𝑛, 𝑡 + 𝑇)𝑇

Il modello di Gipps permette di simulare la dinamica di ogni singolo veicolo condizionata con le interazioni con il veicolo precedente attraverso due semplici equazioni.

Tale modello è attualmente uno dei più usati e dei più accurati tra i modelli microscopici, grazie anche ad alcune rettifiche che ne semplificano l’impiego.

Per utilizzarlo realmente, è necessario separare i veicoli in classi, raggruppandoli in base alle loro prestazioni (a(n), d(n)).

Questa elevata approssimazione dei casi di traffico riscontrabili riduce notevolmente la complessità del modello, anche se questo richiede comunque la conoscenza di dati molto dettagliati su ogni veicolo, come tutti i modelli microscopici.

In SUMO è possibile utilizzare una vasta gamma di modelli car following specificandoli fra gli attributi vType all’interno del file delle routes, con il comando “carFollowModel”.

Fig 1. 12: Esempio di impiego di modello car following (in questo caso il modello “Krauß”) nella definizione del vType nel file delle routes.

Tenendo conto dei modelli car following, SUMO utilizza due valori per lo spazio occupato dal veicolo: l'attributo "length" descrive la lunghezza vera e proprio del veicolo, l'attributo "minGap" descrive la distanza dello stesso dal veicolo leader in condizioni di congestione.

Fig 1. 13: Rappresentazione della “length” e del “minGap”

All'interno della simulazione, ogni veicolo ha bisogno (quando si ignora la distanza di sicurezza) di length + minGap.

Parametri come il distanziamento minimo (minGap), la massima accelerazione (accel) e decelerazione (decel, o emergencyDecel per frenate d’emergenza) possono essere editate con i comandi indicati.

1.4.4.2 Teoria del cambio corsia - Lane Change

I modelli car following sono usati per modellare strade a un’unica corsia; perciò, per la modellizzazione di tratte stradali più grandi, sarà necessario considerare la possibilità di effettuare dei cambi di corsia. Per questo motivo i modelli car following vengono migliorati con l’aggiunta di una nuova componente modellistica chiamata lane changing models.

(28)

Fig 1. 14: Rappresentazione del funzionamento dei modelli lane change

Il cambio di corsia di marcia può avvenire discrezionalmente o forzatamente.

Cambiare corsia discrezionalmente equivale a seguire la volontà del conducente di sostenere una certa velocità o spostarsi in prossimità di un’uscita.

Il cambio di corsia forzato può dipendere da alcuni fattori, fra cui la geometria della strada e il rispetto della connessione tra i rami che compongono il percorso scelto dall’utente.

Il primo modello lane change è stato introdotto da Gibbs nel 1986; esso è stato progettato per considerare le varie situazioni urbane dove i segnali, le ostruzioni e la presenza di veicoli pesanti (es. bus, camion)

interessano le decisioni dei guidatori su quale corsia percorrere.

I tre fattori principali che sono stati valutati nel processo di decisione sono: la necessità, l’opportunità e la sicurezza di un cambiamento di corsia.

La necessità o l’opportunità di modificare corsia è determinata calcolando un fattore di rischio per ogni guidatore, che è funzione della posizione relativa del veicolo rispetto all’oggetto che dà luogo alla necessità di un cambiamento di corsia.

Il fattore di rischio è determinato dalla decelerazione che un guidatore dovrà applicare se il suo predecessore frena: i fattori di rischio del veicolo in esame nei riguardi di quello che precede e del veicolo che segue nei riguardi di quello in esame sono calcolati per ogni cambio di corsia; il rischio è poi confrontato con un fattore di rischio accettabile che dipende dal tipo di cambiamento di corsia che deve essere effettuato e dalla sua urgenza.

Molti microsimulatori realizzano i comportamenti lane change basati sul modello di Gipps.

I modelli di Lane Changing si basano sulla valutazione della distanza anteriore e posteriore nella corsia di destinazione, a prescindere dalla regola secondo la quale queste due grandezze siano ritenute accettabili. Esistono due tipologie di modelli: deterministici e stocastici.

I cambiamenti di corsia, invece, sono classificati come:

 MLC (scelta obbligata), quando il guidatore deve per forza cambiare corsia come nel caso di rampe di uscita,

 DLC (scelta a discrezione), quando il guidatore capisce che le condizioni di guida nell’altra corsia sono migliori.

In SUMO è possibile utilizzare il modello lane changing specificandolo fra gli attributi vType all’interno del file delle routes, con il comando “laneChangeModel”, analogamente a quanto visto a proposito dei modelli car following.

(29)

Codice Descrizione

LC2013 È il modello di default, che si basa sul modello car following sviluppato da Jakob Erdmann SL2015 È il modello lane changing per i modelli Sublane (modelli usati in caso di circolazione/sorpassi

su singola corsia, come in caso di più veicoli a 2 ruote che guidano in parallelo su una sola corsia, o veicoli che sorpassano una bicicletta su una sola corsia ecc…)

DK2008 È il modello lane changing originale, sviluppato da Daniel Krajzewicz e utilizzato come unica alternativa fino alla versione 0.18.0 di SUMO

Tab 1. 6: Modelli lane-changing implementati in SUMO

1.4.4.3 Teoria dell’intervallo minimo di accesso - Gap Acceptance

Il gap acceptance è un elemento importante nella maggior parte dei modelli lane change: per eseguire manovre di cambio di corsia, il guidatore valuta la posizione e la velocità dei veicoli che lo precedono e in arrivo nella corsia prescelta.

Il “gap” è l’intervallo temporale netto tra l’arrivo di due successivi veicoli che procedono lungo la stessa direzione in corrispondenza del punto di conflitto.

Nel modello di Gap Acceptance, un parametro importante da tenere presente è il “Critical gap”, ovvero il minimo intervallo di tempo (il gap minimo) che un veicolo in ingresso va a individuare prima di immettersi nella corrente di traffico; al contrario, il “Reject gap” è l’intervallo di tempo che definisce l’incapacità del veicolo di immettersi in una corsia a causa dell’eccessivo flusso.

Perciò avremo come “Maximum reject gap” il più grande tra i “Reject gap” di tutti i veicoli rispetto al singolo veicolo.

Pertanto sarà realistico per un singolo veicolo la misura del “Reject gap” e del Gap Acceptance.

In SUMO è possibile definire l’intervallo critico (Critical Gap) per diverse situazioni; come per i modelli car following e lane changing, anche i Gap vengono introdotti nel file delle routes attraverso le definizioni vType.

I comandi di definizione dei Gap rientrano, in SUMO, nella famiglia dei comandi inerenti il comportamento dei veicoli alle intersezioni (Junction Model Parameters):

(30)

Attributo Valore di

default Descrizione

jmCrossingGap 10 Distanza minima dai pedoni che camminano verso il punto di conflitto con il veicolo; se i pedoni sono più lontani, il veicolo può attraversare l'attraversamento pedonale. jmIgnoreKeepClearTime -1 Indica il tempo di attesa accumulato dopo il quale un

veicolo attraversa un incrocio anche se ciò potrebbe causare un la congestione dello stesso. Per valori negativi, il veicolo cercherà sempre di mantenere l'incrocio

sgombro.

jmDriveAfterRedTime -1 Questo valore fa sì che i veicoli violino il semaforo rosso se la durata della fase rossa è inferiore alla soglia indicata; se impostato su 0, i veicoli guideranno sempre in giallo ma proveranno a frenare in rosso. Se questo comportamento induce un veicolo a guidare così velocemente che non è più possibile fermarsi, non tenterà di fermarsi. Questo valore si applica anche al modello pedonale predefinito. jmDriveAfterYellowTime -1 Questo valore fa sì che i veicoli attraversino il semaforo giallo se la durata della fase gialla è inferiore alla soglia indicata. I veicoli che sono troppo veloci per frenare proseguono sempre con semaforo giallo.

jmDriveRedSpeed Valore max di velocità sull’intersezione

Questo valore fa rallentare i veicoli interessati da jmDriveAfterRedTime in caso di attraversamento con semaforo rosso. La velocità specificata non verrà superata quando si entra nell'intersezione.

jmIgnoreFoeProb 0 Questo valore fa sì che i veicoli non diano la precedenza a quelli che arrivano da destra con diritto di precedenza (intervallo [0,1] che indica la probabilità; con “0” il diritto di precedenza viene sempre rispettato, con “1” mai). jmIgnoreFoeSpeed 0 Questo valore viene utilizzato insieme a jmIgnoreFoeProb:

solo i veicoli con una velocità inferiore o uguale al valore dato possono essere “ignorati”.

jmTimegapMinor 1 Questo valore definisce il Gap minimo quando si è in attesa di immissione ad un incrocio (Critical Gap).

impatience 0.0 Comando che indica la propensione dei conducenti a

ostacolare i veicoli con priorità più elevata; l'impazienza di un conducente è un valore compreso tra 0 e 1 che aumenta ogni volta che il conducente deve fermarsi

involontariamente (ad esempio a causa di un ingorgo o in attesa ad un incrocio).

Tab 1. 7: Comandi per la definizione del Gap critico in SUMO

Fig 1. 15: Esempio di definizione di parametri Junction in vType: in questo caso, il veicolo di id “ambulance” attraversa con il rosso se la durata della fase rossa è inferiore a 300 s, e lo farà con velocità 5.56 m/s

(31)

1.5 Algoritmi di assegnazione

Concentrandosi sul compromesso tra l'accuratezza dell'assegnazione e il tempo di calcolo, si possono studiare i diversi metodi di assegnazione del traffico mirati alla simulazione.

Analizzando e confrontando i corrispondenti indici di prestazione a livello di rete, i set di itinerari generati e i rispettivi test di significatività, si nota che il risparmio sui tempi di calcolo è significativo con l'uso di

simulazioni macroscopiche; tuttavia, la carenza di trascurare i le manovre di svolta in tali assegnazioni porta a risultati di assegnazione peggiori.

Inoltre, il tempo di calcolo utilizzato di alcuni metodi microscopici (ad esempio il metodo one-shot) è competitivo con quello dei metodi macroscopici.

Mentre l'esatta parametrizzazione e la sensibilità dei metodi alla dimensione degli scenari necessitano ancora di ulteriori approfondimenti, sembra vantaggioso impiegare tecniche di assegnazione microscopiche o metodi ibridi per produrre una buona assegnazione del traffico.

Nell'ultimo decennio la modellazione microscopica di simulazione è stata ampiamente applicata al fine di descrivere accuratamente i comportamenti di guida e la dinamica del traffico veicolare, che sono importanti per la gestione del traffico online.

Con una matrice origine-destinazione affidabile (matrice O-D) un'assegnazione del traffico accurata produce previsioni precise sullo stato del traffico.

In generale, i modelli applicati nell'assegnazione del traffico possono essere classificati in modelli di simulazione e modelli di equilibrio della rete.

Con l'innovazione e l'avanzamento dell'Information Technology (IT), è aumentato significativamente l'interesse nei confronti della modellizzazione microscopica della simulazione del traffico per descrivere in modo specifico i comportamenti di guida e la dinamica del traffico.

Tale tecnica di modellizzazione è già applicata anche nell'analisi del traffico di reti su larga scala.

L'Institute of Transportation Systems del German Aerospace Centre è stato coinvolto in molti progetti in cui sono stati simulati scenari in città di grandi dimensioni: proprio a tale scopo è stato sviluppato e utilizzato il pacchetto di simulazione del traffico microscopico SUMO, che applica un algoritmo Dynamic User

Assignment (D.U.A.) proposto da Gawron per modellare la scelta del percorso e l'assegnazione del traffico. Con l'aumentare delle dimensioni delle reti, la complessità dell'algoritmo D.U.A. impedisce rapidi

(32)

Tab 1. 8: Tipi di assegnazione e algoritmi utilizzati

1.5.1 Dynamic User Assignment – algoritmo di Gawron

L'algoritmo Dynamic User Assignment sviluppato da C. Gawron (DUA-Gawron), utilizzato dal pacchetto “DuaIterate”, è un approccio microscopico, il che significa che gli itinerari attraverso la rete vengono calcolati per ogni veicolo individualmente.

La procedura di base è la seguente:

1) si inizializza il processo calcolando il percorso più veloce a rete vuota per ciascun veicolo simulato; quindi si imposta la probabilità di utilizzo per questo percorso su "1".

2) si esegue la simulazione utilizzando gli itinerari attuali per ottenere i tempi di percorrenza degli archi nel tempo di simulazione.

3) si confrontano i tempi medi di percorrenza con l'ultima iterazione (se presente) e si esce dal

procedimento se il risultato converge, ovvero se la riduzione del tempo di viaggio medio scende al di sotto di una determinata soglia.