Tesi laurea magistrale

1. Universit`a degli Studi di Trieste
Dipartimento di Ingegneria e Architettura
Corso di Studi in Ingegneria Informatica
Tesi di Laurea Magistrale
Analisi e sviluppo di un algoritmo di
pianificazione ordini
di una ditta di trasporto container su camion
Studente:
Marco Furlanetto
Relatore:
Prof.essa Maria Pia Fanti
Correlatori:
Prof. Walter Ukovich
Dott. Massimiliano Nolich
ANNO ACCADEMICO 2015–2016

2. Indice
1 Introduzione 1
1.1 Descrizione del problema . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Panoramica tesi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Il trasporto delle merci 2
2.1 Il trasporto marittimo . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Il trasporto terrestre . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 L’azienda di trasporto . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Tipi di viaggio . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Letteratura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Il Generatore degli Ordini 10
3.1 Struttura del programma . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1 Matrice delle Distanze . . . . . . . . . . . . . . . . . . . . 10
3.1.2 La generazione degli ordini . . . . . . . . . . . . . . . . . 13
3.2 Visualizzazione ordini . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.1 OpenLayers . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2 GeoJSON . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2.3 Implementazione . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.4 Pagina Web . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Analisi ordini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Algoritmo sviluppato 20
4.1 Problema multi-obiettivo . . . . . . . . . . . . . . . . . . . . . . 20
4.2 Richiamo sulla programmazione dinamica . . . . . . . . . . . . . 20
4.2.1 Formalizzazione del metodo . . . . . . . . . . . . . . . . . 20
4.3 Realizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Semplificazioni rispetto alla realt`a . . . . . . . . . . . . . 22
4.3.2 Definizione dell’orizzonte temporale . . . . . . . . . . . . 22
4.4 Sviluppo del programma . . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1 Analisi ordini . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.4.2 Definizione delle strutture dati . . . . . . . . . . . . . . . 29
4.4.3 Definizione dello stato . . . . . . . . . . . . . . . . . . . . 32
4.4.4 Assegnazione . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5 Visualizzazione su mappa . . . . . . . . . . . . . . . . . . . . . . 35
i

3. 5 Risultati 37
5.1 Visualizzazione su mappa . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Analisi assegnazioni flotta . . . . . . . . . . . . . . . . . . . . . . 38
5.2.1 Dove l’algoritmo funziona meglio . . . . . . . . . . . . . . 39
5.2.2 Dove l’algoritmo funziona peggio . . . . . . . . . . . . . . 41
5.2.3 Altre analisi . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.4 Considerazioni sui risultati . . . . . . . . . . . . . . . . . 49
6 Conclusioni 50
6.1 Elementi non considerati . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 Considerazioni generali . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3 Possibili miglioramenti . . . . . . . . . . . . . . . . . . . . . . . . 51
6.4 Raggiungimento dello scopo . . . . . . . . . . . . . . . . . . . . . 51
ii

4. Capitolo 1
Introduzione
Lo scopo della tesi `e la realizzazione di un programma in grado di ottimizzare
il problema della pianificazione degli ordini per una ditta di trasporto di merci
su camion.
Tale programma deve generare casualmente varie tipologie di ordini distribuiti
in una settimana lavorativa e successivamente ottimizzare l’assegnazione dei
viaggi agli autisti in modo da ridurre le distanze a vuoto percorse.
Si vuole dimostrare che attraverso l’utilizzo della programmazione dinamica si
pu`o migliorare la pianificazione di una flotta coprendo un numero maggiore di
ordini e allo stesso tempo percorrendo meno chilometri.
1.1 Descrizione del problema
Per la realizzazione di questo progetto si considera un’azienda di trasporto con-
tainer su camion. La pianificazione dei viaggi viene generalmente fatta su carta
da una persona specializzata definita Pianificatore: questa operazione consi-
ste nell’analizzare gli ordini che attualmente non sono stati assegnati e valutare
qual `e la migliore combinazione viaggio - autista.
Questo metodo tuttavia viene applicato considerando gli ordini pi`u vicini tem-
poralmente e per questo motivo le assegnazioni non permettono un uso efficiente
della flotta lungo la settimana lavorativa.
1.2 Panoramica tesi
La tesi sar`a sviluppata nel seguente modo: nel Capitolo 2 si descrive in linea
generale il problema del trasporto delle merci e si vuole analizzare lo stato
dell’arte sugli algoritmi di gestione di flotte di veicoli esaminando la letteratura
esistente; nel Capitolo 3 si descrive il programma di generazione di ordini; nel
Capitolo 4 si descrive il metodo utilizzato per la pianificazione dei viaggi e la sua
implementazione; nel Capitolo 5 si analizzano i risultati forniti dall’algoritmo e
nel Capitolo 6 le conclusioni.
1

5. Capitolo 2
Il trasporto delle merci
2.1 Il trasporto marittimo
Il trasporto mondiale delle merci `e svolto principalmente da compagnie di na-
vigazione 1
.
Il tipo di merce trasportato influisce sul tipo di nave: in particolare per il
trasporto di merci containerizzare si utilizzano specifiche navi chiamate por-
tacontainer, mostrate in figura 2.1. In questo caso la compagnia dispone non
solo di proprie navi ma anche di contenitori.
Figura 2.1: Passaggio di due navi portacontainer nella Baia di San Francisco [2]
L’utilizzo per scopi marittimi del contenitore fu un’idea risalente all’anno
1956 grazie ad un’intuizione del signor Malcolm McLean, in figura 2.2, che
venne definito il padre della containerizzazione.
1Tutte le informazioni della sezione sono state tratte dal libro Container shipping : viaggio
intorno al contenitore marittimo [1]
2

6. Figura 2.2: Il sig. Malcolm McLean al Port Newark–Elizabeth Marine Terminal,
1957. [3]
Il contenitore `e una unit`a di base del trasporto delle merci in grado, grazie
alla dotazione di dispositivi che consentono il sollevamento ed il bloccaggio,
di essere caricata sia su mezzi marittimi sia su mezzi terrestri.
Figura 2.3: Container della compagnia marittima MSC. [1]
Le misure standard di container, per l’utilizzo a livello mondiale, venne-
ro definite nel 1967 secondo le norme ISO (International Organization for
Standardization):
• 20 piedi (20’): larghezza 2,438 m, altezza 2,591 m, lunghezza 6,058 m,
volume interno 33 m3
;
• 40 piedi (40’): larghezza 2,438 m, altezza 2,591 m, lunghezza 12,192 m,
volume interno 66 m3
.
A questi due modelli venne aggiunto anche il contenitore da 40’ con altezza
maggiore chiamato high cube alto 2,896 m con un volume interno di 76 m3
.
Le norme ISO classificano altri tre contenitori di lunghezza maggiore, princi-
palmente utilizzati negli Stati Uniti:
3

7. • 45’: lunghezza 13,7 m, introdotto nel 1980;
• 48’: lunghezza 14,6 m;
• 53’ (chiamato Ocean 53): lunghezza 16,2 m, realizzato nel 2007.
Particolari esigenze commerciali hanno richiesto la realizzazione di altri tipi di
contenitori, chiamati special equipment:
• 20’ e 40’ open top, la cui sommit`a `e coperta da un telone (tarpaulin);
• flat rack, pianale con sponde fisse o ribaltabili;
• platform, contenitore piattaforma;
• heavy loader, contenitore con portata superiore alle norme ISO (27 o
33 tonnellate);
• reefer container, contenitore per carico refrigerato a temperatura con-
trollata;
• tank container, contenitore per il trasporto di liquidi;
• bulk container, contenitore per il trasporto di rinfuse.
2.2 Il trasporto terrestre
Lo scambio tra trasporto marittimo e terrestre viene effettuato nei porti in spe-
cifiche aree per la movimentazione e lo smistamento dei contenitori chiamate
container terminal 2
.
La movimentazione viene effettuata con mezzi speciali che, grazie alla standar-
dizzazione delle dimensioni e dei sistemi di aggancio, possono operare il solleva-
mento e lo spostamento ad alte velocit`a. Tra i mezzi principali vi sono le gru
portacontainer di banchina, in figura 2.4, per l’imbarco/sbarco dei contenitori
dalle navi.
Vi sono poi tipologie di gru specifiche per caricare/scaricare efficientemente i
contenitori da treni e camion.
2Tutte le informazioni della sezione sono state tratte dal libro Container shipping : viaggio
intorno al contenitore marittimo [1]
4

8. Figura 2.4: Gru portacontainer al Porto di Shanghai. [4]
Nel corso degli anni sono nati terminal terrestri, denominati interporti,
che rappresentano un punto di servizio intermodale nave-ferrovia-strada. Que-
ste strutture rappresentando un’estensione del porto nel suo stesso entroterra e
sono posizionate in punti strategici rispetto ad un’area industriale e commer-
ciale: dispongono di superfici molto ampie che comprendono piazzali per la
movimentazione dei contenitori, per l’interscambio gomma-rotaia e per altri nu-
merosi servizi. Grazie ad allacciamenti autostradali e ferroviari viene consentito
un accesso diretto ai mezzi di trasporto.
Figura 2.5: Interporto di Verona Quadrante Europa. [5]
5

9. 2.3 L’azienda di trasporto
Le compagnie marittime, per spostare i contenitori nell’entroterra si affidano a
ditte di trasporto su camion; queste hanno in carico la gestione del trasporto
dei contenitori tra porti/interporti per garantire il servizio porta a porta alle
aziende che lo richiedono.
Solitamente all’interno dell’azienda il pianificatore procede come segue:
• nella mattina si risolvono eventuali problematiche sorte durante la nottata
e per verificare la fattibilit`a di ulteriori giri;
• verificare se i viaggi assegnati il giorno prima richiedono una modifica in
base allo stato attuale della flotta;
• controllare quali viaggi devono ancora essere coperti;
• nel pomeriggio si procede con le nuove assegnazioni, avviando il lavoro di
pianificazione per il giorno successivo considerando per primi gli autisti
disponibili.
Il pianificatore quindi lavora cercando di tenere conto dell’intera settimana
ma pone sempre particolare attenzione alla giornata successiva.
2.3.1 Tipi di viaggio
La ditta di trasporto in oggetto opera viaggi definiti ABC, dove A e C rap-
presentano il porto/interporto e B rappresenta il luogo dove la merce viene
scaricata/caricata.
Lo spostamento del contenitore carico dal porto/interporto al B viene defini-
to viaggio di importazione merce (o import), viceversa lo spostamento di un
contenitore vuoto viene chiamato viaggio di esportazione (o export).
Viaggio import
Nei viaggi import l’autista deve recarsi al porto/interporto stabilito per prele-
vare il container contenente la merce, trasportarlo e scaricarlo presso l’azienda
che ha effettuato la richiesta ed infine depositare il vuoto al porto/interpor-
to stabilito: `e quindi fondamentale che venga rispettato l’orario richiesto dal
cliente.
6

10. A
B
C
Scaricare contenuto contenitore
Depositare contenitore vuoto
Prelevare contenitore pieno
Figura 2.6: Viaggio import
Viaggio export
Nei viaggi export l’autista deve prelevare il container vuoto al porto/interporto
stabilito, recarsi all’azienda che ha effettuato la richiesta per caricare la merce ed
infine trasportarlo al porto/interporto stabilito: in questo caso `e fondamentale
rispettare gli orari imposti dalle compagnie marittime/ferroviarie.
7

11. A
B
C
Caricare contenitore
Depositare contenitore pieno
Prelevare contenitore vuoto
Figura 2.7: Viaggio export
Altri tipi di viaggio
I viaggi effettuati dalla ditta di trasporto si possono classificare in ulteriori
tipologie; una distinzione viene fatta in base al fatto se il punto A e il punto C
coincidono:
• se C ≡ A si parla di viaggio round trip;
• se C = A si parla di viaggio one way.
Un’altra distinzione viene fatta in base agli accordi tra compagnia marittima e
ditta di trasporto:
• se la compagnia marittima cura l’intero trasporto terrestre del contenitore
pieno si parla di viaggio carrier;
• si parla invece di viaggio merchant quando il trasporto terrestre viene
gestito dalla ditta di trasporto e la compagnia marittima mette solamente
a disposizione il contenitore vuoto nel suo terminal.
Per motivi di semplificazione queste tipologie non vengono considerate software
di pianificazione.
2.4 Letteratura
La letteratura riguardante i modelli e gli algoritmi per la risoluzione del proble-
ma della gestione dei camion, ed in particolare sulla sua versione dinamica, `e
8

12. molto estesa. La maggior parte `e dedicata alla risoluzione di sequenze di proble-
mi deterministici che riflettono solamente ci`o che `e noto in un istante di tempo
(vedere Psaraftis (1995) [6]; Powell, Jaillet e Odoni (1995) [7]; Gendreau e Pot-
vin (1998) [8]; Larsen, Madsen e Solomon (2002) [9]).
L’articolo di Ichousa, Gendreau e Potvin (2006) [10] propone politiche per il
routing dinamico di veicoli ottimizzato nel tempo; questa ricerca si focalizza su
politiche miopi che regolano il comportamento attuale basandosi su stime pro-
babilistiche di domande future. Su Secomandi (2000) [11] e Secomandi (2001)
[12] si forniscono trattamenti pi`u formali per le politiche sulla risoluzione di pro-
blemi stocastici di routing; questa linea di ricerca per`o `e limitata ai problemi di
routing sul veicolo singolo.
Il problema di routing degli autisti in modo che questi possano fare ri-
torno a casa ha ricevuto poca attenzione: Caliskan e Hall (2003) [13] propone
a riguardo un metodo deterministico, ma non `e in grado di catturare tutte le
caratteristiche degli autisti (et`a, competenze ecc.) ed inoltre non `e in grado
di far tornare a casa gli autisti quando sono presenti le tipiche incertezze che
caratterizzano il trasporto delle merci.
Le ricerche di Desrosiers, Solomon e Soumis (1995) [14] e Desaulniers et al.
(1998) [15] si focalizzano sulla pianificazione dei programmi di volo per aerei
riuscendo a catturare sia tutte le caratteristiche dei piloti sia tutte le regole di
lavoro. Tuttavia questi problemi sono deterministici e traggono beneficio dal
fatto che le operazioni aeronautiche sono altamente programmate.
Una separata linea di ricerca si `e focalizzata sullo sviluppo di modelli in grado
di produrre soluzioni ottime per un intero periodo di pianificazione. Un’intro-
duzione a differenti modelli e strategie algoritmiche per i problemi di gestione
dinamica della flotta si trova negli articoli di Powell (1988) [16] e Powell, Jaillet
e Odoni (1995) [7].
I primi studi in questa area si focalizzavano sulla gestione di grandi flotte di
veicoli relativamente simili: questi problemi potevano essere formulati come
modelli spazio-temporali (dove un nodo rappresentava un punto nello spazio e
nel tempo) e potevano essere risolti come un problema di rete se c’era un solo
tipo di veicolo (vedere White (1972) [17]), oppure potevano essere risolti come
problemi di flusso multicommodity se c’erano pi`u tipi di veicoli (vedere Tapiero
e Soliman (1972) [18] e Crainic, Ferland e Rousseau (1984) [19]).
Questi modelli per`o non permettono di modellare tutte le caratteristiche degli
autisti.
Sono state trovate due ricerche che pi`u si avvicinano al problema di questa tesi:
la prima `e stata fatta da Spivey e Powell (2004) [20], che fornisce un modello
formale per il problema della gestione stocastica e dinamica degli autisti; la
seconda `e stata fatta da Simao et al. (2009) [21] che si basa sul modello della
ricerca precedente introducendo ulteriori tecniche matematiche.
Ad oggi nessuna ricerca si `e focalizzata sul problema della gestione della flotta
dove i viaggi sono di tipo ABC.
9

13. Capitolo 3
Il Generatore degli Ordini
In questo capitolo si descrive il programma per la generazione degli ordini.
L’output deve rispettare tre specifiche principali:
• tipologia viaggi ABC
A porto/interporto di partenza
B posizione del cliente
C porto/interporto di arrivo
• distribuzione ordini per tutta la settimana lavorativa
• orario di B entro 8:00 - 19:00
3.1 Struttura del programma
Il generatore degli ordini `e composto da pi`u programmi, organizzati nel modo
seguente:
1. realizzazione matrice delle distanze
2. generazione ed analisi ordini
3. parsing per visualizzazione su pagina Web
3.1.1 Matrice delle Distanze
Il primo obiettivo del Generatore `e la realizzazione della Matrice delle Di-
stanze.
Questo strumento permette agli altri programmi di ottenere velocemente la di-
stanza tra due citt`a, deve cio`e essere strutturata in modo che l’elemento (i, j)
rappresenta la distanza tra le citt`a i e j. Si ottiene cos`ı una matrice n × n
simmetrica con diagonale nulla, dove n `e il numero di citt`a.
Il calcolo delle distanze viene effettuato dal Distanziere (figura 3.1): questo
programma accetta come input due valori interi che rappresentano i codici che
identificano le citt`a e fornisce come output la distanza in ettometri (hm) come
valore double. Questo programma `e stato scritto nel linguaggio C++ ed `e sta-
to possibile utilizzarlo all’interno del generatore trasformandolo in una libreria
(dll) ed importandolo nel codice C#.
10

14. DISTANZIERE
CODICE CITTA 1
CODICE CITTA 2
DISTANZA (IN HM)
Figura 3.1: Il Distanziere
I codici delle citt`a vengono prelevati da un apposito file CSV (comma sepa-
rated value) mostrato in figura 3.2. Come si vede dall’immagine per ogni citt`a
sono memorizzate 5 informazioni: il nome, la sigla della provincia, il codice e le
coordinate geografiche.
Figura 3.2: Struttura file citt`a
Definizione dei porti e degli interporti
Dal file in figura 3.2 non `e possibile distinguere univocamente tutte le citt`a
portuali (o interportuali), infatti alcune citt`a come Trieste e Padova hanno il
codice che identifica esclusivamente la zona portuale (o interportuale) (Trieste
Porto, Padova Interporto, ecc), mentre citt`a come Marghera e Segrate, ad
esempio, non vengono considerate.
`E stato quindi necessario definire staticamente tutte le citt`a portuali (o inter-
portuali) di interesse per il generatore; esse sono Genova, La Spezia, Livorno,
Marghera, Trieste, Bologna, Segrate, Verona, Padova e Fernetti.
11

15. La Lista delle Citt`a
Una volta quindi definite le citt`a portuali e le province di interesse per il pro-
gramma si procede alla lettura del file csv per la realizzazione della Lista delle
Citt`a.
PORTO /
INTERPORTO?
APRI FILE CITTA’
LEGGI RIGA FILE
PROVINCIA
CONSENTITA?
MEMORIZZA CITTA’
ULTIMA RIGA?
CHIUDI FILE
NO NO
SI SI
NO
SI
Figura 3.3: Creazione lista casuale citt`a
Come mostrato in figura 3.3 un ciclo infinito legge ciascuna riga 1
; per ciascu-
na di queste ci si chiede se si tratta di un porto/interporto oppure se appartiene
ad una provincia consentita.
Per effettuare il primo test si confronta il nome della citt`a prelevato dalla riga
con la lista dei porti/interporti: se l’esito `e positivo il field booleano viene set-
tato a true, viene creata una nuova istanza della classe che viene aggiunta alla
Lista delle Citt`a e si passa alla riga successiva; se l’esito `e negativo il field
booleano viene settato a false e si controlla se il campo provincia prelevato
coincide con uno degli elementi della lista delle province consentite: se l’esito
`e positivo si crea una nuova istanza e la si aggiunge alla Lista delle Citt`a,
altrimenti si passa alla riga successiva.
Filtraggio numero citt`a
Un altro aspetto importante `e la limitazione del numero totale di citt`a da con-
siderare: per ridurre i tempi di creazione della Matrice delle Distanze, che con-
terrebbe pi`u di 200 milioni di elementi, si `e deciso di considerare casualmente
dei comuni appartenenti a province scelte arbitrariamente.
1In realt`a il file contiene anche citt`a straniere, ma ai fini della tesi si `e deciso di prelevare
solo quelle italiane, che sono 16070
12

16. Realizzazione della Matrice
A questo punto si ha una lista che contiene porti, interporti e citt`a appartenenti
alle province consentite (inclusi i capoluoghi); per ogni citt`a della lista viene
calcolata la distanza da tutte le altre citt`a tramite il Distanziere. 2
Questa matrice infine viene salvata sul file binario matrice.dat e i nomi delle
citt`a corrispondenti nel file di testo header.txt.
3.1.2 La generazione degli ordini
La realizzazione della Lista delle citt`a e della Matrice delle Distanze per-
mette di procedere alla generazione degli ordini.
Essi vengono generati in modo da coprire tutta la settimana lavorativa a partire
dalle 8:00 del luned`ı. Vengono generate quattro istanze di viaggi:
• ONEWAY brevi
• ONEWAY lunghi
• ROUND TRIP brevi
• ROUND TRIP lunghi
Un viaggio viene considerato breve quando la distanza totale stimata percorsa
dal camion `e inferiore a 200 km, viene invece considerato lungo quando la di-
stanza pu`o raggiungere 800 km.
Ai fini del calcolo di potenziali triangolazioni (spiegate pi`u in dettaglio nel
capitolo 3.3) vengono generati casualmente altri due parametri:
• CARRIER / MERCHANT
• CONTAINER OWNER
Un viaggio `e di tipo CARRIER quando l’intera tratta `e pagata dalla compa-
gnia marittima, `e di tipo MERCHANT invece quando il costo del viaggio `e a
carico della ditta di trasporto.
Il CONTAINER OWNER rappresenta il vettore marittimo proprietario del
contenitore utilizzato per il viaggio (sono stati scelti arbitrariamente MAERSK,
MSC, EVERGREEN).
In figura 3.4 si mostra la struttura generale del programma:
GENERATORE
GENERATORE
MATRICE
csv
DISTANZIERE
MATRICE
HEADER
RISULTATI
LETTURA FILE E
GENERAZIONE
ORDINI
ANALIZZATORE
TRIANGOLAZIONI
Figura 3.4: Dalla generazione all’analisi
Il risultato in output `e rappresentato da un file di testo (esempio in figura
3.5), ciascuna riga rappresenta un ordine ed `e strutturata come segue:
2Se le due citt`a coincidono, il Distanziere ritorna 0
13

17. IMPORT;MERCHANT;ROUNDTRIP;MSC;
MARGHERA;VENEGAZZU’;TV;MARGHERA;
49,5;49,5;99;
24/10/2016;08:00;24/10/2016;09:00;25/10/2016;10:00;
12,224575;45,463936;12,092204;45,779556;12,224575;45,463936
La prima riga contiene informazioni generali dell’ordine, la seconda contiene
le citt`a (indicando anche la provincia per il punto B), la terza riga indica le
distanze tra le citt`a e la distanza totale, la quarta riga indica le date e gli orari
previsti per ogni citt`a ed infine la quinta riga indica le coordinate geografiche di
ogni citt`a. Il risultato di una generazione di ordini ONEWAY lunghi `e mostrato
in figura 3.5:
Figura 3.5: File ordini generati
3.2 Visualizzazione ordini
Per capire meglio come funziona il Generatore si `e deciso di visualizzare le citt`a
scelte per gli ordini su una mappa, visualizzando il percorso che dovrebbe essere
effettuato dal camion.
3.2.1 OpenLayers
Per la visualizzazione si `e deciso di utilizzare OpenLayers, una libreria open
source realizzata in javascript che permette di inserire una mappa dinamica
all’interno di una pagina web. [22]
In maniera analoga a Google Maps e Bing Maps viene fornita una API per lo
sviluppo di applicazioni geografiche web-based. Come si vede dalla figura 3.6
OpenLayers `e in grado di comunicare tramite vari protocolli.
14

18. Figura 3.6: Openlayers `e in grado di comunicare tramite vari protocolli. [23]
OpenLayers supporta:
• GeoRSS;
• KML (Keyhole Markup Language);
• GML (Geography Markup Language);
• GeoJSON;
• altre sorgenti dati le cui specifiche sono state imposte dal Open Geospatial
Consortium (OGC), quali WMS (Web Map Service) e WFS (Web Feature
Service)
3.2.2 GeoJSON
Per questo progetto si `e deciso di utilizzare il formato dati GeoJSON, un for-
mato aperto realizzato per rappresentare caratteristiche (features) geografiche
descritte da attributi non spaziali, basato sul formato JavaScript Object Nota-
tion (JSON).
Queste features sono:
• punti (indirizzi, localit`a);
• linee (strade, autostrade e confini);
• poligoni (citt`a, regioni e aree di terreno);
• strutture complesse contenenti le features precedenti.
15

19. Le specifiche del formato vennero terminate nel Giugno 2008 e nell’Agosto 2016
IETF rilasci`o GeoJSON come RFC 7946. [24]
Di seguito si mostra un esempio di codice GeoJSON:
Listing 3.1: Esempio GeoJSON
{ "type": "FeatureCollection",
"features": [
{ "type": "Feature",
"geometry": {"type": "Point", "coordinates": [102.0, 0.5]},
"properties": {"prop0": "value0"}
},
{ "type": "Feature",
"geometry": {
"type": "LineString",
"coordinates": [
[102.0, 0.0], [103.0, 1.0], [104.0, 0.0], [105.0, 1.0]
]
},
"properties": {
"prop0": "value0",
"prop1": 0.0
}
},
{ "type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates": [
[ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],
[100.0, 1.0], [100.0, 0.0] ]
]
},
"properties": {
"prop0": "value0",
"prop1": {"this": "that"}
}
}
]
}
3.2.3 Implementazione
Per ottenere il file GeoJSON a partire dalla lista testuale degli ordini `e stato
necessario effettuare un parsing; tale operazione viene effettuata da uno script
realizzato in linguaggio Python (di cui un estratto del codice viene mostrato nel
listato 3.2).
Per ogni riga scansionata lo script effettua le seguenti operazioni:
• crea una feature point per ogni citt`a trovata
• per ognuna di queste features inserisce come properties nomi, orario e data
di ogni citt`a
16

20. • crea una feature contenente i 3 punti realizzati
• a questa feature si aggiungono come propriet`a le caratteristiche dell’ordine
(IMPORT/EXPORT, ecc.)
Al termine della scansione tutte le features create vengono inserite all’interno di
una struttura pi`u complessa chiamata featureCollection, che a sua volta viene
memorizzata all’interno di un file JSON.
Listing 3.2: Estratto di codice Python
for item in coords:
orders = item.split(";")
if len(orders) > 1:
if orders[0] != "IM-EX":
pntA = geojson.Point((float(orders[17].replace(",",".")),
float(orders[18].replace(",",".")))) #PUNTO A
featA = geojson.Feature(geometry=pntA, properties={"name":
orders[4], "date": orders[11], "hour": orders[12]})
pntB = geojson.Point((float(orders[19].replace(",",".")),
float(orders[20].replace(",",".")))) #PUNTO B
featB = geojson.Feature(geometry=pntB, properties={"name":
orders[5] + ’ (’ + orders[6] + ’)’, "date": orders[13],
"hour": orders[14]})
pntC = geojson.Point((float(orders[21].replace(",",".")),
float(orders[22].replace(",",".")))) #PUNTO C
featC = geojson.Feature(geometry=pntC, properties={"name":
orders[7], "date": orders[15], "hour": orders[16]})
thisFeat = geojson.FeatureCollection([featA, featB, featC],
properties={"index": count,"im_ex": orders[0], "me_ca":
orders[1], "ro_on": orders[2], "owner": orders[3]})
featColl.append(thisFeat)
count = count + 1
coll = geojson.FeatureCollection(featColl)
dump = geojson.dumps(coll, sort_keys=True)
out_file.write(dump)
3.2.4 Pagina Web
L’ultimo passo che permette la visualizzazione su mappa degli ordini `e la rea-
lizzazione di una pagina web.
Questa pagina `e stata realizzata per permettere all’utente di filtrare la visualiz-
zazione degli ordini sia per giorno sia per fascia oraria.
La pagina contiene codice JavaScript per implementare le API OpenLayers e
per leggere il file JSON realizzato precedentemente; il risultato della lettura e
della elaborazione viene mostrato in fugura 3.7.
17

21. Figura 3.7: Visualizzazione ordini su pagina web
In figura 3.7 si mostra il risultato della generazione degli ordini, filtrando
quelli previsti per il gioved`ı pomeriggio della settima considerata. 3
Com’`e possibile vedere, nella mappa vengono evidenziati
• il tipo di viaggio: icona blu per IMPORT; icona rossa per EXPORT
• retta di collegamento verde (pi`u marcata) per tratto di viaggio con carico;
retta rossa (pi`u sottile) per viaggio a vuoto
Inoltre per ciascun punto `e mostrata la data e l’orario previsti.
3.3 Analisi ordini
In questo capitolo si mostrano due funzionalit`a aggiuntive del programma:
• verifica esistenza triangolabilit`a viaggi
• visualizzazione ordini della mattina o del pomeriggio di uno specifico
giorno
Triangolazione Ricordando quanto descritto in sezione 2.3, i viaggi possono
essere di tipo import oppure di tipo export.
In certi casi `e possibile combinare queste due tipologie in un unico viaggio
sfruttando il contenitore vuoto (figura 3.8); le ipotesi principali per cui si pu`o
verificare questo evento sono:
• vicinanza spaziale e temporale tra il punto B del viaggio import (B1) ed
il punto B del viaggio export successivo (B2);
• il container utilizzato deve appartenere alla stessa compagnia marittima
(salvo specifici accordi);
3La data e l’orario fanno riferimento alla citt`a B
18

22. • compatibilit`a del contenitore richiesto dai viaggi (container da 40’ non
compatibile con mezzo che trasporta contenitori da 20’);
• compatibilit`a tra la merce trasportata nei due viaggi (se deve essere espor-
tata merce alimentare allora nel viaggio di importazione non dev’essere
presente merce che ne possa compromettere il contenuto);
A1 B1/B2 C2
USO CONTAINER VUOTO
IMPORT EXPORT
Figura 3.8: Triangolazione Import-Export
Per semplicit`a il programma tiene conto solo della vicinanza spaziale/temporale
degli ordini e del proprietario del container. I risultati dell’analisi sono mostrati
in figura 3.9, dove vengono evidenziate le tratte con carico (verdi) e le tratte a
vuoto (rosse).
Figura 3.9: Visualizzazione triangolabilit`a su pagina web
Distribuzione ordini L’ultima funzionalit`a del programma riguarda la pos-
sibilit`a di filtrare gli ordini per mattina o pomeriggio di un giorno specifico;
come gi`a mostrato in figura 3.7, nella mappa vengono visualizzati solo gli ordini
il cui arrivo nel punto B `e previsto per il gioved`ı pomeriggio della settimana
scelta.
19

23. Capitolo 4
Algoritmo sviluppato
Come `e stato illustrato nella sezione 2.3, all’interno dell’azienda `e la figura del
pianificatore che si occupa di gestire le assegnazioni viaggi-autista: il suo ruolo
quotidiano `e di risolvere i problemi sorti la nottata precedente e pianificare i
viaggi per la giornata successiva.
In generale durante il lavoro di pianificazione esso cerca di tenere conto di tutta
la settimana, ma pone sempre particolare attenzione alla giornata successiva.
4.1 Problema multi-obiettivo
Lo scopo della tesi quindi `e la realizzazione di un algoritmo che sia in grado
di ottimizzare la gestione di una flotta di veicoli tenendo conto di pi`u giorni,
completando il maggior numero possibile di ordini e minimizzando il numero di
viaggi a vuoto, in quanto comportano maggiori spese. Una volta che `e stato
completato un ordine quindi, l’algoritmo deve decidere quale deve essere l’or-
dine successivo da assegnare ad un determinato autista. Le decisione presa `e
influenzata sia dallo stato attuale della flotta sia dalla conoscenza degli ordini
futuri assegnabili; maggiore `e la conoscenza del futuro migliori saranno le solu-
zioni elaborate dall’algoritmo. Per questo motivo, data la natura temporale del
problema, si `e deciso di utilizzare la tecnica della programmazione dinamica.
4.2 Richiamo sulla programmazione dinamica
La programmazione dinamica `e un metodo di ottimizzazione dove un problema
complesso viene scomposto in una sequenza di problemi pi`u semplici;
questo metodo `e simile alla tecnica divide et impera, ma mentre quest’ultima
genera molti sotto-problemi identici da risolvere ad ogni chiamata ricorsiva, la
programmazione dinamica memorizza di volta in volta le soluzioni in modo da
renderle disponibili senza ulteriori calcoli. Per questo motivo, a fronte di un
utilizzo maggiore di memoria, il tempo di elaborazione `e inferiore.
4.2.1 Formalizzazione del metodo
I concetti principali della programmazione dinamica sono:
20

24. • periodo: descrivibile come l’unit`a di elaborazione del problema non ulte-
riormente scomponibile. La scomposizione di un problema complesso in N
periodi, risolvendone sequenzialmente uno alla volta, `e la caratteristica es-
senziale della programmazione dinamica: ogni periodo viene risolto come
un classico problema di ottimizzazione, la cui soluzione viene utilizzata per
definire le caratteristiche del periodo seguente. Da notare che il concetto
di periodo, tuttavia, non deve essere obbligatoriamente temporale;
• stato: ad ogni periodo del problema di ottimizzazione `e associato uno sta-
to; esso contiene l’informazione necessaria per capire quali possono essere
le ripercussioni che una decisione presa adesso pu`o avere nel futuro;
• ottimizzazione ricorsiva: la procedura di ottimizzazione ricorsiva per-
mette di risolvere un problema di N periodi trovando la soluzione di un
problema mono-periodo includendo sequenzialmente i periodi successivi
finch´e non viene raggiunto l’ottimo globale.
Nel caso di questa tesi il metodo della programmazione dinamica viene ap-
plicato al singolo camion, con lo scopo di trovare la sequenza di ordini che
minimizza la somma dei viaggi a vuoto, pertanto il periodo viene rappresentato
dall’ordine mentre lo stato viene rappresentato dalla citt`a dove si trova l’autista
al termine dell’esecuzione di un ordine (e quindi anche l’orario di disponibilit`a).
Definiamo funzione di costo di un periodo la funzione fn(dn, sn), dove dn
rappresenta una decisione ammissibile scelta dall’insieme Dn delle decisioni am-
missibili e sn lo stato del processo quando mancano n periodi.
L’obiettivo del progetto `e la scelta della sequenza migliore di variabili decisionali
dn, dn−1, ..., d0 per risolvere i seguenti problemi:
vn(ss) = min[fn(dn, sn) + fn−1(dn−1, sn−1) + ... + f0(d0, s0)]
soggetti a:
sm−1 = tm(dm, sm) (m = 1, 2, ..., n),
dm ∈ Dm (m = 0, 1, ..., n).
Si definisce vn(sn) funzione del valore ottimo; essa rappresenta il costo com-
plessivo di tutti i periodi.
In questo progetto si `e deciso di dividere la giornata lavorativa in due periodi,
mattina e pomeriggio, assumendo che un autista riesca a portare a termine al
massimo due ordini al giorno e si `e deciso ottimizzare la pianificazione sull’intera
settimana lavorativa per un totale di 10 periodi. 1
1Queste scelte sono state fatte per facilitare la spiegazione, in realt`a l’algoritmo pu`o essere
esteso dividendo la giornata lavorativa in pi`u di 2 periodi e considerando una pianificazione
relativa a pi`u di 5 giorni.
21

25. 4.3 Realizzazione
4.3.1 Semplificazioni rispetto alla realt`a
Dal momento che lo scopo principale del progetto `e la dimostrazione dell’efficacia
della programmazione dinamica per la gestione della flotta dei veicoli si `e deciso,
per motivi di semplificazione, di:
• considerare autista e camion un’unica entit`a;
• non fare distinzioni tra:
– tipo di merce;
– tipo di container;
– compagnia marittima;
• considerare come unico vincolo legale le ore di sonno al giorno previste per
legge, fissate a 9;
• all’inizio della settimana lavorativa si conoscono gi`a tutti gli ordini previsti
(orizzonte temporale);
Il progetto quindi pu`o essere facilmente esteso per integrare nuovi vincoli.
4.3.2 Definizione dell’orizzonte temporale
Come descritto precedentemente gli ordini vengono organizzati in dieci gruppi,
come rappresentato in tabella 4.3.2
Luned`ı Marted`ı Mercoled`ı Gioved`ı Venerd`ı
Mat Pom Mat Pom Mat Pom Mat Pom Mat Pom
O1m1
O1p1
O2m1
O2p1
O3m1
O3p1
O4m1
O4p1
O5m1
O5p1
O1m2
O1p2
O2m2
O2p2
O3m2
O3p2
O4m2
O4p2
O5m2
O5p2
...
...
...
...
...
...
...
...
...
...
O1mn1
O1pn2
O2mn3
O2pn4
O3mn5
O3pn6
O4mn7
O4pn8
O5mn9
O5pn10
Tabella 4.1: Orizzonte temporale
In tabella si mostra la disposizione degli ordini lungo la settimana lavorativa:
n1, ..., n10 rappresentano il numero di ordini disponibili per ogni suddivisione,
ad esempio per il Luned`ı pomeriggio sono previsti n2 ordini (da O1p1 a O1pn2 ).
Dato N il numero totale degli ordini generati deve valere:
10
i=1
ni = N
22

26. Idea di sviluppo Di seguito si vuole mostrare graficamente il funzionamento
del metodo della programmazione dinamica: si considera un autista che fa capo
alla filiale di Segrate con disponibilit`a dalle ore 7 del Luned`ı mattina e si consi-
derano tre ordini, di cui due previsti per la mattina stessa (4.3.2) e uno per il
pomeriggio (4.3.2).
Gli ordini considerati sono i seguenti:
ORDINE 1 ORDINE 2
A SEGRATE 13:00 SEGRATE 11:00
B CABIATE (CO) 14:00 ARCONATE (MI) 12:00
C SEGRATE 15:00 MILANO CERTOSA 13:00
KM a vuoto 34,5 KM a vuoto 51,2
Tabella 4.2: Ordini del Luned`ı mattina
ORDINE 3
A MILANO CERTOSA 16:00
B TESSERA (MI) 17:00
C SEGRATE 18:00
KM a vuoto 37,5
Tabella 4.3: Ordine del Luned`ı pomeriggio
Caso 1 Si supponga di conoscere solo gli ordini del periodo 1 (Luned`ı mattina),
quindi ORDINE 1 e ORDINE 2 (4.3.2); dal confronto dei km a vuoto si decide
di scegliere ORDINE 1 in quanto 34, 5 < 51, 2; pertanto questa scelta permette
una spesa minore.
Si mostra in figura 4.1 il risultato grafico della scelta.
Figura 4.1: Decisione con un periodo conosciuto
Caso 2 Si supponga ora di conoscere anche gli ordini del Luned`ı pomeriggio,
quindi ORDINE 3 (4.3.2). In questo caso la scelta dell’ordine della mattina
23

27. ricade su ORDINE 2 in quanto la citt`a di arrivo `e MILANO CERTOSA, che
coincide con la citt`a di partenza di ORDINE 3.
Conclusione Si prende atto che con la sequenza ORDINE 2 - ORDINE 3 si
percorrono meno km a vuoto rispetto alla sequenza ORDINE 1 - ORDINE 3, ma
soprattutto si porta a termine un numero maggiore di ordini; si visualizza
il risultato in figura 4.2.
Figura 4.2: Decisione con due periodi conosciuti
Nota Aumentando il numero di periodi potremmo subire variazioni sulla scel-
ta sia di ORDINE 2 sia di ORDINE 3.
4.4 Sviluppo del programma
Il programma di pianificazione `e strutturato in modo da ricevere in input la lista
degli ordini creati dal Generatore e la composizione della flotta e ritornare come
output un unico file di testo contenente la programmazione settimanale della
flotta; ci`o `e rappresentato da una lista di ordini (catena) associata a ciascun
autista.
24

28. INIZIO
FINE
LISTA
ORDINI
AUTISTI
PIANIFICATORE
PIANIFICAZIONE
FLOTTA
Figura 4.3: Panoramica programma di pianificazione
Come si vede in figura 4.3 i file in input sono
• la lista degli ordini creati dal Generatore;
• la Matrice delle Distanze;
• la lista delle filiali;
• la lista degli autisti.
Il parametro principale per l’esecuzione `e rappresentato dal numero di periodi
di programmazione.
4.4.1 Analisi ordini
La prima azione svolta dal pianificatore `e l’importazione degli ordini ed il
prelievo dei dati di interesse per le fasi successive. Questi dati sono:
25

29. • le citt`a A, B e C con le rispettive date ed orari;
• le distanze tra le stesse espresse in km.
Orizzonte temporale
La fase successiva consiste nella definizione dell’orizzonte temporale di pianifi-
cazione: gli ordini appena letti vengono distribuiti in 10 distinti gruppi, in base
al giorno e fascia oraria, definita considerando il mattino dalle 8 alle 13, mentre
il resto `e considerato pomeriggio.
Si ottiene il risultato mostrato in tabella 4.3.2.
Ordini fattibili
La costruzione delle catene di ordini successivi da assegnare ad ogni autista `e
realizzata attraverso l’analisi di fattibilit`a: in questa fase si verifica se e quali
ordini possono essere svolti da un autista a partire dallo stato attuale si. La
verifica tra due ordini on e om (n = m) viene eseguita confrontando l’orario di
arrivo previsto al punto C di on con l’orario del punto A dell’ordine om (se on
`e previsto per il pomeriggio si aggiunge un’ulteriore parametro per indicare le
ore di sonno).
Quindi se vale:
ORAC(on) + h + hd < ORAA(om)
dove h `e la distanza stimata in ore tra CITTAC(on) e CITTAA(om) e hd il
numero di ore di sonno previste per legge allora om viene aggiunto alla lista dei
candidati successori di on.
26

30. ORD –
ORD –
ORD –
OK
NO
ORD –OK
PERIODO 1 PERIODO 2
ORARIO C < ORARIO A ?
ANALISI FATTIBILITA ORDINE SUCCESSIVO
ORA A
ORA A
ORA A
ORA C
PREVISTA
Figura 4.4: Fattibilit`a ordine successivo
A partire quindi dall’orizzonte temporale definito precedentemente il tabella
4.3.2 si esegue un ciclo di scansione per ogni ordine del Luned`ı mattina (gruppo
1), verificando per ciascuno di questi la fattibilit`a con gli ordini del Luned`ı po-
meriggio (gruppo 2): in questo modo si ottiene una lista di tutte le combinazioni
possibili e fattibili. Se la condizione di fattibilit`a non dovesse venire soddisfatta
si memorizza ugualmente l’ordine in quanto lo si confronter`a con gli ordini del
Marted`ı mattina (gruppo 3).
Supponendo di voler fare una pianificazione basata su quattro periodi, al ter-
mine del ciclo otterremo un insieme di liste, le pi`u lunghe avranno dimensione
4 e le pi`u corte avranno dimensione 1.
Ottimizzazione ricorsiva
A questo punto dell’elaborazione si procede con l’ottimizzazione ricorsiva, mo-
strata in figura 4.5, applicando il metodo backward induction (induzione a ritro-
so): grazie a questo metodo si ottengono le sequenze migliori senza contenere
ordini in comune.
27

31. 1
1
2
2 3
41 2 3
1 2 3 4
1 2 3 4
5
1
5
2 3 4 5 6
6
OTTIMIZZAZIONE RICORSIVA
PERIODO 6
PERIODO 5
PERIODO 4
PERIODO 3
PERIODO 2
PERIODO 1
Figura 4.5: Esempio di ottimizzazione ricorsiva per 6 periodi
Backward induction In figura 4.6 si mostra l’implementazione del metodo
dell’induzione a ritroso: questo metodo permette di ottenere una sequenza di
liste che minimizzano la somma delle distanze tra gli ordini.
28

32. INIZIO
LETTURA
SEQUENZA
FINE
MIGLIORE?
NO
AGGIUNGO A
LISTA MIGLIORI
SI
ELIMINO SEQUENZE
DALLA LISTA
CONTROLLATITUTTI?
NO
SI
Figura 4.6: Induzione a ritroso
4.4.2 Definizione delle strutture dati
Per questo progetto si `e deciso di utilizzare la programmazione dinamica con-
siderando fino a sei periodi di pianificazione (tre giorni lavorativi), pertanto il
programma genera sei diversi output: in ognuno di questi vi `e memorizzata
la pianificazione settimanale per ogni autista della flotta in base al numero di
periodi di decisione. Per rendere disponibili i risultati per la pianificazione si `e
deciso di realizzare una classe contenente una matrice tri-dimensionale irregola-
re (jagged array).
Ogni esecuzione dell’ottimizzazione ricorsiva genera la matrice appena citata
che viene memorizzata nella struttura mostrata in figura 4.7.
29

33. ELENCO LISTE
PERIODO 1
ELENCO LISTE
PERIODO 2
ELENCO LISTE
PERIODO 3
ELENCO LISTE
PERIODO 4
ELENCO LISTE
PERIODO 5
ELENCO LISTE
PERIODO 6
ELENCO LISTE
PERIODO 1
ELENCO LISTE
PERIODO 2
ELENCO LISTE
PERIODO 3
ELENCO LISTE
PERIODO 4
ELENCO LISTE
PERIODO 5
ELENCO LISTE
PERIODO 6
10 LISTE 5 LISTE 4 LISTE 2 LISTE 2 LISTE 2 LISTE
PROBLEMA DI ASSEGNAZIONE LISTE - CAMION
Figura 4.7: Realizzazione catene ordini
Come descritto poco fa, ogni oggetto contiene una matrice tri-dimensionale
irregolare in cui ciascun elemento `e il codice identificativo dell’ordine ed `e
rappresentato come segue:
v[i][j][k]
Significato degli indici Si illustra di seguito il significato degli indici i, j e
k:
Periodo 1 




O11
O21
...
OA11










O12
O22
...
OA22





. . .





O110
O210
...
OA1010





In questo caso si considera solo un periodo di previsione, quindi non vi sono rag-
gruppamenti; si ottengono pertanto 10 liste in cui le sotto-liste sono composte
da 1 elemento.
• i identifica ciascuna delle 10 liste;
• j identifica le sotto-liste delle liste identificate da i;
• k identifica il singolo elemento della sotto-lista, quindi il codice dell’ordine;
in questo caso vale sempre 0.
Periodo 2









O11
O12
O21 O22
...
...
OB11 OB12


















O13
O14
O23 O24
...
...
OB23 OB24









. . .









O19
O110
O29 O210
...
...
OB59 OB510









In questo caso si considerano 2 periodi di previsione, si ottengono pertanto
10/2 = 5 liste in cui le sotto-liste sono composte da 2 elementi.
• i identifica ciascuna delle 5 liste;
• j identifica le sotto-liste delle liste identificate da i;
• k identifica il singolo elemento della sotto-lista, quindi il codice dell’ordine.
30

34. Periodo 3









O11 O12 O13
O21
O22
O23
...
...
...
OC11
OC12
OC13









. . .









O17 O18 O19
O27
O28
O29
...
...
...
OC37
OC38
OC39


















O110
O210
...
OA1010









In questo caso si considerano 3 periodi di previsione, si ottengono pertanto
10/3 = 3 liste composte da 3 elementi e la restante `e composta da un elemento.
• i identifica ciascuna delle 4 liste;
• j identifica le sotto-liste delle liste identificate da i;
• k identifica il singolo elemento della sotto-lista, quindi il codice dell’ordine.
Periodo 4









O11 O12 O13 O14
O21
O22
O23
O24
...
...
...
...
OD11
OD12
OD13
OD14


















O15 O16 O17 O18
O25
O26
O27
O28
...
...
...
...
OD25
OD26
OD27
OD28


















O19
O110
O29
O210
...
...
OB59
OB510









In questo caso si considerano 4 periodi di previsione, si ottengono pertanto
10/4 = 2 composte da 3 elementi e la restante `e composta da 2 elementi.
• i identifica ciascuna delle 3 liste;
• j identifica le sotto-liste delle liste identificate da i;
• k identifica il singolo elemento della sotto-lista, quindi il codice dell’ordine.
Periodo 5









O11 O12 O13 O14 O15
O21
O22
O23
O24
O25
...
...
...
...
...
OE11
OE12
OE13
OE14
OE15


















O16
O17
O18
O19
O110
O26
O27
O28
O29
O210
...
...
...
...
...
OE26
OE27
OE28
OE29
OE210









In questo caso si considerano 5 periodi di previsione, si ottengono pertanto
10/5 = 2 liste composte da 5 elementi.
• i identifica ciascuna delle 2 liste;
• j identifica le sotto-liste delle liste identificate da i;
• k identifica il singolo elemento della sotto-lista, quindi il codice dell’ordine.
31

35. Periodo 6









O11 O12 O13 O14 O15 O16
O21
O22
O23
O24
O25
O16
...
...
...
...
...
...
OF 11
OF 12
OF 13
OF 14
OF 15
OF 16


















O17
O18
O19
O110
O27
O28
O29
O210
...
...
...
...
OD37
OD38
OD39
OD310









In questo caso si considerano 6 periodi di previsione, si ottiene pertanto 10/6 =
1 lista composta da 6 elementi e la restante `e composta da 4 elementi.
• i identifica ciascuna delle 2 liste;
• j identifica le sotto-liste delle liste identificate da i;
• k identifica il singolo elemento della sotto-lista, quindi il codice dell’ordine.
4.4.3 Definizione dello stato
Lo stato del sistema viene rappresentato dallo stato della flotta, e quindi di
ciascun autista. Pertanto un autista, a livello di programma, `e rappresentato
da una classe i cui campi sono:
• codice identificativo (cod);
• filiale di appartenenza (fil);
• posizione attuale (pos);
• orario di disponibilit`a (ora);
• lista degli ordini assegnati (list).
Si mostra graficamente la classe in figura 4.8.
Figura 4.8: Stato autista
Allo stato iniziale s0 di ciascun autista si ha che pos ≡ fil, ora `e fissata,
come parametro, alle 05:00 e list non contiene nessun elemento.
Lo stato di un autista si aggiorna quando gli viene assegnato un ordine fattibile
32

36. ord: in questo caso questo ordine viene inserito nella lista delle assegnazioni
dell’autista list, il campo posizione diventa la citt`a C dell’ordine, cio`e pos =
ordC e l’orario di disponibilit`a viene incrementato del tempo impiegato per
raggiungere la citt`a A dell’ordine sommato al tempo per completare l’ordine
stesso, quindi ora = ora + (distF A + distord)/vel, dove vel `e la velocit`a media
stimata del camion, impostata come parametro.
4.4.4 Assegnazione
Come descritto precedentemente, al termine dell’ottimizzazione ricorsiva si ot-
tengono P matrici tri-dimensionali, dove P `e il numero di stage scelto per la
pianificazione; in base al valore di P varia il numero di gruppi di sequenze di
ordini da assegnare:
P Gruppi
1 10
2 5
3 4
4 3
5 2
6 2
Tabella 4.4: Numero di gruppi di sequenze in base al numero di stage
L’ultima fase del programma consiste nell’assegnazione agli autisti dei gruppi
creati. Sono stati analizzati vari algoritmi ([27] [28] [29] [30] [31] [32] [33] [34]
[35], [36] [37] [38]) e in questo progetto si `e deciso di utilizzare l’algoritmo
ungherese [25], in particolare la versione sbilanciata [26].
Algoritmo ungherese
L’algoritmo ungherese `e un metodo di ottimizzazione che permette di risolvere
in tempo polinomiale (O(n3
)) il problema dell’assegnamento: a partire da due
insiemi distinti si vuole associare gli elementi creando delle coppie, dal momento
che ciascuna coppia ha un costo il suo scopo `e di minimizzare la somma totale
dei costi. Formalizzando, data una matrice nxn di costi cij si vuole trovare una
permutazione f di 1, 2, ..., n che minimizzi
n
i=0
cif(i)
Nel caso di questo progetto i due insiemi sono rappresentati dalla flotta e dai
gruppi di sequenze di ordini, mentre i costi sono rappresentati dalla distanza in
chilometri tra la posizione attuale dell’autista e la citt`a A dell’ordine successivo
33

37. distP A. La matrice dei costi assume quindi la seguente forma:





d11 d12 . . . d1n
d21 d22 . . . d2n
...
...
...
...
dn1 dn2 . . . dnn





Dove dij indica la distanza tra la posizione attuale dell’autista i e la citt`a A
dell’ordine j. L’algoritmo fornisce in output un vettore di n elementi nella
seguente forma
v = [b0, b1, ..., bn−1]
dove il valore i-esimo rappresenta la coppia autista i, ordine bi.
Problema sbilanciato
Si definisce Na il numero di autisti che compone la flotta e NM la dimensione
del gruppo M-esimo: si ha che NM = Na, quindi la matrice dei costi non `e
quadrata.
Ci si trova quindi di fronte ad un problema di assegnazione non bilanciato (figura
4.9), non si pu`o quindi applicare il metodo dell’ungherese puro.
Figura 4.9: Come assegnare autista a gruppo?
Per ovviare a questo inconveniente si aggiungono alla matrice non quadrata
righe o colonne fittizie i cui elementi corrispondono a costi molto elevati (H) in
34

38. modo che l’algoritmo cerchi di non dargli priorit`a durante l’elaborazione.









d11 d12 . . . d1NM
d21 d22 . . . d2NM
...
...
...
...
dNa1 dNa2 . . . dNaNM
H H . . . H
H H . . . H














d11 d12 . . . d1NM
H H
d21 d22 . . . d2NM
H H
...
...
...
...
...
...
dNa1 dNa2 . . . dNaNM
H H





Si supponga che l’algoritmo ungherese fornisca il risultato di figura 4.10: `e
necessario eseguire un controllo di tutte le coppie perch´e pu`o capitare che ven-
ga fornita una assegnazione non fattibile. In questo caso lo stato dell’autista
coinvolto non viene aggiornato.
Figura 4.10: Assegnazione ottima
Termine dell’assegnazione
Finch´e ci sono ancora gruppi di sequenze di ordini a disposizione si itera il pro-
cedimento descritto finora a partire dal nuovo stato ottenuto.
Al termine dell’elaborazione ogni autista ha memorizzato la sequenza degli
ordini che deve eseguire.
4.5 Visualizzazione su mappa
La visualizzazione su mappa viene effettuata analogamente a come `e stato fatto
per la visualizzazione degli ordini creati dal Generatore; la differenza risiede nel
fatto che il file di testo generato dal Pianificatore `e composto da 6 gruppi, cio`e
uno per ogni orizzonte di pianificazione. Ciascuno di questi gruppi `e compo-
sto da un numero di righe pari al numero di camion che compone la flotta; a
35

39. sua volta ciascuna di queste righe contiene gli ordini assegnati al camion stes-
so. Anche il parsing del file contenente gli ordini viene effettuato in maniera
analoga: il risultato `e un file con estensione .json che viene letto dal codice
javascript della pagina web. Tale pagina permette di visualizzare la pianifi-
cazione settimanale del singolo autista, scegliendo il numero di stage desiderato.
In figura 4.11 si mostra un esempio di assegnazione per l’autista con codice
0 appartenente alla filiale di Segrate considerando uno stage di pianificazione;
in blu sono evidenziati gli ordini IMPORT, in rosso gli ordini EXPORT.
Figura 4.11: Assegnazione ad uno stage
36

40. Capitolo 5
Risultati
5.1 Visualizzazione su mappa
All’inizio di questo capitolo si vuole mostrare la differenza della distribuzione
delle assegnazioni in base al numero di stage; l’analisi verr`a fatta considerando
un autista che fa capo alla filiale di Segrate (MI).
Pianificazione ad uno stage In figura 5.1 `e illustrato il comportamento del
programma per una pianificazione ad uno stage.
Come `e possibile vedere dalla mappa gli ordini assegnati all’autista sono mol-
to localizzati; questo accade perch´e al termine dell’esecuzione di un ordine il
programma tende a cercare il successivo ordine in modo tale da minimizzare la
distanza d(o1, o2) per prelevare il nuovo contenitore, dove
d(o1, o2) = d(CITTAC(o1), CITTAA(o2))
Figura 5.1: Assegnazione ad uno stage
37

41. In questo caso, per la giornata del 24/10 `e stato assegnato un ordine la
cui durata non permette l’esecuzione di ulteriori ordini; infatti questo ordine `e
strutturato come segue:
A SEGRATE (MI) 11:00
B TRAVAGLINO (PV) 14:00
C MILANO CERTOSA (MI) 17:00
Tabella 5.1: Questo ordine non permette ulteriori pianificazioni per la giornata
Pianificazione a quattro stage In figura 5.2 `e illustrato il comportamento
del programma per una pianificazione a quattro stage.
Come `e possibile vedere dalla mappa gli ordini assegnati all’autista sono pi`u
distribuiti sul territorio; questo accade perch´e `e stata assegnata all’autista una
catena di ordini che coinvolge un maggior numero di porti/interporti.
Figura 5.2: Assegnazione a quattro stage
5.2 Analisi assegnazioni flotta
In questa sezione si vogliono mostrare i casi dove l’algoritmo fornisce i risultati
aspettati e i punti deboli.
Le analisi sono state fatte attraverso 10 generazioni casuali da 100 ordini cia-
scuna dove questi possono essere sia lunghi (entro 800 km) sia corti (entro 200
km).
La flotta considerata `e composta da 10 autisti distribuiti nel seguente modo:
• 1 a Milano Certosa;
• 1 a Bologna;
• 1 a Genova;
• 2 a Livorno;
• 1 a Verona;
38

42. • 1 a Padova;
• 2 a Trieste;
• 1 a La Spezia.
E’ stata decisa questa distribuzione in modo da cercare di ottenere assegnazioni
distribuite in maniera omogenea.
Nella realizzazione delle catene non sono stati imposti ne vincoli di distanza ne
vincoli temporali (fatta eccezione ovviamente per la fattibilit`a) tra ordini con-
secutivi.
I grafici illustrati di seguito sono riferiti all’intera flotta, e sono strutturati come
segue: lungo l’asse delle ascisse vengono indicati gli stage, da 1 a 4; lungo l’asse
delle ordinate vengono visualizzati rispettivamente:
• il totale dei km percorsi;
• km percorsi con container carico;
• km percorsi con container vuoto;
• km percorsi senza container.
`E stata aggiunta inoltre una linea di tendenza per mostrare il variare dei km
totali percorsi in funzione del numero di stage scelto.
5.2.1 Dove l’algoritmo funziona meglio
Attraverso varie esecuzioni casuali, distinguendo tra ordini oneway e roundtrip,
si `e constatato che l’algoritmo funziona meglio nel primo caso in quanto le citt`a
A e C sono distribuite in maniera meno localizzata. Come si vede dal grafico in
figura 5.3 il numero di km totali percorsi dalla flotta diminuisce con l’aumentare
del numero di stage, mentre quello dei km percorsi senza container aumenta:
questo `e dovuto dal fatto che con l’aumentare di stage gli autisti eseguono ordini
pi`u lontani rispetto alla loro filiale, aumentando il raggio di copertura.
39

43. 1 2 3 4
Totale 20519,46 18835,69 19021,77 19414,03
Container Pieno 9217,88 6810,51 6227,62 6459,63
Container Vuoto 9182,62 6496,54 6070,17 6303,19
Senza Container 2118,96 5528,64 6723,98 6651,21
20519,46
18835,69 19021,77 19414,03
9217,88
6810,51
6227,62 6459,63
9182,62
6496,54 6070,17 6303,19
2118,96
5528,64
6723,98 6651,21
0
5000
10000
15000
20000
25000
Media chilometri percorsi
Totale Container Pieno Container Vuoto Senza Container Lineare (Totale)
Figura 5.3: Assegnazione a quattro stage
Nel grafico in figura 5.4 si mette in risalto il fatto che, in media, all’aumen-
tare del numero di stage aumenta il numero di ordini portato a termine, e nel
contempo diminuisce il rapporto r tra km percorsi con container e km totali.
r =
distanzacontainer
distanzatotale
40

44. 71,1
82
74,9
78,1
0,898
0,706
0,648
0,658
64 66 68 70 72 74 76 78 80 82 84
1
2
3
4
1 2 3 4
Numero Ordini 71,1 82 74,9 78,1
km con Container / km totali 0,898 0,706 0,648 0,658
Numero ordini e Rapporto
Numero Ordini km con Container / km totali
Figura 5.4: Assegnazione a quattro stage
Concludendo, considerando ordini oneway, l’algoritmo fornisce risultati po-
sitivi all’aumentare del numero di stage.
5.2.2 Dove l’algoritmo funziona peggio
Nel corso delle varie simulazioni si `e visto invece che, elaborando ordini round-
trip, l’algoritmo non fornisce sempre risultati soddisfacenti. Infatti come si vede
nel grafico in figura 5.5, all’aumentare degli stage aumenta anche il numero to-
tale di km percorsi; questo perch´e in media aumenta il numero di km percorsi
senza contenitore in quanto A e C coincidono.
41

45. 1 2 3 4
Totale 19525,22 18916,26 20295,86 19313,24
Container Pieno 8821,88 6576,94 6324,7 6309,44
Container Vuoto 8881,98 6471,34 6317,26 6298,04
Senza Container 1821,36 5867,98 7653,9 6705,76
19525,22
18916,26
20295,86
19313,24
8821,88
6576,94 6324,7 6309,44
8881,98
6471,34 6317,26 6298,04
1821,36
5867,98
7653,9
6705,76
0
5000
10000
15000
20000
25000
Media chilometri percorsi
Totale Container Pieno Container Vuoto Senza Container Lineare (Totale)
Figura 5.5: Assegnazione a quattro stage
Dal punto di vista degli ordini coperti, invece, il loro numero aumenta
all’aumentare degli stage, come si vede nel grafico di figura 5.6.
74
86
83
85
0,908
0,692
0,622
0,654
66 68 70 72 74 76 78 80 82 84 86 88
1
2
3
4
1 2 3 4
Numero Ordini 74 86 83 85
km con Container / km totali 0,908 0,692 0,622 0,654
Numero ordini e Rapporto
Numero Ordini km con Container / km totali
Figura 5.6: Assegnazione a quattro stage
42

46. 5.2.3 Altre analisi
In questa sottosezione si mostrano analisi fatte per le quattro categorie principali
di viaggio:
• oneway corti;
• oneway lunghi;
• roundtrip corti;
• roundtrip lunghi.
Viaggi Oneway corti
Nei grafici delle figure 5.7 e 5.8 si mostra l’andamento dei chilometri totali
percorsi dalla flotta al variare del numero di stage per i viaggi corti di tipo
oneway.
1 2 3 4
Totale 15096,38 17059,31 18074,1 17092,77
Container Pieno 5538,5 5434,85 5229,73 5086,55
Container Vuoto 5622,77 5677,51 5363,33 5288,78
Senza Container 3935,11 5946,95 7481,04 6717,44
15096,38
17059,31
18074,1
17092,77
5538,5 5434,85 5229,73 5086,55
5622,77 5677,51 5363,33 5288,78
3935,11
5946,95
7481,04
6717,44
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
Media chilometri percorsi
Totale Container Pieno Container Vuoto Senza Container Lineare (Totale)
Figura 5.7: Chilometri percorsi per ordini oneway corti
43

47. 87
89
83
83
0,74
0,649
0,586
0,608
78 80 82 84 86 88 90 92
1
2
3
4
1 2 3 4
Numero Ordini 87 89 83 83
km con Container / km totali 0,74 0,649 0,586 0,608
Numero ordini e Rapporto
Numero Ordini km con Container / km totali
Figura 5.8: Numero ordini coperti per viaggi oneway corti
Viaggi Oneway lunghi
Nei grafici delle figure 5.9 e 5.10 si mostra l’andamento dei chilometri totali
percorsi dalla flotta al variare del numero di stage per i viaggi lunghi di tipo
oneway.
44

48. 1 2 3 4
Totale 25248,7 23037,25 22320,49 25722,04
Container Pieno 11864,03 10734,26 8264,01 10026,23
Container Vuoto 11888,2 10819,64 8363,64 10113,93
Senza Container 1496,47 1483,35 5692,84 5581,88
25248,7
23037,25
22320,49
25722,04
11864,03
10734,26
8264,01
10026,23
11888,2
10819,64
8363,64
10113,93
1496,47 1483,35
5692,84 5581,88
0
5000
10000
15000
20000
25000
30000
Media chilometri percorsi
Totale Container Pieno Container Vuoto Senza Container Lineare (Totale)
Figura 5.9: Chilometri percorsi per ordini oneway lunghi
51
50
42
50
0,941
0,936
0,745
0,785
0 10 20 30 40 50 60
1
2
3
4
1 2 3 4
Numero Ordini 51 50 42 50
km con Container / km totali 0,941 0,936 0,745 0,785
Numero ordini e Rapporto
Numero Ordini km con Container / km totali
Figura 5.10: Numero ordini coperti per viaggi oneway lunghi
45

49. Viaggi Roundtrip corti
Nei grafici delle figure 5.11 e 5.12 si mostra l’andamento dei chilometri totali
percorsi dalla flotta al variare del numero di stage per i viaggi corti di tipo
roundtrip.
1 2 3 4
Totale 14438,83 16338,4 18878,02 18107,21
Container Pieno 5399,89 5365,47 5273,09 5159,84
Container Vuoto 5399,89 5365,47 5273,09 5159,84
Senza Container 3639,05 5607,46 8331,84 7787,53
14438,83
16338,4
18878,02
18107,21
5399,89 5365,47 5273,09 5159,845399,89 5365,47 5273,09 5159,84
3639,05
5607,46
8331,84
7787,53
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
Media chilometri percorsi
Totale Container Pieno Container Vuoto Senza Container Lineare (Totale)
Figura 5.11: Chilometri percorsi per ordini roundtrip corti
46

50. 90
93
90
90
0,75
0,658
0,56
0,571
88 89 90 91 92 93 94
1
2
3
4
1 2 3 4
Numero Ordini 90 93 90 90
km con Container / km totali 0,75 0,658 0,56 0,571
Numero ordini e Rapporto
Numero Ordini km con Container / km totali
Figura 5.12: Numero ordini coperti per viaggi roundtrip corti
Viaggi Roundtrip lunghi
Nei grafici delle figure 5.13 e 5.14 si mostra l’andamento dei chilometri totali
percorsi dalla flotta al variare del numero di stage per i viaggi lunghi di tipo
roundtrip.
47

51. 1 2 3 4
Totale 14438,83 16338,4 18878,02 18107,21
Container Pieno 5399,89 5365,47 5273,09 5159,84
Container Vuoto 5399,89 5365,47 5273,09 5159,84
Senza Container 3639,05 5607,46 8331,84 7787,53
14438,83
16338,4
18878,02
18107,21
5399,89 5365,47 5273,09 5159,845399,89 5365,47 5273,09 5159,84
3639,05
5607,46
8331,84
7787,53
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
20000
Media chilometri percorsi
Totale Container Pieno Container Vuoto Senza Container Lineare (Totale)
Figura 5.13: Chilometri percorsi per ordini roundtrip lunghi
51
52
41
52
0,967
0,973
0,739
0,764
0 10 20 30 40 50 60
1
2
3
4
1 2 3 4
Numero Ordini 51 52 41 52
km con Container / km totali 0,967 0,973 0,739 0,764
Numero ordini e Rapporto
Numero Ordini km con Container / km totali
Figura 5.14: Numero ordini coperti per viaggi roundtrip lunghi
48

52. 5.2.4 Considerazioni sui risultati
Analizzando i risultati delle simulazioni risulta migliore la pianificazione consi-
derando due stage, dove si migliora notevolmente il rapporto tra il numero degli
ordini coperti rispetto al totale dei chilometri percorsi. Questo fatto probabil-
mente `e causato dal criterio di suddivisione delle sequenze di ordini lungo la
settimana lavorativa.
49

53. Capitolo 6
Conclusioni
6.1 Elementi non considerati
Per la realizzazione di questo progetto, sono state considerate classificazioni
degli ordini quali import/export e merchant/carrier, oltre al proprietario del
container; queste informazioni per`o non sono state utilizzate per la realizzazio-
ne del pianificatore in quanto ci si voleva concentrare sul miglioramento della
copertura degli ordini e della diminuzione dei chilometri percorsi.
Nei casi pratici tuttavia gli elementi considerati sono molti di pi`u, a partire
dalle caratteristiche dell’autista stesso (et`a, abilitazioni, esperienza..), dal tipo
di container (20 piedi, 40 piedi, HiCube ecc..), dal tipo di merce trasporta-
ta ecc. Tuttavia la struttura modulare del programma ne permette una facile
integrazione.
6.2 Considerazioni generali
Realizzazione delle catene Dalle varie analisi fatte si pensa che un punto
debole dell’algoritmo sia l’assegnazione delle catene agli autisti: quando una
catena viene assegnata ad un autista, vengono eliminate tutte le sequenze che
contengono gli ordini della catena; in questo modo pu`o facilmente capitare che
se gli ordini non sono ben distribuiti vengono eliminate molte catene ”lunghe”,
ne risulta quindi un numero inferiore assegnato alla flotta. Si `e notato inoltre
che la pianificazione a 3 stage `e quella che fornisce risultati meno soddisfacenti:
questo probabilmente `e causato dal criterio di suddivisione settimanale scelto,
cio`e 3 gruppi contenenti sequenze lunghe al massimo 3 pi`u un gruppo di sequenze
da un solo ordine.
Qualit`a dell’input Tutte le simulazioni sono state fatte con un input di ordini
e citt`a casuali creato dal Generatore; non avendo una conoscenza generale della
distribuzione degli ordini in campo pratico tale input non pu`o quindi essere
considerato reale.
Capacit`a di elaborazione Le simulazioni sono state fatte ponendo a 4 il
numero massimo di stage a causa delle limitate prestazioni del computer su cui
`e stato sviluppato l’algoritmo. L’assegnazione di una flotta di 10 autisti su un
50

54. input di 100 ordini considerando 4 stage viene elaborata nell’ordine dei secondi
(in media 2 secondi); se il numero di ordini viene aumentato a 300, con una
pianificazione a 6 stage, il tempo di computazione `e stimato a circa 4 ore.
6.3 Possibili miglioramenti
Tutte le simulazioni eseguite sono state fatte dividendo la giornata lavorativa
in 2 gruppi, mattina e pomeriggio; non si esclude che aumentando il numero di
suddivisioni i risultati possano migliorare.
Inoltre data la limitata capacit`a di elaborazione del calcolatore su cui `e stato
sviluppato questo programma non `e stato possibile eseguire simulazioni con un
numero maggiore di ordini e stage.
Un ulteriore miglioramento pu`o essere il fatto di mettere in evidenza le possibili
triangolazioni, cio`e dove si hanno due ordini consecutivi dove il proprietario
del container `e lo stesso, il primo ordine di tipo import, il secondo ordine di
tipo export; tuttavia nella realt`a bisogna considerare la compatibilit`a dei tipi di
contenitori e del tipo di merce trasportata.
6.4 Raggiungimento dello scopo
Attraverso le varie analisi, quando l’input dell’algoritmo `e ben distribuito, il
pianificatore fornisce risultati soddisfacenti, in questo modo possiamo affermare
che la tecnica della programmazione dinamica `e utile per dimostrare che una
pianificazione della flotta, considerando tutta la settimana e non solo il giorno
successivo, permette una copertura maggiore degli ordini con un minor
numero di chilometri percorsi dalla flotta.
Concludendo, programma pu`o rappresentare un buon punto di partenza per
sviluppare modelli applicabili nella pratica, soprattutto perch´e nella pianifica-
zione settimanale si tiene conto delle ore di sonno degli autisti e viene privile-
giato il fatto di assegnare ordini pi`u vicini alla filiale al termine della settimana
lavorativa.
51

55. Elenco delle figure
2.1 Passaggio di due navi portacontainer nella Baia di San Francisco
[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Il sig. Malcolm McLean al Port Newark–Elizabeth Marine Ter-
minal, 1957. [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Container della compagnia marittima MSC. [1] . . . . . . . . . . 3
2.4 Gru portacontainer al Porto di Shanghai. [4] . . . . . . . . . . . 5
2.5 Interporto di Verona Quadrante Europa. [5] . . . . . . . . . . . . 5
2.6 Viaggio import . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.7 Viaggio export . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1 Il Distanziere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Struttura file citt`a . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 Creazione lista casuale citt`a . . . . . . . . . . . . . . . . . . . . . 12
3.4 Dalla generazione all’analisi . . . . . . . . . . . . . . . . . . . . . 13
3.5 File ordini generati . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.6 Openlayers `e in grado di comunicare tramite vari protocolli. [23] 15
3.7 Visualizzazione ordini su pagina web . . . . . . . . . . . . . . . . 18
3.8 Triangolazione Import-Export . . . . . . . . . . . . . . . . . . . . 19
3.9 Visualizzazione triangolabilit`a su pagina web . . . . . . . . . . . 19
4.1 Decisione con un periodo conosciuto . . . . . . . . . . . . . . . . 23
4.2 Decisione con due periodi conosciuti . . . . . . . . . . . . . . . . 24
4.3 Panoramica programma di pianificazione . . . . . . . . . . . . . . 25
4.4 Fattibilit`a ordine successivo . . . . . . . . . . . . . . . . . . . . . 27
4.5 Esempio di ottimizzazione ricorsiva per 6 periodi . . . . . . . . . 28
4.6 Induzione a ritroso . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.7 Realizzazione catene ordini . . . . . . . . . . . . . . . . . . . . . 30
4.8 Stato autista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.9 Come assegnare autista a gruppo? . . . . . . . . . . . . . . . . . 34
4.10 Assegnazione ottima . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.11 Assegnazione ad uno stage . . . . . . . . . . . . . . . . . . . . . . 36
5.1 Assegnazione ad uno stage . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Assegnazione a quattro stage . . . . . . . . . . . . . . . . . . . . 38
5.3 Assegnazione a quattro stage . . . . . . . . . . . . . . . . . . . . 40
5.4 Assegnazione a quattro stage . . . . . . . . . . . . . . . . . . . . 41
5.5 Assegnazione a quattro stage . . . . . . . . . . . . . . . . . . . . 42
5.6 Assegnazione a quattro stage . . . . . . . . . . . . . . . . . . . . 42
5.7 Chilometri percorsi per ordini oneway corti . . . . . . . . . . . . 43
52

56. 5.8 Numero ordini coperti per viaggi oneway corti . . . . . . . . . . . 44
5.9 Chilometri percorsi per ordini oneway lunghi . . . . . . . . . . . 45
5.10 Numero ordini coperti per viaggi oneway lunghi . . . . . . . . . . 45
5.11 Chilometri percorsi per ordini roundtrip corti . . . . . . . . . . . 46
5.12 Numero ordini coperti per viaggi roundtrip corti . . . . . . . . . 47
5.13 Chilometri percorsi per ordini roundtrip lunghi . . . . . . . . . . 48
5.14 Numero ordini coperti per viaggi roundtrip lunghi . . . . . . . . 48
53

57. Elenco delle tabelle
4.1 Orizzonte temporale . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Ordini del Luned`ı mattina . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Ordine del Luned`ı pomeriggio . . . . . . . . . . . . . . . . . . . . 23
4.4 Numero di gruppi di sequenze in base al numero di stage . . . . . 33
5.1 Questo ordine non permette ulteriori pianificazioni per la giornata 38
54

58. Bibliografia
[1] Container shipping : viaggio intorno al contenitore marittimo. Genova: LE
NAVI Agenzia Marittima, 2009.
[2] W. Commons, “Apl post-panamax container ships image id: line0534, ame-
rica’s coastlines. collection location: San francisco,” unknown. https:
//upload.wikimedia.org/wikipedia/commons/7/74/Line0534.jpg.
[3] Wikipedia, “Malcolm mclean — wikipedia, the free encyclopedia,” 2016.
[4] W. Commons, “Container cranes at shanghai port,” 2009.
https://en.wikipedia.org/wiki/Container_crane#/media/File:
Yangshan-Port-Balanced.jpg.
[5] “Interporto quadrante europa.” http://www.quadranteeuropa.it/
images/quadrante/immobiliare/immobiliare_centrosped.jpg.
[6] H. Psaraftis, “Dynamic vehicle routing: Status and prospects,” Annals of
Operations Research, vol. 61, no. 1, pp. 143–164, 1995.
[7] W. Powell, P. Jaillet, and A. Odoni, “Chapter 3 stochastic and dynamic net-
works and routing,” Handbooks in Operations Research and Management
Science, vol. 8, no. C, pp. 141–295, 1995.
[8] M. Gendreau and J.-Y. Potvin, “Dynamic vehicle routing and dispatching,”
Fleet Management and Logistics, pp. 115–126, 1998.
[9] A. Larsen, O. Madsen, and M. Solomon, “Partially dynamic vehicle routing
- models and algorithms,” Journal of the Operational Research Society,
vol. 53, no. 6, pp. 637–646, 2002.
[10] S. Ichoua, M. Gendreau, and J.-Y. Potvin, “Exploiting knowledge about
future demands for real-time vehicle dispatching,” Transportation Science,
vol. 40, no. 2, pp. 211–225, 2006.
[11] N. Secomandi, “Comparing neuro-dynamic programming algorithms for
the vehicle routing problem with stochastic demands,” Computers and
Operations Research, vol. 27, no. 11-12, pp. 1201–1225, 2000.
[12] N. Secomandi, “A rollout policy for the vehicle routing problem with
stochastic demands,” Operations Research, vol. 49, no. 5, pp. 796–802,
2001.
55

59. [13] C. C¸ali¸skan and R. Hall, “A dynamic empty equipment and crew allocation
model for long-haul networks,” Transportation Research Part A: Policy and
Practice, vol. 37, no. 5, pp. 405–418, 2003.
[14] J. Desrosiers, Y. Dumas, M. Solomon, and F. Soumis, “Chapter 2 time
constrained routing and scheduling,” Handbooks in Operations Research
and Management Science, vol. 8, no. C, pp. 35–139, 1995.
[15] G. Desaulniers, J. Desrosiers, M. Gamache, and F. Soumis, “Crew schedu-
ling in air transportation,” Fleet Management and Logistics, pp. 169–185,
1998.
[16] W. Powell, “A comparative review of alternative algorithms for the dy-
namic vehicle allocation problem,” Vehicle Routing: Methods and Studies,
pp. 249–291, 1988.
[17] W. White, “Dynamic transshipment networks: An algorithm and its ap-
plication to the distribution of empty containers,” Networks, vol. 2, no. 3,
pp. 211–236, 1972.
[18] C. Tapiero and M. Soliman, “Multicommodities transportation schedules
over time,” Networks, vol. 2, no. 4, pp. 311–327, 1972.
[19] T. Crainic, J.-A. Ferland, and J.-M. Rousseau, “Tactical planning model for
rail freight transportation.,” Transportation Science, vol. 18, no. 2, pp. 165–
184, 1984.
[20] M. Spivey and W. Powell, “The dynamic assignment problem,”
Transportation Science, vol. 38, no. 4, pp. 399–419, 2004.
[21] H. Sim˜ao, J. Day, A. George, T. Gifford, J. Nienow, and W. Powell,
“An approximate dynamic programming algorithm for large-scale fleet ma-
nagement: A case application,” Transportation Science, vol. 43, no. 2,
pp. 178–197, 2009.
[22] “Openlayers 3.” https://openlayers.org/.
[23] SEWilco, “Geoserver and geonetwork with interfaces and applica-
tions sketch. green represents read and write paths. dotted arro-
wed line indicates mostly read-only data flow.,” 2007. [GFDL
(http://www.gnu.org/copyleft/fdl.html) or CC BY-SA 4.0-3.0-2.5-2.0-
1.0 (http://creativecommons.org/licenses/by-sa/4.0-3.0-2.5-2.0-1.0)], via
Wikimedia Commons.
[24] H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, and T. Schaub, “The
geojson format,” 2016. https://tools.ietf.org/html/rfc7946.
[25] H. W. Kuhn, “The hungarian method for the assignment problem,” Naval
Research Logistics Quarterly, vol. 2, no. 1-2, pp. 83–97, 1955.
[26] H. W. Kuhn, “Variants of the hungarian method for assignment problems,”
Naval Research Logistics Quarterly, vol. 3, no. 4, pp. 253–258, 1956.
56

60. [27] J. Munkres, “Algorithms for the assignment and transportation problems,”
Journal of the Society for Industrial and Applied Mathematics, vol. 5, no. 1,
pp. 32–38, 1957.
[28] R. Brualdi, Combinatorial Matrix Classes. No. v. 13 in Combinatorial
matrix classes, Cambridge University Press, 2006.
[29] R. Burkard, M. Dell’Amico, and S. Martello, Assignment Problems, Revised
Reprint:. Other titles in applied mathematics, Society for Industrial and
Applied Mathematics (SIAM, 3600 Market Street, Floor 6, Philadelphia,
PA 19104), 2009.
[30] D. P. Bertsekas, Network optimization : continuous and discrete models tex-
te imprim´e. Optimization and neural computation series, Belmont, Mass.
Athena Scientific, 1998. lccopycat.
[31] K. Mulmuley, U. V. Vazirani, and V. V. Vazirani, “Matching is as ea-
sy as matrix inversion,” in Proceedings of the Nineteenth Annual ACM
Symposium on Theory of Computing, STOC ’87, (New York, NY, USA),
pp. 345–354, ACM, 1987.
[32] M. Fischetti, Lezioni di ricerca operativa. Progetto Libreria, 1995.
[33] R. K. Ahuja, T. L. Magnanti, and J. B. Orlin, Network Flows: Theory,
Algorithms, and Applications. Upper Saddle River, NJ, USA: Prentice-Hall,
Inc., 1993.
[34] S. Martello, “Jen˝o egerv´ary: from the origins of the hungarian algori-
thm to satellite communication,” Central European Journal of Operations
Research, vol. 18, no. 1, pp. 47–58, 2010.
[35] J. C. Borchardt, C.W., “De investigando ordine systematis aequatio-
num differentialium vulgarium cujuscunque.,” Journal f¨ur die reine und
angewandte Mathematik, vol. 64, pp. 297–320, 1865.
[36] D. Konig, Theorie Der Endlichen Und Unendlichen Graphen. Ams Chelsea
Publishing, AMS Chelsea Publ., 2001.
[37] E. Egerv´ary, “Matrixok kombinatorius tulajdons´agair´ol (hungarian) on
combinatorial properties of matrices,” Matematikai ´es Fizikai Lapok,
vol. 38, pp. 16–28, 1931.
[38] G. B. Dantzig, R. J. Duffin, K. Fan, L. R. Ford, D. R. Fulkerson, D. Ga-
le, A. J. Goldman, I. Heller, J. B. Kruskal, H. W. Kuhn, H. D. Mills,
G. L. Thompson, C. B. Tompkins, A. W. Tucker, and P. Wolfe, Linear
Inequalities and Related Systems. (AM-38). Princeton University Press,
1956.
57