Tesi di Laurea in Ingegneria Gestionale - Dist

Università degli Studi di Genova - Polo di Savona - Facoltà di Ingegneria 

Tesi di Laurea in Ingegneria Gestionale 

Modellistica, Simulazione e Previsione a Breve Termine del 

Comportamento Dinamico del Traffico su Tratti Autostradali 

Candidati: Carlo Caligaris, Iacopo Salvarani 

Relatore: Ch.mo Prof. Ing. Simona Sacone 

Correlatori: Dott. Alessandro Seri, Dott. Ing. Silvia Siri 

Con la Collaborazione di: Società Autostrade per l’Italia S.p.A. 

2006

Sommario 

Questa Tesi si propone di illustrare il lavoro da noi svolto presso la Società Au- 

tostrade per l’Italia e finalizzato alla realizzazione di uno strumento informatico 

in grado di simulare l’andamento del traffico lungo una tratta autostradale. Que- 

ste pagine contengono una descrizione d’insieme dell’ambiente di lavoro in cui ci 

siamo inseriti, una spiegazione teorica degli strumenti matematici ed informatici 

utilizzati ed una presentazione del risultato finale che abbiamo conseguito. Gli 

argomenti scientifici trattati più nel dettaglio sono i modelli matematici per la rap- 

presentazione del traffico e la teoria informatica relativa alla gestione di basi di 

dati relazionali basate sul concetto di transazione.

Ringraziamenti e Notazioni 

Figura 1: Highway Lanes [58] 

3

Carlo Caligaris, Iacopo Salvarani 

Ringraziamenti di Carlo Caligaris e Iacopo Salvarani 

Scrivere questa Tesi e lavorare su questo progetto è stato un lavoro molto lungo 

e difficile, ma al contempo gratificante e foriero di grande soddisfazione. Per 

questi motivi non possiamo che ringraziare la prof. Simona Sacone, la quale ci 

ha proposto questa attività, ci ha consentito di lavorare sempre nelle migliori 

condizioni possibili e ci ha seguito con grande puntualità aiutandoci anche ad 

indirizzare il nostro futuro. Con lei, citiamo anche la Dott. Silvia Siri che si è 

sempre dimostrata gentile e ben disposta nei nostri confronti. 

Meritano un ringraziamento particolare anche tutte le persone che hanno se- 

guito il nostro percorso di inserimento nella realtà aziendale della Società Auto- 

strade per l’Italia. Ci riferiamo sicuramente al Dott. Alessandro Seri che, nono- 

stante i mille impegni, ha sempre trovato il tempo (e la pazienza) per ascoltarci 

e seguire i nostri progressi. Con lui ricordiamo anche Fabio Santucci, che ci ha 

aiutato moltissimo sui tanti problemi tecnici che abbiamo incontrato, sottraendo 

tempo al suo lavoro per dedicarlo a noi. Inoltre, non possiamo non citare Valerio, 

che ha condiviso con noi la Sala Conferenze di Infoblu per due mesi, dimostrando- 

si una persona estremamente affabile e simpatica; Vittorugo, che trovava sempre 

il modo per tirarci un pò su di morale e Mary, una delle persone più gentili con le 

quali abbiamo mai avuto a che fare. 

Vogliamo ringraziare e salutare anche lo staff della sede della Direzione del 

Primo Tronco di Genova per averci accolto e fornito tutto quello di cui abbiamo 

avuto bisogno. Citiamo in particolare il dott. Paolo Spingardi e Cristina Rossi. 

4

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale 

Ringraziamenti di Carlo Caligaris 

Ebbene, questa è la mia Tesi. 

Ho sempre pensato alla realizzazione di questo lavoro come ad un momento 

importante della mia vita. So che, come si dice fino all’abuso, questo non deve 

essere un punto di arrivo ma anzi un punto di partenza, tuttavia, sarebbe nega- 

re la realtà sminuire la dimensione di questo evento. Ho sempre dato un grande 

valore alla scuola ed al lavoro fatto in funzione di essa e la Laurea è una meta 

che ha condizionato ogni aspetto della mia vita fin da quando ho memoria. Aver- 

la raggiunta mi pone in una dimensione nuova che spero possa essere ricca di 

soddisfazione come la precedente. 

La possibilità di scrivere una pagina come questa nella mia Tesi si è pre- 

sentata nel momento in cui ho visto quelle scritte da alcuni miei colleghi. Da 

quel momento, mi sono interrogato molto su come organizzarla e sul criterio con 

il quale inserire le varie persone che, a mio parere, meritano di essere ricordate. 

Alla fine, ho deciso di ringraziare tutti quelli che mi hanno aiutato in modo impor- 

tante durante questi cinque anni e mezzo di Universitá, sia in ambito prettamente 

scolastico che in altri settori. 

Il primo ringraziamento va a Dio e spiegare i motivi mi sembra, come dire, 

superfluo. Quindi, vorrei ringraziare tutti i membri della mia famiglia: mio papà 

Ottavio, che mi ha sempre seguito con grande attenzione, mia mamma Roberta, 

che mi ha sempre aiutato con tutto l’affetto di cui solo una mamma è capace, ed 

i nonni Carlo e Maria (che però tutti chiamano Giovanna) che si sono sempre 

interessati ai miei risultati universitari. Vorrei citare e salutare anche i miei due 

gatti: Spot e Isis. 

Tra i docenti, la prima persona da ringraziare è di nuovo mio papà: il suo 

doppio ruolo non ci ha mai creato grossi problemi e spero che questa situazione 

sia stata ben accetatta anche dall’ambiente circostante. Con lui, saluto anche 

il prof. Oliva. Voglio poi ringraziare la prof. Simona Sacone (e con lei Silvia 

Siri) che ci ha proposto questa Tesi e ci ha seguito nel lavoro conseguente. Un 

5


ringraziamento va anche ad Angelo Alessandri, che si è dimostrato una persona 

molto interessata ed interessante e con il quale spero, in futuro, di intraprendere 

qualche fruttuosa collaborazione. Ringrazio anche il prof. Giribone, che si è 

sempre curato delle mie (alterne) fortune. Infine, voglio ringraziare due ragazzi 

che, per la loro età potrebbero anche essere inclusi nel paragrafo sottostante, ma 

il cui ruolo ne impone la presenza in questo contesto e me li propone come esempi 

da seguire: questi sono Renato Procopio e Federico Delfino (colgo l’occasione 

per ricordare il padre di Federico, scomparso prematuramente, insegnante di rara 

qualità del quale ho avuto la fortuna di seguire un intero corso). 

Infine, vorrei ringraziare un pò di amici. Il più importante e più grande di 

questi ringraziamenti va a Iacopo, il mio amico migliore e l’unica persona con la 

quale sarei stato in grado di svolgere un lavoro così impegnativo come quello ine- 

rente questa Tesi. L’altro amico che ho conosciuto in questi anni è Fabio Gungui; 

ragazzo di grande serietà ed ambizione e cortesia Spero che in futuro potremo 

ancora incrociare le nostre strade che, per adesso, si divideranno. Ho avuto la 

fortuna di condividere il cammino anche con persone con le quali spero di mante- 

nere un rapporto durevole negli anni: Francesca Viale, Michela Morasso, Andrea 

Pitzalis, Livio Ginevri e Federico Beltramini. Queste sono le persone che hanno 

reso il mio soggiorno universitario più leggero e piacevole e la cui amicizia è una 

delle cose più preziose che questi anni mi hanno lasciato. 

6


Ringraziamenti di Iacopo Salvarani 

Onestamente non sono mai stato un drago a fare discorsoni... e non penso di aver 

imparato proprio prima di mettermi a scrivere questa pagina. Non sono mai stato 

un grande amante della forma e in cuor mio spero di non diventarlo mai. Per- 

tanto perdonate il linguaggio un poco colloquiale e prendetelo a testimone della 

sinceritá di ciò che scrivo... 

Con queste poche righe voglio cercare di mostrare tutta la gratitudine che provo 

verso le persone che in questo quinquennio hanno contribuito al raggiungimento 

di questo mio traguardo. 

Grazie a quella gabbia di matti che é la mia famiglia, della quale sono felice 

e fiero di far parte, per il sostegno economico e soprattutto per quello morale. 

Grazie alla Vale, che quando preparavo Impianti Industriali 1 mi hai regalato 

la coccinella volante. 

Grazie a Carlo, col quale ho potuto lavorare e divertirmi al contempo (e non 

mi pare poco). Se non fosse stato per il tuo sprone, pigro come sono, ci avrei 

messo almeno un anno in piú. 

Grazie a tutti i compagni di corso coi quali ho vissuto numerose avventure insieme 

(partite, risate, aperitivi, cene, feste, festini, festoni e altre amenitá del genere), 

per merito vostro sono stati cinque anni piacevoli. 

post scriptum 

Per tutte le persone alle quali tengo, che amo e che stimo ma che non ho citato 

sopra: 

Tranquilli... non mi sono dimenticato di voi (anche se conoscendomi in effetti il 

dubbio era lecito)... semplicemente non avete avuto parte nella mia vita universi- 

taria e non mi sembrava l’occasione adatta per dirvi grazie. 

7


E poi lo sapete, appartenete a qualcosa di ben piú importante di una tesi di lau- 

rea; appartenete alla mia vita quotidiana... e per quella vi tributo giá, anche se 

silenziosamente, 365 grazie all’anno, e 366 nei bisestili. 

8


Notazione Utilizzata 

Organizzazione del Testo 

La Tesi è divisa in Capitoli, Sezioni, Sottosezioni e Sottosottosezioni. 

Nel corso della trattazione, queste quattro suddivisioni saranno riconoscibili per 

il carattere del loro titolo e per il numero che compare a sinistra di quest’ultimo 

(tranne che nel caso delle Sottosottosezioni). 

Il numero identificativo del paragrafo corrente può essere composto da uno, due 

o tre elementi. Evidentemente, il primo numero indica il Capitolo, il secondo, 

ove presente, la Sezione, il terzo, ove presente, la Sottosezione. Le Sottosot- 

tosezioni sono considerate come uno strumento di organizzazione del testo a li- 

vello basso e quindi non hanno alcun numero identificativo (e, conseguentemen- 

te, non compaiono nemmeno sull’Indice). Il paragrafo che state leggendo è una 

Sottosezione. 

Citazioni 

Le citazioni possono comparire in seguito ad una figura o ad un campo di testo. 

Nel caso della figura, indicano la risorsa dalla quale quella figura è stata estratta. 

Se mancante, significa che la figura è stata prodotta dagli Autori della Tesi. Per 

quanto riguarda le citazioni immerse nel testo, esse indicano gli strumenti da cui 

sono state tratte le informazioni riportate in precedenza. A seconda del livello di 

profondità che la struttura del testo assume in un particolare contesto, la citazione 

può essere posta in coda ad un Capitolo, ad una Sezione o ad una Sottosezione 

(non ad una Sottosottosezione). La citazione è valida a ritroso fino al primo titolo 

di una non Sottosottosezione o fino ad un’altra citazione, se precedente a quel 

titolo. 

Evidentemente, ove le citazioni fossero assenti, il testo sarebbe frutto della mente 

degli Autori ed i loro ispiratori sarebbero tanti e tali da non poter comparire in un 

solo riferimento bibliografico. 

9

10 

Carlo Caligaris, Iacopo Salvarani

Indice 

1 Presentazione del Lavoro e di Autostrade per l’Italia S.p.A. 17 

1.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 

1.2 La Società Autostrade . . . . . . . . . . . . . . . . . . . . . . . . 19 

1.2.1 Autostrade per l’Italia . . . . . . . . . . . . . . . . . . . 19 

1.2.2 Infoblu . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 

1.3 AutoTraf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 

1.3.1 Interfaccia di AutoTraf . . . . . . . . . . . . . . . . . . . 22 

1.3.2 Possibili Implementazioni . . . . . . . . . . . . . . . . . 25 

2 Strumenti Matematici 27 

2.1 L’Obiettivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 

2.2 Introduzione ai Modelli di Traffico . . . . . . . . . . . . . . . . . 30 

2.2.1 L’Utilità dei Modelli di Traffico . . . . . . . . . . . . . . 30 

2.2.2 Modelli Microscopici . . . . . . . . . . . . . . . . . . . . 32 

2.2.3 Modelli Macroscopici . . . . . . . . . . . . . . . . . . . 39 

2.2.4 Modelli Mesoscopici . . . . . . . . . . . . . . . . . . . . 44 

2.2.5 Trattazione Analitica . . . . . . . . . . . . . . . . . . . . 45 

2.3 Il Modello Macroscopico di Traffico Autostradale . . . . . . . . . 49 

2.3.1 Un esempio di trasporto nel caso della velocità costante . 51 

2.4 Modelli Differenziali di Traffico Autostradale . . . . . . . . . . . 53 

2.4.1 Ripartenza dopo un blocco . . . . . . . . . . . . . . . . . 55 

2.4.2 La formazione di code . . . . . . . . . . . . . . . . . . . 61 

2.5 Metodi di calcolo numerici alle Differenze Finite . . . . . . . . . 64 

11

INDICE Carlo Caligaris, Iacopo Salvarani 

2.5.1 Generalità Sulle Equazioni Iperboliche . . . . . . . . . . 64 

2.5.2 Introduzione al Metodo delle Differenze Finite . . . . . . 67 

2.6 Il Modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 

2.6.1 La Scelta del Modello . . . . . . . . . . . . . . . . . . . 94 

2.6.2 L’equazione fondamentale di Papageorgiou . . . . . . . . 95 

2.6.3 L’Equazione del Modello . . . . . . . . . . . . . . . . . . 97 

2.6.4 Le Equazioni di Papageorgiou . . . . . . . . . . . . . . . 100 

2.6.5 Inizializzazione del modello . . . . . . . . . . . . . . . . 109 

2.6.6 Pregi e difetti del modello . . . . . . . . . . . . . . . . . 110 

3 Strumenti Informatici Utilizzati 115 

3.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 

3.1.1 Introduzione al Linguaggio di Programmazione Java . . . 116 

3.1.2 Linguaggi Macchina, Assembly e di Alto Livello . . . . . 116 

3.1.3 La Storia dei Linguaggi C e C++ . . . . . . . . . . . . . . 118 

3.1.4 La Storia di Java . . . . . . . . . . . . . . . . . . . . . . 119 

3.1.5 Le Librerie di Classi Java . . . . . . . . . . . . . . . . . . 120 

3.1.6 Gli Elementi Fondamentali di un Tipico Ambiente Java . . 120 

3.1.7 Concetti Fondamentali della Tecnologia ad Oggetti . . . . 123 

3.2 Le Basi di Dati ed i Sistemi di Gestione di Basi di Dati . . . . . . 125 

3.2.1 Introduzione alle Basi di Dati . . . . . . . . . . . . . . . 125 

3.2.2 Modelli dei Dati: il Modello Relazionale . . . . . . . . . 128 

3.2.3 Livelli di Astrazione nel DBMS ed Indipendenza dei Dati 129 

3.2.4 Definizioni Fondamentali . . . . . . . . . . . . . . . . . . 131 

3.2.5 Relazioni e Basi di Dati . . . . . . . . . . . . . . . . . . 132 

3.2.6 Linguaggi ed Utenti delle Basi di Dati . . . . . . . . . . . 134 

3.2.7 Vantaggi e Svantaggi dei DBMS . . . . . . . . . . . . . . 135 

3.3 Oracle9i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 

3.3.1 Introduzione ad Oracle9i . . . . . . . . . . . . . . . . . . 137 

3.3.2 Componenti per lo Sviluppo di Applicazioni su Database . 139 

3.3.3 Componenti di Connessione del Database . . . . . . . . . 140 

3.3.4 Oracle9iApplication Server . . . . . . . . . . . . . . . . 141 

12

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale INDICE 

3.3.5 Confronto con Altri RDBMS . . . . . . . . . . . . . . . . 142 

3.4 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 

3.4.1 Introduzione ad SQL . . . . . . . . . . . . . . . . . . . . 144 

3.4.2 Standardizzazione dell’SQL . . . . . . . . . . . . . . . . 144 

3.4.3 Interrogazioni in SQL . . . . . . . . . . . . . . . . . . . 145 

3.5 JDBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 

3.5.1 Cosa Significa JDBC? . . . . . . . . . . . . . . . . . . . 146 

3.5.2 Gli Oracle JDBC Drivers . . . . . . . . . . . . . . . . . . 146 

3.5.3 La Connessione da Java ad Oracle . . . . . . . . . . . . . 148 

3.6 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 

3.6.1 Introduzione ad XML . . . . . . . . . . . . . . . . . . . 149 

3.6.2 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 

3.6.3 Che Cosa È l’XML . . . . . . . . . . . . . . . . . . . . . 151 

3.6.4 Lo Stack di Protocolli XML . . . . . . . . . . . . . . . . 151 

3.6.5 Specifiche XML . . . . . . . . . . . . . . . . . . . . . . 153 

3.6.6 Le Interfacce di Programmazione . . . . . . . . . . . . . 154 

3.6.7 Altre Specifiche XML . . . . . . . . . . . . . . . . . . . 156 

3.6.8 Java ed XML . . . . . . . . . . . . . . . . . . . . . . . . 159 

3.7 SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 

3.7.1 Cosa è SVG . . . . . . . . . . . . . . . . . . . . . . . . . 160 

3.7.2 Storia e Vantaggi di SVG . . . . . . . . . . . . . . . . . . 160 

3.8 JavaScript ed HTML . . . . . . . . . . . . . . . . . . . . . . . . 162 

3.8.1 Cosa è JavaScript . . . . . . . . . . . . . . . . . . . . . . 162 

3.8.2 Scripting e Programmazione . . . . . . . . . . . . . . . . 163 

3.8.3 Principali Caratteristiche di JavaScript . . . . . . . . . . . 163 

3.8.4 Come Inserire uno Script in un Documento HTML . . . . 164 

3.8.5 ECMAScript . . . . . . . . . . . . . . . . . . . . . . . . 165 

4 Oggetto del Lavoro 167 

4.1 Presentazione del Tratto Milano-Brescia . . . . . . . . . . . . . . 168 

4.1.1 La Autostrada A4 . . . . . . . . . . . . . . . . . . . . . . 168 

4.1.2 Il Tratto Milano-Brescia . . . . . . . . . . . . . . . . . . 171 

13


4.1.3 Quante Auto hanno il Telepass? . . . . . . . . . . . . . . 177 

4.1.4 Matrice di Ingresso ed Uscita . . . . . . . . . . . . . . . 183 

5 Applicazione del Modello 191 

5.1 Il Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 

5.2 Il Simulatore . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 

5.2.1 Equazione della Densità . . . . . . . . . . . . . . . . . . 195 

5.2.2 Equazione della Velocità . . . . . . . . . . . . . . . . . . 197 

5.2.3 Equazione Fondamentale di Papageorgiou . . . . . . . . 198 

5.2.4 Funzionamento del Programma . . . . . . . . . . . . . . 199 

5.2.5 Definizioni . . . . . . . . . . . . . . . . . . . . . . . . . 201 

5.2.6 Ridimensionamento dei Vettori . . . . . . . . . . . . . . 201 

5.2.7 Inizializzazione dei Vettori . . . . . . . . . . . . . . . . . 201 

5.2.8 Cancellazione dei Files XML . . . . . . . . . . . . . . . 201 

5.2.9 Inizializzazione dei Parametri . . . . . . . . . . . . . . . 202 

5.2.10 Inizializzazione degli Ingressi . . . . . . . . . . . . . . . 203 

5.2.11 Inizializzazione delle Uscite . . . . . . . . . . . . . . . . 204 

5.2.12 Inizializzazione di Velocità, Flussi e Densità . . . . . . . 205 

5.2.13 Simulazione . . . . . . . . . . . . . . . . . . . . . . . . 208 

5.2.14 Come Usiamo la JDBC per Passare Queries al Database . 211 

5.2.15 La Nostra Tabella sul Database . . . . . . . . . . . . . . . 214 

5.2.16 Interfaccia del Simulatore . . . . . . . . . . . . . . . . . 215 

5.2.17 Grafici con Matlab . . . . . . . . . . . . . . . . . . . . . 228 

5.3 Considerazioni sui Grafici . . . . . . . . . . . . . . . . . . . . . 231 

5.3.1 Grafico Flusso-Densità . . . . . . . . . . . . . . . . . . . 231 

5.3.2 Assonometria della Velocità . . . . . . . . . . . . . . . . 232 

5.4 Programma di Controllo . . . . . . . . . . . . . . . . . . . . . . 235 

5.4.1 Elenco.js e Controllo.html . . . . . . . . . . . . 239 

5.4.2 Simulazioni Confrontabili e Simulazioni non Confrontabili 241 

5.4.3 Esecuzione delle Query . . . . . . . . . . . . . . . . . . . 242 

5.4.4 Scrittura sui files xml . . . . . . . . . . . . . . . . . . . 242 

5.4.5 Rappresentazione Grafica del Controllo . . . . . . . . . . 249 

14

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale INDICE 

5.5 Qualche Risultato . . . . . . . . . . . . . . . . . . . . . . . . . . 254 

6 Sviluppi Futuri 259 

6.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260 

6.2 Pubblicazione sul Server . . . . . . . . . . . . . . . . . . . . . . 261 

6.3 Disegno delle Curve di Approssimazione delle Entrate . . . . . . 263 

6.4 Applicazione ad Altre Tratte . . . . . . . . . . . . . . . . . . . . 268 

15


16

Capitolo 1 

Presentazione del Lavoro e di 

Autostrade per l’Italia S.p.A. 

Figura 1.1: Infrared picture of the interchange of I-95 and I-695, northeast of 

Baltimore. [61] 

17

1.1. INTRODUZIONE Carlo Caligaris, Iacopo Salvarani 

1.1 Introduzione 

Per la realizzazione di questa Tesi, abbiamo collaborato con la Società Autostrade 

per l’Italia S.p.A.. 

Il nostro obiettivo era quello di realizzare un simulatore di traffico autostra- 

dale su una tratta specifica (nel nostro caso la Autostrada A4 nel tratto Milano - 

Brescia). In pratica, abbiamo costruito un software in grado di ricevere in ingres- 

so i dati sul traffico rilevati sulla rete, elaborarli secondo un modello matematico 

derivante dalle equazioni di continuità e di conservazione della massa caratteri- 

stiche della dinamica dei fluidi ed ottenere dei valori previsti di velocità, flusso e 

densità per i 30 minuti successivi all’istante di partenza. Questi dati vengono poi 

visualizzati tramite un’interfaccia che ne consente la comprensione immediata. 

Entreremo nel dettaglio del nostro lavoro nei Capitoli seguenti; per ora ci interes- 

sa introdurre l’ambiente al quale abbiamo fatto riferimento durante lo svolgimento 

del nostro lavoro, ossia quello della Società Autostrade. 

18

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale CAPITOLO 1. PRESENTAZIONE DEL LAVORO E DI AUTOSTRADE PER L’ITALIA S.P.A. 

1.2 La Società Autostrade 

Il Gruppo Autostrade si posiziona al primo posto in Europa tra i concessionari di 

costruzione e gestione di autostrade a pedaggio e di servizi alla mobilità. Tra le 

società del gruppo è compresa Autostrade per l’Italia S.p.A., che ha in gestione 

2854.6 km di rete autostradale (tra cui anche il tratto di nostro interesse). Tra 

le attività collegate al proprio core business, il Gruppo Autostrade ha attivato la 

Infoblu S.p.A., che svolge attività relative alla produzione e diffusione di servizi 

informativi sulle condizioni del traffico lungo la rete autostradale. [54] 

1.2.1 Autostrade per l’Italia 

Autostrade per l’Italia, controllata al 100% dalla holding Autostrade S.p.A., è la 

società capofila del settore autostradale del Gruppo Autostrade, che dal 1 luglio 

del 2003 ha completato il processo di riorganizzazione strategica (Progetto Medi- 

terraneo), attraverso il conferimento delle attività operative a società di nuova co- 

stituzione. A seguito del conferimento, la società concessionaria delle attività di 

costruzione e gestione della rete autostradale Autostrade concessioni e costruzioni 

S.p.A. ha assunto. la nuova denominazione Autostrade per l’Italia S.p.A.. 

Autostrade per l’Italia, oltre alla rete in concessione, controlla a sua volta altre 

8 società concessionarie (Traforo Monte Bianco, Raccordo autostradale Valdosta- 

no (RAV) Torino-Savona, Tangenziale di Napoli, Società Autostrade Meridiona- 

li (SAM), Strada dei Parchi, Società Autostrada Tirrenica (SAT) e Pedemontana 

Lombarda). La rete gestita da tutte le società concessionarie appartenenti al Grup- 

po ha un’estensione di 3408.1 Km, pari al 62% della rete autostradale italiana a 

pedaggio. 

19

1.2. LA SOCIETÀ AUTOSTRADE Carlo Caligaris, Iacopo Salvarani 

Figura 1.2: Organigramma [55] 

L’impegno di Autostrade per l’Italia è focalizzato ad assicurare la massima 

funzionalità della rete autostradale e a perseguire il costante miglioramento del- 

la sicurezza e della qualità del servizio offerto alla clientela, anche attraverso lo 

sviluppo di servizi innovativi. La continuità dell’impegno profuso da Autostra- 

de per l’Italia rispetto alla sicurezza, la telematica e l’ambiente hanno consentito 

alla Società di partecipare con un ruolo di primo piano alla Piattaforma Tecnolo- 

20


gica Europea, dedicata al tema della costruzione e della gestione delle infrastrut- 

ture promossa dalla Direzione Generale Ricerca della Commissione Europea e 

finalizzata allo sviluppo di piani pluriennali di ricerca e innovazione tecnologica. 

[54] 

1.2.2 Infoblu 

Infoblu nasce dalle più avanzate tecnologie del gruppo Autostrade e cresce come 

società nel settore dell’infomobilità offrendo informazioni e servizi personalzzati 

ed in tempo reale. 

Infoblu, nata nel 2000 con le più avanzate esperienze e tecnologie del gruppo Au- 

tostrade, è un progetto che si è evoluto nel tempo e che è oggi partecipato al 100% 

da Autostrade SpA con un team composto da persone altamente qualificate in gra- 

do di rispondere alle esigenze di mercato. 

Infoblu nasce per soddisfare i bisogni di informazione sulla viabilità delle per- 

sone in movimento, con l’obiettivo di erogare in modo utile, semplice e veloce 

servizi sull’infomobilità ad automobilisti ed a chiunque necessiti informazioni e 

contenuti autorevoli su traffico, percorribilità delle autostrade, eventi autostradali 

che hanno incidenza sulla mobilità, percorsi alternativi, microclima e molto al- 

tro. Attraverso le più moderne tecnologie, Infoblu è in grado di erogare contenuti 

sull’infomobilità a emittenti televisive e radiofoniche, operatori on line, società di 

servizi e diversi altri operatori che necessitano di informazioni in tempo reale su 

percorsi autostradali, traffico, tempi di percorrenza, proiezioni ed altro. 

A livello concettuale in Infoblu si può identificare il seguente ambito di sviluppo 

tecnologico: sistemi e tecnologie volte a fornire al personale operativo interno, 

agli utenti ed al mondo degli operatori del settore le informazioni sulla viabi- 

lità, lo stato della percorribilità della rete (tempi di percorrenza, immagini e vi- 

deo), le criticità nei percorsi (incidenti, cantieri, etc.), gli impedimenti di natura 

meteorologica, servizi e facilities usufruibili su rete. [56] 

21

1.3. AUTOTRAF Carlo Caligaris, Iacopo Salvarani 

1.3 AutoTraf 

Per rispondere alle moderne esigenze di infomobilità, Autostrade ha sviluppato 

un sistema di rilevazione dei tempi di percorrenza sulle tratte autostradali. Tale si- 

stema, denominato AutoTraf, consiste nell’effettuare in modo completamente au- 

tomatico la stima delle condizioni di viabilità basandosi su una misura oggettiva: 

il tempo di percorrenza tra due stazioni successive. 

Ogni giorno la rete autostradale è percorsa da 4 milioni di veicoli che al loro 

ingresso in autostrada ricevono un biglietto (fisico o virtuale) che viene ritirato in 

uscita. Quando un veicolo entra ed esce dalla rete autostradale vengono registrate 

la stazione, la data e l’ora di transito. È possibile quindi ricostruire il tempo di 

percorrenza da una stazione all’altra e, nota la distanza tra queste stazioni, la ve- 

locità media mantenuta. Confrontando i tempi di percorrenza con dei tempi medi 

stimati per ciascuna tratta è possibile determinare lo stato della viabilità sulla rete 

autostradale. 

AutoTraf calcola il tempo necessario per percorrere una tratta base, intesa co- 

me tratta autostradale tra due accessi (entrata/uscita) consecutivi, utilizzando i 

dati provenienti dalle piste Telepass, ed integrandoli con quelli provenienti da una 

rete di sensori collocati in itinere. Nel seguito parleremo dettagliamente della 

sensoristica utilizzata. [4] 

1.3.1 Interfaccia di AutoTraf 

Il sistema dispone di un’interfaccia web che mostra, nella prima schermata, lo 

stato della percorrenza sull’intera rete autostradale, attraverso l’uso di colori che 

esprimono le condizioni di viabilità attualmente stimate per ogni tratto. 

22


Figura 1.3: Rete Autostradale gestita da AutoTraf [53] 

Il colore blu indica una situazione indeterminata per carenza di dati, mentre il 

traffico regolare, rallentato, o con code viene indicato rispettivamente con i colori 

verde, giallo o rosso. L’attribuzione di un colore ad un tratto avviene in base 

all’indice di percorrenza stimato ed alle soglie definite per quel tratto: se l’indice 

di percorrenza è minore di 1.5, ovvero se il tempo stimato non supera il 150% del 

tempo di riferimento, il colore è verde, giallo se l’indice è compreso tra 1.5 e 2.0, 

23


e rosso se è maggiore di 2.0. Con un click su un’area della cartina, si accede ad 

una visione di dettaglio della rete. Il sistema offre attualmente un dettaglio per 

ognuno dei nove tronchi. 

Figura 1.4: Dettaglio della A4 e della A8 [53] 

È possibile avvicinare ulteriormente il punto di vista dell’utente visualizzando 

una particolare tratta compresa nella schermata precedente. 

Figura 1.5: Il tratto Milano-Brescia [53] 

Da queste pagine è possibile collegarsi a pagine di supporto in grado di vi- 

sualizzare informazioni sui vari tipi di congegni elettronici distributi lungo la rete; 

24


ogni telecamera, boa in itinere, stazione etc. è collegata ad un pop-up che propone 

diverse elaborazioni dei dati ricevuti da quel dispositivo. [4] 

1.3.2 Possibili Implementazioni 

Dalla breve descrizione che abbiamo fornito di AutoTraf, appare chiaro come 

esso sia in grado di fornire esaurienti informazioni sullo stato presente della rete 

autostradale, ma non abbia la possibilità di fornire alcuna informazione di tipo 

previsionale su ciò che più probabilmente è in procinto di accadere. Il nostro 

compito è proprio quello di elaborare uno strumento che sia in grado di attingere 

dalle stesse risorse di AutoTraf ma che possa fornire indicazioni di massima sulla 

situazione del traffico nell’immediato futuro. 

25


26

Capitolo 2 

Strumenti Matematici 

Figura 2.1: Atlanta traffic jams at the interstate connector in downtown [63] 

27

2.1. L’OBIETTIVO Carlo Caligaris, Iacopo Salvarani 

2.1 L’Obiettivo 

Come già illustrato nella sezione precedente l’obiettivo proposto è quello di stu- 

diare e cercare di prevedere, almeno nell’immediato futuro, il comportamento del 

traffico veicolare in un momento qualsiasi e su un tratto autostradale. 

Per raggiungere questo proposito occorre passare dallo studio del fenomeno 

in sè allo studio di una sua modellizzazione. Occorre pertanto seguire i seguenti 

punti. 

• Trasformare in informazioni matematiche tutti i dati relativi all’autostrada, 

quali la condizione del traffico (scorrevole, congestionato, rallentato, ecc.), 

le caratteristiche della carreggiata (velocità massima delle corsie, capienza 

massima di veicoli, ecc.), la quantità di veicoli in ingresso ed in uscita dalle 

stazioni di pedaggio e molte altre. 

• Scegliere un insieme di grandezze che, ad ogni istante di tempo t, descriva- 

no in maniera esauriente lo stato in cui si trova il sistema. Esse prendono il 

nome di variabili di stato del sistema: 

– ρ(x, t) è la densità veicolare e definisce quanti veicoli stanno impe- 

gnando la carreggiata autostradale al tempo t ed in x; 

– q(x, t) è il flusso veicolare e definisce quanti veicoli attraversano la 

sezione in x, in un determinato intervallo di tempo t; 

– v(x, t) è la velocità media e definsce la velocità media che i veicoli 

mantengono al tempo t ed in x. 

• Scegliere un insieme di grandezze dinamiche che ad ogni istante di tempo 

t descrivano in maniera esauriente l’interazione fra l’esterno ed il sistema. 

Esse prendono il nome di variabili di ingresso del sistema e sono: 

– r(x, t) è il flusso di veicoli in ingresso e definisce quanti veicoli si 

immettono, in un determinato intervallo di tempo, sulla carreggiata, al 

tempo t ed in x; 

28

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale CAPITOLO 2. STRUMENTI MATEMATICI 

– s(x, t) è il flusso di veicoli in uscita e definisce quanti veicoli fuo- 

riescono, in un determinato intervallo di tempo, dalla carreggiata, al 

tempo t ed in x. 

• Scegliere un insieme di grandezze statiche che descrivano in maniera esau- 

riente quelle che sono le caratteristiche fisiche della carreggiata autostrada- 

le. Esse prendono il nome di parametri fisici del sistema e sono: 

– vmax(x) è la velocità massima e definisce la velocità che mediamente 

possono tenere i veicoli, in x con condizioni di traffico scorrevole e 

carreggiata libera; 

– ρmax(x) è la densità massima (o densità di congestionamento) defini- 

sce, in x, il valore di densità di veicoli che comporta un congestiona- 

mento e quindi il relativo blocco del traffico; 

– τ, ν e χ sono ulteriori parametri che definiscono altre proprietà della 

carreggiata ed il cui significato fisico verrà illustrato successivamente. 

• Definire in quale maniera gli elementi del fenomeno reale interagiscono 

e dipendono fra di loro. Gli stessi comportamenti dovrebbero essere de- 

scritti anche dal modello matematico. Le interazioni e le dipendenze fra 

tutte le grandezze in gioco dovranno trasformarsi in equazioni e funzioni 

matematiche che agiranno sulle variabili di stato del modello. 

29

2.2. INTRODUZIONE AI MODELLI DI TRAFFICO Carlo Caligaris, Iacopo Salvarani 

2.2 Introduzione ai Modelli di Traffico 

La realtà è multidimensionale. Questa ovvia affermazione è, in sostanza, il motivo 

dell’interesse a sviluppare modelli matematici basati su equazioni a derivate par- 

ziali. Spesso, anche un modello che utilizza equazioni differenziali ordinarie è il 

risultato della semplificazione di un modello originariamente formulato in più va- 

riabili. Nella riduzione del modello si utilizzano solitamente ipotesi che, talvolta, 

permettono un’utile semplificazione; tuttavia, questa non può essere la situazione 

generale. 

Per determinati obiettivi la forma particolare di un corpo, la sua composizione 

eterogenea e la presenza di stati transitori non possono essere trascurati senza che 

il modello perda di utilità. Di conseguenza si ha un aumento nel numero delle di- 

mensioni spaziali e/o l’introduzione di una variabile temporale. Il modello cresce 

in complessità, ma, in corrispondenza (almeno questa è la speranza), aumenta la 

sua capacità di rappresentare un fenomeno reale. 

Tuttavia, la potenzialità informativa di un modello matematico dipende, in 

maniera essenziale, dalla sua risolubilità. 

2.2.1 L’Utilità dei Modelli di Traffico 

Il crescente numero di veicoli che ogni giorno circola sull’intera rete autostradale 

italiana comporta inevitabilmente la generazione di ingorghi e rallentamenti che, 

oltre a creare un notevole disagio agli automobilisti, aumenta il rischio di inci- 

denti. Esistono due possibili soluzioni, diametralmente opposte, a questo annoso 

problema. 

La prima prevede di aumentare la capacità delle arterie stradali con l’aggiunta 

di nuove corsie. Tale approccio, seppur molto efficace, risulta essere molto co- 

stoso e di forte impatto ambientale, in quanto richiede sovente la costruzione di 

nuovi ponti, gallerie e altre infrastrutture. Inoltre, nella maggior parte dei casi, la 

capacità di sopportazione del traffico da parte di strade ed autostrade risulta essere 

insufficiente solo in alcune particolari fasce orarie della giornata (fasce di punta). 

Per tale ragione si è cercata una soluzione alternativa che consiste nello sfrut- 

30


tare la massimo le potenzialità delle attuali infrastrutture andando a monitorare 

continuamente le condizioni del traffico e, attraverso azioni preventive, tentare di 

evitare la creazione di ingorghi. 

La modellizzazione di strade urbane ed extraurbane ha attirato l’attenzione di 

molti studiosi del settore già a partire dalla seconda metà degli anni ’50. Negli 

ultimi anni, poi, si è notato un notevole aumento dell’interesse e del lavoro di 

ricerca dedicato alla risoluzione dei problemi legati al traffico stradale ed auto- 

stradale, proprio a causa della sopracitata crescita del numero di veicoli circolanti 

ed ai sempre più frequenti problemi di sovraccarico della rete stradale. 

Gli sforzi degli esperti del settore hanno condotto alla creazione di modelli 

matematici che potessero riprodurre fedelmente la realtà. In tal maniera è stato 

possibile ottenere strumenti informatici i quali permettono principalmente due tipi 

di analisi. 

Una di queste è quella simulativa e consiste nell’osservare come il modello 

si comporta se sollecitato da particolari condizioni esterne, senza che queste deb- 

bano per forza verificarsi nella realtà. Infatti, potrebbe sicuramente interessare al 

gestore di una tratta stradale sapere cosa accadrebbe se, per un qualsiasi motivo 

che esula dalla quotidianità, la tratta in questione fosse temporaneamente sottopo- 

sta a condizioni ben diverse da quelle di regime (per esempio un drastico aumento 

dei veicoli dovuto ad una eventualità particolare o una diminuzione del numero di 

corsie percorribili). 

La seconda analisi è di tipo previsionale, e consiste nel monitorare, istante 

per istante (quindi on-line e real-time), le condizioni del traffico veicolare e da 

queste trarre importanti indicazioni sulla possibile evoluzione, nel breve futuro, 

del comportamento del sistema reale. Questo chiaramente permette di anticipare 

l’accadimento di fenomeni critici quali ingorghi o rallentamenti, eventualmente 

prevenirli, oppure, qualora non sia comunque possibile restare in una situazione 

di traffico scorrevole, attrezzarsi per affrontare nella maniera migliore la criticità. 

In generale, fin dall’inizio, gli studiosi hanno seguito due vie distinte nella 

creazione di modelli matematici: modelli microscopici e macroscopici. Negli ulti- 

mi anni, inoltre, si sta affermando una terza famiglia di modelli, detti mesoscopici, 

31


i quali si pongono come una via di mezzo tra i due sopra citati. 

2.2.2 Modelli Microscopici 

I modelli di simulazione del traffico basati sull’approccio microscopico permet- 

tono di determinare la posizione, la velocità e l’accelerazione dei singoli veicoli 

o di un gruppo di essi. La simulazione di tali sistemi viene fatta considerando il 

comportamento che ogni singolo veicolo viene a tenere in relazione ai veicoli con 

i quali condivide il tratto stradale. 

L’idea è che, per ogni veicolo, la posizione a tempo t + ∆t dipende dalla po- 

sizione e dalla velocità che caratterizzavano quel veicolo al tempo t; la velocità 

al tempo t invece è definita da una serie di grandezze relative al veicolo in que- 

stione ed a quello immediatamente davanti, quali la distanza, la velocità relativa, 

il tempo di reazione dell’autista, la presenza di altri veicoli nelle corsie adiacenti 

e quanto altro può rendere più simile il comportamento del modello a quello di un 

automobilista reale. 

I modelli di simulazione microscopici vengono applicati a reti di traffico urba- 

no ed extraurbano e sono caratterizzati da due principali elementi di modellistica 

che stanno a rappresentare il comportamento reale dei veicoli: 

• car following; 

• lane change con gap acceptance. 

Car Following 

La dinamica di car following, detta anche follow the leader, si basa sul fatto che 

ogni veicolo deve mantenere una distanza di sicurezza dal veicolo che gli sta im- 

mediatamente davanti e la misura di tale distanza è funzione della velocità relativa 

fra i due veicoli (come peraltro indicano e il Codice Stradale e il buon senso). 

In linea del tutto generale, i modelli microscopici assumono la forma riportata 

nella (2.1): ⎧ 

⎨v(t 

+ ∆t) = f � g(t), v(t), ˜v(t), ξ(t), p � 

⎩ 

x(t + ∆t) = x(t) + v(t) · ∆t 

32 

(2.1)


dove 

g(t) = ˜x(t) − x(t) − s 

è la distanza effettiva fra il veicolo ed il suo predecessore (con s lunghezza del 

veicolo). 

• v(t) e x(t) sono rispettivamente velocità e posizione al tempo t del veicolo 

in esame; 

• ˜v(t) e ˜x(t) rappresentano la velocità e la posizione del veicolo che precede 

quello in esame, ∆t è il tempo di campionamento; 

• ξ(t) è una componente di rumore che può essere introdotta per modellizzare 

il fatto che ogni autista, essendo un individuo dotato di un suo modo di agire, 

si comporterà in maniera non uguale a parità di condizioni; 

• p è un vettore di eventuali parametri presenti nel modello. 

Figura 2.2: Schematizzazione del modello car following 

I primi modelli microscopici sono attribuiti a Reuschel e Pipes ([38], [37]). Essi 

descrivono il fenomeno del moto di una coppia di veicoli uno seguente l’altro 

tramite l’espressione: 

xn − xn+1 = L + S˙xn+1 

(2.2) 

dove xn+1 è la posizione del veicolo considerato e xn la posizione del veicolo che 

sta davanti. 

33


Figura 2.3: Il modello di Reuschel e Pipes 

In questa formula si suppone che ogni automobilista mantenga una distanza 

di sicurezza proporzionale alla velocità del proprio veicolo più una distanza L 

relativa al caso in cui le auto sono ferme ed idealmente attaccate (˙xn+1 = ˙xn = 0) 

e che in pratica comprende la lunghezza dell’auto davanti. 

Passando alle derivate, dall’equazione (2.2) otteniamo: 

¨xn+1 = 1 

S (˙xn − ˙xn+1) (2.3) 

(proposta per la prima volta dall’americano Chandler in [7]) che dal punto di vista 

fisico significa che l’accelerazione o decelerazione di un veicolo è proporzionale 

alla sua velocità relativa rispetto al veicolo che lo precede. Se definiamo fattore 

di sensibilità λ = 1 

ed introduciamo un ritardo temporale τ di risposta alla sol- 

S 

lecitazione (nessun essere umano può reagire in tempo nullo ad alcuno stimolo), 

otteniamo dalla (2.3): 

¨xn+1(t + τ) = λ[˙xn(t) − ˙xn+1(t)] (2.4) 

che è generalmente nota come l’equazione di base dei modelli car following. 

Si possono ottenere risultati più accurati se il fattore di sensibilità λ viene 

espresso con la formula 

˙xn+1(t + τ) m 

λ = λ0 

[xn(t) − xn+1(t)] l 

34 

(2.5)


dove λ0 è una costante e l e m sono esponenti interi. 

Vari modelli car following non lineari sono caratterizzati da coppie di valori spe- 

cifici (l, m). Per esempio, il modello lineare (2.4) è caratterizzato da (0, 0). 

Nel 1958 Chandler e altri ricercatori provarono la correttezza e consistenza del 

modello proposto da Reuschel e Pipes con i dati forniti dal General Motors Tech- 

nical Center. Questi mostrarono, per via sperimentale, che per condizioni tipiche 

di traffico autostradale, τ era approssimativamente 1, 5 s e λ assumeva valore pari 

0.37 s −1 . 

Quello presentato da Pipes sembra il modello migliore tra quelli presentati 

nella classe dei microscopici. È stato mostrato come, con questo modello, sia 

possibile simulare il comportamento dei flussi veicolari in un transitorio. 

Lane Change e Gap Acceptance 

Come appare chiaro, nel voler modellare tratti stradali che rappresentino adegua- 

tamente grosse arterie, sarà sicuramente necessario considerare la possibilità di 

effettuare dei cambi di corsia e sorpassare veicoli che si muovono a velocità in- 

feriore; lo stesso dicasi per quei casi in cui una tratta principale presenta, lungo 

il suo snodarsi, corsie di ingresso e di uscita che logicamente vengono impegnate 

dagli automobilisti con cambi di corsia e di velocità. 

Per rispondere a questa esigenza i modelli car following sono stati migliorati 

aggiungendo un’importante componente modellistica. 

Gipps è stato il primo a presentare la formulazione di un modello che tenesse 

conto anche di cambi di corsia (lane change), in [17], non vincolando la possibi- 

lità di superare il veicolo che precede. Questo modello viene sviluppato ed imple- 

mentato con MITSIM, che è appunto un simulatore microscopico, dove i guidatori 

possono decidere, se sono rallentati dal veicolo che li precede, di operare un cam- 

bio di corsia. Il cambio di corsia viene effettuato tenendo in considerazione la 

corsia attuale, quella prescelta, l’eventualità di veicoli in arrivo già presenti sulla 

corsia futura, la velocità e la distanza di tali veicoli e la propensione al rischio 

dell’autista che sta decidendo se effettuare o meno il cambio di corsia. 

In pratica, è necessario definire una funzione di gap acceptance, con cui si 

35


riescono a descrivere le situazioni di sorpasso e tutti i tipi di intersezioni non rego- 

late da semafori, ove siano identificabili una strada principale ed una secondaria. 

Il gap, definito come la distanza della macchina che arriva dalla strada principale 

rispetto al veicolo che si trova nella strada secondaria, varia a seconda dell’au- 

tomobilista: dipende da quanto un guidatore è disposto a rischiare piuttosto che 

rimanere fermo all’incrocio. 

Figura 2.4: Manovra di Lane Change 

Pertanto, viene modellata una funzione di rischio che dipende dalla velocità 

dei veicoli che sopraggiungono, da quanto sono distanti e dal fattore di rischio che 

caratterizza il conducente. 

I campi di maggiore applicazione dei modelli di simulazione microscopici ri- 

guardano il test di tecniche adattative di controllo, di strategie real-time per le 

autovetture, di priorità tra gli autobus e comunque sono di maggiore interesse in 

ambito di applicazioni a traffico urbano. Questi simulatori sono inoltre utilizzati 

per prevedere le emissioni inquinanti agli incroci stradali provvisti di segnaletica 

semaforica e per testare l’efficienza dei sistemi di prevenzione per i rischi di in- 

cidenti nei flussi veicolari. Partendo dal car following ed integrandolo prima con 

il lane change e poi con il gap acceptance si riesce a descrivere esaustivamente 

anche il problema del traffico autostradale. 

Nelle figure 2.5, 2.6, 2.7, 2.8 possiamo osservare un simulatore a modello 

microscopico creato per studiare la risposta a determinate condizioni di flussi vei- 

colari per alcuni tratti tipici comuni a tutte le autostrade (da [42]). Si può notare 

l’interazione fra veicoli following e veicoli leader, la cui distanza di sicurezza è 

36


effettivamente proporzionata alla velocità di crociera, così come l’ingresso dalla 

corsia di accelerazione sull’arteria principale. 

È significativo il verificarsi dei fenomeni tipici del traffico, quali code, stop 

and go, e propagazione di onde di velocità. 

Figura 2.5: Simulatore Modello Microscopico [42] 


37




A fronte di una così elevata capacità di rappresentare la realtà, i modelli mi- 

croscopici richiedono una elevata mole di dati. Infatti, come è possibile notare 

dalla (2.1), si suppone di conoscere in ogni istante la posizione e la velocità di 

ogni veicolo. Oltre alla indiscutibile difficoltà computazionale -si hanno 2 × n 

(con n numero dei veicoli mediamente presenti nella simulazione) variabili di 

stato da aggiornare per ogni istante- è spesso troppo difficile riuscire a trasporre 

in informazione matematica adattabile al modello la caratteristiche fisiche della 

tratta stradale e quelle psico-attitudinali degli automobilisti. 

È impensabile gestire un modello di questo genere per un’applicazione real- 

time. Ecco il motivo per cui l’uso dei modelli microscopici è limitato ai casi in 

38


cui la rete stradale risulti relativamente semplice ed il numero di veicoli molto 

ristretto. 

2.2.3 Modelli Macroscopici 

I modelli macroscopici si basano su una relazione empirica determinata osservan- 

do un sistema di traffico in condizioni stazionarie. La maggior parte dei modelli 

matematici strutturati in maniera macroscopica partono dalla formulazione del 

modello di traffico microscopico, prima analizzato, prendendo in considerazione 

un flusso di veicoli tutti con la stessa rilevanza; in particolare, si prestano alla si- 

mulazione di corridoi di traffico veicolare ed arterie autostradali. Di conseguenza, 

non essendo modellabili accelerazioni e decelerazioni di velocità, e non essendo 

previste intersezioni nel flusso del traffico, questo tipo di modelli non si adatta ad 

una applicazione in ambito urbano. 

Fondamentalmente il modello macroscopico si è sviluppato seguendo un’ana- 

logia tra lo stato stazionario di comportamento del traffico e la legge di conserva- 

zione propria della teoria della fluidodinamica. 

Infatti, il traffico può essere modellizzato come un fluido omogeneo, senza 

porre alcuna distinzione tra le classi di veicoli. A differenza delle molecole dei 

fluidi reali i singoli veicoli saranno interessati da una particolare caratteristica 

origine-destinazione diversa per ognuno di questi; questa è un’informazione che 

sarà persa. Nei modelli macroscopici, infatti, non si presta attenzione nel modella- 

re il comportamento del singolo veicolo con posizione e velocità; si pensa invece 

di descrivere l’intero sistema considerando file di veicoli come flussi di un fluido 

incomprimibile e, di conseguenza, la posizione e la velocità del singolo veicolo 

vengono espresse in relazione a quella degli altri veicoli. 

Pertanto, un modello macroscopico del flusso veicolare implica la definizio- 

ne di adeguate variabili di sistema che esprimano il comportamento mediamente 

tenuto in un preciso punto della tratta stradale ad un istante di tempo. 

Definizione 2.1 

39


Definiamo la densità del traffico 

ρ(x, t) [veicoli/km] 

come il numero di veicoli presenti mediamente per unità di lunghezza. Si misura 

in veicoli per chilometro. 


Definiamo la velocità media dei veicoli 

Si misura in chilometri orari. 


Definiamo il flusso del traffico 

v(x, t) [km/h] 

q(x, t) [veicoli/h] 

come il numero di veicoli passanti da una specifica sezione della tratta stradale 

nell’unità di tempo. Si misura in veicoli per ora. 

Per un flusso di traffico omogeneo, si può mostrare, sulla base di considerazio- 

ni microscopiche, che le tre grandezze che abbiamo pocanzi definito sono legate 

fra loro dalla relazione 

q = ρ · v (2.6) 

analoga alla relazione presente in fluidodinamica. Inoltre, l’equazione (2.6) de- 

scrive approssimativamente il flusso di traffico anche in condizioni in cui l’omo- 

geneità non è verificata, e pertanto è un’equazione presente nella maggior parte 

dei sistemi macroscopici. 

Vi è un’altra relazione che lega le variabili di stato definite, ma, a differenza 

della precedente, non ha una analogia con la fluidodinamica, essendo propria dei 

flussi di traffico. La velocità media del traffico decresce monotonamente al cresce- 

re della densità dei veicoli, come è stato anche dimostrato da parecchi rilevamenti 

di misure di velocità-densità. 

40


Nel 1935 Greenshields ([19]) ipotizzò l’esistenza di una relazione lineare tra 

velocità e densità del tipo 

� ρ(x, t) � 

v(x, t) = vf 1 − 

ρmax 

(2.7) 

dove vf è la velocità a corsia completamente libera (ovvero per densità di veicoli 

nulla o molto prossima a zero) e ρmax è la densità di congestionamento, ossia il 

valore di densità dei veicoli che causa un calo della velocità tale da farla andare a 

zero e bloccare il movimento dei veicoli, come si può vedere in Figura 2.9. 

Figura 2.9: Relazione Lineare Velocità-Densità 

È molto interessante constatare che la relazione macroscopica (2.7) è la diretta 

conseguenza del modello microscopico lineare (2.4) per (l = 2, m = 0). 

Assumiamo di trovarci in condizioni di omogeneità e di regime stazionario 

(τ = 0) ed introduciamo la distanza media fra i veicoli s. 

e che: 

Si ha che: 

s � xn − xn+1 

s = 1 

ρ 

L � 1 

ρmax 

41 

. 

(2.8)


L’integrazione dell’equazione (2.4) rende: 

v = − λ0 

s + b = −λ0ρ + b (2.9) 

dove b è una costante di integrazione. Se assumiamo che, per ρ = ρmax, la 

velocità media precipiti a zero, otteniamo: 

b = λ0ρmax. 

Ponendo vf = λ0/ρmax, l’equazione (2.9) diviene identica alla (2.7). Per differen- 

ti valori di (l, m) otteniamo diverse formule per la curva caratteristica velocità- 

densità a regime stazionario. Chiaramente, una volta che si stabilisce di utilizzare 

un modello macroscopico, il miglior approccio sarebbe quello di determinare la 

curva caratteristica empiricamente con un set di misurazioni. 

Una volta che la curva caratteristica velocità-densità è determinata, possiamo 

usare l’equazione (2.6) per determinare la curva flusso-densità. Per esempio nel 

caso della formulazione lineare (2.7) otteniamo: 

q(x, t) = ρ(x, t) · v(x, t) = vf · ρ(x, t) � ρ(x, t) � 

1 − 

ρmax 

(2.10) 

il cui grafico è mostrato in Figura 2.10. È facile notare come il flusso veicolare 

sia crescente con la densità fino a qmax che è raggiunto per un valore critico di 

densità ρcr. 

Un’ulteriore crescita del valore della densità dei veicoli comporta un calo del 

flusso di traffico fino al raggiungimento di ρmax, che causa il congestionamento 

dell’arteria e, pertanto, il flusso veicolare nullo. 

Questo fenomeno, chiamato capacity drop, è comune a tutti i sistemi di veico- 

lazione del traffico, ed è dovuto alle considerazioni sulla distanza di sicurezza fra 

i veicoli dipendente dalla velocità dei veicoli stessi. 

42


Figura 2.10: Curva Caratteristica a Regime Stazionario Flusso-Densità 

In questo caso, trovare ρcr è molto semplice: nota la funzione q(ρ) (2.10) 

basta porre q ′ (ρ) = 0, da cui: 

q ′ (ρ) = vf(1 − 2ρ 

ρmax 

) = 0. 

In questo caso, si ha: ρcr = ρmax 

2 . 

Tale proprietà risulta dal fatto che la regolazione della distanza di sicurezza è 

effettuata dagli autisti delle vetture. Misurazioni sperimentali estensive mostrano 

che autisti umani agenti come regolatori di distanza di sicurezza conducono a un 

flusso veicolare instabile quando la densità supera il valore critico (ρ > ρcr). Per 

instabile si intende che, il flusso di traffico diventa, rapidamente ed, apparente- 

mente, senza un’ovvia ragione, sempre più congestionato, fino a quando vengono 

raggiunti i valori di densità prossimi a quello di congestionamento ρmax. 

La zona intermedia è quella interessata dal fenomeno di stop and go. Infatti, 

in termini microscopici, l’instabilità è dovuta ad un aumento dell’ampiezza della 

perturbazione che viene propagata all’indietro (fenomeno delle shock waves o 

back waves) lungo una fila di vetture, portando infine all’arresto delle vetture più 

arretrate. 

[31] 

43


2.2.4 Modelli Mesoscopici 

Questa classe di modelli di simulazione sta guadagnando popolarità e si pone a 

metà tra i modelli precedentemente illustrati, unendo l’approccio aggregato dei 

modelli macroscopici con quello particolare e riferito al singolo elemento dei 

modelli microscopici. 

Tipicamente, i modelli microscopici descrivono le singole entità ad un elevato 

livello di dettaglio, ma il loro comportamento e le loro interazioni sono gestite ad 

un livello più generale. 

Questi modelli possono assumere varie forme. Ad esempio, è possibile rag- 

gruppare i veicoli in piccoli insiemi in moto lungo la rete ([25]). Questi insiemi 

agiscono come se fossero un elemento unico e la loro velocità lungo un percor- 

so è ottenuta da una funzione velocità-densità definita per ciascun tratto stradale. 

I cambiamenti di corsia e le accelerazioni o decelerazione dei veicoli non sono 

modellate. 

Una caratteristica importante del modello mesoscopico è che la velocità dei 

veicoli non è determinata dalle decisioni del singolo guidatore, ma dal comporta- 

mento di gruppi di veicoli ([1]). In altri modelli ([21]), ([16]), ([27]) si utilizza 

un sistema a coda dove la strada è vista come un insieme di zone di coda e di 

zone in movimento. Le corsie possono essere descritte individualmente, sebbene 

generalmente non lo siano. 

In questi casi, i veicoli sono rappresentati individualmente e ciascuno è carat- 

terizzato dalla propria velocità; tuttavia, il comportamento non è modellato nel 

dettaglio. La parte in movimento viene percorsa con una velocità ricavata utiliz- 

zando una relazione velocità-densità di tipo macroscopico mentre la parte in coda 

è gestita con un sistema coda-server. 

Questo ultimo approccio combina i vantaggi dei modelli dinamici con flussi 

di traffico disaggregati (i veicoli sono modellati singolarmente) con la facilità di 

utilizzo delle relazioni macroscopiche velocità-densità. Incroci controllati da se- 

gnali come i semafori possono essere modellati rimpiazzando il server con un un 

gate che apra e chiuda in accordo con gli stati del segnale. 

Un altro tipo di modello mesoscopico utilizza una visione cellulare della stra- 

44


da, che è discretizzata in celle unitarie che possono essere vuote o riempite da un 

veicolo. Il veicolo in esame segue un insieme di regole di comportamento piutto- 

sto semplici ([29]) che determinano, ad ogni istante di tempo, il numero di celle 

attraversate dal veicolo ([2]). 

Le principali aree di applicazione dei modelli mesoscopici sono quelle in cui 

il dettaglio della simulazione microscopica, sebbene potrebbe risultare utile, non 

è applicabile a causa delle grandi dimensioni della rete o della mancanza di alcune 

risorse che sono necessarie per implementare uno strumento simulativo basato su 

tale principio. [5] 

2.2.5 Trattazione Analitica 

Ora che abbiamo individuato le caratteristiche dei modelli macroscopici descrivia- 

mo il problema del traffico in maniera analitica, per cogliere a pieno il passaggio 

della trattazione dalle singole vetture ad una descrizione globale del comporta- 

mento. 

Ipotizziamo un tratto autostradale rettilineo monocorsia senza stazioni di en- 

trata ed uscita. Il tratto in questione può essere suddiviso in ipotetiche sezioni. 

Figura 2.11: Divisione in sezioni di un ipotetico tratto stradale 

q(t1, t2, x) rappresenta il valore medio del flusso veicolare nella sezione stra- 

dale x e nell’intervallo di tempo [t1, t2] e vale: 

q(t1, t2, x) = n(t1, t2, x) 

t2 − t1 

in cui n(t1, t2, x) indica il numero di veicoli che transitano nella sezione stradale 

x e nell’intervallo di tempo [t1, t2]. 

45


Abbiamo già introdotto i concetti di flusso, densità e velocità media. Li ri- 

proponiamo in questo contesto utilizzando una definizione un poco più precisa. 

q(x, t) è il flusso istantaneo nella sezione stradale x; può essere misurato tramite 

particolari sistemi di monitoraggio posti sulla sezione stradale, ed è definito come: 

q(x, t) = lim 

∆t→0 q� t − ∆t, t + ∆t, x � . 

ρ(x1, x2, t) è invece la densità media di veicoli fra la tratta x1 e la tratta x2 al 

tempo t. Può essere misurata tramite osservazione diretta ed è definita come: 

ρ(x1, x2, t) = n(x1, x2, t) 

x2 − x1 

dove, in questo caso, n(x1, x2, t) indica il numero di veicoli presenti fra la sezione 

x1 e la sezione x2 al tempo t. 

Come fatto in precedenza, è possibile ottenere un’espressione della densità 

locale nella sezione generica x al tempo t 

ρ(x, t) = lim 

∆x→0 ρ� x − ∆x, x + ∆x, t � . 

È importante ora determinare il legame tra le variabili fino ad ora introdotte; ci 

viene quindi in aiuto la relazione fondamentale che si basa sull’equazione di con- 

servazione della massa, con la quale si impone che le variazioni nell’intervallo 

(t1, t2) del numero di veicoli tra la sezione x1 e la sezione x2 deve essere uguale 

alla differenza tra il numero di veicoli in ingresso alla sezione x1 e quelli in uscita 

dalla x2, considerando lo stesso intervallo temporale. Il legame cercato è definito 

dalla seguente espressione: 

� x2 

x1 

� ρ(t2, x) − ρ(t1, x) � dx = 

� t2 

t1 

� q(x1, t) − q(x2, t) � dt. (2.11) 

Molti studiosi e ricercatori nel settore dei modelli di traffico hanno fornito 

un’equazione che potesse rappresentare nella maniera più adeguata possibile le 

dinamiche di relazione fra la densità dei veicoli e la loro velocità media. In Tabella 

2.1 sono riportati i vari risultati che la letteratura offre. È possibile definire la 

dipendenza di v da ρ in diversi, ragionevoli e più o meno efficaci modi. 

46


Come si vede dalla tabella 2.1 in ognuna delle forme proposte la velocità 

decresce in maniera monotona al crescere di ρ. 

Un esame più attento conduce ben presto a concludere che, quella introdotta 

da Papageorgiou in [33] è senz’altro più flessibile e meglio adattabile a diverse 

situazioni. 

Infatti, la forma di Greenshields si ottiene per l = m = 1; quella di Drew 

per l = 1 e m = λ. Per le altre tre, dopo qualche considerazione elementare, 

possiamo accorgerci che, fondamentalmente, si riconducono alle prime due. 

Infatti, poichè 

log ρmax 

�� 

ρ 

= = − log 

ρ 

ρmax 

� � �� 

− 1 + 1 = = 1 − ρ 

� � 

+ ρω(ρ) 

ρmax 

(2.12) 

la forma di Greenberg è del tipo della forma di Greenshields per valori piccoli di 

ρ 

mentre, se teniamo conto che, 

ρmax 

ρ 

− 

e ρmax = 1 − ρ 

+ ρω(ρ) (2.13) 

ρmax 

vediamo che lo stesso si può dire della formula di Underwood. 

La formula di May, infine, è un pò più flessibile, ma comunque si riduce a: 

e α( ρ 

ρmax ) = 

� 

1 − ρ 

e quindi è molto simile a quella di Drew. 

47 

ρmax 

+ ρω(ρ) 

� α 

(2.14)


Greenshields (1935) v = vf 

[19] 

� 

1 − ρ 

� 

ρmax 

� � 

ρ 

Greenberg (1959) v = vf ln 

ρmax 

[18] 

“ 

− 

Underwood (1961) v = vfe 

ρ 

” 

ρmax 

[43] 

Drew (1968) v = vf 

[14] 

� 

1 − ρ 

�λ ρmax 

May (1988) v = vfe α 

“ 

− ρ 

” 

ρmax 

[28] 

Papageorgiou (1995) v = vf 

[33] 

[6] 

�� 1 − ρ 

� � 

l 

m 

ρmax 

Tabella 2.1: L’evoluzione della relazione tra velocità e densità 

48


2.3 Il Modello Macroscopico di Traffico Autostra- 

dale 

Vogliamo qui descrivere brevemente le basi del modello macroscopico di traffico 

autostradale e delle approssimazioni alle differenze finite che sono a loro volta 

ispiratrici del modello discreto di Papageorgiou che abbiamo deciso di implemen- 

tare. 

La teoria poggia sulle semplici considerazioni che servono per giustificare 

l’equazione di continuità dei fluidi. 

Cominciamo con il vedere come si può giustificare tale equazione. Conside- 

riamo una massa fluida che si muove lungo l’asse x nel tempo t. In analogia con 

la Sezione precedente, assumiamo: 

• x la coordinata relativa all’asse su cui avviene il movimento; 

• t la variabile di tempo; 

• ρ(x, t) la densità della sostanza che intendiamo studiare; 

• q(x, t) il flusso attraverso x al tempo t. 

Ricordiamo anche le dimensioni di ρ, che sono: 

unità di massa 

unità di lunghezza , 

e quindi la massa compresa tra x e x + ∆x può essere calcolata mediante la: 

m(t, x, x + ∆x) = 

� x+∆x 

x 

ρ(t, s)ds. 

Il flusso q(x, t) attraverso la sezione in x al tempo t è la quantità di massa che 

transita per il punto x nell’istante t. 

Le dimensioni di q sono: 


unità di tempo . 

49

2.3. IL MODELLO MACROSCOPICO DI TRAFFICO AUTOSTRADALE Carlo Caligaris, Iacopo Salvarani 

Consideriamo un intervallo di lunghezza I = [x, x + ∆x] ed un intervallo di 

tempo T = [t, t + ∆t]. 

Sia 

µ(t, x) 

la massa che è fluita attraverso il punto x fino all’istante t; il flusso istantaneo puo’ 

essere definito mediante la: 

per cui: 

q(t, x) − q(t, x + ∆x) 

∆x 

µ(t, x) − µ(t + ∆t, x) 

q(t, x) = lim 

∆t→0 ∆t 

Scambiando derivata ed integrale si ha: 

q(t, x) − q(t, x + ∆x) 

∆x 

= − ∂µ 

(t, x), 

∂t 

= − 1 ∂ 

(µ(t, x) − µ(t, x + ∆x)) = 

∆x ∂t 

= 1 

� x+∆x 

∂ 

ρ(t, s)ds. (2.15) 

∆x ∂t 

= 1 

∆x 

� x+∆x 

x 

x 

� � 

∂ 

ρ(t, s) ds. 

∂t 

Passando al limite per ∆x → 0 si ottiene l’equazione 2.16. 

∂ρ(x, t) 

∂t 

= − 

∂q(x, t) 

. (2.16) 

∂x 

Possiamo anche tenere conto di apporto o sottrazione di massa mediante un 

termine k(x, t) a secondo membro: 

∂ρ(x, t) 

∂t 

∂q(x, t) 

= − + k(x, t). (2.17) 

∂x 

Tuttavia, fino a questo punto, l’equazione 2.17 contiene troppe incognite (ρ e 

q) e quindi occorre introdurre qualche ulteriore condizione. 

A tale scopo occorre ipotizzare una dipendenza tra ρ e q. Ad esempio possia- 

mo supporre che: 

così che: 

∂q 

∂x = 

q = q(ρ), 

� dq 

dρ 

50 

� � � 

∂ρ 

. 

∂x


L’equazione 2.17 diventa allora: 

� � � � 

∂ρ(x, t) ∂q(ρ(x, t)) ∂ρ(x, t) 

= − 

+ k(x, t). (2.18) 

∂t 

∂ρ ∂x 

Per definire la dipendenza q(ρ) possiamo supporre, che: 

q(ρ) = v(x, t)ρ. 

Consideriamo quindi l’ipotesi di advezione; v(x, t) ha dimensione: 

unità di lunghezza 

unità di tempo 

cioè ha le dimensioni di una velocità che rappresenta la velocità con cui la materia 

si muove lungo l’asse x; infatti: 

v = q 

ρ 

= unità di massa 

unità di tempo 

Il caso più semplice si incontra quando v(x, t) = c. 

L’equazione, quindi, prende la forma: 

∂ρ(x, t)) 

∂t 

unità di lunghezza 

. 


∂(ρ(x, t)v(x, t)) 

= − + k(x, t). (2.19) 

∂x 

2.3.1 Un esempio di trasporto nel caso della velocità costante 

Consideriamo il caso in cui la velocità con cui avviene il moto del fluido sia co- 

stante. Si tratta di un caso particolarmente semplice ma permette di mettere in 

luce alcune interessanti caratteristiche del fenomeno di trasporto 

Supporremo anche che ci sia una diminuzione della densità proporzionale alla 

densità stessa. 

Fisicamente possiamo trovare un significato pratico a questa equazione consi- 

derando l’evoluzione di un inquinante organico in un fiume che scorre a velocità 

c ed è metabolizzato proporzionalmente alla densità stessa. 

L’equazione quindi è: 

∂ 

∂ 

ρ(x, t) = −c ρ(x, t) − µρ(x, t). (2.20) 

∂t ∂x 

51

2.3. IL MODELLO MACROSCOPICO DI TRAFFICO AUTOSTRADALE Carlo Caligaris, Iacopo Salvarani 

Riscriviamo la 2.20 nella forma: 

∂ 

∂ 

ρ(x, t) + c ρ(x, t) = −µρ(x, t). 

∂t ∂x 

Il primo membro è la derivata rispetto a t della funzione 

e quindi 

ne: 

d d 

R(x, t) = ρ(x + ct, t) = 

dt dt 

R(x, t) = ρ(x + ct, t) 

= ∂ 

∂ 

ρ(x + ct, t) + c ρ(x + ct, t) = 

∂t ∂x 

= −µρ(x + ct, t) = −µR(x, t). 

Integrando rispetto a t l’equazione differenziale lineare che ne risulta si ottie- 

ρ(x + ct, t) = h(x)e −µt . 

Imponendo le condizioni iniziali ρ(x, 0) = ρ0(x) (è nota la densità iniziale in 

ogni luogo del fiume) si ha: 

da cui: 

e: 

ρ0(x) = ρ(x, 0) = h(x), 

ρ(x + ct, t) = ρ0(x)e −µt 

ρ(x, t) = ρ0(x − ct)e −µt . 

Consideriamo ora la situazione in cui si verifichi, in una locazione x = 0, che 

possiamo supporre coincidente con l’origine, una immissione di inquinante con 

flusso costante γ. 

Allo scopo, posto: 

⎧ 

⎨0 

t < 0 

γ(t) = 

⎩ 

γ0 t ≥ 0 

52


possiamo imporre nella 2.3.1 che: 

γ(t) = ρ(0, t) = ρ0(−ct)e −µt . 

Da cui, posto x = −ct si ricava t = − x 

e quindi: 

c 

γ(− x 

c ) = ρ0(x)e µx/c , ρ0(x) = γ(− x 

c )e−µx/c . 

Se ne conclude: 

Ed infine: 

ρ(x, t) = ρ0(x − ct)e −µt = γ( 

ct − x 

)e 

c 

−µ(x−ct)/c e −µt . 

ρ(x, t) = γ(t − x 

c )e−µx/c . 

In questa espressione, possiamo osservare che si evidenzia il fatto che, per 

t − x 

< 0, cioè per x > ct, l’inquinante ha densità ρ nulla. (L’inquinante, in quel 

c 

momento non ha ancora raggiunto quel punto del fiume). 

2.4 Modelli Differenziali di Traffico Autostradale 

Veniamo ora a considerare il caso del traffico lungo un’autostrada utilizzando un 

modello di trasporto in cui il flusso dipende dalla densità delle auto. 

Denotiamo con x la variabile di spazio che identifica un punto sulla retta che 

descrive l’autostrada e con t, come al solito, il tempo; ρ(x, t) è la densità delle 

auto mentre indichiamo ancora con q(x, t) il flusso. 

L’equazione che usiamo è di tipo advettivo, di trasporto e, per semplificare la 

trattazione, che ha lo scopo di mettere in evidenza le caratteristiche elementari del 

modello, non prevediamo che nel tratto in esame esistano ingressi od uscite. 

Occorre anche ipotizzare il comportamento del flusso q rispetto alla densità ρ 

delle auto. 

A tale scopo possiamo fare riferimento alla più semplice, dal punto di vista al- 

gebrico, delle dipendenze che nell’arco dell’evoluzione del modello macroscopico 

sono state proposte da vari autori: quello di Greenshields del 1935 ([19]). 

Se ρm è la massima densità possibile, supponiamo che: 

53

2.4. MODELLI DIFFERENZIALI DI TRAFFICO AUTOSTRADALE Carlo Caligaris, Iacopo Salvarani 

1. la velocità delle auto sia compresa tra 0 e vm, quest’ultimo valore essendo 

conseguenza dei limiti di velocità o delle condizioni stradali; 

2. la velocità delle auto dipenda dalla densità mediante la: 

da cui: 

Dalla 2.21 si ricava: 

• se ρ = 0 allora v = vm; 

• se ρ = ρm allora v = 0. 

Tenuto conto che: 

v(ρ) = vm 

q(ρ) = v(ρ)ρ = vm 

� 

1 − ρ 

ρm 

� 

ρ − ρ2 

ρm 

� 

. (2.21) 

� 

, 

q ′ (ρ) = d 

� 

q(ρ) = vm 1 − 

dρ 2ρ 

� 

, 

ρm 

l’equazione che regola lo scorrere del traffico autostradale potrà essere scritta 

nella forma: 

o, più brevemente, 

∂ρ(x, t) 

∂t 

ρt = −vm 

= −vm 

� 

1 − 

� 

1 − 2ρ 

ρm 

� 

2ρ(x, t) ∂ρ(x, t) 

∂x 

� 

ρm 

(2.22) 

ρx = −q ′ (ρ)ρx. (2.23) 

Possiamo studiare la soluzione dell’equazione individuandone le curve di li- 

vello; possiamo cercare cioè di trovare le curve descritte dalle equazioni (x(t), t) 

sulle quali risulta: 

Se: 

ρ(x(t), t) = costante = ρ0. (2.24) 

ρ(x(t), t) = costante = ρ0 

54


avremo che: 

è esso pure costante. 

q ′ (ρ) = q ′ (ρ0) = q ′ 0 

Pertanto, possiamo riscrivere la 2.23 come segue: 

D’altro canto, derivando la 2.24, si ha: 

Da 2.26 e 2.25 possiamo dedurre che: 

da cui, ricordiamo che: q ′ 0 = q′ (ρ0) 

ρt = −q ′ 0ρx. (2.25) 

ρt + ˙x(t)ρx = 0. (2.26) 

˙x(t) = q ′ o 

x(t) = q ′ 0t + x0. 

Le curve di livello (x(t), t) della soluzione ρ(x, t) sono rette di equazione 

x = q ′ 0t + x0. 

Se ρ(x, 0) = ρ0(x) si ha: 

ρ(q ′ 0t + x0, t) = ρ(x0, 0) = ρ0(x0) (2.27) 

E se supponiamo nota la densità iniziale ρ0(x): 

ρ(x, t) = ρ(x − q ′ (ρ0)t) = ρ0(x − q ′ 0t). 

Esaminiamo ora due casi molto interessanti che possono offrire spunti per 

ulteriori studi. 

2.4.1 Ripartenza dopo un blocco 

Supponiamo che le auto siano incolonnate ad un semaforo prima del quale la 

densità è massima e dopo il quale la densità è nulla. 

55


Sia t = 0 l’istante in cui il semaforo diventa verde. 

Il flusso di traffico successivo può essere descritto dall’equazione 2.22 con la 

condizione iniziale: 

⎧ 

⎨ρm 

x < 0 

ρ(x, 0) = ρ0(x) = 

⎩ 

0 x > 0. 

In corrispondenza di tali dati iniziali avremo che: 

q ′ 0 = q ′ 0(ρ(x, 0)) = q ′ 0(ρ0(x)) = = 

⎧ 

⎨vm 

x > 0 (ρ0 = 0) 

. 

⎩ 

−vm x < 0 (ρ0 = ρm) 

(2.28) 

La densità risulta costante su rette che si chiamano linee caratteristiche dell’e- 

quazione e sono date da: 

⎧ 

⎨vmt 

+ x0 x0 > 0 

x = 

. 

⎩ 

−vmt + x0 x0 < 0 

Su ognuna di tali rette la densità è ρ0 ed il flusso corrispondente è: 

q ′ 0 = q ′ (ρ(x, 0)) = q ′ (ρ0). 

Tali rette coprono solo una parte del semipiano t > 0, ma non forniscono 

alcun dato su quanto accade nella zona del semipiano che è compresa tra le rette 

x = ±vmt. 

La zona non coperta corrisponde al caso x0 = 0 e non è ragionevole fissare il 

valore della densità per x0 = 0; infatti: 

• a destra di zero la densità è nulla; 

• a sinistra è massima; 

e quindi la densità presenta in zero una discontinuità di tipo “salto”. 

In tale zona ci interessa definire una soluzione ρ(x, t) in grado di raccordare il 

valore ρm con il valore 0. 

56


Figura 2.12: Le linee caratteristiche 

Per x0 = 0 le curve di livello della densità ρ sono: 

x = q ′ (ρ(0, 0))t = q ′ (ρ0(0))t (2.29) 

ma la densità iniziale ρ0(0) non è definita, possiamo soltanto affermare che: 

Quindi: 

q ′ (ρ0(0)) = vm 

ρ0(0) ∈ [0, ρm]. 

� 

1 − 2ρ0(0) 

� 

ρm 

∈ [−vm, vm]. 

Pertanto, per x0 = 0 possiamo considerare non una, ma infinite rette sulle 

quali ρ è costante. 

Se in t = 0 assumiamo un valore della densità ρ, tale valore si manterrà 

costante sulla retta 

Ricavando ρ si ottiene: 

x = q ′ (ρ)t = vm 

� 

1 − 2ρ 

ρm 

Osserviamo che per t = 0 la 2.30 non è definita. 

� 

t. 

ρ = 1 

2 ρm 

� 

1 − x 

� 

. (2.30) 

vmt 

57


Figura 2.13: Grafico e livelli della 2.30 

La 2.30 soddisfa l’equazione 2.22; infatti si ha: 

Per cui, trascurando la costante 1 

2 ρm: 

� 

x 

+ vm 1 − 

vmt2 2ρ 

� � � 

−1 

= 

ρm vmt 

ρt = x 

2vmt 2 , ρx = −1 

2vmt . 

= x 1 2ρ 

− + 

vmt2 t ρmt = 

= x 1 

− 

vmt2 t + 

ρm 

� 

1 − x 

� 

vmt 

ρmt 

= 0. 

La soluzione così definita ha linee di livello che sono rette per l’origine, esse 

corrispondono ai diversi valori di densità che possono essere assunti nell’origine. 

Tali valori vanno da: 

• ρm, in corrispondenza del quale x = −vmt 

• a 0 caso in cui x = vmt. 

Infatti: 

ρ = 1 

2 ρm 

� 

1 − x 

� 

� 

= k ⇐⇒ x = vm 1 − 

vmt 

2k 

� 

. 

ρm 

58


Le rette (al variare di k ∈ [0, ρm] hanno pendenza crescente da −vm a vm e 

coprono la zona lasciata scoperta dalle precedenti considerazioni. Sono le curve 

caratteristiche che passano per l’origine. 

I punti della retta x = −vmt caratterizzano i tempi ed i luoghi in cui inizia il 

movimento di un’auto in coda al semaforo. 

Al tempo t iniziano a muoversi le auto che per t = 0 si trovano alla posizione 

x = −vmt mentre al tempo t l’auto che si trova in x = 0 per t = 0 avrà raggiunto 

la posizione x = vmt. 

La velocità con cui le auto si muovono nella zona in esame, sarà: 

� 

v = vm 1 − ρ 

� 

e quindi dalla soluzione 2.30 trovata per ρ, 

per cui: 

e 

v = vm 

v = vm 

� 

1 − 1 

2 

v = vm 

2 

ρm 

� 

1 − x 

vmt 

� � 

1 x 

+ 

2 2vmt 

+ x 

2t . 

�� 

Se x(t) è la posizione di un’auto avremo che ˙x(t) = v. Si ottiene: 

˙x(t) = vm 

2 

+ x 

2t . 

(2.31) 

Si è in questo modo trovata una equazione differenziale che definisce il movi- 

mento dell’auto alla partenza dopo il verde. 

Una condizione iniziale può essere dedotta tenendo conto che l’auto comincia 

a muoversi da x0 al tempo t0 = −x0/vm; 

Ne viene: ⎧ ⎨ 

˙x(t) = x(t) 

2t 

vm + 2 

⎩ 

x(− x0 ) = x0. 

vm 

59


L’integrale generale dell’equazione è: 

e imponendo che: 

si ricava: 

√ 

x(t) = C1 t + vmt; 

x0 = x(− x0 

� 

) = C1 − 

vm 

x0 

� 

+ vm − 

vm 

x0 

� 

vm 

C1 = −2 √ −x0vm 

per cui la cui soluzione del problema di Cauchy è 

ricava: 

x(t) = −2 √ √ 

−x0vm t + vmt √ t √ vm 

� 

√vm√ 

√ � 

t − 2 −x0 . 

Si calcola che l’auto raggiungerà il semaforo al tempo ˜t tale che x(˜t) = 0; si 

˜t = −4 x0 

. 

La figura seguente mostra come si muove un’auto in coda al semaforo dopo 

che il semaforo è diventato verde. 

Figura 2.14: Traiettoria di un’auto inizialmente in attesa al semaforo 

60 

vm


2.4.2 La formazione di code 

Una situazione opposta si verifica quando la densità di traffico aumenta. In tal 

caso il metodo delle caratteristiche presenta inconvenienti e si rendono necessari 

degli aggiustamenti. 

La densità iniziale sia data da: 

⎧ 

⎨ ρm x < 0 

4 

ρ(x, 0) = ρ0(x) = 

⎩ 

ρm x > 0. 

Avremo che: 

q ′ 0 = q ′ 0(ρ(x, 0)) = q ′ 0(ρ0(x)) = = 

⎧ 

⎨ 

vm 

2 x < 0 (ρ0 = ρm 

4 ) 

⎩ 

−vm x > 0 (ρ0 = ρm). 

(2.32) 

Le curve caratteristiche su cui risulta costante la densità dell’equazione, sa- 

ranno date da: 

come si vede nella figura seguente. 

⎧ 

⎨ vm t + x0 x0 < 0 

2 

x = 

⎩ 

−vmt + x0 x0 > 0 

Figura 2.15: 

61


È evidente che la situazione non è affatto chiara: esiste una zona del piano in 

cui le caratteristiche si sovrappongono. 

Ciò causa la mancanza di unicità della soluzione, o meglio la sua indetermi- 

natezza. Questo è dovuto alla discontinuità del dato iniziale Dobbiamo pertanto 

operare una scelta tra le due soluzioni. 

Poichè la densità è discontinua la 2.16 può causare problemi. 

Ad esempio può non essere lecito lo scambio tra derivata ed integrale in 2.15. 

La 2.15 afferma: 

q(t, x) − q(t, x + ∆x) = 

= d 

dt 

� x+∆x 

x 

ρ(t, s)ds. 

Se σ(t) ∈ [x, x + ∆x] è un punto in cui si verifica la discontinuità la 2.15 

applicata agli intervalli [x, σ+(t)] e [σ−(t), x + ∆x] assicura 

d 

dt 

x 

� σ(t) 

x 

ρ(s, t)ds + d 

dt 

σ(t) 

� x+∆x 

σ(t) 

ρ(s, t)ds = 

= q(σ − (t), t) − q(x + ∆x, t) − q(σ + (t), t) + q(x, t). 

σ − 

σ + 

62 

x + ∆x


d 

dt 

ovvero 

D’altro canto, per le solite regole di derivazione, si ha: 

� σ(t) 

x 

ρ(s, t)ds + d 

dt 

� x+∆x 

σ(t) 

= ˙σ(t)ρ(σ − (t), t) + 

ρ(s, t)ds = 

� σ(t) 

Quindi, se x → σ(t) − e x + ∆x → σ(t) + otteniamo: 

x 

∂ρ(s, t) 

ds − ˙σ(t)ρ(σ 

∂t 

+ (t), t)+ 

� x+∆x 

∂ρ(s, t) 

+ 

ds. 

∂t 

˙σ(t)ρ(σ − (t), t) − ˙σ(t)ρ(σ + (t), t) = − q(σ + (t), t) + q(σ − (t), t). 

Più brevemente: 

˙σ(t)ρ− − ˙σ(t)ρ+ = −q+ + q− 

˙σ(t) = q+ − q− 

ρ+ − ρ− 

Nel nostro caso, si verifica subito che: 

Per cui: 

= ρ+v+ − ρ−v− 

. 

ρ+ − ρ− 

ρ+ = ρm , ρ− = ρm 

4 , 

v+ = 0 , v− = 3vm 

4 . 

˙σ(t) = − vm 

4 

σ(t) 

e σ(t) = − vm 

t. (2.33) 

4 

63

2.5. METODI DI CALCOLO NUMERICI ALLE DIFFERENZE FINITE Carlo Caligaris, Iacopo Salvarani 

La 2.33 rappresenta l’equazione della curva lungo la quale si passa da velocità 

v− = 3vm 

4 a velocità v+ = 0 ed ivi si riscontra una brusca interruzione del traffico; 

quindi σ(t) individua il punto in cui in traffico subisce uno shock e ne descrive 

l’andamento nel tempo; solitamente σ(t) viene indicata come “shock wave” (onda 

d’urto). 

2.5 Metodi di calcolo numerici alle Differenze Finite 

2.5.1 Generalità Sulle Equazioni Iperboliche 

Per poter offrire una più comprensibile trattazione del metodo di calcolo alle dif- 

ferenze finite, partiamo illustrando come esse vengono applicate ai diversi tipi di 

equazioni differenziali. 

L’esempio di base di equazione differenziale di tipo iperbolico è dato dall’e- 

quazione del trasporto lineare: 

ut + aux = 0 (2.34) 

dove a è una costante, t rappresenta la variabile temporale e x è la variabile spa- 

ziale. Data la funzione u = u(x, t) ad un istante iniziale t = 0, imponendo la 

condizione: 

u(x, 0) = u0(x) (2.35) 

per una certa funzione data u0, vogliamo determinare il valore di u per tempi suc- 

cessivi (∀ t ≥ 0). Questo è un problema ai valori iniziali o di Cauchy. Risolvere 

questa equazione significa pertanto risolvere in maniera analitica il problema del 

traffico, ovvero stimare quale sarà il flusso veicolare lungo la variabile spaziale ne- 

gli istanti successivi a t = 0, avendo come dato iniziale il flusso lungo la variabile 

spaziale a t = 0. Purtroppo, come vedremo in seguito, questo tipo di trattazione 

è effettuabile soltanto in casi molto semplici e specifici e non sulle tratte autostra- 

dali, le quali presentano forti caratteristiche di discontinuità o elementi che danno 

vita ad equazioni di difficile risoluzione. 

64


L’unica soluzione di questo problema è data da: 

u(x, t) = u0(x − at). (2.36) 

Dalla formula (2.36) possiamo dedurre alcune importanti indicazioni. Innanzitut- 

to, la soluzione non è altro che la traslazione (verso destra se a > 0 o verso sinistra 

se a < 0) del dato iniziale, con “velocità dell’ondà’ pari ad a. Inoltre, lungo le 

rette ξ = x − at, la soluzione è costante e vale u0(ξ). Queste rette sono le linee 

caratteristiche dell’equazione. Possiamo ritrovare la soluzione utilizzando questo 

concetto di caratteristica. Si effettui il cambio di variabili da (x, t) a (ξ, τ) definito 

da: 

La sua inversa è data da: 

ξ = x − at 

τ = t. 

x = ξ + aτ 

t = τ. 

Possiamo allora definire una nuova funzione ũ(ξ, τ) = u(x, t). Nelle nuove 

coordinate, l’equazione (2.34) diventa: 

ũτ = ∂t 

∂τ ut + ∂x 

∂τ ux = 0. 

Questa è una semplice equazione differenziale in τ che ha come unica soluzione: 

ũ(ξ, τ) = u0(ξ) 

da cui si può ottenere anche la (2.36). Analogamente è possibile dimostrare che 

la soluzione dell’equazione 

con la condizione iniziale (2.35) è data dalla funzione: 

u(x, t) = u0(x − at)e −bt + 

ut + aux + bu = f(x, t) (2.37) 

� t 

0 

e −b(t−s) f(x − a(t − s), s)ds. (2.38) 

65


Anche in questo caso si vede come la soluzione sia influenzata solo dai valori dei 

dati u0 ed f lungo la retta caratteristica ξ = x − a(t − s). 

Si osservi che, nonostante l’equazione richieda la differenziabilità della so- 

luzione u, le (2.36) e (2.38) hanno senso per dati iniziali molto generali. Que- 

sto permette di trattare soluzioni generalizzate eventualmente discontinue. Que- 

sti metodi si possono estendere facilmente, benché in quel caso non ci sia più 

necessariamente una soluzione esplicita, alle equazioni semilineari. 

ut + aux = f(x, t, u) (2.39) 

Come vedremo in seguito, porre a costante è un caso particolare che mal si 

adatterebbe a trattare dal punto di vista matematico il fenomeno che andremo a 

studiare. 

Un’ulteriore estensione della teoria è data da equazioni e sistemi a coefficienti 

variabili, eventualmente con termine di sorgente dipendente dall’incognita. Si 

consideri per esempio l’equazione scalare: 

dove a(x, t) è una funzione regolare. 

ut + a(x, t)ux = 0 (2.40) 

Se cerchiamo un cambio di variabili che, come prima, ci riporti ad un’equazio- 

ne differenziale ordinaria, eseguiamo la trasformazione da (x, t) a (ξ, τ) definita 

da: 

lasciando per ora ξ indeterminata. 

τ = t 

Tramite questa trasformazione possiamo definire una nuova funzione ũ(ξ, τ) = 

u(x, t). Nelle nuove coordinate, l’equazione (2.40) diventa 

se imponiamo che 

ũτ = ∂t 

∂τ ut + ∂x 

∂τ ux = 0 

dx 

dτ 

= a(x, τ). 

66


In pratica, si risolve il sistema di equazioni differenziali ordinarie: 

⎧ 

⎨ dũ = 0 ũ(ξ, 0) = u0(ξ) 

⎩ 

dτ 

dx 

dτ = a(x, τ) x0 = ξ. 

(2.41) 

Essendo x0 = ξ, almeno per piccoli valori di τ, la relazione x = x(ξ, τ) è inver- 

tibile per τ fissato tramite una funzione ξ = ξ(x, τ). La soluzione del problema 

(2.40) sarà allora data dalla funzione 

u(x, t) = ũ(ξ, τ) = u0(ξ(x, t), t). 

Osserviamo infine che le idee qui esposte non si applicano direttamente al 

caso in cui le velocità possano dipendere dall’incognita u, poichè, come vedremo 

in seguito, le caratteristiche possono intersecarsi e generare soluzioni discontinue, 

che necessitano un trattamento particolare. 

2.5.2 Introduzione al Metodo delle Differenze Finite 

Il metodo alle differenze finite è fondamentale per riuscire a risolvere le equazioni 

differenziali con algoritmi numerici. In pratica, con questo metodo si modifica il 

dominio dell’analisi dal caso continuo al caso discreto. Le equazioni differenziali 

funzionano in un insieme continuo e le derivate stesse sono definite su interval- 

li infinitesimi. Evidentemte, questi comportamenti non possono essere simulati 

nel modo reale, ma devono essere discretizzati (considerazione, questa, che si 

apre a molte obiezioni di natura filosofica, oltre che matematica, ma che aiuta a 

comprendere la necessità di questo passaggio). 

Definiamo quindi una griglia di punti nel piano cartesiano (x, t) e, per sem- 

plicità, ipotizziamo che il piano rappresenti le coordinate spazio/temporali di un 

qualsiasi fenomeno he abbia luogo in una sola dimensione spaziale. Fissati un 

passo di discretizzazione spaziale ∆x = h ed un passo di discretizzazione tempo- 

rale ∆t = k, la griglia sarà data dai punti nodali del piano (xm, tn) = (mh, nk), 

per valori interi arbitrari m e n. 

Per una funzione v definita sulla griglia, scriveremo vm,n per il suo valore 

al nodo (xm, tn), e questa notazione sarà estesa naturalmente a funzioni definite 

ovunque per indicare i valori sui nodi. 

67


Figura 2.16: Una rappresentazione bidimensionale della griglia 

L’idea di base dei metodi alle differenze finite è quella di sostituire nell’equa- 

zione da approssimare, ad ogni derivata, un rapporto incrementale finito. 

Per esempio, per una funzione regolare u, la derivata temporale ∂tu(xm, tn) 

può essere approssimata sia dalla differenza in avanti (forward): 

∆+tu 

∆t 

sia dalla differenza all’indietro (backward): 

∆−tu 

∆t 

u(mh, (n + 1)k) − u(mh, nk) 

� ; 

k 

u(mh, nk) − u(mh, (n − 1)k) 

� ; 

k 

sia, infine, dalla differenza centrata (central): 

∆tu 

2∆t 

u(mh, (n + 1)k) − u(mh, (n − 1)k) 

� . 

2k 

Si procede analogamente nel caso di una derivata spaziale, ed eventualmente an- 

che nel caso di più variabili spaziali. In particolare, la derivata seconda spaziale 

68


sarà spesso approssimata dalla differenza seconda centrata 

∆2 xu u(mh, (n + 1)k) − 2u(mh, nk) + u(mh, (n − 1)k) 

� 

(∆x) 2 h2 . 

Questi schemi sono definiti da un sistema algebrico 

Ph,kv = 0 

che agisce sullo spazio delle funzioni definite sui nodi della griglia. 

Usando diverse approssimazioni per le derivate si ottengono chiaramente sche- 

mi numerici differenti. Per esempio, per l’equazione (2.34) otteniamo i seguenti 

schemi: 

vm,n+1 − vm,n 

k 


k 


k 

vm,n+1 − vm,n−1 

2k 

+ a vm+1,n − vm,n 

h 

+ a vm,n − vm−1,n 

h 

+ a vm+1,n − vm−1,n 

2h 

+ a vm+1,n − vm−1,n 

2h 

vm,n+1 − 1 

2 (vm+1,n + vm−1,n) 

+ a 

k 

vm+1,n − vm−1,n 

2h 

= 0 (2.42) 

= 0 (2.43) 

= 0 (2.44) 

= 0 (2.45) 

= 0. (2.46) 

Il primo schema (2.42) è un forward-forward o upwind con a > 0 (le differen- 

ze prendono la direzione delle caratteristiche), perchè in tale approssimazione è 

usata la differenza in avanti sia per la variabile temporale che per quella spazia- 

le. Lo schema (2.43) è un forward-backward o upwind con a < 0 ed il (2.44) 

è un forward-central. Lo schema (2.45) è un central-central o leapfrog men- 

tre il (2.46), che ha una struttura leggermente differente, è chiamato schema di 

Lax-Friedrichs. 

Come si è visto, il modo di derivare gli schemi è estremamente semplice e 

permette di approssimare qualsiasi equazione differenziale, anche a coefficienti 

variabili o non lineare. Questo non vuol dire che tutti gli schemi così ottenuti 

siano ugualmente efficienti e veloci, e in effetti non è detto nemmeno che tutti 

approssimino la soluzione del problema (2.34). Nel seguito, ci occuperemo di 

69


stabilire certi criteri che assicurino la convergenza, ossia la proprietà di approssi- 

mare la soluzione del problema limite quando i passi di discretizzazione spaziale 

e temporale tendono entrambi a zero. Tra gli schemi convergenti cercheremo di 

selezionare quelli che danno un’approssimazione più accurata con il minor nume- 

ro di punti. Una prima osservazione da fare riguardo agli schemi (2.42), (2.43), 

(2.44), (2.45) e (2.46) è che tutti possono essere riformulati esprimendo vm,n+1 co- 

me una combinazione lineare dei valori di v al livello n o, nel caso dello schema 

central-central, anche al livello n − 1. 

Per esempio lo schema (2.42) può essere riscritto come 

avendo posto 

vm,n+1 = (1 + aλ)vm,n − aλvm+1,n 

λ � k 

. (2.47) 

h 

Questo valore λ, detto anche rapporto di CFL (da Courant, Friedrichs, Lewy, noti 

studiosi dell’argomento, con riferimento a [9]), apparirà spesso nel seguito e il suo 

valore sarà determinante nello stabilire le proprietà degli schemi. Gli schemi che 

dipendono dai valori al passo immediatamente precedente sono chiamati schemi 

ad un passo, altrimenti, come nel caso dello schema central-central, si parla di 

schemi multistep. Per gli schemi ad un passo, una volta fissato il dato iniziale ed 

una sua ragionevole approssimazione sulla griglia di discretizzazione (per esem- 

pio il suo valore sui nodi), la soluzione approssimata viene costruita facilmente 

per ricorrenza. Per gli schemi multistep a k passi, k > 1, bisogna invece pre- 

scrivere una procedura di inizializzazione per assegnare la soluzione nei livelli k 

occorrenti. Per fare questo, usualmente si utilizza un metodo ad un passo per i 

primi k passi e poi si continua con il metodo proposto. 

Esempio 2.1 

Prima di procedere con l’analisi degli schemi a differenze finite, analizziamo alcu- 

ni risultati numerici ottenuti utilizzando lo schema di Lax-Friedrichs. Si consideri 

l’equazione 

ut + ux = 0 

70


con il dato iniziale 

u0 = 

⎧ 

⎨1 

− x per | x |≤ 1 

⎩ 

0 per | x |> 1 

la cui soluzione è ottenuta semplicemente ponendo u(x, t) = u0(x − t), ossia 

traslando verso destra a velocità 1 il dato iniziale. 

Figura 2.17: Lax-Friedrichs, λ = 0, 8 [30] 

Per calcolare la soluzione noi ci limiteremo al caso 0 ≤ t ≤ 2, per cui il sup- 

porto della soluzione sarà contenuto solo nell’intervallo −1 ≤ x ≤ 3 e basterà 

imporre le condizioni al bordo nulle per la v. La formula relativa allo schema di 

Lax-Friedrichs è 

vm,n+1 = 1 

2 (vm+1,n + vm−1,n) − 1 

2 λ(vm+1,n − vm−1,n) 

eccetto negli estremi destri e sinistri dove imporremo v = 0. La soluzione al 

tempo t = 1, 6 per λ = 0, 8 appare in figura (2.17), dove la soluzione esatta è 

data dalla linea continua. Si osserva allora un sostanziale rispetto della soluzio- 

ne, che viene però smussata negli spigoli a causa del fenomeno della cosiddetta 

71


viscosità numerica, che verrà discusso in seguito. Mantenendo fisso il valore di 

λ e diminuendo il valore di h, e quindi di k, la precisione migliora e possiamo 

constatare una sostanziale convergenza numerica. Se però usiamo λ = 1, 6, co- 

me mostrato nella figura (2.18) per il tempo t = 0, 8, vediamo che la soluzione 

numerica si comporta in modo anomalo, oscillando in modo incontrollato intorno 

alla soluzione esatta. Questo fatto, che verrà ripreso e spiegato in seguito, mostra 

l’importanza di una corretta scelta del parametro λ. 

Convergenza e Consistenza 

Figura 2.18: Lax-Friedrichs, λ = 1, 6 [30] 

Come già osservato, la proprietà principale di uno schema è la sua convergenza 

verso la soluzione esatta al tendere dei passi di discretizzazione h e k verso lo 

zero. Nel seguito estenderemo la nozione di schema convergente ad operatori più 

generali, ma per ora vogliamo limitarci solo alle equazioni scalari del prim’ordine 

iperboliche. 


Uno schema alle differenze finite ad un passo dato da un operatore discreto 

72


Ph,kv = 0 è convergente per l’equazione differenziale (2.34) se per qualsiasi so- 

luzione u dell’equazione con la condizione iniziale (2.35), data la soluzione vm,n 

dello schema alle differenze finite, tale che vm,0 converge a u0 quando mh con- 

verge a x, allora vm,n converge a u(x, t) se (mh, nk) tende a (x, t) al tendere di 

h e k a 0. 

Per gli schemi multistep la definizione si estende senza difficoltà specificando 

la procedura di inizializzazione. 

Per confrontare una soluzione discreta v con una definita ovunque u, dobbia- 

mo introdurre delle opportune topologie. Sia Ω un’intervallo reale e JΩ l’insieme 

dei valori dell’indice m tali che mh ∈ Ω. I valori di una discretizzazione 

v = {vm,n} al livello temporale n saranno definiti da: 

v n � {vm,n, m ∈ JΩ}. 

Una notazione analoga sarà utilizzata per la restrizione della funzione u sui 

nodi della griglia. 

Possiamo allora considerare due tipi di norma. Per prima cosa la norma del 

massimo, che è data da: 

|| v n ||∞,h� max � � 

| vm,n |, m ∈ JΩ . (2.48) 

Utilizzando la stessa norma per valutare u n avremo un’approssimazione (dal bas- 

so) della norma usuale in L ∞ della funzione u(·, tn), che in generale non coinci- 

derà con essa. 

Un’altra norma largamente utilizzata, specialmente nel contesto dei problemi 

lineari, sarà la norma discreta L 2 : 

|| v n ||2,h � 

� � 

m ∈ JΩ 

h | vm,n | 2 

� 1 

2 

. (2.49) 

La scelta della norma discreta da utilizzare non modifica in modo sostanziale 

l’analisi degli schemi, se non dal punto di vista tecnico. 

Nell’esempio precedente si vedeva che per λ = 0, 8 gli schemi di Lax-Friedrichs 

e leapfrog erano convergenti, mentre lo schema di Lax-Friedrichs mostrava un 

73


cattivo comportamento per λ = 1, 6. Dimostrare che uno schema è convergente 

è spesso difficile per un problema di natura generale e procedendo in maniera di- 

retta. Per le equazioni lineari a coefficienti costanti si può però caratterizzare la 

convergenza in modo completo utilizzando delle condizioni di facile verifica, la 

consistenza e la stabilità. 


L’errore di troncatura T di uno schema alle differenze finite per l’equazione (2.34) 

Ph,kv = 0 è definito sostituendo nello schema della soluzione numerica una 

soluzione esatta u di (2.34) abbastanza regolare, ossia: 


T(x, t) = Ph,ku(x, t). (2.50) 

Uno schema si dice consistente con l’equazione (2.34) se: 

per ogni (x, t) nel dominio di interesse. 

T(x, t) → 0 se h, k → 0 

Per alcuni schemi dovremmo dare delle restrizioni al modo in cui h e k ten- 

dono a zero. Le soluzioni dovranno essere abbastanza regolari nel senso di essere 

derivabili abbastanza volte per eseguire i calcoli. 

Esaminiamo adesso la consistenza degli schemi proposti: 

Esempio 2.2 Lo Schema Upwind con a < 0 

In questo caso sia u soluzione di (2.34), e: 

Ph,kv = vm,n+1 − vm,n 

k 

+ a vm+1,n − vm,n 

h 

= 0. 

Eseguendo lo sviluppo di Taylor di u in un intorno di (mh, nk) otteniamo 

allora, ponendo um,n = u(mh, nk) 

um,n+1 = um,n + kut + 1 

2 k2 utt + O(k 3 ), 

um+1,n = um,n + hux + 1 

2 h2 uxx + O(h 3 ), 

74


essendo le derivate calcolate nel punto stesso (mh, nk). Da questo si deduce che 

T = Ph,ku = ut + aux + 1 

2 kutt + 1 

2 ahuxx + O(k 2 ) + O(h 2 ) (2.51) 

che tende a zero se h e k tendono a zero, per cui lo schema è consistente. 

Esempio 2.3 Lo Schema di Lax-Friedrichs 

Per questo schema abbiamo: 

Ph,ku = um,n+1 − 1 

2 (um+1,n + um−1,n) 

k 

+ a um+1,n − um−1,n 

. 

2h 

Sfruttando nuovamente gli sviluppi di Taylor si può osservare che: 

ed otteniamo quindi: 

e anche: 

um±1,n = um,n ± hux + 1 

2 h2 uxx ± 1 

6 h3 uxxx + O(h 4 ) 

1 

2 (um+1,n + um−1,n) = um,n + 1 

2 h2uxx + O(h 4 ) 

um+1,n − um−1,n 

= ux + 1 

6 h3 uxxx + O(h 4 ). 

2h 

Sostituendo queste espressioni nello schema otteniamo: 

Ph,ku = ut + aux + 1 

2 k2 utt − 1 

2 k−1 h 2 uxx + 1 

6 ah3 uxxx + O(h 4 + k −1 h 4 + k 2 ). 

che, essendo u una soluzione, tende a zero se h e k tendono a zero con k −1 h 2 → 0 

Vediamo ora come l’errore di troncatura ci possa dare in alcuni esempi ele- 

mentari una stima dell’errore di approssimazione numerica che stiamo commet- 

tendo. Per un dato schema denotiamo con Tm,n l’errore di troncatura in (xn, tm) 

e sia data una stima di questo errore su di un intervallo fissato [0, T0) con 

| Tm,n |≤ Γ (2.52) 

se nk ≤ T0. Si denoti quindi con e l’errore v − u nell’approssimazione; più 

precisamente sia: 

em,n = vm,n − um,n. (2.53) 

75


Analizziamo ora, per esempio, lo schema upwind con a < 0. Inserendo la 

quantità em,n nello schema (2.42) troviamo: 

em,n+1 = (1 + aλ)em,n − aλem+1,n − kTm,n. (2.54) 

Osserviamo allora che se −1 ≤ aλ ≤ 0, i coefficienti dei due primi termini 

a destra sono non negativi e sommati danno 1. Introduciamo quindi la norma del 

massimo dell’errore: 

E n � max � � 

| em,n |, m ∈ JΩ . 

A questo punto utilizzando la non negatività dei coefficienti di em,n nella 

(2.54) si ottiene facilmente: 

ovvero, essendo E 0 = 0: 

Utilizzando la stima (2.51) abbiamo però che: 

Γ ≤ 1 

2 k 

� 

| a | 

Mtt + 

λ Mxx 

� 

E n+1 ≤ E n + kΓ. (2.55) 

E n ≤ nkΓ ≤ T0Γ. (2.56) 

dove Mtt e Mxx sono la norma del massimo per le derivate utt e uxx rispettiva- 

mente. 

Abbiamo quindi che l’errore tende a zero, ovvero l’approssimazione numerica 

converge, al tendere di k = λh a zero, con λ costante, se la soluzione limite 

ha le derivate seconde utt e uxx uniformemente limitate su tutto il dominio. Un 

ragionamento analogo si applica allo schema di Lax-Friedrichs e ovviamente allo 

schema upwind con a > 0. 

In pratica la consistenza e la convergenza sono legate dal fatto che la prima 

dice che la soluzione esatta è una soluzione approssimata dello schema numerico, 

mentre la seconda dice che la soluzione dello schema numerico è una soluzio- 

ne approssimata dell’equazione. Bisogna però porre attenzione al fatto che la 

consistenza da sola non implica necessariamente la convergenza, come si vede 

nell’esempio successivo. 

76


Esempio 2.4 Lo Schema Forward-Forward non Sempre Converge 

Si riprenda lo schema (2.42), però con a = 1. Possiamo allora scrivere lo 

schema come: 

vm,n+1 = (1 + λ)vm,n − λvm+1,n 

avendo posto come al solito λ � k 

. Si prenda, come dato iniziale: 

h 

⎧ 

⎨1 

per − 1 ≤ x ≤ 0 

u0 = 

⎩ 

0 altrove. 

(2.57) 

La soluzione u sarà allora data da una semplice traslazione verso destra 

con velocità t, ed in particolare ci saranno valori positivi di x per cui u = 1. 

Analogamente, per lo schema alle differenze si prenda come dato iniziale 

vm,0 = 

⎧ 

⎨1 

per − 1 ≤ mh ≤ 0 

⎩ 

0 altrove. 

Dalla (2.57) si vede che la soluzione numerica dipende solo dai valori di m 

maggiori o uguali al valore nel punto, per cui avremo: 

vm,n = 0 

per tutti i valori m > 0, n ≥ 0. Per questo, essendo l’approssimazione vm,n 

identicamente nulla per x > 0 non può tendere a u nel limite in nessun senso 

ragionevole. 

Stabilità 

Abbiamo visto che la sola condizione di consistenza non è sufficiente in generale 

a garantire la convergenza. La condizione supplementare da tenere in conside- 

razione è la stabilità. Per capire questa condizione si deve tener conto che se la 

successione approssimante converge in una qualche topologia, allora deve essere 

almeno limitata nella stessa topologia. 

77



Uno schema alle differenze finite a un passo Ph,kv = 0 che approssima l’equazio- 

ne (2.34) è stabile nella norma || · ||·,h nella regione Ω se per ogni T > 0 esiste 

una costante CT tale che, per ogni v 0 , 

per 0 ≤ nk ≤ T 

|| v n ||·,h≤ CT || v 0 ||·,h 

(2.58) 

Ci concentreremo nel seguito sugli schemi ad un passo espliciti per l’equazione 

(2.34) che possono dunque essere scritti come: 

v n+1 = Cv n 

dove C è un operatore lineare alle differenze indipendente da n del tipo: 

vn,m+1 = (Cv n )m = � 

k ∈ JΩ 

cm,kvk,n 

(2.59) 

(2.60) 

I coefficienti cm,k potranno in effetti dipendere da m e k per poter includere in 

seguito il caso a coefficienti variabili e le possibili condizioni al bordo. Eventuali 

termini di sorgente potranno anche essere inclusi senza difficoltà e non cambie- 

ranno le proprietà essenziali dello schema. 

Poichè stiamo trattando il caso lineare, è facile vedere che in generale la nostra 

richiesta di stabilità equivale ad una condizione sui coefficienti dell’operatore C 

del tipo: 

|| C n ||≤ CT 

per 0 ≤ nk ≤ T usando un’opportuna norma operatoriale. 

Diremo infine che uno schema è convergente nella norma prescelta se: 

(2.61) 

|| v n − u n ||·,h→ 0 (2.62) 

con λ = k/h fissato e k → 0 e per nk → t ∈ (0, T), per ogni dato iniziale u0 

per cui il problema di Cauchy per la (2.34) è ben posto nella norma prescelta. Nel 

caso presente per la norma del massimo serviranno dati limitati e per la norma 

di tipo L 2 serviranno dati nello stesso spazio. A questo punto abbiamo tutti gli 

elementi per enunciare il risultato fondamentale che vale più generalmente per 

tutti gli schemi alle differenze finite che approssimino problemi di tipo lineare. 

78


Teorema 2.1 Teorema di Equivalenza di Lax-Richtmyer. 

Uno schema alle differenze finite consistente per un problema lineare ben 

posto di evoluzione è convergente se e solo se è stabile. 

Il Teorema di Equivalenza di Lax-Richtmyer, stabilito per la prima volta da 

Peter Lax nel 1953 ([23]), quando aveva soltanto 27 anni, è un risultato di grande 

importanza. Riesce a caratterizzare un concetto utile, ma difficile come la conver- 

genza, essenzialmente legata a nozioni di carattere topologico, ad altri criteri più 

semplici da stabilire come la stabilità e la consistenza. In pratica la consistenza 

è un requisito abbastanza facile da verificare. La stabilità comporta un po‘ più 

di difficoltà, ma come vedremo in seguito è possibile operare con manipolazioni 

essenzialmente di tipo algebrico. Inoltre questa caratterizzazione è ottimale. Os- 

sia non dice soltanto che la consistenza e la stabilità implicano la convergenza, 

ma anche che uno schema instabile o non consistente non può essere convergente. 

Questo permette di scartare eventuali candidati con una semplice verifica a priori. 

Passiamo ora a considerare la classe degli schemi a tre punti, ossia degli 

schemi della forma: 

con α, β e γ costanti da fissare. 

vm,n+1 = αvm+1,n + βvm,n + γvm−1,n 

Abbiamo intanto questo primo risultato di stabilità in L 2 . 


(2.63) 

Sia dato uno schema a tre punti della forma (2.63) per l’equazione (2.34). Una 

condizione sufficiente affichè lo schema risulti stabile rispetto alla norma (2.49) è 

che valga la disuguaglianza: 

| α | + | β | + | γ | ≤ 1 (2.64) 

Per assicurare la consistenza con l’equazione (2.34) abbiamo: 


Sia il rapporto k 

h 

uguale ad una costante fissata λ > 0. Allora uno schema 

79


Schema (α, β, γ) q Convergenza 

Upwind con a < 0 (−λa, (1 + λa), 0) −λa −1 ≤ λa ≤ 0 

Upwind con a > 0 (0, (1 − λa), λa) λa 0 ≤ λa ≤ 1 

Forward-Central (−λa/2, 1, λa/2) 0 Mai 

� � 

1 − λa 1 + λa 

Lax-Friedrichs 

, 0, 1 | λa |≤ 1 

2 2 

Tabella 2.2: Schema Coefficienti [30] 

a tre punti della forma (2.63) è consistente con l’equazione (2.34) se e solo se 

α + β + γ = 1 e γ − α = λa. 

Si osservi che stiamo in effetti imponendo una limitazione nel modo di con- 

vergere delle discretizzazioni spaziali e temporali, richiedendo che λ sia una co- 

stante. Da questa proposizione si vede che la classe degli schemi lineari a tre punti 

che sono consistenti con l’equazione (2.34) forma una famiglia ad un parametro. 

Ponendo: 

q = α + γ (2.65) 

possiamo riscrivere tutti questi schemi nella forma cosiddetta viscosa; 

vm,n+1 = vm,n − aλ 

2 (vm+1,n − vm−1,n) + q 

2 (vm+1,n − 2vm,n + vm−1,n). (2.66) 

Il parametro q è legato infatti alla viscosità numerica dello schema, in quanto 

formalmente lo schema è consistente all’ordine 2, con l’equazione viscosa; 

ut + aux = 1 q 

λh( 

2 λ2 − a2 )uxx. (2.67) 

In particolare, abbiamo la tabella dei coefficienti 2.2. 

Le condizioni di stabilità trovate grazie alla (2.64) sono in questo caso anche 

necessarie. Osserviamo tuttavia che, tra gli schemi esaminati, la viscosità mas- 

sima, in regime di stabilità, è quella dello schema di Lax-Friedrichs, mentre il 

forward-central, che come si potrebbe dimostrare non è mai stabile, ha viscosità 

negativa nell’equazione equivalente. 

80


La Condizione di CFL 

Prima di passare a discutere più in dettaglio la stabilità dei vari schemi, essenzial- 

mente grazie all’analisi di von Neumann, presentiamo una condizione necessaria 

per la convergenza di facile verifica e che permette quindi una veloce analisi preli- 

minare. Questa condizione fu proposta nel 1928 da R. Courant, K.O. Friedrichs e 

H. Lewy nel loro lavoro fondamentale sui metodi alle differenze finite ed è cono- 

sciuta oggi come la condizione di CFL. Essa esprime una condizione necessaria 

di convergenza nei termini del dominio di dipendenza della soluzione. Prendiamo 

ad esempio la soluzione del problema dato dalle equazioni (2.34) e (2.35). Questa 

soluzione è completamente determinata in un punto (x, t) a partire dal valore del 

dato iniziale nel punto (x − at). La condizione di CFL stabilisce che per uno 

schema convergente il dominio di dipendenza dello schema numerico deve con- 

tenere il dominio di dipendenza dell’equazione differenziale. Nel caso dell’equa- 

zione (2.34), eventualmente anche nel caso disomogeneo (2.38), questo si riduce 

alla caratteristica retrograda uscente dal punto (x, t), ossia la retta di equazione 

ξ = x − a(t − s). 

Teorema 2.2 

Se fissiamo il rapporto λ = k 

= costante per uno schema esplicito a tre punti 

h 

per l’equazione (2.34) della forma (2.63), allora una condizione necessaria per 

la stabilità è la seguente, detta condizione di CFL: 

| λa | ≤ 1 (2.68) 

In particolare è facile estendere questo risultato ai sistemi lineari fortemente 

iperbolici del tipo (2.40) per cui vale quindi la seguente regola generale: non 

ci sono schemi espliciti incondizionatamente stabili e consistenti alle differenze 

finite per sistemi fortemente iperbolici. La stabilità incondizionata potrà infatti 

essere solo recuperata al prezzo di una perdita di accuratezza dello schema per la 

classe dei cosiddetti schemi impliciti. 

81


Monotonia 

Un modo semplice per trovare stime della norma del massimo è quello di costruire 

degli schemi che verifichino la proprietà del confronto monotono, ossia se due dati 

iniziali discretizzati verificano vm,0 ≤ ˜vm,0 allora per ogni n > 0 vale: 


vm,n ≤ ˜vm,n. 

Uno schema nella forma (2.60) è detto essere monotono se tutti i coefficienti 

cm,k ≥ 0. 

Si vede facilmente che lo schema è monotono se e solo se verifica la proprietà 

del confronto monotono. Abbiamo la seguente stima di limitatezza. 

Teorema 2.3 

Sia dato uno schema monotono della forma (2.60). Allora, posto 

e 

avremo che 

vmin � min{vm,0} 

vmax � max{vm,0} 

vmin ≤ vm,n ≤ vmax 

(2.69) 

Dal Teorema di Lax-Richtmyer abbiamo immediatamente la convergenza di 

tutti gli schemi consistenti e monotoni (per una dimostrazione diretta si può pro- 

cedere anche stimando direttamente l’errore numerico come nelle (2.54)-(2.56). 

È facile inoltre caratterizzare gli schemi monotoni tra tutti gli schemi consistenti 

a tre punti della forma (2.63). Per enunciare questa caratterizzazione utilizziamo 

però la forma viscosa (2.66). 


Uno schema esplicito a tre punti consistente con l’equazione (2.34), nella forma 

viscosa (2.66), è monotono se e solo se 

λ | a | ≤ q ≤ 1 (2.70) 

82


Per dimostrare tale risultato basta osservare che valgono le seguenti uguaglianze: 

α = 1 

(q − aλ) 

2 

β = 1 − q 

γ = 1 

(q + aλ) 

2 

Vediamo dunque che la condizione di CFL è ancora necessaria per la conver- 

genza. Inoltre gli schemi upwind e Lax-Friedrichs sono monotoni. In particolare 

lo schema monotono con la più bassa viscosità numerica è lo schema upwind, 

mentre Lax-Friedrichs è quello con la più alta. Osserviamo infine come la condi- 

zione (2.70) sia in effetti equivalente alla condizione (2.64) che avevamo trovato 

per la norma L 2 . 

Sfortunatamente la classe degli schemi monotoni è troppo ristretta per contenere 

delle approssimazioni più accurate, per cui sarà necessario considerare la stabilità 

di tipo L 2 , che risulterà essere meno restrittiva. 

L’Analisi di Von Neumann 

Lo strumento più efficace per l’analisi delle equazioni lineari alle derivate par- 

ziali è senz’altro l’uso estensivo della trasformata e delle serie di Fourier. Nel 

caso a coefficienti costanti questo permette di stabilire in modo diretto la buona 

disposizione e le proprietà qualitative delle soluzioni di larghe classi di problemi 

differenziali. In particolar modo è possibile caratterizzare in modo completo se, 

in L 2 , i problemi di tipo iperbolico e parabolico siano ben posti, e nel caso scalare 

e per i sistemi. 

Se si considera una funzione v = {vm} definita su una griglia spaziale di passo 

h, la sua serie di Fourier è data da: 

per 

^v(ξ) = 1 

√ 2π 

∞� 

m=−∞ 

83 

he −imhξ vm 

(2.71)


dà: 

ξ ∈ 

� 

− π 

� 

� 

π 

, . Si ha allora che ^v − 

h h 

π 

� � � 

π 

= ^v e la formula di inversione 

h h 

vm = 1 

� π 

h 

√ 

2π − π 

e 

h 

imhξ ^v(ξ)dξ. (2.72) 

� Si noti che, di solito, si parte con una funzione periodica sull’intervallo 

− π 

� 

π 

, e si mostra che sotto opportune ipotesi vale la formula di rappresenta- 

h h 

zione (2.71) con i coefficienti dati da (2.72). 

Prima di addentrarci ulteriormente nell’analisi degli schemi numerici, vale la 

pena di dare un cenno alle proprietà della trasformata di Fourier che viene utiliz- 

zata per la risoluzione dei problemi differenziali. Sia ad esempio u una soluzione 

dell’equazione (2.34) e û la sua trasformata di Fourier nella variabile spaziale, 

ossia: 

û(ω) = 1 

� ∞ 

√ e 

2π −∞ 

−iωx u(x)dx. (2.73) 

Allora û risolve l’equazione differenziale ordinaria 

che ha come unica soluzione: 

ût = −iaωû 

û(ω, t) = e −iatω û0(ω). 

La norma L 2 viene conservata nell’evoluzione dell’equazione e le proprietà di 

regolarità della soluzione vengono trasformate in proprietà di decrescenza all’in- 

finito della û e viceversa. Questo spiega perchè le soluzioni irregolari presentano 

oscillazioni sulle frequenze più alte, che in questo caso si trovano ad avere grande 

ampiezza. 

Per illustrare il metodo di Von Neumann considereremo un caso particolare, 

lo schema forward-backward (2.43) per l’equazione (2.34): 


k 

che riscriviamo in forma compatta come: 

+ a vm,n − vm−1,n 

h 

vm,n+1 = (1 − aλ)vm,n + aλvm−1,n 

84 

= 0 (2.74) 

(2.75)


sempre ponendo λ � k 

h . 

Dalla (2.83) abbiamo: 

vm,n = 1 

√ 2π 

� π 

h 

− π 

h 

e imhξ ^v n (ξ)dξ. 

Sostituendo quindi nella (2.75) si ottiene la relazione 

vm,n+1 = 1 

√ 2π 

� π 

h 

− π 

h 

da cui si deduce la relazione per ricorrenza 

con 

e imhξ [(1 − aλ) + aλe −ihξ ]^v n (ξ)dξ (2.76) 

^v n+1 (ξ) = g(hξ)^v n (ξ) (2.77) 

g(hξ) � (1 − aλ) + aλe −ihξ . 

Questo mostra come l’avanzamento di un passo temporale dello schema pro- 

vochi un’amplificazione di un fattore g(hξ) della trasformata numerica, ottenendo 

così 

^v n (ξ) = g(hξ) n ^v 0 (ξ). (2.78) 

Daremo adesso la condizione per la stabilità in L 2 per le approssimazioni nu- 

meriche dell’equazione (2.34), nonostante questa analisi sia valida più in gene- 

rale per problemi iperbolici e parabolici che siano ben posti in questa topologia. 

Seguendo quanto illustrato nell’esempio precedente possiamo affermare che per 

ogni schema alle differenze ad un passo e su 2l + 1 punti della forma (2.59), 

possiamo scrivere la relazione: 

con 

^v n+1 (ξ) = g(hξ)^v n (ξ) (2.79) 

g(hξ) � 

l� 

cle ilhξ . 

k=−l 

La funzione g è detta fattore di amplificazione e contiene tutte le informazio- 

ni importanti sullo schema e, cosa più importante, risulta essere uno strumento 

abbastanza facile da analizzare. 

85


Teorema 2.4 

Uno schema alle differenze ad un passo per l’equazione (2.34) è stabile se e solo 

se esiste una costante K e alcuni valori fissati k0 e h0 tali che 

| g(χ, h, k) |≤ 1 + Kk (2.80) 

per tutti i valori di χ, 0 < k ≤ k0, e 0 < h ≤ h0. Se inoltre g(χ, h, k) è 

indipendente da h e k allora basta porre K = 0 nella (2.80). 

Si osservi che si può dimostrare che la condizione di Von Neumann è neces- 

saria per i sistemi a coefficienti costanti, se applicata agli autovalori della matrice 

di amplificazione, e continua ad essere anche sufficiente per tutti gli schemi ad un 

passo per le equazioni scalari con una sola derivata nel tempo. 

Terminiamo infine osservando che l’analisi di Von Neumann può essere adat- 

tata opportunamente, anche se non direttamente, allo studio delle equazioni a 

coefficienti variabili, mediante il metodo del congelamento dei coefficienti. Per 

esempio per l’equazione a coefficienti variabili 

ut + a(x, t)ux = 0 (2.81) 

varrà ancora la condizione di stabilità | a(xm, tn)λ | ≤ 1 per tutti i punti della 

griglia (xm, tn) nel dominio computazionale. 

Ordine di Accuratezza e Schema di Lax-Wendroff 

Fino a questo momento abbiamo considerato gli schemi solamente in base alla 

loro convergenza o meno, ossia in ultima analisi in base alla loro consistenza e 

stabilità. Tuttavia dal punto di vista numerico è altrettanto importante stabilire la 

velocità di convergenza degli schemi. Questo sarà fatto come conseguenza della 

nozione di accuratezza dello schema che definiamo qui di seguito. 


Uno schema consistente con l’equazione (2.34) si dice accurato di ordine q in 

spazio e di ordine p in tempo, in breve accurato di ordine (q, p), se: 

| T(x, t) |= O(k p ) + O(h q ) se (h, k) → 0 

86


per ogni (x, t) nel dominio di interesse. Nel caso in cui k = K(h) diciamo che lo 

schema è di ordine r se: 

| T(x, t) |= O(h r ) se h → 0. 

In pratica l’accuratezza è una nozione più forte di consistenza, che corrisponde 

ad un errore di troncatura solamente dell’ordine di o(1). 

Cominciamo adesso a verificare l’ordine di accuratezza di alcuni degli schemi 

conosciuti. Lo schema di Lax-Friedrichs dà uno sviluppo del tipo: 

1. 

T = 1 

2 kutt − 1 

2 k−1 h 2 uxx + 1 

6 ah2 uxxx + O(h 4 + k −1 h 4 + k 2 ). 

Fissando k = λh per una costante λ fissata, vediamo che lo schema è di ordine 

Analogamente abbiamo lo schema upwind con a < 0 che dà: 

T = 1 

2 kutt + 1 

2 ahuxx + O(k 2 ) + O(h 2 ), 

corrispondente ad uno schema di ordine (1, 1) o, fissando k = λh per una costante 

λ fissata, ancora uno schema di ordine 1. 

Più in generale vale la seguente proprietà: 

Teorema 2.5 

Uno schema lineare monotono nella forma (2.60) è al più del primo ordine, a 

meno che non sia lo schema banale vm,n+1 = vm,n con λ | a |= 1. 

Si prenda la forma generale (2.66) di uno schema a tre punti consistente per 

l’equazione (2.34). Uno schema di questo tipo può essere di ordine (2, 2), oppure 

per λ = k/h fissato, di ordine 2, se e solo se vale la condizione: 

q = (aλ) 2 . (2.82) 

Questo significa che esiste un solo schema lineare a tre punti consistente che sia 

di ordine 2. Questo schema, chiamato schema di Lax-Wendroff, è stato proposto 

per la prima volta nel 1960 e si scrive: 

vm,n+1 = vm,n− aλ 

2 (vm+1,n−vm−1,n)+ a2 λ 2 

2 (vm+1,n−2vm,n+vm−1,n). (2.83) 

87


La sua viscosità numerica è la più bassa possibile per lasciare l’equazione 

equivalente (2.67) ancora parabolica. Chiaramente, poichè la condizione (2.70) 

non è verificata, lo schema non è monotono. 

Eseguiamo ora l’analisi di stabilità dello schema di Lax-Wendroff. Il suo fattore 

di amplificazione si calcola facilmente ed è dato da 

per cui 

g(χ) = 1 − aλ 

� 

e 

2 

iχ − e −iχ 

� 

+ a2λ2 � 

e 

2 

iχ − 2 + e −iχ 

� 

= 

= 1 − iaλ sin(χ) − 2a 2 λ 2 sin 2 

� � 

χ 

2 

| g | 2 = 1 − 4a 2 λ 2 (1 − a 2 λ 2 4 χ 

) sin 

2 

Abbiamo quindi che g(χ) ≤ 1 se e soltanto se | aλ |≤ 1. Lo schema risulta quindi 

L 2 -stabile. In generale vale anzi la seguente caratterizzazione degli schemi a tre 

punti consistenti con l’equazione (2.34). 


Uno schema esplicito a tre punti consistente con l’equazione (2.34), nella forma 

viscosa (2.66), è L 2 -stabile se e solo se 

(λa) 2 ≤ q ≤ 1 (2.84) 

Vediamo quindi che la stabilità L 2 è meno restrittiva della stabilità nella norma 

del massimo e permette quindi di trovare almeno uno schema del secondo ordine 

stabile. Vediamo come si comporta lo schema di Lax-Wendroff nei confronti per 

esempio dello schema upwind. Si prenda l’equazione (2.34) con il dato iniziale 

uguale alla funzione caratteristica dell’intervallo (0.2, 0.4). La figura (2.19) mo- 

stra il risultato per lo schema upwind, mentre la figura (2.20) per lo schema di 

Lax-Wendroff. Nello schema monotono si nota uno smussamento degli spigoli e 

una piccola riduzione dell’altezza, mentre lo schema di Lax-Wendroff mantiene 

l’altezza dei bordi molto meglio, producendo tuttavia delle piccole oscillazioni. 

Riducendo h si vede un sostanziale miglioramento, anche se le oscillazioni per- 

sistono. Questo è dovuto al fatto che la nostra analisi dell’errore è valida solo 

88


per soluzioni abbastanza regolari. Si veda infatti come si comporta lo schema di 

Lax-Wendroff con un dato molto più regolare (di fatto ∈ C ∞ ) nella figura (2.21). 

In pratica, l’instabilità, essendo legata alla crescita delle frequenze elevate, appa- 

re prima per dati irregolari, come si vede nelle figure (2.20) e (2.21). Si osservi 

anche che in generale questa instabilità è di fatto un fenomeno locale. Per esem- 

pio nella figura (2.2) si vede che l’instabilità nasce essenzialmente nel punto di 

discontinuità della derivata e solo dopo si propaga a tutta la soluzione. Questo 

permette di distinguere tra gli effetti di un errore di programmazione, che spesso 

sono globali, e l’instabilità numerica dello schema. 

89


Figura 2.19: Trasporto lineare con il metodo upwind [30] 

90


Figura 2.20: Trasporto lineare con il metodo di Lax-Wendroff [30] 

91


Figura 2.21: Trasporto lineare (dato regolare) con il metodo di Lax-Wendroff [30] 

92


Accenniamo infine alla relazione che intercorre tra uno schema di ordine r e 

la sua accuratezza. Vale il seguente risultato, e in particolare se ne può dimostrare 

uno analogo nel caso parabolico e più generalmente per tutti i problemi di Cauchy 

ben posti in L 2 . 

Teorema 2.6 

Sia dato uno schema stabile per l’equazione (2.34) che sia accurato di ordine 

r ≥ 1. Allora esiste un indice intero non negativo s ≥ r tale che se u0 ∈ H s , 

per ogni fissato T > 0 esiste una costante CT tale che 

per ogni n tale che 0 ≤ kn ≤ T 

|| u n − v n ||2,h ≤ CTh r || u0 ||H s 

In generale per i metodi iperbolici si trova s = r + 1 e per quelli parabolici 

s = r + 2. [30] 

93

2.6. IL MODELLO Carlo Caligaris, Iacopo Salvarani 

2.6 Il Modello 

2.6.1 La Scelta del Modello 

Dopo una attenta valutazione delle possibili equazioni che possono meglio rap- 

presentare il comportamento della tratta autostradale di nostra competenza si è 

scelto di usufruire, nell’implementazione del software, delle considerazioni mo- 

dellistiche suggerite da Markos Papageorgiou, ingegnere e ricercatore matematico 

greco che a lungo si è occupato di problemi di controllo del traffico e ha fornito 

un metodo per utilizzare equazioni che rappresentano un modello macroscopico 

di traffico veicolare. 

Come già illustrato il tratto di competenza appartiene ad una categoria ben 

definita: si tratta, infatti, di una autostrada multicorsia con numerose rampe di in- 

gresso e uscita. Questo chiaramente comporta una ulteriore complicazione della 

trattazione ma permette di adattare adeguatamente un modello di tipo macrosco- 

pico quale quello suggerito da Papageorgiou. è pertanto possibile considerare il 

comportamento del flusso di traffico come quello di un fluido avente determinate 

grandezze che lo caratterizzano. 

Variabili di Stato del Modello 

Riprendiamo le definizioni tipiche dei modelli macroscopici per il traffico: 


Si definisca la densità locale dei veicoli alla sezione x al tempo t 

ρ(x, t) 

come la grandezza che dà un’informazione su quanti veicoli stanno impegnando 

la carreggiata. È misurata in veicoli per chilometro. 


Si definisca la velocità media dei veicoli alla sezione x al tempo t 

v(x, t) 

94


come la media delle velocità tenute dai veicoli nella sezione e al tempo indicato. 

È misurata in chilometri orari. 


Si definisca il flusso veicolare 

q(x, t) 

come la grandezza che dà un’informazione su quanti veicoli attraversano una 

sezione di carreggiata in un intervallo di tempo. È misurato in veicoli all’ora. 

Agendo in maniera ricorsiva su queste variabili di stato è possibile farle evolvere 

in maniera congruente al comportamento del traffico veicolare e da questo ottenere 

una previsione sull’effettivo andamento futuro del traffico autostradale. 

Le ulteriori variabili che verranno ad essere definite per necessità rappresentativa 

del modello verranno illustrate e definite in seguito quando saranno introdotte nel 

modello. 

2.6.2 L’equazione fondamentale di Papageorgiou 

Come già è stato illustrato una delle proprietà fondamentali dei modelli macro- 

scopici è proprio la maniera in cui le variabili che lo descrivono interagiscono e 

sono relazionate fra loro, e questo è tanto più vero nei modelli macroscopici ove le 

variabili tentano di rappresentare non i singoli elementi ma l’insieme degli stessi. 

Sicuramente è sempre valida la relazione 

q(x, t) = ρ(x, t) · v(x, t) 

ma non possiamo essere altrettanto sicuri della bontà della curva caratteristica ve- 

locità-densità che era stata definita partendo da ipotesi di omogeneità e condizione 

stazionaria che sicuramente non sono proprie del tratto stradale in questione. 

Abbiamo utilizzato una delle relazioni tra velocità e densità illustrate in Tabel- 

la 2.1, cioè quella proposta dallo stesso Papageorgiou, che chiameremo diagram- 

ma fondamentale o relazione fondamentale: 

� 

1 − � ρ 

vρ = vf 

95 

ρmax 

�m �l (2.85)


dove l e m sono parametri determinabili in via sperimentale dall’osservazione di 

casi reali. In altre parole è possibile raccogliere una grande quantità di dati sulle 

coppie (ρ, v) per ogni singola sezione in cui è divisa l’autostrada. Tutti i dati pun- 

tuali raccolti vengono posti su un piano cartesiano (ρ, v). A tal punto mantenendo 

la formulazione di Papageorgiou si può cercare la curva che meglio segue il com- 

portamento della distribuzione dei punti semplicemente modificando i valori degli 

esponenti l e m. 

Applicando un qualsiasi algoritmo (ad esempio nel nostro caso abbiamo utilizzato 

un semplice metodo di programmazione lineare volto alla minimizzazione della 

somma dei quadrati delle distanze fra punti reali e punti della curva caratteristica) 

è possibile cercare la curva caratterizzata dalla migliore approssimazione e fissare 

i valori dei due esponenti. 

I principali vantaggi della relazione fondamentale sono due. Innanzitutto è ca- 

ratterizzata da una grande capacità descrittiva del comportamento dell’autostrada; 

infatti possiamo definire una coppia di esponenti (l, m) per ogni singola sezione 

in cui abbiamo suddiviso il percorso globale. Questo è molto importante poichè 

ćhiaro che la relazione fra densità e velocità è influenzata soprattutto dalle carat- 

teristiche della sezione stradale, che possono variare anche di parecchio anche su 

uno stesso tronco autostradale. 

In secondo luogo lo stesso Papageorgiou suggerisce i range entro i quali ricercare 

i valori degli esponenti l e m, per cui la ricerca stessa dei valori ha una comples- 

sità computazionale relativamente bassa (lo stesso problema di minimizzazione 

dei quadrati ne risulta molto semplificato). Si consiglia di tenere: 

e 

0, 5 ≤ m ≤ 2, 5 

2 ≤ l ≤ 4. 

Da ciò derivano le nuove curve caratteristiche velocità-densità e flusso-densità, 

una diversa per ogni singola sezione autostradale. 

96


Figura 2.22: Curva Caratteristica velocità-densità 

Figura 2.23: Curva Caratteristica flusso-densità 

2.6.3 L’Equazione del Modello 

Consideriamo nuovamente il caso in studio; si tratta come già detto di una lunga 

autostrada multicorsia con numerose stazioni di ingresso e di uscita. L’obiettivo è 

sviluppare un modello matematico del flusso di traffico che descriva l’evoluzione 

97


dinamica delle variabili, che abbiamo definito per descrivere il comportamento 

del traffico, lungo l’autostrada. 

Come illustrato in precedenza osserviamo il flusso veicolare come un un fluido 

avente un certo valore di densità e flusso. Da ciò possiamo desumere l’equazione 

di conservazione della materia che già prima abbiamo trattato. La differenza è che 

però in questo caso l’equazione: 

∂ρ(x, t) 

∂t 

+ ∂q(x, t) 

∂x 

non è sufficiente e descrivere il comportamento del modello. 

= 0 (2.86) 

In effetti, mantenendo il paragone fra comportamento del traffico e comporta- 

mento del fluido, appare chiaro che nel nostro caso il canale di trasporto del fluido 

non è assolutamente un canale chiuso, proprio a causa dei caselli di entrata e usci- 

ta da cui i veicoli possono liberamente entrare e uscire. Ciò fa sì che l’equazione 

che avevamo trattano analiticamente non sia più valida e impone la correzione del 

modello. 


Definiamo il flusso di veicoli entrante alla sezione x e al tempo t 

r(x, t) 

come la grandezza che dà un’informazione su quanti veicoli entrino nell’unità di 

tempo alla sezione e al tempo indicati. Si misura in veicoli per ora. 


Definiamo il flusso di veicoli uscente dalla sezione x e al tempo t 

s(x, t) 

come la grandezza che dà un’informazione su quanti veicoli escano nell’unità di 

tempo alla sezione e al tempo indicati. Si misura in veicoli per ora. 

Introdotti questi fondamentali elementi possiamo riscrivere l’equazione che regola 

il modello. 

∂ρ 

∂t 

+ ∂q 

∂x 

98 

= r − s (2.87)


Chiaramente il significato dell’equazione è identico, semplicemente viene anche 

considerata la possibilità che alcuni veicoli entrino o escano dall’autostrada. 

Trattandosi di un’equazione differenziale alle derivate parziali simile a quella vi- 

sta nella trattazione analitica del problema del traffico, la sua risoluzione comporta 

le medesime difficoltà che erano state riscontrate in precedenza; inoltre troviamo 

due complicazioni in più che introducono ulteriore complessità alla risoluzione: 

i due termini relativi agli ingressi e alle uscite dei veicoli e il fatto che la fun- 

zione v(ρ) non segue più la legge lineare (2.7) ma la relazione fondamentale di 

Papageorgiou (2.85). Per farla breve sarebbe impensabile cercare di ottenere una 

risoluzione analitica del problema. 

Pertanto per poter avere una soluzione dell’equazione conviene passare attraverso 

una soluzione numerica del problema sfruttando i metodi di risoluzione alle dif- 

ferenze finite. 

Come è stato illustrato in precedenza l’idea di base dei metodi alle differenze finite 

è quella di sostituire, nell’equazione da approssimare, ad ogni derivata un rapporto 

incrementale finito. Se ad esempio ci troviamo a trattare un fenomeno che avviene 

nel tempo e in una sola dimensione spaziale (ed è proprio questo il nostro caso), 

ciò si ottiene definendo una griglia di punti nel piano cartesiano (x, t). Fissati un 

passo di discretizzazione spaziale ∆x = h ed un passo di discretizzazione tempo- 

rale ∆t = k, la griglia sarà data dai punti nodali del piano (xm, tn) = (mh, nk), 

per valori interi arbitrari m e n. Soluzioni di questo genere sono molto facilmente 

implementabili e programmabili su calcolatore. 

Si pone però a questo punto un problema dovuto principalmente alla natura fisi- 

ca del problema. Scegliere un passo di discretizzazione ∆t per il tempo è cosa 

concettualmente abbastanza semplice: se ci si dimentica per un attimo di tutti i 

problemi relativi alla convergenza e alla stabilità delle soluzioni alle differenze 

finite, basta scegliere una porzione di tempo non troppo piccola, dal momento 

che appesantirebbe eccessivamente l’elaborazione, e non troppo grande, poiché 

il problema potrebbe perdere capacità descrittiva. Molto più complicato sarebbe 

scegliere un passo di discretizzazione spaziale da applicare alla lunghezza del- 

l’autostrada. Per scegliere un ∆x sensato bisognerebbe tenere conto di numerosi 

99


fattori: la lunghezza dei veicoli, la lunghezza dell’intera autostrada, la lunghezza 

delle varie tratte fra una stazione di entrata/uscita e quella successiva. 

Papageorgiou è riuscito a rispondere a questo problema adattando i metodi di ri- 

soluzione alle differenze finite al problema; ciò che ha fatto è stato imporre una 

discretizzazione a passo costante sulla dimensione temporale (ovvero le variabili 

di stato vengono calcolate solo per gli istanti nk). Quindi ha suddiviso il percorso 

autostradale in numerose tratte, ognuna delle quali avesse al massimo una singo- 

la stazione di entrata e una singola stazione di uscita; infine lungo la dimensione 

spaziale ha applicato una discretizzazione a passo variabile, in cui la lunghezza 

del passo è uguale alla lunghezza delle singole tratte (ovvero le variabili di stato 

sono calcolate in modo da dare un valore per ognuna delle tratte). 

Quello che avviene in pratica è che ad ogni ricorsione del metodo numerico il mo- 

dello avanza di un istante temporale e, per ogni singola tratta, vengono calcolati 

i valori delle variabili di stato. Per effettuare questo calcolo vengono utilizzati i 

valori delle variabili all’istante precedente riferiti a quella medesima tratta e alle 

due tratte adiacenti (la precedente e la successiva). 

2.6.4 Le Equazioni di Papageorgiou 

L’equazione della densità 

L’equazione alle derivate parziali della densità diventa l’equazione discretizzata: 

ρi(k + 1) = ρi(k) + T 

∆i 

� qi−1(k) − qi(k) + ri(k) − si(k) � 

(2.88) 

dove l’indice i è quello relativo alle tratte, mentre l’indice k è quello relativo agli 

istanti temporali. T è il passo di discretizzazione temporale; pertanto ρi(k+1) è il 

valore della densità sulla tratta i-esima al passo di discretizzazione (k + 1)-esimo, 

ovvero al tempo T · (k + 1). ∆i è invece la lunghezza della i-esima tratta. 

qi(k) è il flusso veicolare in uscita dalla tratta i-esima al passo di discretizzazione 

(k)-esimo; analogamente qi−1(k) è il flusso veicolare in uscita al medesimo passo 

di discretizzazione ma relativo alla tratta (i − 1)-esima, che è quella immediata- 

mente prima; pertanto trattasi del flusso in entrata per la tratta i-esima. 

100


ri(k) è il flusso veicolare entrante proveniente dalla stazione di ingresso nella trat- 

ta i-esima al passo di discretizzazione (k)-esimo; si(k) è il flusso veicolare uscen- 

te attraverso la stazione di uscita nella tratta i-esima al passo di discretizzazione 

(k)-esimo. 

Figura 2.24: Flussi veicolari relativi alla tratta i-esima 

Significato dell’equazione della densità 

L’equazione della densità ha un significato fisico molto chiaro: il termine 

� qi−1(k) − qi(k) + ri(k) − si(k) � 

costituisce la somma algebrica dei flussi che interagiscono con la tratta i-esima 

immettendo in essa veicoli e permettendo l’uscita degli stessi. Tale termine per- 

tanto dà come risultante il differenziale nel tempo del numero dei veicoli (potrem- 

mo definirlo un flusso incrementale). 

Moltiplicato tale valore per il periodo di discretizzazione del tempo 

T � qi−1(k) − qi(k) + ri(k) − si(k) � 

otteniamo il differenziale effettivo di veicoli che si è verificato nel passo temporale 

per quella tratta; volendolo vedere espresso dall’analisi dimensionale 

� � 

numero veicoli 

[tempo] · 

= [numero veicoli] 

tempo 

101


Dividendo poi il numero incrementale di veicoli per la lunghezza della tratta 

T 

∆i 

� qi−1(k) − qi(k) + ri(k) − si(k) � 

si ottiene il differenziale di densità per quella tratta 

� � 

numero veicoli 

= [densitá] 

lunghezza 

il quale va sommato al valore della densità al passo di discretizzazione temporale 

precedente per ottenere il nuovo valore di densità. 

ρi(k) + T 

∆i 

Convergenza della densità 

� qi−1(k) − qi(k) + ri(k) − si(k) � 

[densitá] + [densitá] = [densitá] 

Come appena mostrato l’equazione discretizzata della densità proposta da Papa- 

georgiou sembra portare a riprodurre esattamente il comportamento dell’anda- 

mento di ρ(x, t). Non dobbiamo però dimenticare che questa affermazione è vera 

solo se la discretizzazione è tale da assicurare la convergenza. 

Ora però appare chiaro che tutta la trattazione introdotta nella sezione teorica 

è valida per i metodi alle differenze finite di risoluzione di equazioni alle deri- 

vate parziali veri e propri. In realtà l’equazione discretizzata di Papageorgiou è 

un adattamento dell’idea che regola i metodi alle differenze finite al principio di 

conservazione della materia che porta ad un modello macroscopico del comporta- 

mento del traffico. Inoltre come già detto la discretizzazione stessa della variabile 

spaziale non segue la trattazione dei metodi alle differenze finite ma si piega alla 

necessità della rappresentazione delle tratte autostradali. 

Detto questo proveremo ugualmente ad effettuare alcune considerazioni sulla con- 

vergenza delle equazioni di Papageorgiou, ma sottolineando che tale trattazione 

non ha alcuna pretesa di rigore matematico. Semplicemente è nostro desiderio 

mostrare che il metodo del matematico greco, che ha offerto in già numerosissime 

applicazioni ottimi risultati, poggia le sue fondamenta sulla teoria matematica. 

102


Proviamo pertanto a controllare se è verificata la condizione di CFL (2.68), 

che è condizione necessaria per la stabilità e la convergenza: 

applichiamola all’equazione 

| aλ | ≤ 1; 

ρt + vf(1 − 2 ρ 

ρmax 

) ρx = 0. 

Già ci troviamo davanti ad alcuni problemi: la condizione di CFL si riferisce a 

equazioni in cui il termine a sia indipendente dalla funzione incognita, e quindi 

soltanto a(x, t); nel nostro caso invece a dipende anche da ρ. Inoltre alcuni dei 

termini costanti che determinano il valore di a nel nostro caso non sono costanti 

ma variano da tratta a tratta. Infine λ, ovvero il rapporto fra i passi di discretiz- 

zazione, dovrebbe essere costante, ma come ben sappiamo il passo di discretizza- 

zione sulla coordinata spaziale è variabile e corrisponde alle lunghezze delle tratta 

autostradali. 

Proviamo pertanto a porci nella condizione peggiore possibile, ovvero lasciamo 

che | aλ | resti in funzione di ρ e assumiamo che i vari elementi (che dovrebbero 

essere costanti ma nel nostro caso sono variabili) che concorrono a determinare il 

suo valore siano sfavorevoli e quindi tali da massimizzare | aλ |. 

Quindi poniamo: 

· vf = 130 km/h; 

· ρmax=150 auto/km; 

· ∆t = 0.0167 h; 

· ∆x = 2.4 km. 

ed otteniamo il grafico di Figura 2.25. 

103


Figura 2.25: | aλ | in funzione della densità 

Possiamo notare che la condizione di CFL è verificata fino a valori di densità 

di circa 160 veicoli per km. Questo è già abbastanza positivo; infatti i valori mas- 

simi di densità si aggirano di solito intorno a 180 veicoli per km, questo significa 

che la stabilità e la convergenza sono plausibili per quasi la totalità delle situa- 

zioni di traffico, senza contare che ci si era posti volutamente in una condizione 

fortemente negativa che non si realizza mai. 

Proviamo adesso a porre delle condizioni comunque sfavorevoli alla verifica della 

condizione di CFL, ma il cui accadimento è possibile; per la precisione ricerchia- 

mo la condizione che si può realizzare col valore | aλ | maggiore. 

Quindi poniamo: 

· vf = 130 km/h; 

· ρmax=180 auto/km; 

· ∆t = 0.0167 h; 

· ∆x = 2.6 km. 

104


ed otteniamo il grafico di Figura 2.26 

Figura 2.26: | aλ | in funzione della densità 

E osserviamo che la condizione di CFL decade per valori di densità di circa 

200 veicoli per km. Come detto pocanzi i valori massimi di densità che si riscon- 

trano raramente superano i 180 veicoli per km, pertanto si può dire che anche nella 

situazione più sfavorevole la condizione di CFL è verificata per qualsiasi condi- 

zione del traffico veicolare. 

Teniamo a sottolineare per l’ultima volta che questo non equivale a sostenere la 

convergenza di un metodo alle differenze finite, ma certamente si può dire che non 

solo i risultati sperimentali, ma anche la teoria matematica confermano la bontà 

del modello di Papageorgiou. 

L’equazione della velocità 

Una volta che per il passo di discretizzazione k-esimo è nota la distribuzione di ρ 

su tutte le tratte i per conoscere la distribuzione delle velocità allo stesso istante 

si potrebbe semplicemente utilizzare la relazione fondamentale v = V(ρ). L’e- 

105


sperienza convinse però Papageorgiou a non operare semplicemente in questa ma- 

niera. Infatti la relazione fondamentale non tiene conto del tempo che impiega il 

traffico ad adeguare la propria velocità media alla nuova situazione di densità. Si 

potrebbe dire che il traffico agisce con un certo ritardo, e, pertanto, è opportuno 

ipotizzare: 

ove τ è appunto il ritardo di risposta. 

ne: 

v(x, t + τ) = V � ρ(x, t) � 

(2.89) 

Evidentemente passando alla discretizzazione dell’equazione vale la relazio- 

e perciò 

dv(x, t) 

v(x, t + τ) = v(x, t) + τ 

dt 

(2.90) 

˙v = 1� 

� 1� 

� 

v(x, t + τ) − v(x, t) = V(ρ(x, t)) − v(x, t) . (2.91) 

τ 

τ 

La relazione (2.91) è alla base dell’equazione della velocità che Papageorgiou 

inserisce nel suo modello. Alla base poichè oltre a tale termine differenziale, in 

seguito a prove sperimentali, sono aggiunti altri due termini correttivi che cercano 

di rappresentare l’interazione con il comportamento delle due tratte adiacenti. 

vi(k + 1) = vi(k)+ T 

� 

� � 

� 

V(ρi(k))−vi(k) 

vi−1(k)−vi(k) + (2.92) 

τ 

� 

νT 

− 

Significato dell’equazione della velocità 

+ T 

vi(k) 

∆i 

� 

ρi+1(k) − ρi(k) 

� � . 

τ∆i ρi(k) + χ 

L’equazione delle velocità merita particolare attenzione. Sulla tratta generica i- 

esima la velocità al passo temporale (k + 1)-esimo è calcolato come la velocità 

sulla medesima tratta al passo temporale precedente variata da tre fattori incre- 

mentali. Il primo dei tre termini come si è visto proviene dall’equazione discretiz- 

zata della velocità nel continuo; gli altri due termini sono stati ritenuti significativi 

da Papageorgiou a seguito delle prove sperimentali che ha effettuato. 

106


Il primo termine 

� 

� 

T 

V(ρi(k)) − vi(k) 

τ 

dà un’indicazione su quanto può variare la velocità dal suo valore al passo tempo- 

rale precedente k-esimo rispetto ad valore massimo teorico stabilito dall’equazio- 

ne fondamentale di Papageorgiou. 

Se al passo temporale k-esimo la velocità sulla tratta i-esima valeva 

e la densità dei veicoli valeva 

vi(k) 

ρi(k) 

e per V(ρ) si indica la relazione fondamentale di Papageorgiou, allora la velocità 

potrà variare all’istante (k + 1)-esimo di un valore incrementale dato proprio da 

� 

� 

V(ρi(k)) − vi(k) . 

La rapidità con cui la velocità accetta tale variazione dipende dal coefficiente τ 

� 

� 

1 

V(ρi(k)) − vi(k) 

τ 

che rappresenta il ritardo che il traffico impiega per adeguarsi, data una den- 

sità veicolare, al valore di velocità medio dato dalla relazione fondamentale di 

Papageorgiou per quella densità. 

Il secondo termine 

T 

∆i 

� 

� 

vi(k) vi−1(k) − vi(k) 

dà un’indicazione su quanto può variare la velocità sulla tratta i-esima a causa 

del diverso valore di velocità che si verifica sulla tratta precedente. Si presuppone 

infatti che i veicoli entranti in una tratta mantengano la velocità che avevavno 

sulla tratta precedente (ciò è valido chiaramente se la densità rimane costante, e 

infatti ρ non compare nel secondo termine). Con tale termine si traspone tale 

comportamento nel modello. 

107


Se al passo temporale k-esimo le velocità sulle tratte (i − 1)-esima e i-esima 

sono rispettivamente: 

e 

vi−1(k) 

vi(k) 

allora � 

� 

vi−1(k) − vi(k) 

indica di quanto può variare la velocità a causa dell’effetto descritto. La rapidità 

con cui la velocità accetta la variazione dipende da quanto celermente i veicoli con 

la velocità relativa al passo temporale precedente lasciano la tratta in questione, e 

quindi 

T 

∆i 

� 

� 

vi(k) vi−1(k) − vi(k) 

dipende dalla lunghezza della tratta e dalla velocità precedente dei veicoli. 

L’ultimo termine 

� 

� 

νT ρi+1(k) − ρi(k) 

− � � 


dà un’informazione su come si evolve la velocità in relazione alla diversa densità 

sulla tratta successiva. Una densità di traffico sulla tratta successiva 

ρi+1(k) 

molto diversa, in termini relativi, rispetto alla densità sulla tratta per cui si sta 

calcolando la velocità � 

� 

ρi+1(k) − ρi(k) 

[ρi(k)] 

provoca rapidamente un effetto all’indietro di variazione della velocità dovuto al 

fenomeno delle back waves già incontrato nella trattazione dei modelli microsco- 

pici. Infatti, come si era visto, in una fila di veicoli il comportamento della vettura 

di testa viene seguito, ritardato nel tempo e amplificato nell’ampiezza, dalle vet- 

ture che seguono. 

108


La rapidità con cui la velocità varia a causa di tale fenomeno dipende dalla lun- 

ghezza della tratta, dalla costante di ritardo del traffico τ, dalla costante ν che dà 

una misura della velocità di propagazione all’indietro dell’onda, e dalla costante 

χ che attenua la misura della differenza relativa fra i valori delle densità delle due 

tratte contigue 

L’equazione del flusso 

� 

� 

ν ρi+1(k) − ρi(k) 

− � � . 


L’equazione del flusso permette di calcolare il flusso veicolare; essendo noti per 

la tratta i-esima al passo temporale k-esimo il valore della densità dei veicoli 

ρi(k) 

ed il valore della velocità media dei veicoli 

vi(k) 

entrambi calcolati utilizzando le due precedenti equazioni, il flusso relativo alla 

medesima tratta sarà: 

2.6.5 Inizializzazione del modello 

qi(k) = vi(k) · ρi(k). (2.93) 

L’inizializzazione del modello è sicuramente una delle fasi fondamentali per il 

funzionamento della simulazione. Infatti da un diverso tipo di inizializzazione 

dipende fortemente il tipo di risposta che otterremo dal modello. 

Ipotizziamo infatti di trascurare completamente l’inizializzazione delle varia- 

bili di stato di densità dei veicoli, velocità media e flusso veicolare. Questo signifi- 

ca che la simulazione parte con valori casuali, oppure nulli, oppure, per non ritro- 

varsi in una situazione iniziale troppo peculiare, con i valori relativi a condizioni 

di traffico regolare. 

109


Ovviamente i valori immediatamente successivi all’istante di partenza della 

simulazione daranno risultati non congruenti con la realtà. Però, lasciando conti- 

nuare la simulazione per un tempo (simulato, ovviamente) sufficientemente lungo, 

le variabili di ingresso e i parametri inerenti all’autostrada, se sono stati stimati 

con buona accuratezza, porteranno l’andamento della simulazione verso risultati 

coerenti col reale comportamento del traffico. 

Da questo si evince che se il modello viene utilizzato per uno scopo prettamen- 

te simulativo, l’inizializzazione delle variabili di stato riveste un ruolo altamente 

marginale e addirittura è un passaggio che può essere sacrificato. 

Naturalmente è altrettanto vero l’opposto: se il modello viene utilizzato come stru- 

mento previsionale on-line e real-time, la corretta inizializzazione delle variabili 

di stato acquista un’importanza addirittura drastica. è evidente che se l’intenzione 

è di avere una previsione per gli N passi di discretizzazione temporale successivi, 

con N abbastanza piccolo, la bontà della stima dipende quasi esclusivamente dalla 

bontà dell’inizializzazione delle variabili di stato. 

Il problema in tal caso diventa, oltre che sistemistico, anche sensoristico; spesso 

infatti è difficile poter avere buone misurazioni in tempo reale della velocità, del 

flusso veicolare e soprattutto della densità delle vetture. 

In tal caso addirittura diventa necessario trovare un modo per stimare in maniera 

adeguata anche le variabili di ingresso del sistema. Infatti se l’intento del modello 

è quello previsionale, l’ingresso del sistema sarà costituito dai flussi veicolari in 

ingresso e in uscita dalle stazioni, relativi ai passi di discretizzazione temporale 

successivi, che in quanto futuri sono ignoti. Per ottenere buoni risultati dalla si- 

mulazione previsionale occorre che l’inizializzazione delle variabili di ingresso 

all’inizio della simulazione sia il più precisa possibile, e che la stima dei valori 

futuri sia accurata e coerente con il successivo verificarsi nella realtà. 

2.6.6 Pregi e difetti del modello 

I principali vantaggi del modello sono i seguenti: 

• Capacità di modellare sistemi assai vasti. Come si è visto i sistemi macro- 

scopici come quello di Papageorgiou sono i più indicati per affrontare situa- 

110


zioni complesse o molto vaste sia per lunghezza della strada, sia per numero 

di veicoli in gioco. In una situazione autostradale un modello microsco- 

pico si troverebbe nell’assoluta difficoltà di gestire l’eccessivo numero di 

variabili di cui necessita. 

• Bontà dei risultati una volta ben tarati i parametri. Applicazioni speri- 

mentali (molte di queste condotte dallo stesso padre del modello Papa- 

georgiou) dimostrano che, una volta che tutti i parametri che descrivono 

la tratta autostradale sono stimati in maniera da rendere perfettamente il 

comnportamento reale, i risultati delle simulazioni sono sorprendentemente 

validi. 

• Maneggevolezza dal punto di vista informatico. Come si può facilmente 

notare le equazioni di Papageorgiou sono molto semplici da implementare 

in maniera ricorsiva tramite un qualsiasi linguaggio di programmazione. 

I dati in uscita dal modello sono altrettanto maneggevoli, in quanto sono 

in effetti facilmente rappresentabili in forma matriciale. Il che permette 

una grande semplicità di aggregazione secondo la necessità di chi vuole 

usufruire dei dati in uscita. 

• Adattabilità perfetta ai tipi di autostrada compatibili. Le equazioni di Pa- 

pageorgiou sono facilmente applicabili a qualsiasi tipo di autostrada che 

rappresenti un sistema chiuso (ovvero ove si possono avere informazione 

su tutti gli elementi che entrano ed escono dal sistema). Per applicare le 

equazioni ad un nuovo tratto sarà sufficiente modificare il sistema di ac- 

quisizione dei dati iniziali, delle variabili di ingresso e i parametri relativi 

alle tratte autostradali; le equazioni di Papageorgiou restano perfettamente 

immutate. 

I pricipali svantaggi del modello sono i seguenti: 

• Difficoltà di settaggio dei parametri fisici e di simulazione. Per poter settare 

tutti i paraetri relativi alle varie tratte occorre effettuare, come già illustrato, 

111


una serie di misurazioni di prova. Pertanto è necessario consultare un ar- 

chivio di dati storici oppure, se non si è in possesso di dati storici, sfruttare 

una sensoristica distribuita capillarmente che permetta di effettuare le mi- 

surazioni che occorrono. 

Quando capita che manchino entrambe le soluzioni occorre stimare i para- 

metri secondo il buon senso per poi affinarli effettuando continue simula- 

zioni e valutandone la bontà. 

• Necessità di dati per il settaggio iniziale e difficile reperibilità dei suddet- 

ti. Come spiegato precedentemente, se il modello viene utilizzato in ottica 

previsionale, e non simulativa, il problema di una corretta inizializzazione 

diventa di fondamentale importanza. Purtroppo non sempre è facile effet- 

tuare rilevamenti e misurazioni del fenomeno reale per inizializzare le va- 

riabili di stato. Specialmente in ambito autostradale la sensoristica spesso 

difetta in quantità e qualità e il rischio di inficiare in maniera determinante 

la previsione con dati iniziali poco accurati diventa tangibile. 

• Impossibilità di prevedere nel futuro le variabili di ingresso. Un grosso 

limite del modello di Papageorgiou quando viene utilizzato in ottica previ- 

sionale è l’impossibilità di avere i valori esatti per le variabili di ingresso. 

Infatti, ad eccezione dell’istante 0 in cui parte la simulazione ed è possibile 

acquisire i dati tramite misurazione sensoristica, i valori futuri dei flussi in 

ingresso e in uscita relativi alle stazioni non sono noti nè fissi. Chiaramente 

nell’arco della giornata i flussi veicolari ai caselli seguono un comportamen- 

to abbastanza standard, che può essere stimato in maniera anche abbastanza 

precisa, se si è in possesso dei dati storici relativi agli ingressi e alle uscite. 

Ad ogni modo la previsione di questi valori, per accurata che sia, raramente 

centrerà perfettamente il valore reale, e di sicuro non potrà prevedere situa- 

zioni occasionali (che sovente si manifestano). 

L’unico modo sensato di dare una soluzione accettabile a questo problema è 

quello di integrare le informazioni sul comportamento standard delle varia- 

bili di ingresso con il dato reale misurato all’istante iniziale di simulazione 

112


e ottenere da questi due elementi la stima più corretta possibile dei valori 

futuri. 

• Necessità di compatibilità con la tipologia di autostrada. Nella trattazione 

[31] 

analitica del problema si era parlato di equazione di conservazione della 

materia, che è l’equazione che regola il sistema, mettendo in relazione i 

flussi e le densità. Tale equazione presuppone che la tratta autostradale in 

esame sia un sistema chiuso, ovvero che si possa avere l’informazione det- 

tagliata su tutti gli elementi che varcano il confine del sistema, entrandone o 

uscendone. Nelle strade extraurbane dove non sia possibile misurare i flussi 

di ingresso o uscita relativi alle stazioni, oppure ove il flusso entrante nella 

prima tratta o quello uscente dall’ultima non sono nè noti nè misurabili è im- 

possibile applicare il modello di Papageorgiou, in quanto alcuni dei termini 

delle equazioni sono mancanti, e se i loro valori non sono trascurabili chia- 

ramente la previsione delle variabili di stato risulta ampiamente distorta. Per 

nostra fortuna le autostrade, essendo munite dei sistemi di pagamento del 

pedaggio agli ingressi e alle uscite, raramente sono caratterizzate da questo 

tipo di problemi. 

113


114

Capitolo 3 

Strumenti Informatici Utilizzati 

Figura 3.1: Boston Traffic [57] 

115

3.1. JAVA Carlo Caligaris, Iacopo Salvarani 

3.1 Java 

3.1.1 Introduzione al Linguaggio di Programmazione Java 

Quasi tutto il software da noi prodotto è stato scritto in Java. Java è un linguaggio 

di programmazione molto potente ed è diventato lo standard di riferimento per 

l’implementazione di applicazioni basate su Internet e per lo sviluppo di software 

per dispositivi che comunicano attraverso una rete. Gran parte della nuova tec- 

nologia si basa su questo linguaggio: in particolare dispositivi wireless come i 

telefoni cellulari comunicano tramite la cosiddetta wireless Internet usando appli- 

cazioni di rete basate su Java. Java è di fatto entrato prepotentemente nel terreno 

delle applicazioni di larga scala; non è più un linguaggio utilizzato per rendere 

vive le pagine web, ma è diventato il linguaggio preferito di riferimento di molte 

aziende ed organizzazioni. [10] 

Figura 3.2: Gli Aspetti di Java [49] 

3.1.2 Linguaggi Macchina, Assembly e di Alto Livello 

I programmatori possono scrivere le istruzioni in vari linguaggi di programma- 

zione. Alcuni linguaggi vengono compresi direttamente dai computer, mentre 

altri richiedono dei passaggi intermedi di traduzione. Allo stato attuale vengono 

116

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale CAPITOLO 3. STRUMENTI INFORMATICI UTILIZZATI 

utilizzati centinaia di linguaggi di programmazione diversi, che possono essere 

raggruppati in tre grandi categorie: 

1. linguaggi macchina; 

2. linguaggi assembly; 

3. linguaggi di alto livello. 

Un computer è in grado di capire direttamente soltanto il proprio linguaggio mac- 

china, che deve essere considerato come il suo linguaggio naturale, in quanto è 

definito dalla progettazione dell’hardware. In genere i linguaggi macchina con- 

sistono di stringhe di numeri (che si riducono infine a sequenze di 0 ed 1) che 

ordinano al computer di eseguire operazioni elementari, una alla volta. I linguag- 

gi macchina dipendono dall’architettura del computer per cui sono stati definiti e 

sono assolutamente oscuri agli occhi di un essere umano. Con l’aumentare della 

popolarità dei computer ci si rese conto che continuare a programmare in linguag- 

gio macchina era un’operazione decisamente noiosa e lenta. Anziché scrivere 

stringhe di numeri che i computer potevano capire direttamente, i programma- 

tori cominciarono a far uso di abbreviazioni che rappresentavano le operazioni 

elementari dei computer. Tali abbreviazioni costituirono la base dei linguaggi 

assembly. Parallelamente furono sviluppati dei programmi di traduzione, detti as- 

sembler, che convertono i programmi scritti in linguaggio assembly in linguaggio 

macchina. L’utilizzo dei computer aumentò sensibilmente con l’introduzione dei 

linguaggi assembly, ma in definitiva essi richiedevano ugualmente un gran numero 

di istruzioni per eseguire anche il compito più banale. Per velocizzare la program- 

mazione furono allora inventati i linguaggi di alto livello, nei quali una singola 

istruzione poteva eseguire compiti anche complessi. Programmi di traduzione 

detti compilatori convertono poi i programmi scritti nel linguaggio di alto livello 

in linguaggio macchina. I linguaggi di alto livello consentivano ai programmatori 

di scrivere delle istruzioni che suonavano all’incirca come una normale frase in 

lingua inglese e che contenevano alcuni simboli matematici. I linguaggi C, C++, 

Java e quelli della piattaforma Microsoft .NET sono tra i linguaggi ad alto livello 

più potenti ed utilizzati al giorno d’oggi. 

117


La compilazione di un programma ad alto livello in linguaggio macchina può 

comunque richiedere un considerevole tempo di elaborazione. Perciò furono an- 

che inventati i cosiddetti interpreti, in grado di eseguire direttamente i programmi 

scritti in linguaggio ad alto livello senza doverli prima convertire in linguaggio 

macchina. Anche se i programmi compilati sono molto più veloci di quelli in- 

terpretati, gli intrepreti sono spesso utilizzati negli ambienti di sviluppo in cui è 

necessario apportare continue modifiche ai programmi, così da non doverli compi- 

lare frequentemente. Una volta raggiunta la versione definitiva di un programma, 

però, è possibile compilarlo per avere un’efficienza migliore. 

A questo punto è chiaro che esistono fondamentalmente due modalità diverse 

di tradurre un programma scritto con un linguaggio di alto livello in una forma 

che sia direttamente comprensibile da un computer: la compilazione e l’inter- 

pretazione. Java utilizza un’approccio ibrido combinando queste due modalità. 

[10] 

3.1.3 La Storia dei Linguaggi C e C++ 

Il linguaggio Java è una evoluzione del linguaggio C++ che costituisce l’evoluzio- 

ne naturale del linguaggio C, il quale a sua volta discende da altri due linguaggi, 

BCPL e B. Il linguaggio BCPL fu sviluppato nel 1967 da Martin Richards per 

scrivere sistemi operativi e compilatori. Ken Thompson modellò poi molte delle 

caratteristiche del suo linguaggio B sulla base del BCPL ed utilizzò il B per creare 

le prime versioni del sistema operativo UNIX presso i Bell Laboratories nel 1970. 

Il linguaggio C si sviluppò dal B grazie a Dennis Ritchie presso i Bell Labo- 

ratories, e fu implementato originariamente nel 1972. Il C fu noto inizialmente 

come linguaggio di sviluppo del sistema operativo UNIX. Oggi la maggior par- 

te dei sistemi operativi che possiamo trovare nei computer portatili, nei normali 

computer da tavolo, nelle workstation e persino nei piccoli server sono scritti in C 

o C++. 

Il linguaggio C++, estensione del C, è stato sviluppato da Bjarne Stroustrup 

118


agli inizi degli anni ’80 presso i Bell Laboratories. Il linguaggio C++ offre una 

serie di funzionalità che potenziano il C e, cosa più importante, lo rendono adatto 

per la programmazione orientata agli oggetti. Il C++ è un linguaggio ibrido poi- 

ché è possibile scrivere programmi nel vecchio stile procedurale del C, nello stile 

orientato agli oggetti, o in entrambi. Gli oggetti o, più precisamente, le classi di 

oggetti, sono essenzialmente componenti software riutilizzabili. Possiamo creare 

oggetti che rappresentano varie tipologie di dati. Ogni nome può essere utilizzato 

per rappresentare un oggetto software in termini di proprietà e comportamento. 

Gli sviluppatori di software si stanno rendendo conto che usare un approccio mo- 

dulare ed orientato agli oggetti nella programmazione e nell’implementazione può 

rendere i team di programmazione molto più produttivi rispetto alle tecniche del 

passato, come la programmazione strutturata. I programmi orientati agli ogget- 

ti, infatti, sono spesso più semplici da capire, da correggere e da modificare. In 

questo scenario, Java è ormai divenuto il linguaggio di programmazione orientato 

agli oggetti più utilizzato. [10] 

3.1.4 La Storia di Java 

Il contributo più importante della rivoluzione dei microprocessori è stato forse lo 

sviluppo dei personal computer, che hanno avuto un profondo impatto sulla vita 

delle persone ed ancora di più sulle organizzazioni e sulle aziende. Sono in mol- 

ti a credere che il prossimo settore in cui i microprocessori avranno un impatto 

di questo tipo sia quello dei dispositivi elettronici intelligenti di uso comune. In 

vista di questa nuova rivoluzione, Sun Microsystems ha finanziato, nel 1991, un 

progetto di ricerca interno, chiamato Green. Questo progetto ha dato vita ad un 

linguaggio basato su C e C++, inizialmente chiamato Oak dal suo creatore, Ja- 

mes Gosling. Il nome è stato poi modificato in Java (nome di una marca di caffé) 

quando si è scoperto che già esisteva un linguaggio chiamato Oak. Il progetto 

Green ha incontrato delle difficoltà, in quanto il mercato dei dispositivi elettronici 

di consumo non si è sviluppato tanto rapidamente quanto Sun credeva. Fortunata- 

mente, nel 1993 è esploso il World Wide Web e Sun ha intravisto immediatamente 

il potenziale di Java per creare pagine web con contenuti dinamici ed animazioni. 

119


Sun ha presentato ufficialmente Java in una conferenza tenutasi nel Maggio del 

1995, sollevando un clamoroso interesse. Java viene attualmente utilizzato per 

sviluppare applicazioni industriali su larga scala, per estendere le funzionalità dei 

server web, per realizzare applicazioni destinate ai dispositivi di consumo e per 

molti altri scopi. [10] 

3.1.5 Le Librerie di Classi Java 

I programmi di Java si compongono di parti dette classi, che a loro volta contengo- 

no metodi, i quali eseguono vari compiti e, alla fine, ritornano delle informazioni. 

Sebbene sia possibile creare ogni parte di un programma Java, normalmente un 

programmatore cerca di riutilizzare l’enorme quantità di classi già esistenti, rac- 

chiuse nelle librerie di classi Java. Le librerie di classi sono conosciute anche 

come Java API (Application Programming Interface). Per conoscere il mondo 

di Java, quindi, è necessario studiare due cose: il linguaggio vero e proprio, per 

realizzare le proprie classi, e le librerie di classi già esistenti. [10] 

Nel corso del nostro lavoro abbiamo utilizzato un gran numero di classi prede- 

finite, ma abbiamo anche costruito alcune classi personalmente, al fine di raggrup- 

pare comandi ripetitivi in funzioni o al fine di avere dei metodi che ci consentissero 

di trattare i tipi di dati di nostro interesse. 

3.1.6 Gli Elementi Fondamentali di un Tipico Ambiente Java 

Un programma attraversa generalmente cinque fasi per essere eseguito: 

1. scrittura e modifica; 

2. compilazione; 

3. caricamento; 

4. verifica; 

5. esecuzione. 

120


Scrittura e Modifica di un Programma 

Per scrivere e modificare i files che costituiscono il nostro programma Java, si 

utilizza generalmente un editor. I nomi dei file dei programmi Java terminano 

generalmente con l’estensione .java. Le aziende che sviluppano grossi sistemi in- 

formativi utilizzano solitamente ambienti di sviluppo Java integrati (IDE), forniti 

da vari distributori di software. Gli IDE mettono a disposizione del programma- 

tore diversi strumenti per lo sviluppo di programmi e per la loro messa punto, 

facilitando l’individuazione degli errori. I nostri supervisori aziendali ci hanno 

consigliato Eclipse, un IDE dall’interfaccia e dalle funzioni molto simili a quelle 

di Microsoft Visual Studio. 

Compilazione di un Programma Java in Bytecode 

Il compilatore Java converte il codice in bytecode, ossia le istruzioni comprese dal- 

l’interprete Java. Il compilatore Java può essere lanciato tramite linea di comando 

(in ambiente Microsoft, ad esempio, si utilizza il prompt MS-DOS) con l’istruzio- 

ne javac oppure, se l’IDE supporta questa possibilità, impostando il percorso 

del compilatore tra le opzioni dell’IDE stesso e lanciando la compilazione con un 

comando interno all’ambiente di sviluppo. Se il programma è stato compilato cor- 

rettamente, viene prodotto un file con estensione .class contenente i bytecode 

che verranno interpretati durante la fase di esecuzione. 

Il compilatore Java traduce il codice sorgente in un bytecode che rappresenta 

le operazioni che verranno eseguite in fase di esecuzione. I bytecode vengono 

eseguiti dalla Java Virtual Machine (JVM), cioè una parte del JDK ed una com- 

ponente fondamentale della piattaforma Java. Una macchina virtuale (VM) è una 

applicazione software che simula un computer, nascondendo ai programmi che 

con essa interagiscono sia il sistema operativo, sia l’hardware sottostanti. Se la 

stessa macchina virtuale è disponibile per diverse piattaforme, le stesse appli- 

cazioni eseguite dalla VM possono automaticamente essere utilizzate in ognuna 

di tali piattaforme. La macchina virtuale Java è una delle macchine virtuali più 

diffuse. 

121


A differenza del linguaggio macchina, che è specifico per ciascun diverso tipo 

di hardware, il bytecode è costruito da istruzioni che sono indipendenti dalla piat- 

taforma, ossia non sono specifiche per una particolare piattaforma hardware. In 

questo modo il bytecode Java risulta essere portabile: lo stesso bytecode può es- 

sere eseguito in una qualunque piattaforma contenente una JVM compatibile con 

la versione di Java nella quale il bytecode è stato originariamente compilato. La 

JVM è richiamabile da linea di comando con l’istruzione java. La JVM avvia 

tutti i passi necessari per eseguire l’applicazione. 

Caricamento di un Programma in Memoria 

Prima che un programma possa essere eseguito, deve essere posto in memoria. 

Il programma class loader trasferisce nella memoria primaria i files .class. 

Il class loader può anche caricare eventuali files messi a disposizione da Java 

e richiamati dal nostro programma. La sorgente di questi files può essere una 

sorgente hardware interna al sistema o una rete. 

Verifica del Bytecode 

Quando le classi vengono caricate, i loro bytecode vengono esaminati dal verifi- 

catore di bytecode. In questo modo si garantisce che i bytecode delle classi siano 

validi e rispettino le norme di sicurezza Java. Java prevede infatti norme molto se- 

vere nell’ambito della sicurezza, affinché i programmi Java provenienti dalla rete 

non possano danneggiare il sistema ospite. 

Esecuzione 

Finalmente, l’interprete, sotto il controllo del sistema operativo, interpreta il pro- 

gramma, un bytecode per volta, eseguendo tutte le azioni previste dal programma 

stesso. Nelle prime versioni di Java, la JVM era un semplice interprete di byte- 

code. Questa caratteristica rendeva i programmi in esecuzione molto lenti poiché 

la JVM interpretava ed eseguiva un bytecode alla volta. Le JVM attuali, invece, 

eseguono i bytecode sfruttando una combinazione di due tecniche: l’interpreta- 

122


zione e la cosiddetta compilazione just-in-time. Durante questo processo la JVM 

analizza i bytecode non appena essi vengono interpretati, cercando di localizza- 

re quelle parti di bytecode eseguite più spesso, dette hot spot. Una volta isolate 

queste parti, esse vengono passate al compilatore just-in-time, il quale le traduce 

nel linguaggio macchina specifico per la piattaforma corrente. Quando la JVM 

ritrova le stesse parti una seconda volta durante l’esecuzione del programma, ciò 

che viene effettivamente eseguito è il più veloce linguaggio macchina. In questo 

modo i programmi Java passano per due fasi di compilazione distinte: la prima 

in cui il codice sorgente viene tradotto in bytecode (favorendo la portabilità verso 

JVM presenti in diverse piattaforme) e la seconda nella quale, durante l’esecuzio- 

ne, i bytecode vengono tradotti in linguaggio macchina specifico per il computer 

sul quale il programma è in esecuzione. [10] 

3.1.7 Concetti Fondamentali della Tecnologia ad Oggetti 

Concludiamo questa panoramica sul linguaggio di programmazione più utilizzato 

per il nostro lavoro introducendo la metodologia orientata agli oggetti. 

Ovunque si guardi nel mondo reale, si vedono oggetti: persone, animali, piante 

e così via. Le persone, inoltre, pensano in termini di oggetti. I programmi per 

computer, e quindi i programmi Java, possono essere visti come oggetti costituiti 

da tanti altri oggetti software interconnessi. La progettazione orientata agli oggetti 

modella il software in termini simili a quelli utilizzati dalle persone per descrivere 

gli oggetti del mondo reale. Essa sfrutta le relazioni di classe, in cui gli oggetti di 

una certa classe hanno le stesse caratteristiche, e le relazioni di ereditarietà con 

cui è possibile derivare nuove classi assorbendo le caratteristiche di classi esistenti 

ed aggiungendone di nuove. 

La progettazione orientata agli oggetti è un modo naturale ed intuitivo di vede- 

re il processo di progettazione. Modellando i componenti software proprio come 

descriviamo gli oggetti del mondo reale: usando i loro attributi ed il loro compor- 

tamento. La progettazione orientata agli oggetti modella anche la comunicazione 

tra oggetti che avviene tramite messaggi. Questo tipo di progettazione incapsula 

123


gli attributi e le funzionalità (il comportamento) negli oggetti: gli attributi e le 

funzionalità di un oggetto sono strettamente legati tra loro. Gli oggetti hanno la 

proprietà di nascondere le informazioni, Questo significa che, sebbene gli oggetti 

sappiano come comunicare tra loro attraverso ben definite interfacce, non posso- 

no sapere come altri oggetti sono implementati; i dettagli dell’implementazione 

sono nascosti all’interno degli oggetti stessi. Del resto, è possibile guidare una 

macchina senza conoscere i dettagli del funzionamento interno del motore, della 

trasmissione o del cambio. 

Java è un linguaggio orientato agli oggetti; i linguaggi come il C, invece, sono 

procedurali e la loro programmazione tende ad essere orientata all’azione. In C, 

l’unità di programmazione è la funzione. Gruppi di azioni che svolgono qualche 

compito comune vengono trasformati in funzioni e le funzioni sono raggruppate a 

loro volta per formare programmi. In Java l’unità di programmazione è la classe 

da cui gli oggetti vengono istanziati. Le classi Java contengono metodi, che im- 

plementano funzionalità, e campi, che implementano attributi. I programmatori 

Java si concentrano sulla creazione di classi. Ogni classe contiene dei campi e 

l’insieme dei metodi che manipolano questi campi per fornire determinati servizi 

ai clienti. I programmatori usano le classi esistenti come mattoni per costruire 

nuove classi. Da una stessa classe è possibile istanziare molti oggetti. Le rela- 

zioni tra classi vengono chiamate associazioni. Quando il software viene scritto 

come aggregato di classi, queste possono essere riusate in sistemi software futuri. 

Riusare classi esistenti nella costruzione di nuove classi e programmi fa rispar- 

miare tempo e sforzi. Il riuso aiuta anche i programmatori a costruire sistemi più 

affidabili dal momento che le classi ed i componenti esistenti sono stati a lungo 

verificati e corretti. Con la tecnologia degli oggetti, possiamo costruire la maggior 

parte del software che ci serve combinando delle classi. [10] 

124


3.2 Le Basi di Dati ed i Sistemi di Gestione di Basi 

di Dati 

Gran parte della nostra attività ha richiesto una costante interazione con una enor- 

me base di dati dalla quale abbiamo cercato di ricavare le informazioni a noi più 

utili. La raccolta e lo storage dei dati rappresenta un enorme campo di applica- 

zione dei sistemi informatici quindi, prima di descrivere nel dettaglio come abbia- 

mo operato per relazionarci con la banca dati, vogliamo introdurre i fondamenti 

di questo argomento, proprio come abbiamo fatto e faremo con tutte le aree di 

interesse scientifico che abbiamo toccato. 

3.2.1 Introduzione alle Basi di Dati 

Le attività di raccolta, organizzazione, conservazione dei dati costituiscono uno 

dei principali compiti dei sistemi informatici; essi garantiscono che questi dati 

vengano conservati in modo permanente su dispositivi per la loro memorizzazio- 

ne, aggiornati per riflettere rapidamente le loro variazioni e resi accessibili alle 

interrogazioni degli utenti, talvolta distribuiti in modo capillare sul territorio 

Nello svolgimento di ogni attività, sia a livello individuale sia in organizzazio- 

ni di ogni dimensione, sono essenziali la disponibilità di informazioni e la capacità 

di gestirle in modo efficace; ogni organizzazione è dotata di un sistema informa- 

tivo, che organizza e gestisce le informazioni necessarie per perseguire gli scopi 

dell’organizzazione stessa. L’esistenza del sistema informativo è in parte indipen- 

dente dalla sua automatizzazione. A sostegno di questa affermazione possiamo 

ricordare che i sistemi informativi esistono da molto prima dell’invenzione e del- 

la diffusione dei calcolatori elettronici. Per indicare la porzione automatizzata 

del sistema informativo viene di solito utilizzato il termine sistema informatico. 

La diffusione capillare dell’informatica in quasi tutte le attività umane ha fatto 

sì che gran parte dei sistemi informativi fossero anche, in buona misura, sistemi 

informatici. 

Nei sistemi informatici si porta all’estremo il concetto di rappresentazione 

125

3.2. LE BASI DI DATI ED I SISTEMI DI GESTIONE DI BASI DI DATI Carlo Caligaris, Iacopo Salvarani 

e codifica: le informazioni vengono rappresentate per mezzo di dati che hanno 

bisogno di essere interpretati. A livello concettuale possiamo dire che i dati da soli 

non hanno alcun significato ma, una volta interpretati e correlati opportunamente, 

essi forniscono informazioni che consentono di arricchire la nostra conoscenza 

del mondo. Una base di dati è una collezione di dati, utilizzati per rappresentare 

le informazioni di interesse per un sistema informativo. 

L’attenzione ai dati ha caratterizzato le applicazioni dell’informatica fin dalle 

sue origini, ma sistemi software specificamente dedicati alla gestione dei dati sono 

stati realizzati solo a partire dalla fine degli anni Sessanta. Un sistema di gestione 

di basi di dati (DBMS) è un sistema software in grado di gestire collezioni di 

dati che siano grandi, condivise e persistenti, assicurando la loro affidabilità e 

riservatezza. Come ogni prodotto informatico, un DBMS deve essere efficiente ed 

efficace. Una base di dati è una collezione di dati gestita da un DBMS. Precisiamo 

le caratteristiche dei DBMS su cui si basano le definizioni precedenti. 

• Le basi di dati possono essere grandi, talvolta sono enormi (come quella 

con cui abbiamo lavorato) e comunque in generale hanno dimensioni mol- 

to maggiori della memoria centrale disponibile. Di conseguenza, i DBMS 

debbono prevedere una gestione dei dati in memoria secondaria. È impor- 

tante che i sistemi possano gestire i dati senza porre limiti alle dimensioni, 

oltre a quelli fisici imposti dai dispositivi usati. 

• Le basi di dati sono condivise, nel senso che applicazioni ed utenti diversi 

debbono poter accedere, secondo opportune modalità, a dati comuni. É im- 

portante notare che in questo modo si riduce la ridondanza dei dati, poiché 

si evitano ripetizioni, e conseguentemente si riduce anche la possibilità di 

inconsistenze: se esistono varie copie degli stessi dati è possibile che esse, 

in qualche momento, non siano uguali. Per garantire l’accesso condiviso 

ai dati da parte di molti utenti che operano contemporaneamente, il DBMS 

dispone di un meccanismo apposito detto controllo di concorrenza. 

• Le basi di dati sono persistenti, cioè hanno un tempo di vita che non è li- 

mitato a quello delle singole esecuzioni dei programmi che le utilizzano. In 

126


contrasto, ricordiamo che i dati gestiti da un programma in memoria centra- 

le hanno una vita che inizia e termina con l’esecuzione del programma; tali 

dati, quindi, non sono persistenti. 

• I DBMS garantiscono l’affidabilità, cioè la capacità del sistema di conser- 

vare sostanzialmente intatto il contenuto della base di dati (o almeno di per- 

metterne la ricostruzione) in caso di malfunzionamenti hardware e software. 

A questo scopo i DBMS forniscono specifiche funzionalità di salvataggio e 

ripristino (backup e recovery). 

• I DBMS garantiscono la riservatezza dei dati. Ciascun utente, riconosciuto 

in base ad un nome di utente che è specificato all’atto di interagire con il 

DBMS, viene abilitato a svolgere solo determinate azioni sui dati, attraverso 

meccanismi di autorizzazione. 

• Per efficienza si intende la capacità di svolgere le operazioni utilizzando un 

insieme di risorse (tempo e spazio) che sia accettabile per gli utenti. Que- 

sta caratteristica dipende dalle tecniche utilizzate nell’implementazione del 

DBMS e dalla bontà della realizzazione della base di dati da parte dei suoi 

progettisti. Va sottolineato che i DBMS forniscono un insieme piuttosto 

ampio di funzionalità che richiedono molte risorse, e quindi possono garan- 

tire efficienza solo a condizione che il sistema informatico su cui installati 

sia adeguatamente dimensionato. 

• Per efficacia intendiamo la capacità della base di dati di rendere produt- 

tive, in ogni senso, le attività dei suoi utenti. Questa definizione è chia- 

ramente generica e non corrisponde ad un aspetto specifico, dato che un 

DBMS fornisce vari servizi e funzionalità ad utenti differenti. L’attività di 

progettazione della base di dati e delle applicazioni che la utilizzano mira 

essenzialmente a garantire una buona efficacia complessiva del sistema. 

I DBMS sono stati concepiti e realizzati per estendere le funzioni dei file system, 

fornendo la possibilità di accesso condiviso agli stessi dati da parte di più utenti ed 

applicazioni e garantendo anche molti altri servizi in maniera integrata. I DBMS 

127


utilizzano a loro volta files per la memorizzazione ma i files così gestiti ammettono 

organizzazioni dei dati più sofisticate. [3] 

3.2.2 Modelli dei Dati: il Modello Relazionale 

Un modello dei dati è un insieme di concetti utilizzati per organizzare i dati di 

interesse e descriverne la struttura in modo che essa risulti comprensibile ad un 

elaboratore. Ogni modello dei dati fornisce meccanismi di strutturazione, ana- 

loghi ai costruttori di tipo dei linguaggi di programmazione, che permettono di 

definire nuovi tipi sulla base di tipi elementari predefiniti e di costruttori di tipo. 

Il modello relazionale dei dati, attualmente il più diffuso, permette di definire 

tipi per mezzo del costruttore relazione, che consente di organizzare i dati in insie- 

mi di record a struttura fissa. Una relazione viene spesso rappresentata per mezzo 

di una tabella, le cui righe descrivono specifici record e le cui colonne corrispon- 

dono ai campi del record; l’ordine delle righe e delle colonne è sostanzialmente 

irrilevante. Il modello relazionale, definito formalmente agli inizi degli anni Set- 

tanta, si è affermato negli anni Ottanta con una certa lentezza, dovuta all’elevato 

livello di astrazione: non è stato immediato individuare relazioni efficienti per 

strutture significativamente da quelle utilizzate allora. 

Il modello relazionale quindi si basa sui concetti: relazione e tabella, che so- 

no di natura diversa ma facilmente riconducibili l’uno all’altro. La nozione di 

relazione proviene dalla matematica e, in particolare, dalla teoria degli insiemi, 

mentre il concetto di tabella è semplice ed intuitivo. La presenza contemporanea 

di un concetto prevalentemente formale e di uno intuitivo è responsabile del gran- 

de successo del modello: infatti, le tabelle risultano naturali e comprensibili anche 

per gli utenti finali (che le usano nei più svariati contesti per diversi scopi, senza 

un riferimento diretto alle basi di dati sottostanti). D’altra parte, la presenza di 

una formalizzazione semplice e precisa ha permesso anche uno sviluppo teorico a 

supporto del modello con risultati di interesse concreto. 

Il modello relazionale risponde al requisito dell’indipendenza dei dati, che pre- 

vede una distinzione, nella descrizione dei dati, tra livello fisico e livello logico; 

128


gli utenti che accedono ai dati ed i programmatori che sviluppano le applicazio- 

ni fanno riferimento solo al livello logico; i dati descritti al livello logico sono 

poi realizzati per mezzo di opportune strutture fisiche, ma per accedere ai dati 

non è necessario conoscere le strutture fisiche stesse. Infatti, i modelli proposti 

precedentemente al modello relazionale, includevano espliciti riferimenti alla sot- 

tostante struttura realizzativa, attraverso l’uso di puntatori e l’ordinamento fisico 

dei dati. 

Il termine relazione viene utilizzato in questa trattazione in tre accezioni che 

differiscono nella sostanza: 

[3] 

1. relazione matematica secondo la definizione normalmente data nella teoria 

degli insiemi elementare; 

2. relazione secondo la definizione del modello relazionale, che presenta alcu- 

ne differenze rispetto a quella della teoria degli insiemi; 

3. relazione come traduzione dell’inglese relationship, costrutto del modello 

concettuale Entità-Relazione utilizzato per descrivere legami tra entità del 

mondo reale. 

3.2.3 Livelli di Astrazione nel DBMS ed Indipendenza dei Dati 

Nelle basi di dati esiste una parte sostanzialmente invariante nel tempo, detta sche- 

ma della base di dati, costituita dalle caratteristiche dei dati, ed una variabile nel 

tempo, detta istanza o stato della base di dati, costituita dai valori effettivi. lo 

schema di una relazione è costituito dalla sua intestazione, cioè dal nome della 

relazione seguito dai nomi dei suoi attributi. L’istanza di una relazione è costi- 

tuita dall’insieme, variante nel tempo, delle sue righe. Si dice anche che lo sche- 

ma è la componente intensionale della base di dati e l’istanza è la componente 

estensionale. 

129


La nozione di modello e di schema può essere ulteriormente sviluppata te- 

nendo presenti altre dimensioni nella descrizione dei dati. Esiste una proposta di 

architettura standardizzata per DBMS articolata su tre livelli, detti rispettivamente 

esterno, logico ed interno; per ciascun livello esiste uno schema. 

• Lo schema logico costituisce una descrizione dell’intera base di dati per 

mezzo del modello logico adottato dal DBMS. 

• Lo schema interno costituisce la rappresentazione dello schema logico per 

mezzo di strutture fisiche di memorizzazione. 

• Lo schema esterno costituisce la descrizione di una porzione della base di 

dati di interesse, per mezzo del modello logico. Uno schema esterno può 

prevedere organizzazioni dei dati diverse rispetto a quelle utilizzate nello 

schema logico, che riflettono il punto di vista di un particolare utente o 

insieme di utenti. Pertanto, è possibile associare ad uno schema logico vari 

schemi esterni. 

Nei sistemi più moderni il livello esterno non è esplicitamente presente, ma è 

possibile definire relazioni derivate (o viste). 

L’architettura a livelli così definita garantisce l’indipendenza dei dati, la prin- 

cipale proprietà dei DBMS. In generale, questa proprietà permette ad utenti e pro- 

grammi applicativi che utilizzano una base di dati di interagire ad un elevato livel- 

lo di astrazione, che prescinde dai dettagli realizzativi utilizzati nella costruzione 

della base di dati. In particolare, l’indipendenza dei dati può essere caratterizzata 

ulteriormente come indipendenza fisica e logica. 

• L’indipendenza fisica consente di interagire con il DBMS in modo indipen- 

dente dalla struttura fisica dei dati. In base a questa proprietà è possibile 

modificare le strutture fisiche (per esempio le modalità di organizzazione 

dei files gestiti dal DBMS o la allocazione fisica dei files sui dispositivi di 

memorizzazione) senza influire sulle descrizioni dei dati ad alto livello e 

quindi sui programmi che utilizzano i dati stessi. 

130


• L’indipendenza logica consente di interagire con il livello esterno della base 

di dati in modo indipendente dal livello logico. Per esempio, è possibile 

aggiungere uno schema esterno in base alle esigenze di un nuovo utente 

oppure modificare uno schema esterno senza dover modificare lo schema 

logico e perciò la sottostante organizzazione fisica dei dati. Dualmente, 

è possibile modificare il livello logico, mantenendo inalterate le strutture 

esterne (modificandone la definizione in termini delle strutture logiche) di 

interesse per l’utente. 

È importante sottolineare che gli accessi alla base di dati avvengono solo attraver- 

so il livello esterno (che può coincidere con quello logico); è il DBMS che traduce 

le operazioni in termini dei livelli sottostanti. L’architettura a livelli è quindi il 

meccanismo fondamentale attraverso cui i DBMS realizzano l’indipendenza dei 

dati. [3] 

3.2.4 Definizioni Fondamentali 

In questo contesto non riteniamo necessario assumere un livello di dettaglio ecces- 

sivamente profondo per quanto riguarda il modello relazionale e le sue interazioni 

con i DBMS; tuttavia, ci sembra coerente con lo scopo di questa trattazione intro- 

durre alcune definizioni fondamentali e chiarire alcuni concetti di base relativi a 

questi argomenti in modo da consentire anche ad un neofita di comprendere per 

sommi capi gli approcci che abbiamo utilizzato. 

Definizione 3.1 Una relazione matematica su due insiemi D1 e D2 (chiamati do- 

mini della relazione) è un sottoinsieme di D1×D2 dove l’operatore × rappresenta 

il prodotto cartesiano di due insiemi, ossia l’insieme di tutte le coppie possibili 

in cui il primo elemento appartiene al primo insieme ed il secondo elemento al 

secondo insieme. 

A livello teorico si assume, ove necessario, che le basi di dati siano costituite 

da relazioni finite su domini eventualmente infiniti. Generalmente le informazioni 

131


che siamo interessati ad organizzare nelle relazioni delle nostre basi di dati hanno 

una struttura che si può naturalmente ricondurre a quella dei record: una relazione 

è sostanzialmente un insieme di record omogenei, cioè definiti sugli stessi cam- 

pi. Nel casi dei record, ad ogni campo è associato un nome, detto attributo, che 

descrive il ruolo giocato dal dominio stesso. Nella rappresentazione tabellare uti- 

lizziamo gli attributi come intestazioni per le colonne. Si noti come l’ordinamento 

degli attributi risulti irrilevante. 

Definizione 3.2 [3] Per formalizzare i concetti, stabiliamo la corrispondenza tra 

attributi e domini per mezzo di una funzione dom : X → D, che associa a ciascun 

attributo A ∈ X un dominio dom(A) ∈ D. Poi, diciamo che una t-upla su un 

insieme di attributi X è una funzione t che associa a ciascun attributo A ∈ X 

un valore del dominio dom(A). Possiamo quindi dare la nuova definizione di 

relazione: una relazione su X è un insieme di t-uple su X. La differenza tra 

questa definizione e quella tradizionale di relazione matematica risiede solo nella 

definizione di t-upla: nella relazione matematica abbiamo n−uple in cui elementi 

sono individuati per posizione, mentre nelle t-uple della nuova definizione gli 

elementi sono individuati per mezzo degli attributi, cioè secondo una notazione 

posizionale. 

3.2.5 Relazioni e Basi di Dati 

La base di dati nella Figura 3.2.5 mostra una delle caratteristiche fondamentali del 

modello relazionale, che viene spesso indicata dicendo che esso è basato sui valo- 

ri: i riferimenti fra dati in relazioni diverse sono rappresentati per mezzo di valori 

dei domini che compaiono nelle t-uple. Va notato che gli altri modelli realizzano 

le corrispondenze in modo esplicito attraverso puntatori e vengono pertanto detti 

modelli basati su record e puntatori. 

132


Figura 3.3: Una base di dati relazionale 

La Figura 3.2.5 rappresenta la stessa base di dati della Figura 3.2.5 con punta- 

tori al posto dei riferimenti realizzati tramite valori. 

Figura 3.4: Una base di dati non relazionale con puntatori 

Rispetto ad un modello basato su record e puntatori, il modello relazionale 

basato sui valori presenta diversi vantaggi: 

133


• esso richiede di rappresentare solo ciò che è rilevante dal punto di vista del- 

l’applicazione (dell’utente); i puntatori sono qualcosa di aggiuntivo, legato 

ad aspetti realizzativi; nei modelli con puntatori, il programmatore delle ap- 

plicazioni fa riferimento a dati che non sono significativi per l’applicazione; 

• la rappresentazione logica dei dati (costituita dai soli valori) non fa alcun 

riferimento a quella fisica, che può anche cambiare nel tempo: il modello 

relazionale permette quindi l’indipendenza fisica dei dati; 

• essendo tutta l’informazione contenuta nei valori, è relativamente semplice 

trasferire i dati da un contesto ad un altro (per esempio se si deve trasferire 

una base di dati da un calcolatore ad un altro); in presenza di puntatori 

l’operazione è più complessa hanno un significato locale, relativo al singolo 

sistema, che non è sempre immediato esportare. 

In una base di dati relazionale, a livello fisico, i dati possono essere rappresen- 

tati secondo modalità che prevedono l’uso dei puntatori. La differenza, rispetto 

ai modelli basati su puntatore, è nel fatto che qui i puntatori non sono visibili a 

livello logico. Inoltre, nei sistemi di basi di dati ad oggetti, che rappresentano una 

delle direzioni di evoluzione delle basi di dati, vengono introdotti gli identificatori 

di oggetto, che, pur ad un livello di astrazione più alto, presentano alcune delle 

caratteristiche dei puntatori. [3] 

3.2.6 Linguaggi ed Utenti delle Basi di Dati 

I DBMS sono caratterizzati, da un lato, dalla presenza di molteplici linguaggi per 

la gestione dei dati; dall’altro, dalla presenza di molteplici tipologie di utenti. 

Linguaggi per Basi di Dati 

Su un DBMS è possibile specificare operazioni di vario tipo, in particolare quelle 

relative agli schemi ed alle istanze. Al riguardo, i linguaggi per basi di dati si 

dividono in due categorie: 

134


• linguaggi di definizione dei dati o Data Definition Language (DDL), uti- 

lizzati per definire gli schemi logici, esterni e fisici e le autorizzazioni per 

l’accesso; 

• linguaggi di manipolazione dei dati o Data Manipulation Language (DML), 

utilizzati per l’interrogazione e l’aggiornamento delle istanze di basi di dati. 

Il linguaggio SQL, da noi estensivamente utilizzato, presenta in forma integrata le 

funzionalità di entrambe le categorie. 

L’accesso ai dati può essere effettuato con diverse modalità: 

• tramite linguaggi testuali interattivi, per esempio il linguaggio SQL; 

• tramite comandi simili a quelli interattivi immersi in linguaggi di program- 

mazione tradizionali; 

• tramite comandi simili a quelli interattivi immersi in linguaggi di sviluppo 

ad hoc, spesso con funzionalità specifiche e varianti da sistema a sistema. 

• tramite interfacce che permettono di sintetizzare interrogazioni senza usare 

un linguaggio testuale 

Varie categorie di persone possono interagire con una base di dati o con un 

DBMS. L’amministratore della base di dati è il responsabile della progettazio- 

ne, controllo ed amministrazione della base di dati. I progettisti e programmatori 

di applicazioni definiscono e realizzano i programmi che accedono alla base di 

dati. Gli utenti utilizzano la base di dati per le proprie attività. Gli utenti finali 

utilizzano transazioni, cioè programmi che realizzano attività predefinite e di fre- 

quenza elevata, con poche eccezioni previste a priori. Gli utenti casuali in grado 

di impiegare linguaggi interattivi possono invece essere specializzati ed interagire 

frequentemente con la base di dati con interrogazioni non predefinite. [3] 

3.2.7 Vantaggi e Svantaggi dei DBMS 

In conclusione, possiamo riassumere come segue i vantaggi derivanti dall’utilizzo 

dei DBMS. 

135


• I DBMS permettono di considerare i dati come una risorsa comune di una 

organizzazione, a disposizione (con opportune forme di controllo) di tutte 

le sue componenti. 

• La base di dati fornisce un modello unificato e preciso della parte del mondo 

reale di interesse per l’organizzazione, utilizzabile nelle applicazioni attuali 

e, con possibili estensioni, in applicazioni future. 

• Con l’uso di un DBMS è possibile un controllo centralizzato dei dati, che 

può essere arricchito da forme di standardizzazione e beneficiare di econo- 

mie di scala. 

• La condivisione permette di ridurre ridondanze ed inconsistenze. 

• L’indipendenza dei dati, caratteristica fondamentale dei DBMS, favorisce 

lo sviluppo di applicazioni più flessibili e facilmente modificabili. 

L’uso dei DBMS comporta anche alcuni aspetti negativi, o almeno delicati, fra cui 

i seguenti. 

[3] 

• I DBMS sono prodotti costosi, complessi ed abbastanza diversi da molti 

altri strumenti informatici. La loro introduzione comporta quindi notevoli 

investimenti, diretti (acquisto del prodotto) ed indiretti (acquisizione del- 

le risorse hardware e software necessarie, conversione delle applicazioni, 

formazione del personale). 

• I DBMS forniscono, in forma integrata, una serie di servizi, che sono neces- 

sariamente associati ad un costo. Nei casi in cui alcuni di questi servizi non 

siano necessari, è difficile scorporare quelli effettivamente richiesti dagli 

altri, e ciò può comportare una riduzione di prestazioni. 

136


3.3 Oracle9i 

Il centro Infoblu della Società Autostrade per l’Italia utilizza un gestore di data- 

base relazionali tra i più noti e performanti: Oracle9i. Vediamo alcuni concetti 

legati al software Oracle ed a questa versione in particolare. 

3.3.1 Introduzione ad Oracle9i 

Oracle è il fornitore leader nel mondo di software per l’information management 

ma è conosciuto soprattutto per i suoi prodotti di gestione dei database relazionali 

(in particolar modo la versione 9i). Questo software è stato il primo a supportare 

l’SQL (Structured Query Language), che ora è uno standard del settore. 

Come detto, Oracle è un DBMS, ovvero un programma che consente ad uno 

o più utenti di computer di accedere ai dati nei database. In particolare, siamo di 

fronte ad un RDBMS, cioè un programma che consente di creare, aggiornare ed 

amministrare un database relazionale. [48] 

Oracle è salita alla posizione di conclamata leadership da origini molto umili 

che risalgono agli anni Settanta. Con prodotti come Oracle8, Oracle8i ed Ora- 

cle9i, Oracle ha aggiunto maggiore potenza espressiva alla sua già solida base. 

Oracle8, lanciato nel 1977, ha messo a disposizione degli utenti un livello di per- 

formance clamorosamente superiore a tutti gli altri dell’epoca. Oracle8i, datato 

1999, ha aggiunto una nuova serie di sviluppi in grado di rendere questo software 

un punto focale nel nuovo mondo dell’informatica basata su Internet. 

Lo Sviluppo dei Database Relazionali 

Il concetto di database relazionale è stato inizialmente introdotto nel 1970 dal 

Dott. Edgar F. Codd in una ricerca svolta per conto dell’IBM ed intitolata System 

R4 Relational Databases. Inizialmente, non era affatto facile capire se un sistema 

basato su questi concetti avrebbe potuto ambire al successo commerciale. No- 

nostante ciò, nel 1979, venne fondata la RSI (Relational Software Incorporated) 

che mise sul mercato Oracle V.2, il primo database relazionale al mondo. Entro 

137

3.3. ORACLE9I Carlo Caligaris, Iacopo Salvarani 

il 1985, Oracle poteva contare su più di 1000 clienti operanti con database rela- 

zionali. Abbiamo già visto in 3.2.5 i motivi che hanno portato questo modello a 

dominare la scena mondiale. 

Come Oracle Crebbe 

Nel 1983, RSI è stata rinominata Oracle Corporation per evitare confusione con 

un competitor chiamato RTI. Al tempo, gli sviluppatori decisero di creare una 

versione di Oracle portabile, in grado di funzionare non solo su sistemi Digital 

VAX/VMS, ma anche su Unix ed altre piattaforme. Nel 1985 Oracle ha reso nota 

la possibilità di funzionare su 30 piattaforme differenti (che nel frattempo sono 

arrivate a 70). Alcune di queste piattaforme, al giorno d’oggi non sono altro che 

delle curiosità storiche mentre altre sono tuttora utilizzabili. Oggi, Oracle ha este- 

so la sua portabilità a sistemi come Microsoft Windows NT/2000/XP e Linux per 

conquistare una importante fetta di mercato anche su queste piattaforme. Fin dal- 

la metà degli anni Ottanta, il modello di sviluppo si è evoluto da applicazione per 

database sui server ad una architettura client/server orientata all’utilizzo di Inter- 

net per accedere alla base di dati tramite un browser. A partire dalla versione 8i 

Oracle ha messo a disposizione anche una JVM integrata nel database. 

Oracle ha centrato lo sviluppo intorno ad un singolo nucleo di codice sorgente 

fin dal 1983. Ogni versione successiva del database include alcune parti di codi- 

ce sorgente specifiche per il sistema, mentre gran parte del codice è comune tra 

le varie implementazioni. Le interfacce con cui gli utenti, gli sviluppatori e gli 

amministratori hanno a che fare sono coerenti attraverso le varie versioni. 

La Famiglia di Prodotti Oracle 

La famiglia dei prodotti messi a disposizione da Oracle comprende 4 differenti 

tipi di database. 

1. Oracle Server/Standard Edition: la versione di Oracle per un server che 

deve avere a che fare con un numero limitato di utenti e con una banca dati 

di piccole dimensioni. 

138


[20] 

2. Oracle Enterprise Edition: la versione di Oracle per un grande numero di 

utenti e per un grande database con componenti avanzate per estensibilità, 

prestazione e gestione. È la versione da noi utilizzata. 

3. Oracle Personal Edition: versione di Oracle per un singolo utente, tipica- 

mente usato per lo sviluppo di applicazioni da utilizzare su altre versioni di 

Oracle. 

4. Oracle Lite: motore di piccole dimensioni per consentire il lavoro su dispo- 

sitivi portatili come i notebooks. 

3.3.2 Componenti per lo Sviluppo di Applicazioni su Database 

Le applicazioni sono spesso costruite sulle fondamenta del sistema di base di dati 

di Oracle. 

Programmazione verso il Database 

Oracle offre ai programmatori diversi linguaggi e diverse interfacce per consentire 

l’accesso e la manipolazione dei dati. Il primo linguaggio naturalmente supportato 

è l’SQL (si veda 3.4) che mette a disposizione funzioni di base per la manipola- 

zione dei dati, il controllo delle transazioni ed il recupero dei dati dalla banca dati. 

Molti utenti, utilizzano interfacce che nascondono comandi SQL semplificandone 

l’utilizzo. L’SQL viene esteso in Oracle in PL/SQL, un linguaggio procedura- 

le comunemente usato per implementare moduli applicativi contenenti elementi 

logici di programmazione. PL/SQL può essere usato per costruire stored proce- 

dures e triggers, controlli in loop ed istruzioni condizionali oltre ad una gestione 

degli errori. Le procedure PL/SQL possono essere compilate e memorizzate al- 

l’interno del database. I blocchi PL/SQL sono eseguibili anche via SQL*Plus, uno 

strumento interattivo fornito con tutte le versioni di Oracle. 

Con Oracle8isi è introdotto l’uso di Java come linguaggio procedurale appog- 

giato ad una JVM interna al database (inizialmente chiamata JServer). [20] 

139


3.3.3 Componenti di Connessione del Database 

La connessione tra il client ed il server del database è una componente chiave del- 

l’architettura globale di un sistema di computazione. La connessione al database 

è responsabile di tutte le comunicazioni tra una applicazione ed i dati che essa usa. 

Oracle include un numero di strumenti per stabilire e calibrare le connessioni al 

database. 

Gli utenti di Oracle si collegano al database tramite una connessione di rete. 

L’interfaccia di rete utilizzata da Oracle è Oracle Net; questa può essere usata con 

una ampia varietà di protocolli di rete, tra cui il più utilizzato TCP/IP. Oracle Na- 

mes consente ai clients di collegarsi al server senza un file di configurazione per 

ogni utente. Questo consente di ridurre il carico del lavoro di manutenzione, dal 

momento che una modifica nella topologia della propria rete non richiede un cor- 

rispondente cambio nei files di configurazione su ogni macchina client. La stessa 

funzione, ma con protocolli diversi da Oracle Net, è svolta da Oracle Internet 

Directory. 

Figura 3.5: Concentratori per un grande numero di utenti [20] 

Ogni connessione al database sfrutta le risorse di rete in modo intensivo, al 

punto di poter influenzare le performance globali di una applicazione per databa- 

140


se. Il Connection Manager di Oracle (Figura 3.5) riduce il numero di connessioni 

di rete verso il database tramite l’utilizzo di concentratori che eseguono un mul- 

tiplexing per implementare connessioni multiple su una singola connessione di 

rete. Questa tecnica consente grandi benefici nel caso in cui molti utenti siano 

attivi contemporaneamente. 

Il Connection Manager consente anche di provvedere ad una connettività mul- 

tiprotocollo nel caso in cui client e server si servano di protocolli differenti. La 

connessione di rete è resa sicura tramite un meccanismo di criptatura dei dati. [20] 

3.3.4 Oracle9iApplication Server 

Il successo delle applicazioni via Internet o Intranet ha condotto ad uno sviluppo 

da una architettura di tipo client/server ad una che viene generalmente indicata 

con il termine three tier (tre livelli). 

Il modello three-tier si struttura su tre livelli. Il primo livello, quello dei client 

che eseguono le richieste e gestiscono l’interfaccia con l’utente, resta sostanzial- 

mente lo stesso del modello client-server, ma la parte server viene suddivisa in 

due livelli, introducendo un middle-tier, su cui deve appoggiarsi tutta la logica di 

analisi delle richieste dei client per ottimizzare l’accesso al terzo livello, che si 

limita a fornire i dati dinamici che verranno usati dalla logica implementata nel 

middle-tier per eseguire le operazioni richieste dai client. In questo modo si può 

disaccoppiare la logica dai dati, replicando la prima, che è molto meno soggetta 

a cambiamenti ed evoluzioni, e non soffre di problemi di sincronizzazione, e cen- 

tralizzando opportunamente i secondi. In questo modo si può distribuire il carico 

ed accedere in maniera efficiente i dati. [36] 

Oracle9iAS (Application Server) funziona da middle-tier. Nella Figura 3.6 

vediamo le diverse tipiche connessioni che si possono avere tra un client ed un 

server in una architettura Oracle. 

141


Figura 3.6: Tipiche connessioni di un database Oracle [20] 

3.3.5 Confronto con Altri RDBMS 

Esistono altri sistemi di gestione dei database forse ancora più famosi di Oracle: 

in particolare ci riferiamo a Microsoft Access e Microsoft SQL Server. MS Access 

non è un vero sistema di gestione di database relazionali. Fornisce effettivamen- 

te le funzioni di un database relazionale, dal momento che memorizza i dati in 

tabelle relazionali, ma non è un sistema di gestione. Infatti ha una scarsa imple- 

mentazione dei concetti di transazioni multi-utente, di sicurezza multi-utente e 

di altre caratteristiche che definiscono un gestore di database. D’altra parte MS 

Access è stato progettato dall’inizio come un database per un singolo utente. [35] 

SQL Server 2000 lavora solo su piattaforme Windows mentre Oracle lavora 

anche su piattaforme alternative come Unix Linux Intel e Sun Solaris. È molto dif- 

ficile fare un confronto di performance tra SQL Server 2000 ed Oracle 9i. Questa 

caratteristica viene influenzata da fattori fortemente dipendenti dall’esperienza di 

chi sviluppa ed amministra il database. A parità di piattaforma, SQL Server 2000 

può vantare un valore del TPC-C più alto, mentre Oracle si rende preferibile sul- 

le piattaforme alternative. Il TPC (Transaction Processing Performance Council) 

è una organizzazione che determina le transazioni tipiche utilizzate in sistemi di 

controllo di inventario, sistemi di prenotazione nelle linee aeree e sistemi bancari 

ed alcune regole generali che queste transazioni dovrebbero soddisfare. Lo scopo 

142


è produrre benchmarks che misurino le performance di un database nel processare 

transazioni in una certa unità di tempo. Il TPC-C è il più popolare tra questi valori 

di confronto. [8] 

143

3.4. SQL Carlo Caligaris, Iacopo Salvarani 

3.4 SQL 

3.4.1 Introduzione ad SQL 

SQL è il linguaggio di riferimento per le basi di dati relazionali. Il nome SQL 

inizialmente rappresentava l’acronimo di Structured Query Language, ma lo stan- 

dard specifica ora che SQL deve essere considerato come un nome proprio. SQL 

è ben più di un linguaggio per scrivere interrogazioni. Contiene, infatti, al suo 

interno, sia le funzionalità di un Data Definition Language sia quelle di un Data 

Manipulation Language. [3] 

3.4.2 Standardizzazione dell’SQL 

La diffusione di SQL è dovuta in buona parte alla intensa opera di standardizza- 

zione dedicata a questo linguaggio, svolta principalmente nell’ambito degli orga- 

nismi ANSI (American National Standards Institute, l’organismo nazionale sta- 

tunitense degli standard) ed ISO (l’organismo internazionale che coordina i vari 

organismi nazionali). Gran parte dei produttori del settore hanno avuto modo 

di partecipare al processo decisionale. Il processo di standardizzazione ha avu- 

to inizio nella prima metà degli anni Ottanta e continua tuttora. Sono state così 

prodotte nel tempo diverse versioni, sempre più complesse e sofisticate, dello stan- 

dard del linguaggio. La prima definizione di uno standard per il linguaggio SQL 

è stata emanata nel 1986 dall’ANSI. Questo primo standard possedeva già gran 

parte delle primitive di formulazione di interrogazioni, mentre offriva un suppor- 

to limitato per la definizione e manipolazione degli schemi e delle istanze. Sono 

state poi sviluppare versioni successive come SQL-92 ed SQL:1999; quest’ultimo 

è un linguaggio estremamente complesso ed è molto difficile trovare un sistema 

commerciale che metta a disposizione tutte le funzionalità previste dal linguaggio. 

Analizzando con cura i sistemi relazionali, si osserva che ciascuno di essi 

offre in effetti piccole differenze nella implementazione del linguaggio SQL; le 

differenze emergono soprattutto quando si conforntano fra di loro le funzionalità 

innovative. Invece, per quanto riguarda gli aspetti più consolidati del linguaggio, 

144


l’adesione allo standard è maggiore e questo permette agli utenti di dialogare in 

SQL standard con sistemi completamente diversi, come possono essere l’imple- 

mentazione di un DBMS per un personal computer monoutente ed una base di 

dati su mainframe su cui si appoggia il sistema informativo di una grossa azienda. 

[3] 

In questo contesto non scriveremo nulla sui comandi dell’SQL, ma solo infor- 

mazioni di alto livello riguardanti questo linguaggio. 

3.4.3 Interrogazioni in SQL 

La parte di SQL dedicata alla formulazione di interrogazioni fa parte del DML. 

SQL esprime le interrogazioni in modo dichiarativo, ovvero si specifica l’obietti- 

vo dell’interrogazione e non il modo in cui ottenerlo. In ciò SQL segue i principi 

del calcolo relazionale e si contrappone a linguaggi di interrogazione procedurali, 

come l’algebra relazionale, in cui l’interrogazione specifica i passi da compiere 

per estrarre le informazioni dalla base di dati. L’interrogazione SQL per essere 

eseguita viene passata all’ottimizzatore di query (query optimizer), un compo- 

nente del DBMS il quale analizza l’interrogazione e formula a partire da questa 

un’interrogazione equivalente nel linguaggio procedurale interno del sistema di 

gestione di basi di dati. Questo linguaggio procedurale è nascosto all’utente. Per 

questo, chiunque scriva interrogazioni in SQL può trascurare gli aspetti di tradu- 

zione ed ottimizzazione. Il grande sforzo dedicato allo sviluppo di tecniche di 

ottimizzazione ha permesso di costruire strumenti che sono in grado di produrre 

traduzioni molto efficienti per la maggior parte dei DBMS relazionali. 

Esistono in generale molti modi diversi per esprimere la stessa interrogazione 

in SQL: il programmatore dovrà effettuare una scelta basandosi non sull’efficien- 

za, bensì su caratteristiche come la leggibilità e la modificabilità dell’interrogazio- 

ne. SQL agevola così il lavoro del programmatore permettendogli di descrivere le 

interrogazioni in un modo astratto e di alto livello. 

145

3.5. JDBC Carlo Caligaris, Iacopo Salvarani 

3.5 JDBC 

3.5.1 Cosa Significa JDBC? 

JDBC (Java DataBase Connectivity è una interfaccia standard per connettere Java 

con i databases relazionali. Lo standard JDBC è stato definito da Sun Microsy- 

stems con la possibilità per tutti gli utilizzatori individuali di implementare ed 

estendere lo standard con i propri drivers JDBC. Si può usare JDBC per eseguire 

queries ed updates su tabelle dove, per esempio, il numero ed il tipo di colonne 

non sono noti fino al runtime. Questa possibilità si chiama SQL dinamico. JDBC 

consente di utilizzare istruzioni di SQL dinamico in programmi Java. Eviden- 

temente, non ci sono analisi o controlli delle istruzioni SQL: se queste fossero 

sbagliate causerebbero errori durante il runtime. [47] 

Nel software da noi progettato viene spesso utilizzata questa proprietà di JDBC: 

ad esempio, uno dei nostri programmi genera a runtime una query in cui si richiede 

una data dipendente dall’istante di lancio del programma. 

JDBC fornisce un insieme di classi di alto livello che consentono a chiunque 

conosca SQL e Java di scrivere applicazioni operanti su database. Componenti di 

networking e protocolli del database sono trasparenti al programmatore dell’appli- 

cazione; questi sono gestiti da classi interne ai drivers JDBC. Le specifiche JDBC 

sono concordate all’interno della comunità Java ed ogni concessionario di databa- 

se deve provvedere ad implementare queste funzioni per rendere il suo prodotto 

fruibile dagli utenti. [40] 

3.5.2 Gli Oracle JDBC Drivers 

Oracle fornisce 4 diversi JDBC drivers. 

JDBC Thin Driver 

Il JDBC Oracle Thind Driver è un driver al 100% puro Java e quindi è totalmente 

indipendente dalla piattaforma su cui viene utilizzato. Non richiede alcuna com- 

ponente software lato client aggiuntiva oltre al client di Oracle e comunica con il 

146


server utilizzando TTC, un protocollo sviluppato da Oracle per accedere all’Oracle 

RDBMS (Relational DataBase Management System). 

JDBC OCI Driver 

Questo driver deve essere utilizzato per applicazioni Java lato client, richiede l’in- 

stallazione del client di Oracle e dipende dalla piattaforma Oracle su cui deve 

funzionare. Questo driver è scritto con una combinazione di Java e C e converte le 

richieste JDBC in chiamate all’Oracle Call Interface (OCI) usando metodi nativi 

per chiamare punti di accesso in C. Queste chiamate sono spedite attraverso la 

Oracle Net fino al server. 

OCI è una Application Programming Interface (API) che consente di creare 

applicazioni che utilizzano procedure native o chiamate di funzioni di un linguag- 

gio di terza generazione per accedere al server di un database di Oracle e control- 

lare tutte le fasi di esecuzione di una istruzione SQL. Il driver OCI è progettato 

per costruire applicazioni in grado di sostenere un grande numero di utenti in 

sicurezza. 

JDBC Server-Side Thin Driver 

Questo driver le stesse funzionalità dell’omonima versione client-side ma lavora 

all’interno di una base di dati Oracle ed accede ad un database remoto. Questo 

consente anche di accedere ad un server dall’interno di un altro. Questo driver 

può essere usato indifferentemente dal server e dal client. 

JDBC Server-Side Internal Driver 

Il driver interno Oracle JDBC server-side supporta ogni tipo di codice Java che 

funzioni dall’interno di un database, come ad esempio in una stored procedure, e 

debba accedere al database stesso. Questo driver consente alla JVM di comunicare 

direttamente con il motore SQL. 

147

3.5. JDBC Carlo Caligaris, Iacopo Salvarani 

3.5.3 La Connessione da Java ad Oracle 

Nei nostro lavoro abbiamo utilizzato molto spesso la possibilità di connessione al 

database Oracle e lo abbiamo fatto usando il thin driver; riportiamo si seguito un 

esempio della procedura seguita. 

Estratto 3.1 

. . . . 

C o n n e c t i o n c = 

. . . . 

c o n n e c t ( ” o r a c l e . j d b c . d r i v e r . O r a c l e D r i v e r ” , 

” j d b c : o r a c l e : t h i n : @SchemaName : 1 5 2 1 :DBName” , 

” . . . . ” , 

” . . . . ” ) ; 

p u b l i c s t a t i c C o n n e c t i o n c o n n e c t ( S t r i n g DbDriver , 

S t r i n g dbURL , 

S t r i n g dbUser , 

S t r i n g dbPwd ) 

{ 

throws ClassNotFoundException , 

SQLException 

C l a s s . forName ( DbDriver ) ; 

C o n n e c t i o n dbCon=n u l l ; 

dbCon = 

DriverManager . g e t C o n n e c t i o n ( 

r e t u r n dbCon ; 

} 

dbURL , dbUser , dbPwd ) ; 

148


3.6 XML 

Nel corso del nostro lavoro, abbiamo spesso incontrato la necessità di comuni- 

care dati da un programma ad un altro. Per questo, abbiamo scritto questi dati 

migranti su files XML, un linguaggio universalmente accettato per lo scambio di 

informazioni. 

3.6.1 Introduzione ad XML 

Apparentemente, l’XML (eXtensible Markup Language) sembra soltanto un altro 

formato per la serializzazione dei dati, simile a tanti altri formati con i quali si è 

lavorato in passato. Il suo successo non è però legato solamente alla sua sempli- 

cità, ma soprattutto alla sua estensibilità e flessibilità. XML è infatti basato sui 

concetti di apertura e libertà. In termini di libertà, esso non obbliga ad utilizzare 

una particolare API o uno specifico modello di documento (anche se esistono rac- 

comandazioni a riguardo), e quindi gli sviluppatori sono liberi di decidere come 

meglio programmare documenti XML all’interno del loro sistema. In un mon- 

do dove lo scambio di informazioni tra applicazioni eterogenee sta diventando 

una caratteristica sempre più comune, lo sviluppatore può utilizzare l’XML co- 

me uno standard de facto che rende possibile attraversare i confini solitamente 

rappresentati dal sistema su cui si sta lavorando. 

La storia dell’XML ha le sue radici nei primi anni Sessanta quando vennero 

introdotti i linguaggi con marcatori, come l’HTML. Fin dall’inizio della storia del- 

l’informatica, gli sviluppatori sono stati sempre alla ricerca del miglior modo per 

strutturare le informazioni. Praticamente ogni applicazione(da quelle di gestione 

database, ai word processor, ai software ingegneristici) hanno utilizzato dei for- 

mati binari personalizzati per strutturare le informazioni di cui avevamo bisogno. 

A causa di ciò, le informazioni generate da un’applicazione non potevano essere 

utilizzate da un’altra applicazione senza prima venire trasformate. Nei primi anni 

Sessanta, ai tempi delle telescriventi e delle macchine da scrivere, quando si vo- 

levano effettuare delle correzioni ai testi prodotti dai primi elaboratori, venivano 

utilizzati degli speciali simboli, chiamati marcatori, che apposti sui fogli prodotti 

149

3.6. XML Carlo Caligaris, Iacopo Salvarani 

dalle stampanti, servivano, appunto, a marcare le indicazioni su come formatta- 

re una specifica riga, una parola o un paragrafo. Il gruppo di simboli utilizzati 

divenne molto presto famoso come markup language. A quei tempi, c’erano fon- 

damentalmente due tipi di linguaggi, quelli specifici per le indicazioni sul layout 

e quelli generici per l’indicazione sulla struttura del documento. A questo pro- 

posito, il formato RTF (Rich Text Format) è un moderno esempio di specifiche di 

formattazione. Al contrario dei linguaggi specifici per la formattazione dei testi, 

i linguaggi di markup generici non si occupano dei dettagli della formattazione 

quanto della struttura del documento (resta inteso che per ottenerne una specifica 

rappresentazione questi dati dovranno essere trasformati). Ciò fa sì che la struttu- 

ra del documento possa essere codificata in un formato che ne facilita lo scambio 

tra i computer. Questa scoperta aprì la strada al successo dei linguaggi di markup 

generici che ebbe, appunto, inizio nel corso degli anni Sessanta. [12] 

3.6.2 HTML 

L’HTML è un markup language che fu inizialmente sviluppato da uno studioso 

del CERN ed offre uno specifico vocabolario di marcatori per formattare, strut- 

turare, ma soprattutto collegare tra loro i documenti. La possibilità di effettuare 

link tra i documenti ha permesso la creazione di una rete di documenti collegati 

tra loro in grado di sfruttare il potenziale di Internet. Nacque così il World Wide 

Web (WWW). Furono velocemente sviluppati software in grado di visualizzare ed 

elaborare documenti HTML (i cosiddetti browser), e a partire dal 1993, anno del- 

la comparsa di Mosaic (il primo browser sviluppato dall’NCSA) l’interesse per il 

WWW iniziò ad esplodere. Grazie alla sua semplicità, l’HTML fu universalmen- 

te adottato ed un grande numero di pagine web iniziarono ad essere disponibili 

tanto che a tutt’oggi il formato HTML è quello più usato al mondo. Il comitato 

W3C (World Wide Web Consortium) nato nel 1994 al MIT/CERN sviluppa e rac- 

comanda tutte le specifiche dell’HTML per favorirne e governarne l’evoluzione e 

lo sviluppo. Il vocabolario implementato dall’HTML è tuttavia limitato alla for- 

mattazione ed al collegamento di documenti e per questo motivo non può essere 

utilizzato al di fuori dell’ambito dei browser web. 

150


L’XML fu proposto al W3C nel 1996 da Jon Bosak, che a quei tempi lavorava 

in Sun, e che è considerato il padre di questo linguaggio. La sintassi consen- 

te di sviluppare un vocabolario di marcatori personalizzati. Oggi XML è usato 

in una vasta gamma di applicazioni distribuite che richiedono un alto livello di 

interoperabilità. [12] 

3.6.3 Che Cosa È l’XML 

L’XML è un metalinguaggio che permette di creare linguaggi di marcatura per- 

sonalizzati per l’interscambio di dati tra siti web ed applicazioni, anche basati 

su sistemi differenti. XML usa dei marcatori per definire la struttura delle infor- 

mazioni (elementi): l’eventuale aggiunta di metadati (attributi) può ulteriormente 

definire le specifiche delle informazioni stesse. [12] 

Figura 3.7: Un esempio di file XML da noi utilizzato 

3.6.4 Lo Stack di Protocolli XML 

Fino a pochi anni fa i programmatori che parlavano di XML si riferivano alle 

specifiche XML 1.0. Oggi, XML è composto da più parti rispetto alla specifica 

nata nel 1998 e quando i programmatori si riferiscono ad esso, intendono l’intera 

famiglia di specifiche. Queste vengono considerate come se fossero degli strati 

151


Astratto Classi ed oggetti Specifico dell’applicazione 

Tipi ed istanze XML Schema 

Voci strutturali XML Information Set 

Elementi ad attributi XML 1.0 + Namespace 

Entità e documenti XML 1.0 

Files e pacchetti Specifico dell’OS e del protocollo 

Concreto Settori e streams di dati Specifico dell’hardware 

Tabella 3.1: Lo stack di protocolli XML 

(layers) sovrapposti, dato che le specifiche più recenti sono definite in termini di 

specifiche precedenti. Questo meccanismo è simile allo stack di protocolli di rete 

(ad esempio il TCP/IP) progettato in termini di strati isolati tra loro. 

Al pari dei protocolli di rete, il protocollo XML ha sette distinti livelli. I 

due strati di livello più alto definiscono il sistema dei tipi XML nei termini di 

modello di dati astratto sottostante; essi definiscono inoltre in che modo le classi 

e gli oggetti specifici dell’applicazione debbano essere mappati nei tipi XML. Lo 

strato chiamato Infoset definisce l’XML in termini di un modello di dati astratto 

che focalizza l’attenzione sulla strutturazione logica di un documento XML. In 

altre parole, l’Infoset non si occupa di come debbano essere serializzati i dati 

per modellare un documento XML logico. XML 1.0 ed i namespace servono a 

definire i documenti XML in termini di elementi ed attributi. Lo strato successivo, 

definito come XML 1.0, stabilisce come sono costituiti fisicamente i documenti 

XML da entità come files e pacchetti. Il sistema operativo ed i protocolli di rete 

rappresentano lo strato successivo in quanto offrono l’astrazione (in termini di 

files e pacchetti) che incapsula la complessità relativa all’interfacciamento con i 

dispositivi hardware. Il livello hardware non è altro che un insieme di settori e 

flussi di dati. [12] 

152


3.6.5 Specifiche XML 

XML 1.0 + Namespace 

Una delle grandi potenzialità del linguaggio XML è la possibilità di leggere e 

scrivere XML da qualsiasi piattaforma. Per ottenere questo risultato, però, si deve 

costruire il documento XML seguendo una sintassi ben definita da due specifiche: 

XML 1.0 ed i namespaces. Entrambe si occupano della rappresentazione lessicale 

e binaria delle informazioni in un documento XML. 

In maniera particolare esse hanno a che fare con: 

• la sintassi per l’assegnazione dei nomi degli elementi e degli attributi; 

• la sintassi per la strutturazione delle informazioni utilizzando gli elementi e 

gli attributi; 

• la sintassi per altri costrutti dell’XML come direttive di elaborazione, com- 

menti, etc.; 

• le modalità di composizione di documenti logici da entità fisiche; 

• il set di caratteri usato nel documento; 

• l’utilizzo di codifiche differenti in fase di serializzazione; 

• l’associazione al documento di risorse binarie come immagini, files audio 

Infoset 

ed altro. 

L’Infoset definisce il modello astratto dei dati e rappresenta il vero cuore del- 

l’XML. Esso codifica il modello di dati astratto dell’XML, che altre specifiche 

possono utilizzare per costruire documenti ben formati (well formed) e definisce i 

differenti costrutti che servono per creare un documento XML e le relazioni tra di 

essi. Per esempio, l’Infoset stabilisce che ogni documento deve contenere al suo 

interno le informazioni sotto forma di un singolo elemento figlio. Questo, a sua 

volta, può avere zero o più figli ordinati (anche di tipo diverso) ed un insieme di 

153


attributi non ordinati. L’Infoset stabilisce inoltre che ogni elemento ed attributo 

debbano contenere due parti di informazione: il nome locale ed il namespace URI. 

Nell’Infoset non c’è nulla che abbia a che fare con la sintassi XML o con i dettagli 

della serializzazione, in quanto esso è completamente astratto. Infatti, XML 1.0 + 

Namespace è solo uno dei possibili formati di serializzazione dell’Infoset. [12] 

3.6.6 Le Interfacce di Programmazione 

Uno dei motivi di successo dell’XML è costituito dal fatto che non obbliga il 

programmatore ad utilizzare una specifica interfaccia di programmazione. Nel 

corso degli anni sono state sviluppate numerose API, che si sono avvicendate nel 

panorama della programmazione dell’Infoset dell’XML, ma allo stato attuale due 

sono le più comuni, quella che offre una vista a cursore e quella che fornisce una 

vista del documento nella sua interezza. 

Interfaccia per lo Streaming dell’Infoset (parser) 

L’analisi (parsing) di un file XML in modalità a cursore, sia in lettura che in scrit- 

tura, viene offerta da una interfaccia di streaming per l’Infoset. È bene sottolineare 

che allo stato attuale non esiste uno standard che supporti nessuna delle modalità 

di streaming e quindi ogni produttore si è creato la sua particolare implementazio- 

ne. L’implementazione dell’interfaccia di streaming si divide fondamentalmente 

in due metodologie ben distinte: pull parsing e push parsing. 

In un pull parser è il codice dell’applicazione che esplicitamente riceve gli 

eventi dal parser. Solitamente è presente un ciclo nel quale il codice richiede 

l’evento successivo dal parser. Poiché è l’applicazione che controlla il parser, si 

possono scrivere programmi nei quali vengono gestiti specifici eventi e magari 

completamente ignorati altri, che non sono di interesse per l’applicazione. 

In un push parser gli eventi vengono spinti verso il client. Tipicamente, un 

parser di tipo push richiede che l’applicazione registri un metodo di gestione per 

ciascun evento. Durante la lettura del file da parte del parser, per ogni evento viene 

154


richiamato il metodo appropriato ed il controllo rimane al parser fino al termine 

della lettura del documento. 

Interfaccia per la Navigazione dell’Infoset (DOM) 

Spesso si ha bisogno di leggere (o scrivere) un file XML in maniera non sequen- 

ziale, e si potrebbe avere la necessità, per esempio, di invertire l’ordine degli ele- 

menti. Il DOM (Document Object Model) è una interfaccia per la manipolazione 

dei contenuti e della struttura di un file XML in modalità object-oriented. Esso 

definisce un modo standard per la manipolazione di documenti XML con opera- 

zioni accesso agli elementi, l’applicazione di stili, il caricamento in memoria, il 

salvataggio su disco ed altro ancora. 

Il DOM rappresenta il documento XML come un albero di oggetti. Ogni og- 

getto nell’albero è chiamato nodo. Esistono vari tipi di nodo che rispecchiano 

praticamente tutte le componenti di cui è costituito un documento XML, tra cui 

Document, Element, Attr. Alcuni nodi possono avere un sottonodo ed è possibile 

anche specificare il tipo dello stesso. 

Il DOM è indipendente dal linguaggio e dalla piattaforma utilizzata, il che 

significa che può essere utilizzato con qualsiasi linguaggio o framework o sistema 

operativo ed esiste praticamente un’implementazione di DOM in ogni linguaggio 

di programmazione. 

Essendo un’API molto potente, DOM appare come la scelta preferenziale da 

applicare in qualsiasi scenario, ma in realtà non è detto che sia sempre la scelta 

migliore. Infatti, quando un’applicazione deve lavorare con documenti di grosse 

dimensioni, il sovraccarico dovuto all’implementazione del modello DOM può 

essere un grosso problema e la modalità parsing diventa un’alternativa molto in- 

teressante. Grazie alla sua caratteristica di cursore, viene letto un solo nodo per 

volta e, soprattutto nel modello pull, non si è nemmeno costretti a prenderlo in 

considerazione se rappresenta un nodo non rilevante per l’applicazione. È anche 

interessante notare che quasi tutte le implementazioni di DOM utilizzano le classi 

di parsing per il caricamento e la scrittura dei file da/verso il disco. [12] 

155


Figura 3.8: La Struttura ad Albero Tipica dell’XML [51] 

3.6.7 Altre Specifiche XML 

Esistono altre specifiche collaterali che vengono fornite allo sviluppatore tutta una 

serie di funzionalità di elaborazione e gestione del file stesso. 

XML Path 

XPath definisce una sintassi uniforme per identificare sottoinsiemi dell’Infoset. 

XML Path definisce un linguaggio basato su percorsi collegato alle relazioni di pa- 

rentela che intercorrono tra i nodi dell’albero che è la rappresentazione in memoria 

del documento XML. 

XML Schema 

Un XML Schema definisce i tipi di dato per una specifica applicazione nei termini 

dell’Infoset. Una problematica collegata ai linguaggi di markup è quella della 

156


validazione di un documento, e cioè la verifica che gli elementi e gli attributi 

in esso contenuti rispettino determinati requisiti, stabiliti dall’applicazione. In 

questo senso, ad un documento XML è possibile associare un file DTD, che serve 

a descriverne la struttura in termini di nome e posizione di elementi ed attributi. 

[12] 

157


Attributo 

Testo 

Commenti 

Nodo radice 

Documento 

Elemento 

Elemento 

Istruzioni di elaborazione 

Elemento Elemento Elemento 

Attributo 

Testo 

Attributo 

Testo 

Figura 3.9: La Struttura di un file XML [12] 

158 

Elemento


3.6.8 Java ed XML 

Il linguaggio Java consente di interagire con XML tramite librerie create apposita- 

mente. Nel nostro lavoro abbiamo utilizzato una libreria sviluppata internamente 

alla Società Autostrade in grado di fornire un accesso tramite DOM ai files di no- 

stro interesse. Le stesse classi sono state utilizzate anche per la scrittura su files 

XML. 

159

3.7. SVG Carlo Caligaris, Iacopo Salvarani 

3.7 SVG 

I dati che abbiamo memorizzato nei files XML, spesso hanno avuto bisogno di 

una rappresentazione grafica. Si è reso quindi necessario trovare un dispositivo 

grafico in grado di leggere i files XML, estrarre i dati di interesse e mostrarli a 

schermo previa una qualche trasformazione per migliorarne la leggibilità. 

A questo scopo, abbiamo utilizzato l’SVG (Scalable Vector Graphics). 

3.7.1 Cosa è SVG 

SVG è un linguaggio utilizzato per definire elementi grafici vettoriali normalmen- 

te diffusi attraverso il Web. La grafica di SVG è definita in formato XML ed ha 

la proprietà di non perdere qualità qualora dovesse essere ridimensionata. Inol- 

tre, ogni elemento ed ogni attributo dei files SVG può essere animato. Il World 

Wide Web Consortium (W3C) raccomanda l’utilizzo di questo standard. SVG 

si integra con altri standard raccomandati dal W3C come il DOM e l’XSL. La 

raccomandazione è divenuta ufficiale nel Gennaio 2003. [50] 

3.7.2 Storia e Vantaggi di SVG 

Sun Microsystems, Adobe, Apple, IBM e Kodak sono tra le organizzazioni più note 

che sono state coinvolte nella definizione dell’SVG. I vantaggi di usare SVG in 

luogo degli altri formati (come JPEG e GIF) sono: 

• i file possono essere letti e modificati da un grande insieme di strumenti (tra 

cui Notepad o un qualunque editor di testo); 

• i files sono più piccoli e più facilmente comprimibili dei JPEG o GIF; 

• le immagini sono scalabili; 

• le immagini possono essere stampate con alta qualità a qualsiasi risoluzione; 

• le immagini possono essere ingrandite ed ogni parte di una immagine può 

essere ingrandita senza degradazione; 

160


• il testo dell’SVG è selezionabile e può essere cercato all’interno della pagi- 

na (ideale per le mappe); 

• SVG lavora con tecnologia Java; 

• SVG è uno standard aperto; 

• il files SVG sono puri XML. 

Il principale competitor per SVG è Flash. I due hanno molte componenti simili. 

Il più grande vantaggio che SVG ha rispetto a Flash è la compatibilità con altri 

standard; Flash si affida a tecnologia di sua proprietà che non è open source. Il 

difetto principale di SVG è che, al momento, non tutti i browser lo supportano. 

Internet Explorer, in versioni successive alla 5, consente l’utilizzo di SVG; Mo- 

zilla Firefox sta lavorando per consentire ai suoi utenti la completa compatibilità 

con questo standard. 

Per vedere i files SVG, è comunque necessario scaricare gratuitamente dal sito 

Adobe il plug-in SVG Viewer ed installarlo. [50] 

161

3.8. JAVASCRIPT ED HTML Carlo Caligaris, Iacopo Salvarani 

3.8 JavaScript ed HTML 

3.8.1 Cosa è JavaScript 

JavaScript è un linguaggio di scripting, basato su oggetti, che viene utilizzato per 

sviluppare applicazioni per Internet. Venne implementato per la prima volta nel 

Giugno 1995 nella versione beta del browser Navigator 2.0 di Netscape. Tale 

linguaggio ha apportato un notevole cambiamento alle pagine HTML: grazie ad 

esso, alcuni effetti sono diventati più facili da realizzare e la dinamicità delle pa- 

gine Web non è più stata confinata alle sole GIF animate. Oggi tutti i browser più 

importanti hanno al loro interno un interprete JavaScript. 

Il 1995, inoltre, resta una pietra miliare nello sviluppo di Internet, perchè ac- 

canto a Netscape, un’altra azienda saliva all ribalta, la Sun Microsystems Inc., 

che aveva presentato ad inizio anno Java, il linguaggio evoluto che si proponeva 

di diventare uno standard nella comunicazione in rete. Spesso si confonde Java 

con JavaScript, ma i due linguaggi sono profondamente diversi, pur presentando 

qualche aspetto in comune come: 

• la somiglianza sintattica di molti costrutti ed espressioni, ereditati dal C; 

• la possibilità che entrambi offrono di avviare contenuto eseguibile all’inter- 

no di pagine Web. 

Anche il nome dei due linguaggi è simile, ma ciò è del tutto casuale: infatti Ja- 

vaScript, alla sua prima apparizione, si chiamava LiveScript, per parallelismo con 

LiveWire, un linguaggio che la stessa Netscape aveva messo a punto per la gestione 

della programmazione dal lato server; i due linguaggi, affermatisi contemporanea- 

mente, non potevano però che avere vite parallele ed infatti, nel Dicembre 1995, 

la Netscape e la Sun annunciarono la decisione di collaborare sinergicamente allo 

sviluppo di LiveScript, che finì con il prendere il nome attuale di JavaScript. [15] 

162


3.8.2 Scripting e Programmazione 

Come accennato, JavaScript è un linguaggio di scripting e non un linguaggio di 

programmazione. Pur avendo molti aspetti in comune, questi due tipi di linguaggi 

presentano notevoli differenze. Un linguaggio di scripting può controllare il com- 

portamento del browser ed il suo contenuto, ma non può effettuare elaborazioni 

grafiche o gestire la rete, mentre un linguaggio di programmazione non ha alcuna 

possibilità di controllare il browser nella sua interezza, ma può gestire la grafica, 

la rete e possiede funzionalità avanzate che permettono di creare e gestire processi 

paralleli, comportandosi come un sistema operativo in miniatura. JavaScript di- 

spone di diverse caratteristiche appositamente progettate per renderlo semplice da 

usare. Sotto questa apparente semplicità, però, si nasconde la completezza che si 

riscontra in un linguaggio di programmazione. [15] 

3.8.3 Principali Caratteristiche di JavaScript 

JavaScript ha alcune caratteristiche peculiari: 

• è un linguaggio interpretato; 

• è un linguaggio basato sugli oggetti; 

• è un linguaggio guidato dagli eventi; 

• il nucleo del linguaggio è stato incorporato all’interno dei browser; 

• esistono sia la variante lato client che quella lato server. 

La variante lato client è quella più comune ed è anche quella da noi utilizzata 

per i nostri scopi. Essa permette l’inserimento di contenuti eseguibili all’interno 

di pagine Web; in questo modo, le pagine Web non sono più pagine statiche, 

ma diventano pagine attive o dinamiche, cioè possono comprendere programmi 

che interagiscono con l’utente, controllando il browser e creando dinamicamente 

nuovi contenuti HTML. 

163


3.8.4 Come Inserire uno Script in un Documento HTML 

L’HTML prevede un tag apposito per gli script. 

Estratto 3.2 

 

I s t r u z i o n i s c r i t t e con un l i n g u a g g i o d i s c r i p t i n g 

 

Quando il browser, analizzando un documento HTML, incontra il tag , 

interpreta il codice presente al suo interno e lo esegue dall’alto verso il basso. Se 

durante l’esecuzione incontra un errore, può succedere che il documento ven- 

ga visualizzato, ma il codice errato non sia eseguito oppure che il documento 

resti bianco o visualizzato parzialmente, perché l’esecuzione del codice è stata 

interrotta. 

In linea di principio, uno script JavaScript può essere inserito in due modi 

all’interno di un documento HTML: 

• inserendo il codice nel documento HTML sia nel BODY che nell’HEAD; 

• caricandolo da un file esterno. 

Quando lo script è salvato in un file con estensione .js, può essere richiamato 

mediante l’attributo SRC dell’elemento SCRIPT. 

Estratto 3.3 

 

 

Il file esterno viene eseguito all’interno del documento HTML. Ciò vuol di- 

re che questo file viene solo letto come file di testo, trasferito nell’HTML nella 

posizione di richiamo e poi eseguito. [15] 

164


3.8.5 ECMAScript 

Lo Standard ECMA è uno standard di scripting basato su varie tecnologie, tra 

cui le più note sono JavaScript (Netscape) e JScript (Microsoft). Lo sviluppo 

di questo standard è iniziato nel Novembre 1996 e la sua prima edizione è stata 

adottata dall’Assemblea Generale ECMA nel Giugno 1997. 

[46] 

165


166

Capitolo 4 

Oggetto del Lavoro 

Figura 4.1: Night Motorway [60] 

167

4.1. PRESENTAZIONE DEL TRATTO MILANO-BRESCIA Carlo Caligaris, Iacopo Salvarani 

4.1 Presentazione del Tratto Milano-Brescia 

Come abbiamo già detto in precedenza, il nostro obiettivo è stato quello di co- 

struire un simulatore di traffico autostradale relativo alla tratta Milano - Brescia 

della Autostrada A4. Questa tratta ha caratteristiche particolari sotto vari punti di 

vista: 

• è tra quelle che sopporta i maggiori flussi di traffico; 

• ha moltissimi strumenti di rilevazione (se confrontati con quelli delle altre 

tratte) lungo il tracciato; 

• può essere considerata come un tratto “chiuso” (questo importante concetto 

sarà approfondito in seguito). 

Nelle seguenti Sottosezioni analizzeremo questi aspetti. 

4.1.1 La Autostrada A4 

Il tratto Milano - Brescia è una parte dell’Autostrada A4, detta Serenissima. Essa 

attraversa da Ovest ad Est l’intera Pianura Padana, partendo da Torino, passan- 

do per Milano e terminando a Trieste. Numerose sono le interconnessioni con le 

altre grandi arterie autostradali. La A4 dispone, nel tratto tra Torino e Venezia, 

di tre corsie più una d’emergenza (ad eccezione di pochi tratti in concomitanza 

del passaggio sopra fiumi come nel caso del viadotto sull’Adda situato tra Trezzo 

sull’Adda e Capriate San Gervasio). Il tratto compreso tra Venezia e Trieste è, al 

momento attuale, ancora con sole due corsie per ogni senso di marcia. Nel 2005 

sono iniziati i lavori per aggiungere la quarta corsia nel tratto Milano-Bergamo, 

mentre si attende la conclusione dei lavori che hanno interessato il tratto tra Tori- 

no e Milano, collegati ai cantieri dell’alta velocità ferroviaria. Da sempre questa 

autostrada è considerata uno dei punti nevralgici della rete viaria italiana facendo 

parte di uno dei più importanti corridoi europei che collegano l’estremità della 

Penisola Iberica con le nazioni dei Balcani. Il suo percorso, di circa 530 km, è ge- 

stito da società diverse come Autostrade per l’Italia, Autostrada Brescia, Verona, 

168

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale CAPITOLO 4. OGGETTO DEL LAVORO 

Vicenza, Padova, Società delle Autostrade di Venezia e Padova e Autovie venete. 

[52] 

La Storia dell’Autostrada Torino-Milano inizia negli anni Venti dello scorso 

Secolo, quando il Senatore Frola, appoggiato dalla Provincia e dal Comune di To- 

rino, dal Touring, dall’ACI e da altri Enti pubblici e privati costituisce un Comitato 

avente lo scopo di promuovere lo studio di fattibilità dell’opera ed iniziarne la pro- 

gettazione preliminare. La reale costruzione iniziò però grazie al Senatore Agnelli 

e all’Ing. Cartesegna che costituirono la S.A. Autostrada TorinoMilano, ne diven- 

nero rispettivamente Presidente ed Amministratore Delegato/Direttore Generale e 

nel ’29 firmarono la convenzione per la costruzione e l’esercizio dell’opera. 

Figura 4.2: Gli inizi della Torino-Milano [45] 

Il Senatore Agnelli aveva infatti, tra i primi, intuito la necessità di una via 

di trasporto speciale per i veicoli a motore, anche e soprattutto come fattore di 

promozione commerciale dell’automobile. La costruzione durò meno di 3 an- 

ni e l’autostrada venne inaugurata nell’ottobre 1932. L’Autostrada attivava un 

nuovo ed importante collegamento tra Torino e Milano e, assieme alle autostra- 

de Bergamo-Milano, Brescia-Bergamo (già in esercizio) e Venezia-Padova (in 

costruzione) si inseriva nel disegno della progettata “strada automobilistica pe- 

dealpina Torino-Trieste”. La ferrovia costruita nell’800 non aveva, infatti, ancora 

creato un collegamento adeguato, diretto e veloce, tra le due città. 

Il traffico fu sempre consistente, sin dai primordi dell’esercizio, grazie anche 

169


alla politica tariffaria adottata dalla Società, che applicava tariffe di pedaggio re- 

lativamente basse; la media dei passaggi giornalieri raddoppiò nel breve volgere 

di sette anni. Il flusso veicolare è passato dai circa 700.000 passaggi/anno dei 

primi anni di vita dell’infrastruttura agli oltre 35.000.000 di oggi e l’infrastruttura 

è molto cambiata adattandosi alle esigenze che si modificavano. In particolare, 

nel 1953, in seguito ad un notevole incremento di traffico, la larghezza del piano 

viabile venne portata dagli 8 metri originali ai 10 metri e, nel 1962, oramai alle 

soglie della grande industrializzazione del Paese, l’autostrada venne raddoppiata. 

Figura 4.3: Le due corsie dell’autostrada [45] 

All’inizio degli anni Settanta, infine, si passò ad una configurazione a tre corsie 

per senso di marcia. L’autostrada è divisa in due tratte: una cosiddetta “a sistema 

aperto” ovvero dove il pedaggio viene corrisposto in una barriera e gli svincoli 

intermedi sono privi di stazione di esazione, ed una “a sistema chiuso” dove il 

pedaggio corrisposto dipende dalla percorrenza effettuata. In totale vi sono 4 

interconnessioni con altre autostrade, 6 svincoli senza stazione di esazione, 13 

stazioni di uscita con esazione e 2 barriere terminali. Interventi futuri prevedono, 

inoltre, il collegamento autostradale con il nuovo Polo Fieristico Milanese (in zona 

Pero) e il collegamento autostradale Carisio-Biella (18 km). [45] 

170


4.1.2 Il Tratto Milano-Brescia 

Dopo un percorso denominato tratto urbano della A4 in cui l’autostrada passa 

a Nord della città di Milano, attraversando le zone fortemente industrializzate di 

Cormano, Cinisello Balsamo e Sesto San Giovanni e dove, in molte ore della gior- 

nata, il traffico risulta quasi paralizzato, nella A4 confluisce, nei pressi di Agrate 

Brianza dove è situato il casello di Milano Est, il traffico in arrivo dall’autostra- 

da A1 attraverso la Tangenziale Est di Milano. Con un percorso di quasi 90 km 

l’autostrada si snoda completamente in territorio lombardo, presentando un per- 

corso completamente pianeggiante e rettilineo ad eccezione di una impegnativa 

curva in concomitanza con il casello autostradale di Bergamo. A Brescia viene 

intersecata l’autostrada A21, anch’essa originata a Torino, ma con un percorso più 

meridionale rispetto alla A4 attraverso Alessandria, Piacenza e Cremona. [52] 

Figura 4.4: Il tratto Milano-Brescia [53] 

In Figura 4.4 si può vedere il tratto Milano-Brescia così come appare su Au- 

toTraf. Nella Tabella 4.1, riportiamo invece le principali caratteristiche del tratto 

mutuate dal database interno. 

171


Tratta Codice Ent. Entrata Codice Usc. Uscita Lunghezza 

1 654 Milano Est 655 Tangenziale Milano 6.2 km 

2 655 Tangenziale Milano 653 Agrate 2.4 km 

3 653 Agrate 652 Cavenago 4.7 km 

4 652 Cavenago 651 Trezzo 9.0 km 

5 651 Trezzo 650 Capriate 2.6 km 

6 650 Capriate 649 Dalmine 7.6 km 

7 649 Dalmine 648 Bergamo 5.2 km 

8 648 Bergamo 647 Seriate 7.1 km 

9 647 Seriate 646 Grumello 9.1 km 

10 646 Grumello 645 Ponte Oglio 3.8 km 

11 645 Ponte Oglio 644 Palazzolo 2.7 km 

12 644 Palazzolo 643 Rovato 8.7 km 

13 643 Rovato 643 Ospitaletto 5.5 km 

14 642 Ospitaletto 641 Brescia Ovest 9.4 km 

Tabella 4.1: Le stazioni della Milano-Brescia 

Sempre in Figura 4.4 vediamo anche tutta la sensoristica distribuita lungo il 

percorso. I sensori sono sincronizzati attraverso il protocollo NTP (Network Time 

Protocol), per garantire l’assoluta precisione nella determinazione dell’istante di 

rilevamento del dato. 

Figura 4.5: Legenda di AutoTraf [53] 

172


In particolare, noi utilizziamo i dati provenienti da ingressi, uscite, spire e boe. 

Nei paragrafi seguenti illustreremo in che modo il database riflette le informazioni 

in arrivo dalla rete. 

Ingressi 

I dati provenienti dagli ingressi riguardano, tra le altre, le informazioni sull’ora di 

ingresso di ogni veicolo, sul numero del biglietto a cui essa è associata o al codice 

Telepass con il quale è entrata. In effetti, la sensoristica mette a disposizione altri 

dati che però non sono di interesse per questa trattazione. Questi dati vengono 

organizzati in quattro tabelle: TTPMA3 ENT, TTPMA3 ENT 1, TTPMA3 ENT 2 

e TTPMA3 ENT 3. Ciascuna di esse contiene i dati relativi ad un numero di giorni 

precedenti uguale all’ultimo numero del loro nome. Ad esempio, TTPMA3 ENT 2 

contiene i dati relativi agli ingressi di due giorni prima rispetto al momento del- 

l’interrogazione del database. In realtà, l’aggiornamento delle tabelle non avviene 

precisamente alla mezzanotte, ma ad un’ora variabile intorno alle 02:03:00 

AM. La struttura di queste tabelle è parzialmente simile alla seguente. 

Estratto 4.1 ◦ Codice Stazione Ingresso (C STZ) 

◦ Ora di Ingresso (D ENT) 

◦ Codice Biglietto (C APP) 

◦ Codice Apparato Telepass (C APP) 

◦ . . . 

Uscite 

I dati provenienti dalle uscite sono organizzati in un modo molto simile a quello 

con cui sono organizzati i dati provenienti dagli ingressi. L’articolazione in quattro 

tabelle viene utilizzata anche in questo caso e la radice della famiglia di queste 

tabelle è: TTPMA2 USC. Rispetto alla struttura precedente, viene aggiunto un 

campo molto importante che riporta la stazione da cui è entrato il veicolo di cui si 

173


sta rilevando l’uscita. Inoltre, viene anche riportata l’ora di ingresso del veicolo 

stesso. 

Estratto 4.2 ◦ Codice Stazione Uscita (C STZ) 

◦ Ora di Uscita (D MSG) 

◦ Codice Stazione Ingresso (C STZ ENT) 

◦ Ora di Ingresso (D MSG ENT) 

◦ Codice Biglietto (C APP) 


◦ . . . 

Purtroppo, lungo tutto il periodo del nostro lavoro, la stazione 655 non ha mai 

funzionato: il problema è relativo al mancato trasferimento dei dati sul database. 

Le uniche informazioni su questa stazione sono ottenibili dalle tabelle delle usci- 

te: infatti, gli utenti entrati alla stazione 655 ed usciti in una qualunque stazione 

del nostro tratto, vengono regolarmente rilevati grazie al campo di questa tabella 

contenente il codice della stazione di ingresso. 

Le piste Telepass accumulano i dati (messaggi) relativi all’entrata ed all’uscita 

di veicoli in files che sono inviati circa ogni 10’ ad un server centrale, via FTP. 

Il tempo che intercorre tra l’evento e l’invio del messaggio ad esso relativo, ren- 

de tuttavia inadeguato questo meccanismo di acquisizione per quanto riguarda il 

progetto AutoTraf. Per questo motivo, è stato modificato il software delle piste, at- 

tivando un flusso di acquisizione parallelo a quello tradizionale della fatturazione, 

che prevede l’invio del singolo messaggio al server centrale nel momento stesso 

in cui viene generato. Per ridurre al minimo l’overhead delle piste, si è scelto di 

utilizzare il protocollo UDP per l’invio dei dati, senza eseguire quindi alcun con- 

trollo sul recapito del messaggio. La perdita di una bassa percentuale di messaggi 

non è, stata valutata come limitativa per un’applicazione di tipo statistico come 

AutoTraf. [4] 

174


Sistemi PMT o Boe in Itinere 

I sistemi PMT, detti boe in itinere, utilizzano la tecnologia Telepass per rilevare il 

passaggio di veicoli dotati di apparato di bordo. Collocati in opportune posizioni 

sopra la sede autostradale, in prossimità di PMV (Pannelli a Messaggio Variabile) 

o di cavalcavia, inviano al sistema centrale un messaggio contenente il codice del 

sensore, il codice dell’apparato e l’istante in cui la rilevazione ha avuto luogo, 

utilizzando il protocollo UDP. Questi sistemi sono stati sviluppati a partire dalle 

piste Telepass ritagliandone le funzionalità e personalizzando i meccanismi di au- 

todiagnosi. [4] Le boe in itinere sono lo strumento di rilevazione più diffuso lungo 

la rete, ma, purtroppo, sono anche quello meno affidabile. Infatti, è molto difficile 

prevedere la percentuale di veicoli che le boe riusciranno a rilevare in rapporto al 

totale dei veicoli transitati. In pratica, queste boe sono gruppi di rilevamento tal- 

volta costituiti da una sola antenna, altri da due ed altri ancora da tre. Nel nostro 

tratto, le boe hanno tutte due antenne: tuttavia, non esiste una relazione precisa e 

sicura su quanti autoveicoli si perdano in funzione del numero di antenne. 

La struttura delle tabelle TTPMA1 BOE (anche esse replicate per conservare i dati 

dei giorni precedenti) è rappresentata in seguito. 

Estratto 4.3 ◦ Numero Progressivo della Boa (N PRG) 

Spire 


◦ Ora del Passaggio (D MSG) 

◦ . . . 

Le spire sono lo strumento di rilevazione più affidabile e completo sul quale si 

possa fare affidamento. Sono anche i sensori più costosi, dal momento che richie- 

dono una tecnologia avanzata, e sono di difficile installazione a causa della loro 

particolare locazione. Infatti, devono essere immerse nell’asfalto sotto il piano 

stradale. Nel tratto di nostra competenza sono installate tre spire: una lungo la 

175


tratta 6, una lungo la tratta 9 ed una poco dopo il casello di Brescia Ovest in 

direzione di Venezia. La tabella contenente i dati provenienti dalle spire è unica: 

questo significa che tutti i dati sono compresi in (TTPM66 DAT SPR), aggiornata 

con un periodo inferiore ai 4 giorni. Quindi, i dati provenienti dalle spire sono me- 

diamente più recenti di quelli provenienti dalle boe: volendo eseguire una analisi 

incrociata retrospettiva, bisogna assumere la tabella delle spire come riferimento 

postdatato per il tempo in corrispondenza del quale si possono ancora trovare in- 

formazioni. 

I dati delle spire, al contrario di quelli degli altri tre strumenti sopra illustrati, ven- 

gono aggregati lungo il tempo. Quindi, mentre le altre tabelle hanno una nuova 

riga per ogni mezzo rilevato, questa ha una riga che riassume i dati dell’ultimo 

intervallo di tempo. L’intervallo di tempo è variabile, ma per le spire del nostro 

tratto è sempre pari a 60 secondi. In pratica, ogni riga contiene la somma dei dati 

del minuto precedente. I campi rilevanti sono quelli elencati di seguito. 

Estratto 4.4 ◦ Codice della Centralina Contenente la Spira (C CEN) 

◦ Numero della Corsia (N CRS) 

◦ Ora del Messaggio (D MSG) 

◦ Somma dei Veicoli (N TOT VEI) 

◦ Velocità Media (VEL MED) 

◦ Deviazione Standard della Velocità (DEV STD VEL MED) 

◦ Gap Medio (GAP MED) 

◦ Deviazione Standard del Gap (DEV STD GAP MED) 

◦ Headway Medio (HDW MED) 

◦ Deviazione Standard dell’Headway (DEV STD HDW MED) 

◦ Densità (DEN) 

176


◦ . . . 

Le corsie sono numerate come in Figura 4.6 

Figura 4.6: Numerazione delle corsie 

Il gap è definito come la distanza media che intercorre tra la coda di un veicolo 

e la testa del veicolo seguente. L’headway è invece la distanza media tra due teste 

consecutive. In questa tabella, i vari dati calcolati come media possono essere 

anche valutati alla luce della loro deviazione standard. 

4.1.3 Quante Auto hanno il Telepass? 

Per i nostri programmi, serve una percentuale piuttosto precisa che reppresenti 

quante, delle auto che passano mediamente sotto una boa con due antenne, ven- 

gono rilevate. Come abbiamo già detto, le boe possono solo riconoscere le auto 

con il telepass, ma tendono a “perdere” anche alcune di queste. Abbiamo così 

calcolato il rapporto tra utenti con il telepass ed utenti totali ed abbiamo infine 

cercato di calcolare il rapporto tra utenti rilevati sotto una boa ed utenti totali. 

177


Percentuale di Telepass 

Per calcolare la percentuale di auto con il Telepass, possiamo confrontare i dati 

provenienti dagli ingressi del nostro tratto e valutare su quante di esse è montato 

il Telepass. Per ottenere il totale delle auto entrate in ciascuna delle stazioni di 

nostro interesse possiamo eseguire la query 4.5. 

Estratto 4.5 

SELECT C STZ COUNT(D MSG) 

FROM TTPMA3 ENT 

WHERE D MSG BETWEEN 

TO DATE( ’ 08−11−2005 7 : 3 0 : 0 0 ’ , 

’DD−MM−YYYY hh24 : mi : s s ’ ) 

AND TO DATE( ’ 08−11−2005 1 3 : 0 0 : 0 0 ’ , 


AND C STZ>=641 AND C STZ=641 AND C STZ


Codice Stazione Totale Entrate 

641 6542 

642 3827 

643 3609 

644 3250 

645 1760 

646 3032 

647 4470 

648 9831 

649 3822 

650 5885 

651 4443 

652 4009 

653 6428 

654 15986 

656 4514 

Totale 81408 

Tabella 4.2: Il totale delle entrate per ogni stazione in un intervallo di quattro ore 

e mezza 

AND ( C APP’ 00000000 ’ 

AND C APP NOT LIKE ’F%’ 

AND C RET=1) 

GROUP BY( C STZ )} 

Otteniamo il risultato di Tabella 4.3. 

Il rapporto 53875/81408 rende un risultato pari a 0.66. 

Abbiamo anche seguito lo stesso procedimento estendendo il periodo di osserva- 

zione ad una giornata intera. Come prevedibile, il rapporto è leggermente sceso, 

attestandosi a 0.63. 

179


Codice Stazione Totale Entrate 

641 4396 

642 2713 

643 2404 

644 2196 

645 1164 

646 2095 

647 3061 

648 6273 

649 2499 

650 3877 

651 3040 

652 2633 

653 3932 

654 10338 

656 3164 

Totale 53785 

Tabella 4.3: Il totale delle entrate per ogni stazione, considerando i soli utenti 

muniti di telepass, nello stesso intervallo di tempo della Tabella 4.2 

180


Percentuale di Veicoli Recepiti da una Boa 

Secondo quanto già espresso, ci aspettiamo di trovare un coefficiente inferiore a 

quello trovato in precedenza. Per ottenere una stima attendibile di questo fattore, 

abbiamo sviluppato una analisi che sfrutta dati provenienti da vari strumenti di 

rilevazione. 

Consideriamo la situazione di Figura 4.7. 

Figura 4.7: Posizionamento della spira 24 

Anche in questo caso abbiamo un periodo di osservazione di quattro ore e 

mezza. Cerchiamo di trovare il numero di veicoli transitati sopra la spira 24 

(centralina 267). 

Estratto 4.7 

SELECT SUM( N TOT VEI ) 

FROM VTPM66 DAT SPR 

WHERE D ORA BETWEEN 

TO DATE( ’ 08−11−2005 7 : 3 0 : 0 0 ’ , 


AND TO DATE( ’ 08−11−2005 1 3 : 0 0 : 0 0 ’ , 


AND C CEN=267 AND N CRS>=1 AND N CRS


Il risultato è NTOT = 18393. 

Contiamo quindi quante auto transitano sotto la boa 26 nello stesso intervallo di 

tempo. 

Estratto 4.8 

SELECT COUNT( ∗ ) 

FROM TTPMA1 BOE 


TO DATE( ’ 08−11−2005 7 : 3 0 : 0 0 ’ , 


AND TO DATE( ’ 08−11−2005 1 3 : 0 0 : 0 0 ’ , 

AND N PRGA=26 

Il risultato è NBOE = 9039. 


Contiamo anche quante macchine sono uscite alla stazione 646. Le auto che sono 

uscite nella direzione che ci interessa sono tutte quelle che sono entrate in una 

delle entrate a monte della 646 (entrate comprese tra 647 e 656). Si noti come, in 

questa query, si dovrebbe usare un riferimento temporale leggermente diverso (i 

due estremi andrebbero leggermente aumentati). Infatti, se un’auto fosse passata 

sopra la spira alle 7:00, non sarebbe potuta uscire se non dopo un tempo pari 

a quello di percorrenza della distanza tra la spira e l’uscita. In questo caso si 

assume che il flusso rimanga costante per qualche minuto intorno alle 7:00 ed alle 

13:00. 

Estratto 4.9 

SELECT COUNT( ∗ ) 

FROM TTPMA2 USC 


TO DATE( ’ 08−11−2005 7 : 3 0 : 0 0 ’ , 


AND TO DATE( ’ 08−11−2005 1 3 : 0 0 : 0 0 ’ , 

182



AND C STZ=646 AND C STZ ENT>646 AND C STZ ENT


• Andiamo a cercare il codice telepass tra le uscite delle nostre stazioni. 

• Se lo troviamo, allora conosciamo il percorso fatto. 

• Se non lo troviamo, allora non possiamo che concludere che sia uscito dalla 

spira di Brescia. 

Evidentemente, il caso della stazione 654 (la prima stazione del tratto) è piuttosto 

semplice: chi entra da quella stazione non può che andare in direzione di Brescia. 

Tuttavia, vige un sistema di gestione dei dati particolare e non intuitivo. Per il- 

lustrarlo, dobbiamo spiegare la configurazione dei tratti autostradali e non della 

periferia di Milano. Le auto che escono alla barriera di Milano Est, si immettono 

in un tratto autostradale a sistema aperto e che mette a disposizione alcune usci- 

te (come, ad esempio, Milano Viale Zara) che non hanno un relativo casello di 

esazione. Questo tratto può però condurre ad un’altra barriera, quella di Milano 

Nord, da dove inizia nuovamente un tratto autostradale soggetto a tariffa fissa. 

Se un mezzo entra nel nostro tratto, esce dalla barriera di Milano Est e rientra 

dalla barriera di Milano Nord, la combinazione di uscita ed entrata viene elimi- 

nata dal database e si conserva solo il dato sull’entrata originale a cui si aggiunge 

successivamente quello sull’uscita. Questo comportamento è stato desunto da os- 

servazioni sperimentali che abbiamo fatto sul database. Le uscite effettivamente 

assegnate a Milano Est sono quelle delle auto che escono in uno degli svincoli 

“liberi” presenti tra le due barriere. 

Questo problema rende inutilizzabili i dati provenienti dall’uscita di Milano Est. 

Infatti, a noi interessano tutti i veicoli transitati dalla barriera, a prescindere dalla 

loro destinazione finale. Fortunatamente, come si può vedere in Figura 4.8, subito 

dopo Milano Est, è posizionata una boa, (la 231). 

184


Figura 4.8: La situazione alla barriera di Milano Est 

Tutte le auto in uscita da Milano Est, devono transitare sotto lo boa 231. Ab- 

biamo visto però che la boa non recepisce tutti i telepass in transito sotto le sue 

antenne. In questo caso, abbiamo supposto che questo errore fosse trascurabi- 

le e non abbiamo introdotto un coefficiente correttivo desumibile da quelli del- 

la Sottosezione precedente (anche perché si può ragionevolmente pensare che le 

boe “perdano” passaggi in modo indipendente dalla stazione di provenienza dei 

veicoli). 

resse. 

Vediamo adesso le queries che ci consentono di trovare i dati di nostro inte- 

Estratto 4.10 

SELECT DISTINCT ENTRATE . C STZ , 

USCITE . C STZ , COUNT(ENTRATE . C APP ) 

FROM TTPMA3 ENT 1 ENTRATE, TTPMA2 USC 1 USCITE 

WHERE ENTRATE . C APP’ 00000000 ’ 

AND ENTRATE . C RET=1 

AND ENTRATE . C RET NOT LIKE ’F%’ 

AND USCITE . C APP’ 00000000 ’ 

AND USCITE . C RET=1 

AND USCITE . C RET NOT LIKE ’F%’ 

185


AND ENTRATE . D ENT=USCITE . D ENT 

AND ENTRATE . C STZ=USCITE . C STZ ENT 

AND ENTRATE . C APP=USCITE . C APP 

AND ENTRATE . D ENT 

BETWEEN TO DATE( ’ 09−11−2005 4 : 0 0 : 0 0 ’ , 


AND TO DATE( ’ 09−11−2005 2 0 : 0 0 : 0 0 ’ , 


AND ENTRATE . C STZ>=641 

AND ENTRATE . C STZ=641 

AND USCITE . C STZ



AND TO DATE( ’ 09−11−2005 2 0 : 0 0 : 0 0 ’ , 



AND ENTRATE . C STZ


TO DATE( ’ 09−11−2005 4 : 0 0 : 0 0 ’ , 


AND TO DATE( ’ 09−11−2005 2 0 : 0 0 : 0 0 ’ , 



AND ENTRATE . C STZ=641 

AND ENTRATE . C STZ


Arrivati a questo punto, dobbiamo studiare un metodo alternativo per stimare 

le entrate e le uscite della stazione 655 in grado di sopperire alla mancanza di 

dati (ricordiamo che questa stazione non trasmette i dati di ingresso al database a 

causa di un non megli precisato malfunzionamento). Per le entrate, non possiamo 

che affidarci ad un metodo statistico, mentre per le uscite possiamo interrogare 

il database sulle uscite registrate in corrispondenza del casello di entrata numero 

655. 

Estratto 4.14 

SELECT USCITE . C STZ , COUNT( USCITE . C APP ) 

FROM TTPMA2 USC 1 USCITE 

WHERE USCITE . C APP’ 00000000 ’ AND USCITE . C RET=1 

AND USCITE . C APP NOT LIKE ’F%’ 

AND USCITE . D ENT BETWEEN 

TO DATE( ’ 09−11−2005 4 : 0 0 : 0 0 ’ , 


AND TO DATE( ’ 09−11−2005 2 0 : 0 0 : 0 0 ’ , 


AND USCITE . C STZ ENT=655 

GROUP BY( USCITE . C STZ ENT , USCITE . C STZ ) 

ORDER BY USCITE . C STZ ASC 

La query 4.14 cerca il numero di auto che sono entrate alla 655 utilizzando le 

informazioni presenti sulla tabella delle uscite ma relative alle entrate. 

189


190

Capitolo 5 

Applicazione del Modello 

Figura 5.1: Los Angeles Traffic [59] 

191

5.1. IL SOFTWARE Carlo Caligaris, Iacopo Salvarani 

5.1 Il Software 

Per raggiungere l’obiettivo preposto, abbiamo costruito un software in grado di 

interagire in lettura ed in scrittura con il database autostradale al fine di costruire 

una interfaccia user-friendly tramite la quale visualizzare i risultati prodotti dal- 

l’elaborazione dei nostri dati. Il software si divide in due programmi principali: 

quello di simulazione e quello di controllo. 

Il programma di simulazione è il programma principale: è quello che produce 

le previsioni per velocità, densità e flusso ed ha la possibilità di scrivere questi 

risultati sul database. Il programma di controllo, invece, fornisce la possibilità 

di controllare i risultati previsti confrontandole con i risultati reali, una volta che 

questi sono disponibili. Il programma di simulazione è stato sviluppato sia per la 

direzione Milano-Brescia che per la direzione opposta. Il programma di controllo, 

date le sue grandi difficoltà realizzative, è solo relativo alla direzione Milano- 

Brescia. 

192

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale CAPITOLO 5. APPLICAZIONE DEL MODELLO 

5.2 Il Simulatore 

Il simulatore, dal punto di vista matematico, è costituito da un set di equazioni 

differenziali discretizzate nel tempo e quindi definibili come equazioni alle diffe- 

renze finite. Nella pratica, si assegna a tutte le tratte un insieme di valori iniziali 

che ne descrivono lo stato; i parametri che descrivono la situazione generale sulla 

tratta sono: velocità media, densità, flusso dei veicoli lungo la tratta. Una volta 

fatto ciò, il simulatore calcola i valori previsti relativi a queste quantità avanzando 

di un periodo di simulazione alla volta. Ad ogni iterazione i parametri di ciascun 

tratto vengono ricalcolati in base a: 

• i valori dei parametri sulla tratta stessa all’istante precedente; 

• i valori dei parametri all’istante precedente per le tratte che influenzano 

quella su cui il simulatore sta ricalcolando; in termini più semplici la prece- 

dente e la successiva. 

Dopo essere stato inizializzato, il simulatore calcola l’evolvere del sistema fino 

alla condizione di regime nell’ipotesi che le condizioni al contorno rimangano 

costanti. L’affidabilità dei risultati cala con le iterazioni in quanto le condizioni al 

contorno del caso reale variano continuamente. 

Rivediamo adesso le equazioni utilizzate, già introdotte precedentemente, ma 

riscritte in termini di linguaggio di programmazione. Per quanto riguarda le gran- 

dezze utilizzate nei programmi, abbiamo definito una notazione spazio-temporale 

per decidere i loro nomi senza incappare in fastidiose ambiguità: quando utilizzia- 

mo i suffissi prima e dopo, ci riferiamo al tempo, mentre quando usiamo seguente 

e precedente, ci riferiamo allo spazio. 

Con questa distinzione ben presente, abbiamo definito una serie di variabili. 

Definizione 5.1 • dendop � Densità lungo la tratta in analisi prevista per 

l’istante di tempo successivo. 

• denpri � Densità lungo la tratta in analisi relativa all’istante di tempo 

precedente quello per cui si stanno eseguendo le previsioni. 

193

5.2. IL SIMULATORE Carlo Caligaris, Iacopo Salvarani 

• veldop � Velocità lungo la tratta in analisi prevista per l’istante di tempo 

successivo. 

• velpri � Velocità lungo la tratta in analisi relativa all’istante di tempo 

prima di quello per cui si stanno eseguendo le previsioni. 

• velpripre � Velocità lungo la tratta precedente quella in analisi relati- 

va all’istante di tempo precedente quello per cui si stanno eseguendo le 

previsioni. 

• periodo � Periodo di simulazione (assunto pari ad un minuto). 

• indice = [0, 13] � Indice necessario per scorrere i vettori. 

• δ[indice] � Vettore contenente le lunghezze delle tratte (identificate 

dall’indice). 

• flupripre � Flusso lungo la tratta precedente quella in analisi e relati- 

vo all’instante di tempo prima di quello per cui si stanno eseguendo le 

previsioni. 

• flupri � Flusso lungo la tratta in analisi e relativo all’instante di tempo 

prima di quello per cui si stanno eseguendo le previsioni. 

• ingpri � Flusso in ingresso relativo alla tratta in esame e valutato per l’i- 

stante di tempo prima di a quello per cui si stanno eseguendo le previsioni. 

• uscpri � Flusso in uscita relativo alla tratta in esame e valutato per l’i- 

stante di tempo prima di quello per cui si stanno eseguendo le previsioni. 

• funzionev � Equazione fondamentale di Papageorgiou. Viene discussa 

approfonditamente in 5.2.3. 

• τ[indice] � Parametro dell’equazione della velocità. È variabile per ogni 

tratta. 

• χ[indice] � Parametro dell’equazione della velocità. È variabile per ogni 

tratta. 

194


• ν[indice] � Parametro dell’equazione della velocità. È variabile per ogni 

tratta. 

• l[indice] � Parametro dell’equazione fondamentale di Papageorgiou. È 

variabile per ogni tratta. 

• m[indice] � Parametro dell’equazione fondamentale di Papageorgiou. È 

variabile per ogni tratta. 

• vmax[indice] � Parametro relativo alla tratta e rappresentativo della ve- 

locità massima sostenibile in quella tratta. 

• ρmax[indice] � Parametro relativo alla tratta e rappresentativo della den- 

sità massima sostenibile in quella tratta. 

5.2.1 Equazione della Densità 

Parliamo ora dell’equazione della densità (misurata in [veicoli] · [km] −1 ): 

� � 

periodo 

dendop = denpri + 

∗(flupripre −flupri +ingpri −uscpri). (5.1) 

δ[indice] 

Questa equazione mostra come la densità per un istante di simulazione sia 

supposta uguale alla densità come era all’istante precedente corretta dall’effetto 

dei flussi sulle tratte contigue (la precedente e la seguente). 

Per ogni tratta, vi è una grandezza, che possiamo chiamare flusso incrementale, e 

che quantifica l’aumento del numero di auto nella tratta per ogni istante di tem- 

po. Tale flusso è dato da: il flusso in entrata nella tratta (proveniente dalla tratta 

precedente) sommato a quello in ingresso dal casello ed a cui bisogna sottrarre il 

flusso in moto verso la tratta successiva ed il flusso in uscita dal casello. 

195


Flusso entrante Flusso Uscente 

Flusso Ingressi Flusso Uscite 

Figura 5.2: Flusso lungo una tratta 

Gli ingressi e le uscite dei caselli per ogni tratta sono note (a parte per la sta- 

zione 655, di cui abbiamo già parlato in precedenza) e vengono inizializzate per 

poi rimanere costanti lungo tutta la durata della simulazione. Ciò introduce un 

errore, dal momento che ogni volta si hanno valori variabili. Questo è un esem- 

pio di condizioni al contorno dinamiche che introducono un errore continuo nella 

simulazione rendendo maggiore l’imprecisione con l’avanzare della simulazione. 

Con riferimento alla Figura 5.3 possiamo vedere come il flusso in entrata nella 

tratta sia dato dal flusso nella tratta precedente diminuito dall’uscita della tratta 

precedente (flusso rosso - flusso verde) 

Figura 5.3: Flusso a cavallo di due tratte 

Il flusso in uscita dalla tratta è dato invece dal flusso sulla tratta successiva 

196


diminuito dell’ingresso sulla tratta successiva (flusso blu = flusso nero - flusso 

giallo). 

Tutti gli elementi del fattore correttivo sono calcolati in numero di vetture per 

ora, quindi il fattore viene moltiplicato per il periodo misurato in ore (il nostro 

periodo è di un minuto, quindi 0, 01667ore) e si ottiene così il numero di veicoli 

in aumento o in diminuzione sulla tratta nel periodo appena trascorso. Tale nu- 

mero di veicoli viene diviso per la lunghezza della tratta ottenendo una densità 

incrementale da sommare a quella dell’iterazione precedente per ottenere il valore 

attuale. 

5.2.2 Equazione della Velocità 

L’equazione della velocità si scrive come di seguito. 

veldop = 

= velpri+ 

+ periodo 

τ[indice] · (funzionev(indice, denpri) − velpri)+ 

+ periodo 

δ[indice] · velpri · (velpripre − velpri)− 

+ (ν[indice] · periodo · (denpriseg − denpri)) 

((τ[indice] · δ[indice]) · (denpri + χ[indice])) 

(5.2) 

Su una tratta, la velocità calcolata per una iterazione è uguale alla velocità pre- 

cedente, variata da 3 parametri additivi moltiplicati per coefficienti che riportano 

le grandezze alla dimensione della velocità ([km][h] −1 ). 

Il primo termine contiene funzionev(indice, denpri)−velpri: esso fornisce 

un’indicazione su quanto può variare la velocità rispetto al suo valore precedente, 

facendo riferimento all’equazione fondamentale di Papageorgiou (5.2.3). 

Il secondo termine è velpripre −velpri e fornisce un’indicazione su quanto può 

variare la velocità sulla tratta considerata a causa della velocità sulla tratta prece- 

197


dente; se sulla tratta precedente la velocità è in decremento, a parità di densità, 

evidentemente diminuirà anche sulla tratta successiva. 

L’ultimo termine, denpriseg − denpri fornisce un’informazione su come evol- 

ve la velocità in rapporto alla diversa densità della tratta successiva. Se sulla tratta 

successiva il traffico è congestionato (e quindi la densità è molto elevata) l’effetto 

si ripercuote all’indietro come un rallentamento. Il comportamento è duale in ca- 

so di situazione opposta: in pratica si ottiene uno snellimento del traffico. Questi 

fenomeni di propagazione a ritroso prendono il nome di back-waves e ci ricon- 

ducono al collegamento del modello di traffico con quello di propagazione delle 

onde in un un fluido. 

5.2.3 Equazione Fondamentale di Papageorgiou 

Abbiamo già spiegato come il nostro riferimento teorico sia stato il lavoro dell’ing. 

Papageorgiou; uno dei suoi contributi più significativi è stato quello di determi- 

nare un’equazione, derivata da prove sperimentali, in grado di indicare la velocità 

media tenuta dalle vetture in funzione della loro densità su una tratta stradale. 

L’equazione di cui stiamo parlando è quella a cui ci siamo riferiti fino a questo 

momento come equazione fondamentale di Papageorgiou e si può scrivere nella 

forma seguente. 

⎛� 

vel = vmax[indice] · ⎝ 

1 − 

l[indice] 

denpri 

ρmax[indice] 

�m[indice] ⎞ 

⎠ ; (5.3) 

Il significato fisico di tale formula è molto chiaro: la velocità media che le 

vetture tengono è uguale alla velocità massima tipica della tratta stradale (vmax) 

opportunamente diminuita di un fattore che dipende dal rapporto� fra la densità � che 

denpri 

si è effettivamente riscontrata e la densità di congestionamento . 

ρmax 

Gli esponenti l ed m si ottengono sperimentalmente e sono diversi per ogni trat- 

ta stradale e dipendono anche dalle condizioni al contorno. Lo stesso dicasi per 

i parametri della tratta vmax e ρmax; questi valori però possono almeno inizial- 

mente essere ipotizzati in base a semplici considerazioni fisiche sul tratto stradale 

198


preso in esame (ad esempio vmax può essere il limite di velocità e ρmax metà 

del limite teorico della densità, corrispondente alla situazione in cui le auto sono 

letteralmente a contatto una con l’altra). 

5.2.4 Funzionamento del Programma 

Il programma è stato costruito come una catena di metodi che vengono richiamati 

in serie. Per spiegare il funzionamento del programma, analizzeremo uno per uno 

i metodi, nell’ordine con cui sono invocati. 

Inizialmente, l’utente deve scegliere se effettuare una simulazione singola o 

una serie di simulazioni. Nel primo caso, il programma esegue una simulazione 

istantaneamente, mentre nel secondo caso esegue una serie di simulazioni a partire 

da un’ora definita internamente al codice e fino ad un’altra ora sempre definita nel 

codice. Per illustrare il funzionamento del simulatore, ci riferiremo al caso di una 

simulazione singola. 

L’utente può inoltre scegliere se scrivere i dati così calcolati sul database o se 

memorizzarli semplicemente in strutture interne al computer locale (files XML). 

Esistono quattro classi per questo programma: 

• C1, che costituisce la classe principale del programma e che gestisce le 

opzioni inizialmente offerte all’utente; 

• XMLWorks, che contiene i metodi che ci consentono di trasferire i dati 

calcolati dal software su files XML memorizzati su disco; 

• Queries, che contiene i metodi relativi alle interazioni con il database 

realizzate tramite i principi del JDBC. 

• Funzioni, che raccoglie alcune funzioni matematiche esternalizzate per 

rendere più leggibile il programma. 

La Figura 5.4 mostra la sequenza logica del programma. 

199


Definizioni 

Ridimensionamento dei vettori 

Inizializzazione dei vettori 

Cancellazione i files XML già esistenti 

Inizializzazione dei parametri 

Inizializzazione degli ingressi sulle tratte 

Inizializzazione delle uscite sulle tratte 

Inizializzazione delle velocità iniziali sulle tratte 

Inizializzazione dei flussi iniziali sulle tratte 

Inizializzazione delle densità iniziali sulle tratte 

Simulazione - Calcolo delle equazioni 

Scrittura dei files XML 

Cancellazione delle simulazioni sul database più vecchie di tre giorni 

Se l’utente ha scelto di scrivere i risultati sul database 

Scrittura sul database dei risultati della simulazione 

Se l’utente ha scelto di effettuare una simulazione multipla 

Esecuzione del processo di simulazione dal primo punto 

Figura 5.4: Sequenza logica del programma di simulazione 

Illustriamo di seguito i singoli metodi. 

200


5.2.5 Definizioni 

Questo non è un vero e proprio metodo, bensì una parte introduttiva di codice 

contenente tutte le definizioni di cui il nostro programma ha bisogno. Ad esempio, 

definiamo le strutture dati corrispondenti alle grandezze definite in 5.1 

5.2.6 Ridimensionamento dei Vettori 

Un elemento tipico di Java è la separazione tra la definizione di un vettore ed il 

suo dimensionamento. Tutte le grandezze dipendenti dalla tratta o dal tempo (o 

da entrambi) sono rappresentate in linguaggio di programmazione da vettori. La 

dimensione relativa alle tratte è pari al numero di tratte (cioè 14) mentre la dimen- 

sione relativa al tempo è pari all’istante iniziale più i 30 minuti di simulazione (per 

un totale di 31 elementi). Abbiamo anche dati provenienti dalle boe che necessi- 

tano di essere organizzati in vettori con tanti elementi quante sono le boe presenti 

sul nostro tratto. In direzione di Brescia, ad esempio, abbiamo 11 boe. Discorso 

analogo per le spire (3) e per le stazioni (16). 

5.2.7 Inizializzazione dei Vettori 

I vettori sono stati prima definiti e poi ridimensionati. In questo metodo inizia- 

lizziamo tutti i vettori i cui valori rimangono invariati durante la simulazione; 

questi sono i vettori relativi ai parametri fisici dell’autostrada: δ (lunghezza delle 

tratte autostradali) ρmax, vmax, l, m (parametri dell’equazione fondamentale di 

Papageorgiou). Si capisce come questi valori, variabili rispetto alla tratta, sono 

comunque essenzialmente indipendenti dal tempo. 

5.2.8 Cancellazione dei Files XML 

Abbiamo già accennato al fatto che i dati calcolati sono memorizzati in files 

XML. Questi files sono tanti quante sono le tratte in analisi e si chiamano da 

Grafico1.xml fino a Grafico14.xml. Ciascuno contiene i dati relativi 

201


a velocità, densità e flusso per ogni minuto di simulazione. Nell’Estratto 5.1 

vediamo un esempio di questi files XML. 

Estratto 5.1 

 

 

 

 

 

 

 

. . . . 

 

 

Questi files XML devono essere riaggiornati ad ogni lancio del simulatore. In 

pratica, noi li cancelliamo prima per poi riscriverli. 

5.2.9 Inizializzazione dei Parametri 

Le grandezze che intervengono nella simulazione devono essere inizializzate con 

valori coerenti, importantissimi per la riuscita della simulazione. τ fornisce un’in- 

dicazione di quanto rapidamente la velocità si assesta sul valore teorico ricavato 

dall’equazione fondamentale di Papageorgiou (in pratica va ad agire aumentando 

o diminuendo il secondo termine nell’equazione della velocità). ν e χ intervengo- 

no sul terzo termine dell’equazione della velocità (quella relativa alla back-wave 

di densità); in particolare, ν indica quanto rapidamente la velocità varia a causa 

dell’effetto della densità differente sulla tratta successiva, invece χ è un livello 

minimo teorico di densità e fornisce un limite superiore al terzo termine. Se la 

densità sulla tratta tendesse a zero, e χ non ci fosse, la velocità incrementale del 

terzo termine tenderebbe all’infinito, in quanto a denominatore compare proprio 

la densità sulla tratta. I valori di questi parametri sono stati stimati tramite un’a- 

202


nalisi statistica: abbiamo trovato i valori per i quali la curva densità-flusso rilevata 

sulla rete è minimamente differente da quella determinata analiticamente. 

5.2.10 Inizializzazione degli Ingressi 

Gli ingressi e le uscite lungo la tratta vanno inizializzati con dati che rivestono 

una grande importanza, dal momento che gli ingressi alle varie stazioni condizio- 

nano direttamente la densità sulle tratte e quindi indirettamente la velocità media 

dei veicoli. Tale parametro viene passato al simulatore tramite l’uso della JDBC 

illustrato in 5.2.14. Al primo giro di simulazione vengono inseriti gli ingressi ef- 

fettivamente rilevati alle stazioni estratti direttamente dai dati della base. Dalla 

seconda iterazione in poi il simulatore agisce sul futuro e non è possibile avere 

informazioni esatte sugli ingressi. La prima versione del programma imposta gli 

ingressi ad un valore costante lungo l’intero arco di simulazione. Questo valore 

è calcolato come media dei valori recepiti nei cinque minuti precedenti. Natu- 

ralmente, si introduce un errore non indifferente in questo modo: abbiamo già 

studiato un modo per risolvere questo problema, ma non lo abbiamo ancora reso 

operativa la modifica. 

Un altro possibile problema, molto critico per la simulazione, (che poi in effetti 

abbiamo dovuto affrontare a causa della stazione 655) è il caso in cui una stazione 

non invii segnali al database per qualche particolare malfunzionamento. Questo 

fatto potrebbe essere confuso, per esempio, con una situazione di traffico effet- 

tivamente molto ridotto (ad esempio nelle ore notturne) o dall’effettiva chiusura 

della stazione di ingresso (per incidente o per una qualunque causa esterna). Si è 

scelto per ora di considerare un ingresso che viene inizializzato a zero come un 

errore; pertanto un controllo fa in modo che gli ingressi nulli vengano rimpiaz- 

zati con un valore correttivo posto pari alla media fra gli ingressi di tutte le altre 

stazioni di nostra competenza. Con un ciclo di controllo sul vettore degli ingressi 

i valori nulli vengono aggiornati con la media fra tutti i valori non nulli. È da 

considerare il fatto che, se i valori nulli iniziano ad essere preponderanti, la stima 

data dalla media sarà molto poco accurata; se tutti i valori fossero nulli tranne 

uno verrebbero tutti posti uguali a quel valore e se fossero tutti nulli, resterebbe- 

203


ro tali. In questa maniera il valore correttivo diventa una stima, e tiene conto di 

eventuali trend giornalieri e stagionali (che si possono presumere abbastanza coe- 

renti per tutte le stazioni); purtroppo non tiene in alcuna considerazione la diversa 

importanza delle stazioni: appare evidente che in qualsiasi momento saranno in 

maggior numero gli ingressi dalla barriera di Milano o dalla stazione di Brescia 

Ovest piuttosto che quelli da Grumello o Ponte Oglio. 

Inoltre, anche essendo noto il numero di veicoli in ingresso alle varie stazioni, una 

volta che essi hanno superato il casello, non è possibile sapere con esattezza in 

quale delle due direzioni (Brescia o Milano) si siano diretti. Per risolvere que- 

sto abbiamo utilizzato la matrice origine-destinazione (4.1.4) e ne abbiamo tratto 

(tramite considerazioni statistiche) un coefficiente correttivo che indica in media 

quale porzione dei veicoli in ingresso si dirige verso Brescia piuttosto che verso 

Milano. 

5.2.11 Inizializzazione delle Uscite 

Questo metodo inizializza i valori delle uscite per le varie stazioni lungo la trat- 

ta. Così come per gli ingressi, questo è un dato molto importante poiché anche 

in questo caso vi è dipendenza con la densità sulle tratte e con la velocità media 

dei veicoli. I problemi sono esattamente gli stessi già visti per il caso degli in- 

gressi. Pertanto, per ogni stazione, il valore iniziale è impostato come la media 

delle uscite nei 5 minuti precedenti. Tutti i valori delle uscite nelle iterazioni suc- 

cessive di simulazione vengono posti pari al valore iniziale e viene effettuato un 

controllo per correggere eventuali valori nulli e sostituirli con la media dei valori 

non nulli. L’unico problema che non si pone è quello della non determinazione 

della direzione; infatti per i dati in uscita, si può conoscere la stazione di ingresso 

e, quindi, limitare i dati delle uscite ai soli veicoli che hanno percorso l’autostrada 

nella direzione Milano-Brescia. 

204


5.2.12 Inizializzazione di Velocità, Flussi e Densità 

Velocità, densità e flussi medi dei veicoli sulle tratte sono le variabili di stato e 

sono la risposta che il simulatore offre per stimare lo stato del traffico nel futuro. 

Il simulatore potrebbe elaborare una probabile situazione di regime del traffico 

anche partendo da variabili di stato inizializzate casualmente, in quanto le variabili 

di stato sono quelle che vanno ad essere modificate e ad interagire fra loro ad 

ogni iterazione di simulazione. Chiaramente, questa non è la soluzione migliore: 

innanzitutto, seppur abbastanza raramente, potrebbero esserci delle discontinuità 

di funzionamento del modello matematico a seconda delle differenti condizioni 

iniziali e quindi potrebbe accadere che con valori iniziali non reali si giunga ad 

una soluzione finale molto errata. Se i valori iniziali delle variabili di stato, che 

sono proprio quelle che costituiscono l’informazione sulla situazione in cui si 

trova il traffico veicolare, fossero esatti dal principio, potremmo supporre che il 

modello descriva in maniera corretta l’andamento del traffico fin da subito. Quindi 

è possibile non solo fornire un’informazione su come andrà a regime lo stato del 

traffico, ma si può anche dire con buona precisione fra quanto tempo raggiungerà 

questa situazione di regime e ancor più sarà possibile indicare il comportamento 

del traffico nel transitorio. I risultati sono ottimi a due condizioni: i) che il modello 

rappresenti la realtà in maniera adeguata e che quindi il simulatore si comporti in 

maniera analoga al traffico reale, e questo dipende soprattutto dall’esattezza dei 

parametri delle tratte (ρmax, vmax, l, m per tutte e 14 le tratte) e del simulatore (τ, 

χ, ν); ii) che i dati degli ingressi e delle uscite nelle varie iterazioni di simulazione 

siano il più precisi possibile. 

Questo purtroppo trova difficoltà nei motivi illustrati in precedenza. 

Inizializzazione delle Velocità Iniziali 

Dal database estraiamo i valori delle stime attuali delle velocità, che vengono uti- 

lizzate per il software interno di AutoTraf. Abbiamo notato che i valori presenti 

sul database e quelli esposti dalla pagina web di AutoTraf sono sempre differenti; 

precisamente i valori resi dalla pagina web di AutoTraf sono sempre lievemente 

inferiori rispetto a quelli presenti sul database. Probabilmente, chi ha elaborato 

205


AutoTraf, ha rilevato che le stime (che sono effettuate sfruttando i tempi di per- 

correnza fra casello e casello o fra boa e boa oppure fra boa e casello o casello e 

boa e mediandoli con diversi pesi) sono superiori ai valori realmente verificati ed 

ha pensato di diminuire con un opportuno coefficiente le proprie stime. Fidandoci 

di tale approccio, e quindi dei dati di AutoTraf, le velocità estrapolate dal databa- 

se verranno ridotte nell’inizializzazione di un opportuno coefficiente (si è scelto 

quello che minimizza l’errore per alcun dati presenti sulla base di dati ed i loro 

corrispettivi su AutoTraf) stimato a 0.886. Con questa correzione, i valori con cui 

inizializziamo le velocità all’inizio della simulazione, sono gli stessi che compa- 

iono su AutoTraf. Sui valori estratti dal database viene eseguito un controllo in 

caso di valore nullo. Se la velocità stimata fra due stazioni contigue è nulla, il va- 

lore di tale velocità viene stimato come la media delle velocità assegnate alle altre 

tratte. Questa stima è chiaramente poco precisa ed affidabile (la velocità media 

può cambiare molto da tratta a tratta) ma non avendo nessun’altra informazione 

utilizzabile abbiamo ritenuto conveniente porre un valore coerente con quelli delle 

altre tratte. 

In questa parte di codice inizializziamo anche il parametro v00, ovvero la velocità 

alla barriera di Milano. Inizialmente avevamo scelto v00 = 0: le auto in teoria 

partono da ferme in uscita dalla barriera di Milano; tale scelta si è rivelata sba- 

gliata dal momento che rischia di rallentare la velocità simulata nella prima tratta 

a causa del secondo termine dell’equazione delle velocità. Ciò accade soprattutto 

se il valore di τ è abbastanza elevato (con τ = 0.02, come è stato inserito, l’effetto 

del rallentamento non si percepisce più). Infine, viene impostato il vettore v14, 

ovvero la velocità sulla tratta successiva all’ultima di nostra competenza in dire- 

zione Milano-Brescia. Esso viene estratto dal database come la velocità media 

recepita dalla spira 74 presente proprio su quella tratta. Questo valore di velocità 

viene poi mantenuto costante per tutte le rimanenti iterazioni di simulazione. Il 

metodo di stima, con i suoi pregi ed i suoi difetti, è lo stesso utilizzato per gli 

ingressi ed uscite. Se il parametro iniziale v14[0] ha valore zero a causa del non 

funzionamento della spira 74, la risposta della simulazione risulterà assolutamente 

non attendibile. D’altra parte, avrebbe poco senso trovare una soluzione alterna- 

206


tiva, in quanto è molto difficile poter ottenere buone stime senza l’utilizzo delle 

informazioni provenienti dalle spire. 

Inizializzazione dei Flussi Iniziali 

Dal database vengono estratti i dati relativi ai flussi veicolari rilevati dalle boe e 

quelli rilevati dalle spire (anche in questo caso si considera il valore medio sui 

valori rilevati nei 5 minuti precedenti). I flussi delle boe e delle spire vengono 

controllati e se un valore è nullo, esso viene corretto con la media dei valori non 

nulli. Il problema di questa inizializzazione è che, mentre le spire percepiscono 

il flusso costituito dalla totalità dei veicoli, le boe sono in grado di cogliere sol- 

tanto il passaggio dei veicoli muniti di apparecchio telepass. Pertanto, il flusso 

ottenuto dalle boe è soltanto una porzione di quello totale effettivo. L’unico modo 

di ovviare a questo problema è di correggere i flussi delle boe con un opportuno 

coefficiente che possa stimare l’effettivo flusso veicolare in transito sotto una de- 

terminata boa. Per far questo è sufficiente conoscere in media la percentuale di 

automobilisti dotati dell’apparecchio telepass e correggere di conseguenza i valori 

ottenuti. La percentuale di veicoli rilevati dalle boe rispetto al totale è stata cal- 

colata con l’Equazione 4.1. Per fissare i flussi iniziali basta controllare per ogni 

tratta gli apparecchi presenti. Se vi è un solo apparecchio di rilevazione, il flusso 

iniziale sulla tratta è dato dal valore percepito da quel apparecchio (spira o boa 

che sia); se su una tratta è presente più di un apparecchio, il flusso iniziale sulla 

tratta è dato dalla media dei valori rilevati dagli apparecchi; se su una tratta non ci 

sono apparecchi, il flusso è calcolato come la media dei valori assegnati alla tratta 

precedente ed alla tratta successiva. Infine, se un apparecchio che viene interro- 

gato si trova a cavallo fra due tratte, nella zona fra uscita della tratta precedente 

ed ingresso della tratta successiva (che poi sono ingresso e uscita della stessa sta- 

zione) il valore del flusso viene giustamente corretto sottraendo o aggiungendo il 

flusso di ingresso o di uscita del casello della stazione in questione. 

Analogamente al caso della velocità, viene inizializzato q00, ovvero il flusso sul 

tratto precedente la barriera di Milano. Questo valore viene lasciato a zero in 

quanto tutto il flusso in entrata nella prima tratta proviene dal casello di Monza e 

207


dalla Barriera di Milano e sono già conteggiati tra gli ingressi dalle stazioni. Infi- 

ne, viene impostato il vettore q14, contenente i valori del flusso sul tratto stradale 

successivo all’ultimo di nostra competenza. Tale valore è fondamentale per poter 

calcolare l’equazione della densità relativa all’ultima tratta di nostra competenza; 

q14 viene calcolato tramite il flusso percepito dalla spira 74 e viene mantenuto 

costante per tutti i 30 minuti simulati. 

Inizializzazione delle Densità Iniziali 

La densità dei veicoli sulla tratta è forse il parametro più importante fra le varia- 

bili di stato che descrivono le condizioni del traffico; infatti, dalla densità si può 

calcolare la velocità dei veicoli ed il loro flusso (come descritto nelle equazioni di 

Papageorgiou), e quindi la stima della densità dovrebbe essere il più possibile cor- 

retta. Purtroppo, sulla rete autostradale, l’unica apparecchiatura in grado di fornire 

dati sulla densità sembrerebbe essere la spira. In realtà, è pressoché impossibile 

ottenere un qualche dato utilizzabile sulla densità tramite le spire. Innanzitutto, 

esse sono distribuite con una frequenza insufficiente per fornire un’informazione 

buona ed allo stesso tempo coerente su tutte le tratte; inoltre, sebbene nel database 

di Autostrade sembri che le tabelle relative alle spire possano dare informazio- 

ni sulla densità, in realtà i dati presenti presentano varie incosistenze nei valori 

riportati. 

5.2.13 Simulazione 

Il metodo Simulazione comprende il codice per lo sviluppo nei 30 minuti di 

simulazione delle equazioni. Per prima cosa viene indicato l’istante iniziale del- 

la simulazione e quindi il simulatore entra nel ciclo che aggiornerà per 30 volte i 

valori delle variabili di stato. All’interno di questo ciclo, ve ne è un secondo, inne- 

stato, che esegue le equazioni di aggiornamento sulle 12 tratte autostradali interne 

(dalla seconda alla tredicesima); le equazioni della prima e dell’ultima tratta sono 

inserite nel ciclo esterno (quello che scorre i 30 minuti) poiché le tratte sul confine 

necessitano di alcuni parametri particolari trattati diversamente dagli altri. Osser- 

208


viamo quel che accade per una qualsiasi delle tratte intermedie (lo stesso accade 

per quelle di confine; solo che alcuni dei parametri sono fissati diversamente). 

Ad ogni istante k e per ogni singola tratta identificata dal codice i tratta il 

simulatore esegue il seguente flusso operativo. 

Estratto 5.2 

rho [ k + 1 ] [ i t r a t t a ]= F u n z i o n i . C a l c o l o r h o ( . . . . ) ; 

Con questa istruzione viene calcolata la densità all’istante successivo sulla 

tratta stessa tramite la funzione calcolo rho. 

Estratto 5.3 

i f ( rho [ k + 1 ] [ i t r a t t a ]>= rho max [ i t r a t t a ] ) 

{ 

rho [ k + 1 ] [ i t r a t t a ]= rho max [ i t r a t t a ] ; 

} 

Eseguiamo un controllo: se la nuova densità ha un valore superiore alla densità di 

congestione massima relativa a quella tratta, il valore viene corretto e posto uguale 

alla densità massima stessa. 

Estratto 5.4 

i f ( rho [ k + 1 ] [ i t r a t t a ]


usata anche come denominatore di frazione in alcune formule, il valore nullo cree- 

rebbe problemi di calcolo; in fondo, 1veicolo/km è un’ottima approssimazione 

di autostrada sgombra). 

Estratto 5.5 

i f ( rho [ k ] [ i t r a t t a ]>= rho max [ i t r a t t a ] ) 

{ 

v [ k + 1 ] [ i t r a t t a ]= 

. . . . 

} 

F u n z i o n i . C a l c o l o v ( 

, rho max [ i t r a t t a ] , ) ; 

La velocità sulla tratta è calcolata eseguendo un controllo sulla densità all’i- 

stante precedente: se questa era superiore o uguale alla densità massima, allora 

la velocità all’istante successivo viene calcolata considerando la densità pari alla 

densità massima della tratta. 

Estratto 5.6 Da 5.5 

. . . . 

e l s e 

{ 

v [ k + 1 ] [ i t r a t t a ]= 

} 

F u n z i o n i . C a l c o l o v ( 

, rho [ k ] [ i t r a t t a ] , ) ; 

Se la densità precedente non ha superato il valore massimo, la velocità all’i- 

stante successivo viene calcolata considerando la stessa densità all’istante prece- 

dente sulla tratta. 

210


Estratto 5.7 

i f ( v [ k + 1 ] [ i t r a t t a ]


scritte direttamente dentro il listato Java. Nell’esempio seguente, mostriamo come 

sia possibile utilizzare la tecnologia JDBC per scrivere dati sul database. 

Estratto 5.9 

S t r i n g i n s q u e r y =”INSERT INTO CC PREVISIONE” + 

” ( TRATTA ID , ORA SIMULATA, VEL PREVISTA , 

ORA PREVISIONE , DEN PREVISTA , 

FLU PREVISTO , VERSO TRATTA) VALUES ( ” + 

( t r +1) + ” , ” + 

”TO DATE( ’ ” + o r a s i m + ” ’ , 

’YYYY−MM−DD hh24 : mi : s s ’ ) , ” + 

( v e l [ t e ] [ t r ] ) + ” , ” + 

”TO DATE( ’ ” + o r a s t a r t + ” ’ , 

’YYYY−MM−DD hh24 : mi : s s ’ ) , ” + 

( den [ t e ] [ t r ] ) + ” , ” + 

( f l u [ t e ] [ t r ] ) + ” , ” + 

0 + ” ) ” ; 

S t a t e m e n t s t m t = c . c r e a t e S t a t e m e n t ( ) ; 

s t m t . e x e c u t e U p d a t e ( i n s q u e r y ) ; 

s t m t . c l o s e ( ) ; 

La query è del tutto immersa nel linguaggio Java. Viene costruita dinamicamente 

come un oggetto di tipo String costituito da varie sottostringhe unitie tramite il 

simbolo +. La stringa viene costruita con l’inserimento di variabili determinate in- 

ternamente al programma: questo la rende a tutti gli effetti una query dinamica. Il 

trattamento particolare riservato alle query dinamiche è illustrato nella spiegazio- 

ne relativa alla query 5.14. Tuttavia, il vantaggio di utilizzare la tecnologia JDBC 

non è soltanto quello di poter utilizzare componenti dinamiche per la costruzione 

di query (alla stregua del funzionamento della Stored Procedure implemen- 

tate in pressoché tutti i principali RDBM), ma è anche quello di avere il risultato 

della query inserito in una struttura del linguaggio Java. L’oggetto Statement 

può essere associato ad un oggetto Result Set: si tratta di una struttura tabel- 

212


lare non permanente che può essere interpretata internamente al programma. 

Nel nostro caso, molte queries sono statiche, ma richiedono di essere incluse in 

strutture Java per successivi trattamenti. A questo scopo abbiamo costruito una 

architettura in grado di unire la semplicità dell’SQL con i vantaggi della JDBC. In 

pratica, le queries SQL vengono scritte su files .txt salvati in una directory pre- 

definita. Il programma va a leggere le queries direttamente da questa cartella, ne 

trasforma il contenuto in un oggetto String e crea ed esegue lo Statement. Il re- 

sult set associato allo statement può essere così interpretato dal programma. Inol- 

tre, è possibile selezionare solo alcune colonne della query scritta su file. Questo è 

ottenibile per mezzo di una istruzione da inserire al termine della query e definita 

da noi stessi. Inserendo l’istruzione break seguita da un numero, si impone al 

programma di considerare solo tante colonne del result set quante sono richieste 

tramite quel numero. Questo approccio consente anche a chi non ha scritto ma- 

terialmente il programma di modificarne facilmente il codice utilizzando questa 

sorta di metalinguaggio. Purtroppo, con l’aumentare del numero di query e del nu- 

mero di tipologie di strutture dati in cui i risultati provenienti dal database devono 

essere organizzati, abbiamo talvolta fatto ricorso a metodi particolari programma- 

ti per funzionare con una sola query. Tuttavia, l’organizzazione del programma 

tramite l’utilizzo di queries salvate esternamente ha permesso uno sviluppo logico 

più ordinato. 

213


Figura 5.5: Esempio di funzionamento del meccanismo di elaborazione delle 

queries 

5.2.15 La Nostra Tabella sul Database 

Come detto, è possibile scrivere i nostri dati su una tabella del database. Il databa- 

se di test delle autostrade ospita infatti uno schema denominato UNIGE all’inter- 

no del quale abbiamo costruito la tabella CC PREVISIONE. La struttura è quella 

riportata di seguito. 

Estratto 5.10 

Codice identificativo della tratta, determinato da noi in ordine crescente 

rispetto al senso di marcia Milano-Brescia (ID TRATTA) 

◦ Ora corrispondente al momento simulato (ORA SIMULATA) 

◦ Velocità prevista VEL PREVISTA 

214


◦ Ora a cui è stata effettuata la previsione: ne esiste una e soltanto una per 

ogni simulazione e può funzionare come identificativo della simulazione 

(ORA PREVISIONE)) 

◦ Densità prevista DEN PREVISTA 

◦ Flusso previsto FLU PREVISTO 

◦ Identificativo del verso della tratta (VERSO TRATTA) 

5.2.16 Interfaccia del Simulatore 

I risultati del simulatore sono resi fruibili tramite un’interfaccia html che mette 

disposizione varie forme di reporting dei dati elaborati. 

La pagina si presenta come in Figura 5.6. 

Figura 5.6: Interfaccia del simulatore 

Per ogni tratta sono disponibili alcuni grafici che esamineremo in seguito. 

Inoltre, esistono alcune opzioni generali che consentono la visualizzazione di dati 

relativi all’intero tratto. 

215


Grafico della Velocità in Funzione del Tempo 

Il grafico della velocità in funzione del tempo è disponibile per ogni tratta ed è rea- 

lizzato tramite un file SVG che legge i files XML a cui abbiamo fatto riferimento in 

precedenza per poi elaborarne i dati e ricostruirli sul grafico da noi disegnato. Per 

questo grafico, come per tutti quelli dove non è specificato altrimenti, la struttura 

grafica è stata interamente realizzata da noi unendo l’ECMAScript di SVG con 

elementi statici di grafica vettoriale. 

Figura 5.7: Grafico vel(t) 

216


Grafico della Densità in Funzione del Tempo 

Questo grafico è del tutto analogo al precedente eccetto per il fatto che la variabile 

dipendente dal tempo è la densità e non la velocità. 

Figura 5.8: Grafico den(t) 

217


Grafico del Flusso in Funzione del Tempo 

Ancora un grafico dipendente dal tempo: questa volta rappresentiamo il flusso. 

Figura 5.9: Grafico flu(t) 

218


Grafico del Flusso in Funzione della Densità 

Questo grafico è tipico degli studi sul traffico ed è stato riportato per consentire 

alcune valutazioni che leggerete in seguito. 

Figura 5.10: Grafico flu(den) 

219


Tempi di Percorrenza 

Una importante informazione fornita dal simulatore è quella relativa ai tempi di 

percorrenza. Per ogni stazione è possibile capire quali stazioni possono essere 

raggiunte nei 30 minuti successivi e con quali tempi (naturalmente stiamo sempre 

parlando di previsioni). 

Figura 5.11: Tempi di percorrenza a partire dalla stazione di Cavenago 

Con riferimento alla Figura 5.11 andiamo a descrivere le funzionalità di questo 

report. Sull’orologio riportiamo le varie stazioni in corrispondenza del tempo 

necessario per raggiungerle a partire dalla stazione scelta. In questo caso si parte 

220


da Cavenago e vediamo che, ad esempio, si prevede di impiegare circa 24 minuti 

per arrivare a Rovato. Sulla parte destra del grafico, invece, abbiamo inserito 

un rettangolo diviso in tanti tratti quante sono le tratte autostradali coperte. A 

seconda della velocità sostenibile in queste tratte, il rettangolo viene colorato con 

un criterio espresso nella legenda. Infine, i numeri all’estrema destra della figura 

sono gli intertempi previsti da stazione a stazione. 

221


Assonometrie e Prospettive 

I grafici descritti sino ad ora sono disponibili per ciascuna tratta: abbiamo però 

messo a disposizione alcuni grafici di insieme che mostrano in una stessa figura 

una delle grandezze di riferimento. Si tratta di grafici tridimensionali: lungo una 

dimensione cresce il tempo, lungo l’altra si seguono le stazioni. Chiaramente in 

altezza troviamo la grandezza che vogliamo studiare. 

222


Figura 5.12: Assonometria della velocità 

In Figura 5.12 vediamo l’assonometria delle velocità. In pratica questo grafico 

è costruito unendo i vari grafici bidimensionali della velocità. Cliccando su una 

zona del grafico tridimensionale ci si collega direttamente al grafico bidimensio- 

nale relativo alla zona su cui si è cliccato. Inoltre, agendo sui pulsanti a destra 

del grafico, è possibile tracciare una linea che segue il profilo della velocità per 

tempo costante. Questa funzione è attivata nella figura seguente, rappresentante 

l’assonometria della densità. 

223


Figura 5.13: Assonometria della densità 

224


Abbiamo l’assonometria anche per il flusso. 

Figura 5.14: Assonometria del flusso 

225


Analogamente, abbiamo anche disegnato gli stessi grafici secondo i principi 

della prospettiva in luogo di quelli dell’assonometria. 

Figura 5.15: Prospettiva della velocità 

226


Figura 5.16: Prospettiva della densità 

227


5.2.17 Grafici con Matlab 

Figura 5.17: Prospettiva del flusso 

Abbiamo costruito anche tre grafici con Matlab: questi grafici possono essere 

interessanti ma, perchè siano sempre aggiornati, è necessario lanciare il relativo 

programma. Le Figure seguenti mstrano un esempio di ciascuno di questi grafici. 

228


Figura 5.18: Grafico di velocità in funzione del tempo e del flusso in funzione del 

tempo 

Figura 5.19: Grafico della velocità in funzione del tempo e della densità 

229


Figura 5.20: Grafico del flusso in funzione del tempo e della densità 

230


5.3 Considerazioni sui Grafici 

5.3.1 Grafico Flusso-Densità 

I modelli macroscopici si basano su una relazione fondamentale di flusso e densità 

rappresentata a titolo di esempio in Figura 5.21. 

Figura 5.21: Diagramma fondamentale flusso-densità 

Questa rappresentazione è facilmente riscontrabile anche tra i diagrammi flus- 

so densità da noi disegnati, come nel caso della Figura 5.22. 

231

5.3. CONSIDERAZIONI SUI GRAFICI Carlo Caligaris, Iacopo Salvarani 

Figura 5.22: Diagramma flusso-densità 

Il significato fisico di questo diagramma appare piuttosto chiaro: esso rappre- 

senta le due situazioni di traffico realizzabili: la situazione di traffico scorrevole 

(zona sinistra rispetto al massimo) e quella di traffico congestionato (zona destra 

rispetto al massimo). Evidentemente non riusciremo sempre a realizzare entrambe 

le situazioni: la Figura 5.22 è stata scelta tra quelle che prevedono una modifica 

dello stato del traffico entro il periodo di simulazione. 

5.3.2 Assonometria della Velocità 

Un altro argomento spesso citato negli studi sul traffico è quello della propaga- 

zione delle code all’indietro come nel caso di una onda d’urto. Nel diagramma 

tridimensionale relativo alla velocità possiamo apprezzare come anche il nostro 

modello produca queste back waves. In Figura 5.23 ne abbiamo evidenziata una. 

232


Figura 5.23: Il fenomeno delle back waves 

233

5.3. CONSIDERAZIONI SUI GRAFICI Carlo Caligaris, Iacopo Salvarani 

Tra i vari strumenti di corredo al software principale, vi è anche un programma 

in Matlab che riproduce il funzionamento del simulatore e che può essere inizia- 

lizzato manualmente. Combinando dati rilevati dalla rete con approssimazioni 

abbiamo ottenuto i dati rappresentati in Figura 5.24. 

Figura 5.24: Mesh tridimensionale dei dati previsti di velocità 

Da questo grafico si possono vedere bene le valli che tagliano trasversalmente 

il grafico. La Figura 5.25 mostra un ingrandimento di queste zone. 

Figura 5.25: Il fenomeno delle back waves 

234


5.4 Programma di Controllo 

Per consentire ad un potenziale utente una funzione di controllo dei risultati otte- 

nuti, abbiamo costruito un sistema informatico che consente un confronto visuale 

tra i risultati previsti dal simulatore e quelli inviati dai sistemi di rilevamento dati 

presenti sulla rete autostradale. Questa interfaccia, come già scritto precedente- 

mente, si presenta come un sito web; la pagina principale, denominata Home mette 

a disposizione un link alla pagina Controllo. In realtà, questo è solo lo strato più 

esterno del nostro sistema informatico. Questo strato comunica in modi diversi 

con diversi altri strati. Nella Figura 5.26 abbiamo rappresentato schematicamente 

l’architettura del sistema. 

235

5.4. PROGRAMMA DI CONTROLLO Carlo Caligaris, Iacopo Salvarani 

Figura 5.26: Struttura del programma di controllo 

236


Il vero e proprio programma di controllo è stato scritto interamente in Ja- 

va e si costruisce su tre classi: Controllo Main, che è la classe principale, 

Queries C ed XMLWorks C; esse contengono un notevole numero di metodi 

relativi al trattamento dei dati in entrata dal database ed in uscita verso i files 

di nostro interesse. Di fatto, il programma recupera dati dal database, li elabora 

secondo logiche che approfondiremo successivamente e li organizza in strutture 

dati interne all’ambiente Java. Per rendere questi dati persistenti e fruibili da al- 

tre applicazioni, abbiamo fatto in modo di scriverli su files memorizzati du disco. 

Questi files possono quindi essere letti da altre applicazioni: abbiamo così realiz- 

zato una struttura interattiva che connette due programmi differenti consentendo 

lo scambio dei loro dati. Il flusso logico del programma è rappresentato in Figura 

5.27. 

237


write() 

Classe Queries C 

Famiglia call query 






Classe XMLWorks C 

Classe XMLWorks C 

Cancella Elenco.js Elenco.js 

Scrive su Elenco.js impostazioni della pagina html Elenco.js 

Determina numero di simulazioni presenti nel DB Queries *.txt 

Aggiorna Elenco.js con le simulazioni Elenco.js 

Rileva l’ora di inizio delle simulazioni 

Queries *.txt 

Aggiorna Elenco.js con le ore di inizio Elenco.js 

Determina ora corrente ed ora più vecchia 

Scrive su Elenco.js le ore prima rilevate Elenco.js 

Determina se le simulazioni sono confrontabili 

Incrociando i dati di spire, TP, ingressi ed uscite, 

determina un valore per ognuno dei 30 minuti 

seguenti per velocità e flusso 

Scrive i dati di velocità, flusso e densistà, 

su files XML poi letti esternamente 

Figura 5.27: Flusso del programma di controllo 

238 

Elenco.js 

AS.xml 

UNIGE.xml


Nelle due Figure precedenti, si fa spesso riferimento al file Elenco.js. 

Approfondiamo alcuni aspetti che riguardano il suo utilizzo 

5.4.1 Elenco.js e Controllo.html 

Abbiamo già discusso alla Sezione 3.3.8 della possibilità esistente per pagine 

html di contenere al loro interno dei comandi inseriti tramite scripting. Abbiamo 

anche visto come questi comandi possano essere scritti internamente alla pagina 

stessa oppure possano essere parte di un file con estensione .js da richiamare 

all’interno della pagina. Abbiamo sfruttato questa proprietà per costruire una pa- 

gina html attiva: in altre parole, abbiamo costruito la pagina normalmente, con 

una serie di elementi statici, ed abbiamo inserito nella parte dedicata allo scripting 

il collegamento ad un file, appunto Elenco.js. Questo file viene interamente 

gestito dal programma Java che, ad ogni run, prima lo elimina e poi lo ricrea scri- 

vendovi comandi aggiornati. In particolare, questi comandi sono linguaggio html 

che, una volta interpretati dal browser, producono la visualizzazione a schermo 

di tutte le informazioni riguardanti le simulazioni presenti sulla nostra tabella del 

database. Inoltre, il file contiene anche la definizione delle variabili relative al nu- 

mero di simulazioni confrontabili ed al numero di simulazioni non confrontabili 

perché troppo vecchie. Queste variabili vengono gestite dalla pagina al fine di 

riempire i menu a tendina presenti con le opzioni opportune. 

239


Figura 5.28: Interfaccia per il controllo del simulatore prima dell’utilizzo di 

Elenco.js 

Figura 5.29: Interfaccia per il controllo del simulatore dopo l’utilizzo di 

Elenco.js 

Dal confronto tra la Figura 5.28 e 5.33 si nota la differenza introdotta all’in- 

terno della pagina dal file Elenco.js. 

240


5.4.2 Simulazioni Confrontabili e Simulazioni non Confronta- 

bili 

Per ogni simulazione presente sul database, vengono riportate la data e l’ora in cui 

la simulazione è stata effettuata. Queste informazioni sono facilmente ottenibili 

dal database tramite una query, lanciata dall’applicazione secondo i principi della 

JDBC discussi nella Sezione 3.3.5. Il linguaggio di programmazione Java rende 

però piuttosto difficile la manipolazione dei campi data e dei campi ora. Infatti, 

mentre sul database Oracle queste informazioni sono immagazzinate nella stessa 

variabile, in Java devono essere divise in due variabili separate (evidentemen- 

te contenenti una la data e l’altra ora). Per gestire questa discrepanza, abbiamo 

scritto alcuni metodi che consentono di trasformare l’ora e la data in un oggetto 

denominato Calendar, implementato dalla classe java.util.Calendar. 

Questo tipo di oggetto è un vettore contenente vari campi, ciascuno dei quali re- 

lativo ad una differente dimensione temporale (ad esempio le ore, i mesi, gli anni 

o i secondi). Questa classe contiene anche alcuni metodi molto utili che facilitano 

il confronto tra due oggetti Calendar di tipo differente. 

Essendo riusciti infine, non senza qualche difficoltà, a gestire le informazioni ri- 

guardanti date ed ore, abbiamo interrogato il database al fine di ottenere le seguenti 

informazioni: 

• data ed ora dell’ultima rilevazione della sensoristica, che sarà considerata 

come l’ora presente; 

• data ed ora della più vecchia rilevazione eseguita dalle spire del nostro 

tratto. 

I dati delle spire sono cancellati con una frequenza superiore a quella con cui ven- 

gono cancellati i dati delle boe; di conseguenza, ci riferiamo a questo strumento 

come a quello che può indicarci quanto indietro nel tempo possiamo andare a 

confrontare le simulazioni. 

Definizione 5.2 Una simulazione è confrontabile se: 

• sono passati almeno trenta minuti da quando è stata lanciata; 

241


• il database contiene dati delle spire non più recenti del momento del lancio 

della simulazione in esame. 

Il primo confronto viene effettuato paragonando il momento della simulazione 

con il momento assunto come il presente, mentre il secondo confronto sarà effet- 

tuato paragonando il momento della simulazione con quello assunto come il più 

vecchio. 

5.4.3 Esecuzione delle Query 

L’esecuzione delle query avviene secondo meccanismi del tutto simili a quelli 

spiegati per il programma di simulazione. Non ripetiamo quindi l’illustrazione 

anche in questo contesto. 

5.4.4 Scrittura sui files xml 

Oltre ad Elenco.js, il nostro programma scrive su disco anche altri due files: 

• UNIGE.xml 

• AS.xml 

Il primo file ha una struttura rappresentata nello schema seguente. 

Estratto 5.11 Nodo radice: UNIGE 

Nodo: Elemento 

Attributi: Data 

Density 

Flux 

Id Simulazione 

Ora 

Speed 

Tratta 

Nodo: . . . 

242


Ogni elemento rappresenta uno dei 30 minuti di simulazione e quasi tutti gli 

attributi sono ricavati direttamente dalla tabella del database aggiornata con il pro- 

gramma principale di simulazione. L’unico attributo non sottostante a questa re- 

gola è Id Simulazione, un numero assegnato in base all’ordine con il quale 

le simulazioni confrontabili sono state effettuate. Con questo numero assegnamo 

ad ogni entry la simulazione a cui essa è relativa. 

Il file AS.xml ha la stessa struttura del precedente ma è molto più difficile da 

ricavare a partire dai dati del database. Innanzi tutto, esso deve essere costruito in 

diverse fasi distinte. Infatti, le tratte 6 e 9 devono essere trattate in modo differente 

da tutte le altre, dal momento che su queste possiamo utilizzare i dati provenienti 

dalle spire (più affidabili di quelli delle boe). Inoltre, velocità e flusso vanno 

richiesti al database con queries differenti. 

Tratte 6 e 9 

Il flusso è facilmente ricavabile dal database con la seguente query. 

Estratto 5.12 

SELECT C CEN , D ORA, (SUM( N TOT VEI ) ∗ 6 0 ) 

FROM VTPM66 DAT SPR 

WHERE D ORA BETWEEN 

TO DATE( ’ \ $ d a t e 1 \$ ’ , ’DD−MM−YYYY hh24 : mi : s s ’ ) 

AND TO DATE( ’ \ $ d a t e 2 \$ ’ , ’DD−MM−YYYY hh24 : mi : s s ’ ) 

AND ( C CEN=268 or C CEN=267) 

AND ( N CRS=1 or N CRS=2 or N CRS=3) 

GROUP BY( C CEN , D ORA) 

La velocità viene ricavata direttamente dalla tabella che fornisce i valori ad 

AutoTraf. 

Estratto 5.13 

SELECT C PNT DTX INI , C PNT DTX FIN , D UPD , N VEL MED 

243


FROM TTAG18 AT TRF IDX STR 

WHERE D UPD BETWEEN 

TO DATE ( ’ \ $ d a t e 1 \$ ’ , 


AND TO DATE ( ’ \ $ d a t e 2 \$ ’ , 


AND c s u b t r t = ’A’ 

AND ( C PNT DTX INI=3741 AND C PNT DTX FIN=3739 

OR C PNT DTX INI=3737 AND C PNT DTX FIN =3736) 

ORDER BY( C PNT DTX INI , D UPD) 

I campi nominati C PNT DTX INI e C PNT DTX FIN sono dei campi nu- 

merici. Ogni numero ivi contenuto rappresenta un particolare punto della rete 

autostradale italiana. I punti per noi interessanti sono quelli di inizio e fine delle 

tratte contenenti le spire. 

Queste queries sono scritte su files .txt ed utilizzano il meccanismo già spie- 

gato in precedenza (5.2.14). Nelle due queries sopra riportate, compaiono dei 

campi identificati come $date1$ e $date2$. Questi campi sono automatica- 

mente riconosciuti dal programma ed a loro vengono sostituite le date corrette. 

In questo modo siamo riusciti a costruire un semplicissimo meta-linguaggio in 

grado di trasformare una query statica scritta in un file di testo in una query dina- 

mica. In pratica, abbiamo unito la flessibilità tipica della JDBC con la semplicità 

di interrogazione fornita dall’SQL statico. 

In ogni caso, è necessario operare un controllo sui dati estratti, per assicurarsi 

che ci sia almeno un dato, e non più di uno, per ogni minuto. Infatti, le spire 

aggregano i dati per un tempo pari a circa un minuto, ma ci sono minuti durante 

i quali non passano auto. Logicamente, il database in questi casi non scrive nul- 

la sulle sue tabelle, ma per i nostri scopi è fondamentale avere una entry con il 

minuto in questione e con un valore nullo del flusso ad esso relativo. Dobbiamo 

quindi mettere mano alla struttura dati in modo da avere uno ed un solo valore per 

ciascuno dei minuti di previsione. 

244


Altre Tratte 

Sulle altre tratte, i dati relativi alla velocità sono comunque reperibili sempre dalla 

tabella contenente i dati di AutoTraf. Non riportiamo la query, dal momento che 

è del tutto analoga a quella riportata per il caso precedente. 

Molto più complicato è reperire i dati di flusso ed organizzarli in strutture 

che possono poi essere ricondotte a quella dei files xml. Questi dati sono ottenuti 

tramite l’analisi incrociata delle tabelle degli ingressi, delle uscite e delle boe. Ge- 

neralmente preferiamo affidarci ai dati delle boe, ma talvolta è necessario ricorrere 

anche a quelli di ingressi ed uscite. 

I dati provenienti dai caselli (sia in entra che in uscita) devono essere filtrati 

in modo diverso a seconda della direzione che si sta esaminando. Se stiamo con- 

siderando la direzione Milano-Brescia, ci interessano le macchine che, essendo 

entrate ad un casello della tratta in esame, sono uscite ad un casello più vicino a 

Brescia di quello da cui sono entrate. 

La query che interroga il database sugli ingressi è riportata nell’Estratto 5.14. 

Estratto 5.14 

SELECT C STZ , D MSG, (COUNT(D MSG) ∗ 6 0 ) 

FROM $ t a b l e $ 


TO DATE( ’ $ d a t e 1 $ ’ , 


AND TO DATE( ’ $ d a t e 2 $ ’ , 

AND C STZ >= 641 


GROUP BY ( C STZ , D MSG) ORDER BY ( C STZ , D MSG) 

La tabella delle boe non presenta dati aggregati: è quindi necessario, una volta 

ottenuto il result set, procedere all’aggregazione e, quindi alla correzione tramite i 

valori ricavati dalla matrice origine-destinazione ( infatti i valori così trovati sono 

245


relativi ad entrambe le direzioni di marcia, mentre a noi ne interessa solo una). 

Naturalmente, i problemi relativi ai minuti con più valori in questo caso ed in 

quelli seguenti non hanno alcun senso. Si ripropongono, invece, quelli connessi 

ai minuti durante i quali non ci sono mezzi in transito sul tratto in esame. 

Si noti come la query 5.14 contenga un altro tag interattivo: $table$. Infatti, i 

dati relativi alle boe sono memorizzate in tabelle differenti a seconda del giorno 

a cui risalgono. Il programma riconosce questo tag e sostituisce la stringa con il 

nome della tabella da considerare. 

La query che interroga il database sulle uscite è riportata nell’Estratto 5.15. 

Estratto 5.15 

SELECT C STZ , D MSG, (COUNT(D MSG) ∗ 6 0 ) 



TO DATE( ’ $ d a t e 1 $ ’ , 




AND C STZ = 641 

AND C STZ ENT C STZ OR 

( C STZ ENT = 654 AND C STZ = 6 5 5 ) ) 

AND NOT ( C STZ = 654 AND C STZ ENT = 655) 

GROUP BY ( C STZ , D MSG) 

ORDER BY ( C STZ , D MSG) 

La gestione di questi dati è più semplice del caso precedente: infatti, è possi- 

bile restringere il campo di ricerca alle sole auto che vanno nella direzione desi- 

derata, dal momento che la tabella delle uscite riporta anche la stazione di entrata 

da cui ogni veicolo proviene. Tuttavia, anche in questo caso è necessario intro- 

durre una ricerca interattiva della tabella da interrogare ed aggregare i risultati per 

minuto. 

246


Infine, interroghiamo anche la tabella delle boe: i valori andranno divisi per 

il fattore correttivo calcolato in precedenza nel tentativo di capire la percentuale 

media di auto rilevate dalle antenne in itinere rispetto al totale. 

I dati così ottenuti e trattati, vengono utilizzati per determinare il flusso lungo 

ciascuna tratta. Vediamo nel dettaglio come. 

Estratto 5.16 

SELECT N PRG , D MSG, (COUNT( N PRG ) ∗ 6 0 ) 



TO DATE( ’ $ d a t e 1 $ ’ , 




AND ( N PRG=110 OR N PRG=5 OR N PRG=6 OR N PRG=7 

OR N PRG=8 OR N PRG=10 ORN PRG=12 OR N PRG=26 

OR N PRG=14 OR N PRG=23 OR N PRG=16) 

GROUP BY( N PRG , D MSG) 

ORDER BY( N PRG , D MSG) 

247


Gestione dei Dati 

Figura 5.30: Tratta 1 e Tratta 2 [53] 

Nella Figura 5.30 si sono evidenziate con colori differenti le tratte fino a qui identi- 

ficate con i numeri 1 (Milano Est - Tangenziale Est) e 2 (Tangenziale Est - Agrate). 

Sulla tratta 1 abbiamo calcolato il flusso in base ai dati provenienti dalla boa in 

itinere 110. La tratta 2 è invece sprovvista di strumenti di rilevazione. Abbiamo 

scelto di calcolare il flusso come la media dei valori delle tratte limitrofe, consci 

dell’arbitrarietà e dell’imprecisione che questa decisione comporta. 

Nella Figura 5.31 abbiamo evidenziato la tratta 3 (Agrate - Cavenago). In 

questo caso, per determinare il flusso in transito su questa tratta, abbiamo dovuto 

utilizzare i dati della boa 5 sommati a quelli dell’uscita di Cavenago (Uscita 652). 

In effetti, il posizionamento della boa fa sì che essa possa rilevare solo i mezzi 

che hanno effettivamente percorso questo tratto senza uscire a Cavenago. Questo 

metodo è stato adottato in tutte le situazioni di questo tipo presenti sulla tratta. 

Non riportiamo tutti i rimanenti casi, essendo per lo più ripetizioni di quelli che 

abbiamo già visto, ma ne illustriamo di seguito un ultimo che mostra come si 

possano utilizzare anche i dati provenienti dalle entrate. 

In Figura 5.32 si è evidenziata la tratta 5 (Trezzo - Capriate). Il flusso qui può 

essere calcolato come somma di quello rilevato dalla boa 6 e di quello rilevato 

all’ingresso di Trezzo. 

248


Gli altri casi sono generalmente similari a quelli visti in precedenza, tran- 

ne che per la tratta 7 (Dalmine - Bergamo) nella quale sono presenti due boe: 

evidentemente il valore considerato sarà pari alla media dei due. 

Figura 5.31: Tratta 3 [53] 

Figura 5.32: Tratta 5 [53] 

5.4.5 Rappresentazione Grafica del Controllo 

Abbiamo già visto in Figura 5.28 il layout della pagina del Controllo. In essa 

compaiono pulsanti e menu a tendina: tramite un loro utilizzo alquanto intuitivo 

è possibile collegarsi ad un’altra pagina html che consente di visualizzare le 

grandezze relative ad una certa simulazione su una certa tratta. Queste tre variabili 

possono essere scelte utilizzando le opzioni che la pagina mette a disposizione. 

249


Figura 5.33: Le scelte messe a disposizione dalla pagina di controllo 

Le scelte dell’utente sono trasmesse da una pagina all’altra tramite il meto- 

do post. Ogni opzione viene trasformata in una variabile che viene letta tramite 

scripting nella pagina target del post. 

La pagina che consente di visualizzare gli andamenti previsti e reali è divisa 

in due frames. Il sinistro mette a disposizione alcune opzioni, che consentono di 

visualizzare e, in certi casi, anche di sovrapporre alcune rappresentazioni grafi- 

che dei dati. Il destro contiene invece il file SVG che visualizza i grafici richie- 

sti. Tramite un meccanismo di post tra i due frame, siamo riusciti a mettere in 

comunicazione le due parti della pagina. 

Frame sinistro 

On click: 

Opzioni utente 

Controllo.html 

Frame destro 

Passaggio variabili 

Post 

SVG 

Esecuzione grafici 

Visualizzazione grafici 

Figura 5.34: I flussi di dati della pagina 

Come si può vedere in Figura 5.34, il frame destro gestisce due flussi dati. 

Il primo, proveniente dalla pagina Controllo.html viene recepito ed indi- 

rizzato verso il file SVG; esso è responsabile della realizzazione grafica di tutti i 

250


grafici possibili. Questi grafici sono inizialmente impostati come nascosti (pro- 

prietà hidden) e quindi non sono visibili. La visibilità è data loro dall’utente 

nel momento in cui schiaccia uno (o più di uno) dei pulsanti messi a disposizione 

nel frame di sinistra. Ogni pulsante è collegato direttamente al file SVG e può 

modificare alcune sue proprietà, tra cui la visibilità dei grafici. 

Figura 5.35: Il file SVG con due grafici visualizzati 

L’esecuzione dei grafici da parte dell’SVG prevede il collegamento con i files 

XML contenenti i dati di interesse e lo scorrimento dell’albero da noi creato alla 

ricerca degli elementi che devono essere disposti sul video. 

Le opzioni messe a disposizione sono 6. Analizziamole una per una. Per 

questo esempio abbiamo assunto che il controllo riguardi una qualunque tratta e 

che la grandezza esaminata sia la velocità. Per le altre due grandezze e le altre 

tratte, il discorso è analogo. 

251


Velocità Vera 

Figura 5.36: Opzioni 

Abbiamo spiegato nel dettaglio come si sia voluto creare un vettore di velocità, 

dove ciascun elemento del vettore rappresenta la velocità media sulla durata di 

un minuto. Questo vettore è idealmente contenuto nel file xml di riferimento. Se 

stiamo analizzando la velocità vera, il file da considerare è AS.xml, mentre se 

stiamo analizzando quella prevista, dobbiamo riferirci a UNIGE.xml. Il file SVG 

contiene questi percorsi e può così scorrere virtualmente questi vettori. 

Definizione 5.3 Definiamo vi per i = 0 . . . 30 il vettore il cui elemento i−esimo 

contiene la velocità in km/h rilevata per il minuto i−esimo dalla partenza della 

simulazione. 

Il primo pulsante espone il grafico di vi in funzione di i. 

Velocità Prevista 

Questo grafico è del tutto analogo al precedente, tranne che per il fatto che ad 

essere rappresentata non è la velocità vera, ma quella prevista. 

252


Definizione 5.4 Definiamo pi per i = 0 . . . 30 il vettore il cui elemento i−esimo 

contiene la velocità in km/h prevista per il minuto i−esimo dalla partenza della 

simulazione. 

Errore Puntuale 

Definizione 5.5 Definiamo errore puntuale e 1 i come: 

Errore Medio 

e 1 i = pi − vi ∀i = 0 . . . 30. (5.4) 

Definizione 5.6 Definiamo errore medio e 1 i come: 

e 1 i = 

� i 

0 �e1 i � 

i 

Errore Puntuale Percentuale 

= 

� i 

0 �pi − vi� 

i 

Definizione 5.7 Definiamo errore puntuale percentuale e 2 i come: 

e 2 i = e1 i 

vi 

Errore Medio Percentuale 

= pi − vi 

vi 

∀i = 0 . . . 30. (5.5) 

· 100 ∀i = 0 . . . 30. (5.6) 

Definizione 5.8 Definiamo errore medio percentuale e 2 i come: 

e 2 i = 

� i 

0 �e2 i � 

i 

= 

�i pi−vi 

0 � vi � 

i 

253 

∀i = 0 . . . 30. (5.7)

5.5. QUALCHE RISULTATO Carlo Caligaris, Iacopo Salvarani 

5.5 Qualche Risultato 

Utilizzando le funzionalità più affidabili del programma di controllo, siamo riuscit 

ad analizzare qualche risultato. Abbiamo notato come sia di particolare importan- 

za impostare, per ogni tratta, i valori dei parametri. Questo lavoro deve essere an- 

cora completato, ma nel frattempo siamo riusciti a collezionare qualche risultato 

interessante. 

In Figura 5.37 mostriamo un caso particolare: il simulatore si accorge della 

situazione scorrevole di traffico, ma individua dei fenomeni di stop and go che 

non hanno riscontro nella realtà. Evidentemente, in questa tratta è necessario 

stimare meglio la densità massima. 

In Figura 5.38, invece, possiamo vedere quella che è una buona simulazione: 

infatti, a fronte di sensibili variazioni di velocità, il simulatore inizialmente non 

reagisce, salvo poi avvicinarsi sensibilmente alla curva dei valori reali. Questo 

è uno dei pochi casi in cui abbiamo avuto la possibilità di testare il simulatore 

in situazioni di traffico molto variabile. Queste condizioni sono particolarmente 

critiche per il buon funzionamento dello strumento. 

In Figura 5.39 abbiamo riportato una situazione piuttosto prevedibile: i risul- 

tati sono abbastanza aderenti alla realtà (anche se non colgono con precisione i 

vari trend). Il buon risultato qui ottenuto è testimoniato dall’errorre medio per- 

centuale, riportato in Figura 5.40. Si può vedere come esso si attesti intorno al 

10%, risultato da considerarsi molto buono. 

Infine, mostriamo la Figura 5.41: anche in questo caso la simulazione ap- 

prossima abbastanza bene il comportamento reale, tuttavia, si attesta su valo- 

ri costantamente più alti rispetto a quelli verificatisi. È questo un classico caso 

in cui la velocità massima sostenibile è inferiore a quella stimata ed inserita nel 

programma. 

In tutti i casi, il simulatore introduce un errore abbastanza rilevante, ma ra- 

ramente fornisce un’indicazione completamente sbagliata sul comportamento del 

traffico. In altre parole, non rileva fenomeni di congestione dove non ce ne sono: 

chiaramente, prevedere precisamente la velocità è molto difficile e di dubbia uti- 

254


lità. È invece molto più interessante sapere se quella velocità è compresa in un 

intervallo che ben identifica la situazione del traffico. 

Figura 5.37: Un risultato con fenomeni di stop and go non verificati 

Figura 5.38: Una buona simulazione 

255


Figura 5.39: Una simulazione facile 

Figura 5.40: Errore medio percentuale 

256


Figura 5.41: Una tratta dove la velocità massima è troppo elevata 

257


258

Capitolo 6 

Sviluppi Futuri 

Figura 6.1: Design of a 10-ways interchange [62] 

259

6.1. INTRODUZIONE Carlo Caligaris, Iacopo Salvarani 

6.1 Introduzione 

Il lavoro da noi iniziato si presta a diversi possibili sviluppi. Alcuni di questi, 

nel momento in cui stiamo scrivendo, sono già stati parzialmente realizzati, altri 

costituiscono la base per una eventuale collaborazione futura volta a migliorare lo 

strumento che abbiamo implementato. Nelle seguenti Sezioni illustriamo le quat- 

tro direttive di sviluppo più importanti che abbiamo individuato in collaborazione 

con la direzione tecnica di Infoblu. 

260

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale CAPITOLO 6. SVILUPPI FUTURI 

6.2 Pubblicazione sul Server 

Tutti i files da noi prodotti devono essere pubblicati su un server interno, in modo 

tale da consentire l’utilizzo dei programmi a tutti gli utenti collegati all’Intranet. 

Questo lavoro è già stato svolto: al momento i nostri programmi sono attivi e 

funzionanti sullo stesso server che mette a disposizione della rete interna di Au- 

tostrade per l’Italia il servizio di Autotraf. In particolar modo, le pagine html 

sono collegate ad un file presente nella directory radice del server. Solo le pagine 

pubblicate in questa directory sono raggiungibili dall’esterno: con questo collega- 

mento riusciamo a vedere le pagine web senza doverle fisicamente trasferire nella 

root del server. Il trasferimento è stato possibile grazie all’aiuto di un collaborato- 

re di Infoblu ed è stato effettuato via FTP. Le difficoltà maggiori rilevate in questa 

fase sono state portate dal dover reimpostare i programmi in modo che potesse- 

ro girare anche su un server UNIX, come quello messo a nostra disposizione. In 

effetti, Java è indipendente dal sistema operativo su cui è fatto funzionare, come 

già spiegato in precedenza; tuttavia, nel passaggio da un sistema all’altro, ci sono 

alcune differenze tanto banali quanto degne di grande attenzione. In particolar 

modo ci riferiamo alla differenza nell’utilizzo degli slash per la scrittura dei per- 

corsi dei files. 

In ambiente Microsoft, generalmente, i percorsi sono riconosciuti sia che si usi lo 

slash, sia che si usi il backslash (Estratto 6.1). 

Estratto 6.1 

C:\ Dir1 \ Dir2 \ Dir3 \ F i l e . e x t 

In Unix, invece, è necessario sostituire tutti i backslash (\) con gli slash (/) 

(Estratto 6.2). 

Estratto 6.2 

/ Dir1 / Dir2 / Dir3 / F i l e . e x t 

261

6.2. PUBBLICAZIONE SUL SERVER Carlo Caligaris, Iacopo Salvarani 

Una volta corretto questo, insieme ad altri piccoli inconvenienti, siamo riusciti 

a far funzionare i nostri files .class anche da remoto tramite linea di comando 

trasmessa con TelNet. 

262


6.3 Disegno delle Curve di Approssimazione delle 

Entrate 

Come già detto, una delle più grandi limitazioni del simulatore è quella di assu- 

mere ingressi ed uscite costanti per tutto l’arco di previsione. Per ovviare a questo 

problema, abbiamo cercato di ricostruire un andamento standard degli ingressi 

(per le uscite si possono effettuare analoghe considerazioni) lungo l’arco di una 

giornata, basandoci su dati storici. Dal database abbiamo estratto i dati relativi ad 

un’intera giornata di ingressi, raggruppandoli per minuto, in modo da poter cono- 

scere, per ogni minuto, quanti veicoli sono entrati in ciascuna stazione. Questo 

lavoro avrebbe dovuto essere svolto per ciascun giorno della settimana, essendo 

presumibilmente differenti le proporzioni di utilizzo delle varie stazioni a secon- 

da del giorno in esame. Noti questi andamenti di riferimento, abbiamo dovuto 

studiare un modo per renderli fruibili all’interno del programma. 

In pratica, dati il giorno e l’ora di simulazione, noi vogliamo un metodo in 

grado di stimare le entrate per i 30 minuti successivi basandosi sui valori storici 

rilevati nei giorni omonimi. Eventualmente, questi valori potrebbero essere scalati 

proporzionalmente al valore attuale. 

La prima idea è stata quella di memorizzare tutti questi dati in un piccolo 

database interno all’applicazione (quindi non appoggiato al database Oracle di 

Autostrade per l’Italia e non sviluppato secondo un’ottica client-server). Questo 

metodo avrebbe consentito di utilizzare esattamente i valori ricavati dallo sto- 

rico, ma avrebbe anche richiesto un notevole utilizzo di memoria oltre che un 

rallentamento delle prestazioni. 

Abbiamo quindi optato per costruire delle curve in grado di approssimare l’an- 

damento giornaliero degli ingressi. Consideriamo la Figura 6.2: essa rappresenta 

gli ingressi di una giornata intera registrati alla stazione 641. Abbiamo raggrup- 

pato i dati ogni 6 minuti, in modo da consentire una distribuzione del dato più 

regolare. 

263

6.3. DISEGNO DELLE CURVE DI APPROSSIMAZIONE DELLE ENTRATE Carlo Caligaris, Iacopo Salvarani 

Figura 6.2: Entrate alla stazione 641 relative a Venerd 3 Febbraio 2006 

Per approssimare l’andamento di questi dati abbiamo utilizzato un pacchetto 

di Matlab ((Optimization Toolbox)) in grado di eseguire la minimizzazione dei 

quadrati dell’errore data una funzione di riferimento che deve approssimare il 

nostro insieme di dati. La funzione di riferimento scelta è la seguente. 

F = a[13] · sin(a[14] · x) 

+ a[1] · e −(x−a[2])2 

a(3) 

+ a[4] · e −(x−a[5])2 

a(6) 

+ a[7] · e −(x−a[8])2 

a(9) 

+ a[10] · e −(x−a[11])2 

a(12) 

(6.1) 

La funzione dipende dal vettore a[i] definito per i = 1 . . . 14. Questi coefficienti 

sono quelli che vengono modificati in modo da definire la curva del tipo richiesto 

che meglio approssima i dati reali. 

264


Figura 6.3: Approssimazione con il metodo dei minimi quadrati 

In Figura 6.3 vediamo il risultato dell’approssimazione. 

Nelle Figure seguenti, mostriamo altri casi, relativi ad altre tratte, con relative 

curve di regressione. 


265

6.3. DISEGNO DELLE CURVE DI APPROSSIMAZIONE DELLE ENTRATE Carlo Caligaris, Iacopo Salvarani 



Non abbiamo ancora implementato il simulatore in modo da modificare gli 

ingressi in base a queste funzioni. Inoltre, dal momento che i dati sono raggrup- 

266


pato ogni sei minuti, dovremo supporre che le entrate e le uscite restino pressoché 

costanti per intervalli di durata pari proprio a sei minuti. Questa approssimazione 

è necessaria per ottenere curve di regressione accettabili: scegliendo intervalli più 

brevi, si avrebbero andamenti molto distorti rispetto al caso reale. 

267

6.4. APPLICAZIONE AD ALTRE TRATTE Carlo Caligaris, Iacopo Salvarani 

6.4 Applicazione ad Altre Tratte 

L’approccio da noi utilizzato può essere esteso anche ad altre tratte autostradali: 

il vincolo più importante è che esse siano “tratte chiuse”, ossia tratte comprese 

tra sue barriere, tra due spire o tra una barriera ed una spira. In pratica, un tratto 

chiuso è tanto più facilmente gestibile quanti più strumenti di rilevazione vi so- 

no. La sensoristica non è distribuita uniformemente lungo tutta la rete: il tratto 

Milano-Brescia è probabilmente quello più ricco di sensori, eppure abbiamo vi- 

sto come, in certi casi, essi siano insufficienti. Per sviluppare lo stesso modello 

su altre tratte, dovremmo quindi avere a disposizione una rete di rilevazione dati 

adeguata. 

Questo implica la presenza di almeno una spira interna al tratto e di almeno una 

boa su ogni tratta elementare. Sarebbe estremamente utile avere anche un qual- 

che strumento di rilevazione (come le boe) sulle rampe di accesso, in modo da 

conoscere con una precisione maggiore rispetto a quella ottenuta fino ad ora la 

percentuale di veicoli che scelgono una direzione piuttosto che un’altra. 

268

Bibliografia 

[1] M. Ben-Akiva, 

Development of a deployable real-time dynamic traffic assignment sy- 

stem, Task D Interim report: analytical developments for DTA system, 

MIT ITS Program, Cambridge (MA), 1996. 

[2] B.W. Bush, 

An Algorithmic Overview of TRANSIMS, 

Los Alamos National Laboratories, 2000. 

[3] P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone, 

Basi di Dati - Modelli e Linguaggi di Interrogazione, 

McGrawH-Hill, 2002, ISBN 88-386-6008-5. 

[4] M. Bacchi, A. Braccini, 

AutoTraf: Sistema automatico di misura dei tempi di percorrenza sulle 

tratte autostradali, 

Infoblu S.p.A.. 

[5] W. Burghout, 

Hybrid microscopic-mesoscopic traffic simulation, 

Doctoral Dissertation Royal Institute of Technology Stockholm, 14-16, 

Sweden, 2004. 

269

BIBLIOGRAFIA Carlo Caligaris, Iacopo Salvarani 

[6] O. Caligaris, 

Dispense del corso Modelli Matematici e Statistici, 

Università degli Studi di Genova. 

[7] R.E. Chandler, R. Herman, E.W. Montroll, 

Traffic Dynamics: Studies in Car Following, 

Opns. Res., 6, (1958), 317-45. 

[8] A. Chigrik, 

SQL Server 2000 vs Oracle 9i, 

http://www.mssqlcity.com/Articles/Compare/ 

sql server vs oracle.htm. 

[9] R. Courant, K.O. Friedrichs, H. Lewy, 

Über die partiellen diffrezengleichungen der mathematischen physik, 

Math. Ann. 100 (1928), 32. 

[10] H.M. Deitel, P.J. Deitel, 

Java - Fondamenti di Programmazione, Terza Edizione, 

APOGEO, 2005, ISBN 88-503-2388-3. 

[11] C.F. Daganzo, 

Requiem for second-order fluid approximations of traffc flow, 

Transportation Research-B 29, 277-286. 1995. 

[12] S. Del Furia, P. Meozzi, 

Programmare con il .Net Framework - ADO.NET, ASP.NET, XML - Vo- 

lume 3, 

Mondadori Informatica - MSDN Academic Alliance, ISBN 88-04- 

54064-8. 

270

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale BIBLIOGRAFIA 

[13] J. Fritz, 

Partial differential equations, 

Reprint of the fouth edition, Applied Mathematical Sciences, 1. 

Springer-Verlag, New York, 1967. 

[14] D.R. Drew, 

Traffic Flow Theory and Control, 

McGraw-Hill New York. 1968. 

[15] P. Gallo, F. Salerno, 

HTML, CSS e JavaScript, 

Mondadori Informatica - Minerva Italica, 2005, ISBN 88-8331-521-9. 

[16] C. Gawron, 

Simulation-Based Traffic Assignment; Computing User Equilibria in 

Large Street Networks, 

PhD thesis, University of Cologne, Cologne, 1998. 

[17] P.G. Gipps, 

A model for the structure of lane-changing decisions, 

Transportation Research Part B, 5, 403-414, 1986. 

[18] H. Greenberg, 

An Analisys of Traffic Flow, 

Operation Research 7, 79-85. 1959. 

[19] B.D. Greenshields, 

A Study in Highway Capacity, 

Highway Research Board Proceedings 14, 458. 1935. 

271


[20] R. Greenwald, R. Stackowiak, J. Stern, 

Oracle Essentials : Oracle9i, Oracle8i & Oracle8 (2nd Edition), 

O’Reilly & Associates, ISBN 0-596-00179-7. 

[21] R. Jayakrishnan, H.S. Mahmassani, T.Y. Hu, 

An Evaluation Tool fo Advanced Traffic Information and Management 

Systems in Urban Networks, 

Transportation Research C 2C (3): 129-14, 1994. 

[22] O.A. Ladyˇzenskaja, V.A. Solonnikov, 

Ural’ ceva, N. N., Linear and quasilinear equations of parabolic type, 

(Russian) Translated from the Russian by S. Smith. Translations of 

Mathematical Monographs, Vol. 23 American Mathematical Society, 

1967. 

[23] P.D. Lax, 

Hyperbolic systems of conservation laws, 

II. Comm. Pure Appl. Math. 10 1957 537-566. 

[24] P.D. Lax, B. Wendroff, 

System of conservation laws, 

Comm. Pure Appl. Math. 1 (1960) 217-237. 

[25] D.R. Leonard, P. Power, N.B. Taylor, 

CONTRAM: structure of the model, 

Transportation Research Laboratory, Crowthorn, 1989. 

[26] M.J. Lighthill, J.B. Whitham, 

On kinematic waves II: A theory of traffic flow on long crowded roads, 

Proceedings of the Royal Society A 229, 317-345. 1955. 

272


[27] M. Mahut, 

A multi-lane extension of the Space-Time Queue Model of Traffic Dy- 

namics, 

TRISTAN IV, Azores Islands, 2001. 

[28] A.D. May, 

Freeway Simulation Models. 

Transportation Research Rec 1132, 94-99. 1988 

[29] K. Nagel, M. Schreckenberg, 

A cellular automaton model for freeway traffic, 

J. Phys. I France 2 (12): 2221-2229, 1992. 

[30] R. Natalini, 

Introduzione ai metodi numerici alle differenze finite per equazioni di 

evoluzine, 

Istituto per le Applicazioni del Calcolo “Mauro Picone” Consiglio Nazio- 

nale delle Ricerche, 

http://www.iac.rm.cnr.it/∼natalini. 

[31] M. Papageorgiou, 

Applications of Automatic Control Concepts To Traffic Flow Modeling 

and Control, 

A.V. Balakrishnan, M. Thoma 1979. 

[32] M. Papageorgiou, 

Some Remarks on Macroscopic Traffic Flow Modelling, 

Transpn Res.-A, Vol. 32, No. 5, pp. 323-329, 1998 

273


[33] M. Papageorgiou, H. Haj-Salem, 

Ramp Meetering Impact on Urban Corridor Traffic: Field Results, 

Transportation Research Vol. 29A, No. 4, 303-319. 1995 

[34] H.J. Payne, 

Models of freeway traffic and control, 

Simulation Council Proceedings 1, 51-61.1971. 

[35] B. Peasland, 

TechTarget Expert Answer Center, 

http://expertanswercenter.techtarget.com/eac/ 

knowledgebaseAnswer/ 

0,295199,sid63 gci976695,00.html. 

[36] S. Piccardi, 

GaPiL Guida alla Programmazione in Linux, 

http://www.lilik.it/∼mirko/gapil/. 

[37] L.A. Pipes, 

An operational analysis of traffic dynamics, 

Journal of Applied Physics, Vol. 24, No. 3, 1953, pp. 274-281. 

[38] A. Reuschel, 

Vehicle movements in a platoon, 

Oesterreichisches Ingenieeur-Archir, Vol. 4, 1950, pp. 193-215. 

[39] R.D. Richtmyer, K.W. Morton, 

Difference methods for initialvalue problems, 

Reprint of the second edition. Robert E. Krieger Publishing Co., 1994. 

274


[40] J.M. Rosengard, 

Introduction to Oracle and Java, 

w2.syronex.com/jmr/pubs/2003/oralab4.pdf. 

[41] Gino Tironi, 

Università degli Studi di Trieste, 

http://www.dmi.units.it/∼tironi/matdid. 

[42] M. Treiber, 

Microsimulation of Road Traffic, 

http://vwisb7.vkw.tu-dresden.de/ 

∼treiber/MicroApplet/. 

[43] R.T. Underwood, 

Speed, Volume, and Density Relationships, Quality and Theory of 

Traffic Flow, 

Yale Bureau of Highway Traffic, New Haven, 141-188. 1968 

[44] P. Viotti, 

Risoluzione Numerica delle Equazioni Differenziali Ordinarie (EDO), 

http://w3.uniroma1.it/dits/docenti/ 

viotti/dispense/EDO.pdf. 

Università degli Studi di Roma “La Sapienza”. 

[45] Autostrade Torino Milano Torino Piacenza, 

Satap S.p.A. 

http://www.satapweb.it/inside.php?ctype=1. 

[46] ECMAScript Language Specification, 

Standard ECMA-262, 3rd December 1999, 

275


http://www.ecma-international.org/ 

publications/files/ECMA-ST/Ecma-262.pdf. 

[47] Oracle 9i JDBC Developer’s Guide and Reference Release 2 (9.2), 

http://www.lc.leidenuniv.nl/ 

awcourse/oracle/java.920/a96654/. 

[48] SearchOracle.com, 

http://searchoracle.techtarget.com. 

[49] Sun MicroSystems, 

http://www.sun.com/java/everywhere/. 

[50] SVG Tutorial, 

W3 Schools, 

http://www.w3schools.com/svg/svg intro.asp. 

[51] Technion - Israel Institute of Technology - Computer Science Depart- 

ment, 

http://www.cs.technion.ac.il/∼zyoav/ 

hierarchy-pictures/ 

IBM-XML-java-hierarchy%20145 

%20nodes%20178%20edges.jpg. 

[52] Wikipedia - L’Enciclopedia Libera, 

http://it.wikipedia.org/wiki/Autostrada A4. 

[53] AutoTraf. 

[54] Intranet Gruppo Autostrade. 

276


[55] Autostrade per l’Italia S.p.A., 

http://www.autostrade.it/en/investor/ 

profilo attivita.html?initPos=5. 

[56] Infoblu S.p.A., 

http://www.infoblu.it/Infoblu.html. 

[57] http://web.media.mit.edu/∼dmerrill/images/ 

beauty/slides/boston%20traffic.html. 

[58] http://www.edmunds.com/media/ownership/ 

driving/avoid.traffic.tickets/ 

traffic.1.500.jpg. 

[59] http://www.photo.net/photo/ 

pcd0222/los-angeles-traffic-44.3.jpg. 

[60] http://www.picture-newsletter.com/ 

night/motorway-night.jpg. 

[61] http://www.math.toronto.edu/∼drorbn/Gallery/ 

KnottedObjects/Interchange/IRColor.jpg. 

[62] http://web.mit.edu/smalpert/ 

277


www/roads/10-way.jpg. 

[63] http://gtresearchnews.gatech.edu/ 

reshor/rh-spr99/tr-ozone-b.jpg. 

278

Elenco delle figure 

1 Highway Lanes [58] . . . . . . . . . . . . . . . . . . . . . . . . 3 

1.1 Infrared picture of the interchange of I-95 and I-695, northeast of 

Baltimore. [61] . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 

1.2 Organigramma [55] . . . . . . . . . . . . . . . . . . . . . . . . . 20 

1.3 Rete Autostradale gestita da AutoTraf [53] . . . . . . . . . . . . . 23 

1.4 Dettaglio della A4 e della A8 [53] . . . . . . . . . . . . . . . . . 24 

1.5 Il tratto Milano-Brescia [53] . . . . . . . . . . . . . . . . . . . . 24 

2.1 Atlanta traffic jams at the interstate connector in downtown [63] . 27 

2.2 Schematizzazione del modello car following . . . . . . . . . . . . 33 

2.3 Il modello di Reuschel e Pipes . . . . . . . . . . . . . . . . . . . 34 

2.4 Manovra di Lane Change . . . . . . . . . . . . . . . . . . . . . . 36 

2.5 Simulatore Modello Microscopico [42] . . . . . . . . . . . . . . . 37 




2.9 Relazione Lineare Velocità-Densità . . . . . . . . . . . . . . . . 41 

2.10 Curva Caratteristica a Regime Stazionario Flusso-Densità . . . . 43 

2.11 Divisione in sezioni di un ipotetico tratto stradale . . . . . . . . . 45 

2.12 Le linee caratteristiche . . . . . . . . . . . . . . . . . . . . . . . 57 

2.13 Grafico e livelli della 2.30 . . . . . . . . . . . . . . . . . . . . . . 58 

2.14 Traiettoria di un’auto inizialmente in attesa al semaforo . . . . . . 60 

2.15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 

279

ELENCO DELLE FIGURE Carlo Caligaris, Iacopo Salvarani 

2.16 Una rappresentazione bidimensionale della griglia . . . . . . . . . 68 

2.17 Lax-Friedrichs, λ = 0, 8 [30] . . . . . . . . . . . . . . . . . . . . 71 

2.18 Lax-Friedrichs, λ = 1, 6 [30] . . . . . . . . . . . . . . . . . . . . 72 

2.19 Trasporto lineare con il metodo upwind [30] . . . . . . . . . . . 90 

2.20 Trasporto lineare con il metodo di Lax-Wendroff [30] . . . . . . . 91 

2.21 Trasporto lineare (dato regolare) con il metodo di Lax-Wendroff 

[30] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 

2.22 Curva Caratteristica velocità-densità . . . . . . . . . . . . . . . . 97 

2.23 Curva Caratteristica flusso-densità . . . . . . . . . . . . . . . . . 97 

2.24 Flussi veicolari relativi alla tratta i-esima . . . . . . . . . . . . . . 101 

2.25 | aλ | in funzione della densità . . . . . . . . . . . . . . . . . . . 104 

2.26 | aλ | in funzione della densità . . . . . . . . . . . . . . . . . . . 105 

3.1 Boston Traffic [57] . . . . . . . . . . . . . . . . . . . . . . . . . 115 

3.2 Gli Aspetti di Java [49] . . . . . . . . . . . . . . . . . . . . . . . 116 

3.3 Una base di dati relazionale . . . . . . . . . . . . . . . . . . . . . 133 

3.4 Una base di dati non relazionale con puntatori . . . . . . . . . . . 133 

3.5 Concentratori per un grande numero di utenti [20] . . . . . . . . 140 

3.6 Tipiche connessioni di un database Oracle [20] . . . . . . . . . . 142 

3.7 Un esempio di file XML da noi utilizzato . . . . . . . . . . . . . 151 

3.8 La Struttura ad Albero Tipica dell’XML [51] . . . . . . . . . . . 156 

3.9 La Struttura di un file XML [12] . . . . . . . . . . . . . . . . . . 158 

4.1 Night Motorway [60] . . . . . . . . . . . . . . . . . . . . . . . . 167 

4.2 Gli inizi della Torino-Milano [45] . . . . . . . . . . . . . . . . . 169 

4.3 Le due corsie dell’autostrada [45] . . . . . . . . . . . . . . . . . 170 

4.4 Il tratto Milano-Brescia [53] . . . . . . . . . . . . . . . . . . . . 171 

4.5 Legenda di AutoTraf [53] . . . . . . . . . . . . . . . . . . . . . . 172 

4.6 Numerazione delle corsie . . . . . . . . . . . . . . . . . . . . . 177 

4.7 Posizionamento della spira 24 . . . . . . . . . . . . . . . . . . . 181 

4.8 La situazione alla barriera di Milano Est . . . . . . . . . . . . . . 185 

5.1 Los Angeles Traffic [59] . . . . . . . . . . . . . . . . . . . . . . 191 

280

Università degli Studi di Genova, Tesi di Laurea in Ingegneria Gestionale ELENCO DELLE FIGURE 

5.2 Flusso lungo una tratta . . . . . . . . . . . . . . . . . . . . . . . 196 

5.3 Flusso a cavallo di due tratte . . . . . . . . . . . . . . . . . . . . 196 

5.4 Sequenza logica del programma di simulazione . . . . . . . . . . 200 

5.5 Esempio di funzionamento del meccanismo di elaborazione delle 

queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 

5.6 Interfaccia del simulatore . . . . . . . . . . . . . . . . . . . . . . 215 

5.7 Grafico vel(t) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 

5.8 Grafico den(t) . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 

5.9 Grafico flu(t) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 

5.10 Grafico flu(den) . . . . . . . . . . . . . . . . . . . . . . . . . . 219 

5.11 Tempi di percorrenza a partire dalla stazione di Cavenago . . . . . 220 

5.12 Assonometria della velocità . . . . . . . . . . . . . . . . . . . . . 223 

5.13 Assonometria della densità . . . . . . . . . . . . . . . . . . . . . 224 

5.14 Assonometria del flusso . . . . . . . . . . . . . . . . . . . . . . . 225 

5.15 Prospettiva della velocità . . . . . . . . . . . . . . . . . . . . . . 226 

5.16 Prospettiva della densità . . . . . . . . . . . . . . . . . . . . . . 227 

5.17 Prospettiva del flusso . . . . . . . . . . . . . . . . . . . . . . . . 228 

5.18 Grafico di velocità in funzione del tempo e del flusso in funzione 

del tempo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 

5.19 Grafico della velocità in funzione del tempo e della densità . . . . 229 

5.20 Grafico del flusso in funzione del tempo e della densità . . . . . . 230 

5.21 Diagramma fondamentale flusso-densità . . . . . . . . . . . . . . 231 

5.22 Diagramma flusso-densità . . . . . . . . . . . . . . . . . . . . . 232 

5.23 Il fenomeno delle back waves . . . . . . . . . . . . . . . . . . . . 233 

5.24 Mesh tridimensionale dei dati previsti di velocità . . . . . . . . . 234 

5.25 Il fenomeno delle back waves . . . . . . . . . . . . . . . . . . . . 234 

5.26 Struttura del programma di controllo . . . . . . . . . . . . . . . 236 

5.27 Flusso del programma di controllo . . . . . . . . . . . . . . . . . 238 

5.28 Interfaccia per il controllo del simulatore prima dell’utilizzo di 

Elenco.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 

281

ELENCO DELLE FIGURE Carlo Caligaris, Iacopo Salvarani 

5.29 Interfaccia per il controllo del simulatore dopo l’utilizzo di Elenco.js 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 

5.30 Tratta 1 e Tratta 2 [53] . . . . . . . . . . . . . . . . . . . . . . . 248 

5.31 Tratta 3 [53] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 

5.32 Tratta 5 [53] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 

5.33 Le scelte messe a disposizione dalla pagina di controllo . . . . . 250 

5.34 I flussi di dati della pagina . . . . . . . . . . . . . . . . . . . . . 250 

5.35 Il file SVG con due grafici visualizzati . . . . . . . . . . . . . . . 251 

5.36 Opzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 

5.37 Un risultato con fenomeni di stop and go non verificati . . . . . . 255 

5.38 Una buona simulazione . . . . . . . . . . . . . . . . . . . . . . . 255 

5.39 Una simulazione facile . . . . . . . . . . . . . . . . . . . . . . . 256 

5.40 Errore medio percentuale . . . . . . . . . . . . . . . . . . . . . . 256 

5.41 Una tratta dove la velocità massima è troppo elevata . . . . . . . . 257 

6.1 Design of a 10-ways interchange [62] . . . . . . . . . . . . . . . 259 

6.2 Entrate alla stazione 641 relative a Venerd 3 Febbraio 2006 . . . . 264 

6.3 Approssimazione con il metodo dei minimi quadrati . . . . . . . 265 

6.4 Approssimazione con il metodo dei minimi quadrati . . . . . . . . 265 



282

Elenco delle tabelle 

2.1 L’evoluzione della relazione tra velocità e densità . . . . . . . . . 48 

2.2 Schema Coefficienti [30] . . . . . . . . . . . . . . . . . . . . . . 80 

3.1 Lo stack di protocolli XML . . . . . . . . . . . . . . . . . . . . . 152 

4.1 Le stazioni della Milano-Brescia . . . . . . . . . . . . . . . . . . 172 

4.2 Il totale delle entrate per ogni stazione in un intervallo di quattro 

ore e mezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 

4.3 Il totale delle entrate per ogni stazione, considerando i soli utenti 

muniti di telepass, nello stesso intervallo di tempo della Tabella 

4.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 

283

Tesi di Laurea in Ingegneria Gestionale - Dist

Create successful ePaper yourself

Delete template?

Save as template?