Un algoritmo di ottimizzazione per un sistema Dial-a-Ride

Transcript

1 UNIVERSITÀ DEGLI STUDI DI MILANO Facoltà di Scienze Matematiche, Fisiche e Naturali Dipartimento di Tecnologie dell Informazione Corso di Laurea in Scienze e Tecnologie dell Informazione Un algoritmo di ottimizzazione per un sistema Dial-a-Ride RELATORE: Prof. Giovanni Righini CORRELATORE: Prof. Alessandro Luè TESI DI LAUREA DI: Alberto Bosio Matricola Anno Accademico 2006/07

2 Ringraziamenti La nuova generazione è uno spazio in cui vincerà l idea migliore, non il budget più alto Satoru Iwata Mi sento in dovere di ringraziare tutte le persone che mi hanno sostenuto durante l implementazione e la stesura di questa tesi di laurea, in particolare: - Il professor Giovanni Righini per la pazienza e l aiuto dimostratomi - Alessandro Luè, Maurizio Bruglieri e Diego Ciccarelli per avermi dato l oppurtunità di lavorare su questo progetto - I miei genitori, grazie ai quali ho potuto raggiungere questo obiettivo - Michela che mi è sempre vicina incondizionatamente - A tutti gli amici che mi hanno accompagnato il mio cammino universitario

3 Indice 1 Introduzione Sistemi di trasporto a chiamata Obiettivo della tesi Struttura dell esposizione Sistemi di trasporto a chiamata Il servizio Dial-a-Ride Riferimenti alla letteratura Formulazione del problema Il software DaR Funzionamento del software DaR Configurazione del software DaR Statistiche Algoritmi Algoritmo di inserzione Algoritmo di cancellazione Algoritmo di ricerca locale Algoritmo evolutivo Algoritmo costruttivo Taratura dinamica degli intorni Cammini minimi

4 INDICE 3 5 Risultati sperimentali Simulatore Dial-a-Ride Risultati Configurazione di prova Confronto tra algoritmi Destinazioni comuni e distribuite Posizione della fermata di scambio Dimensione delle finestre temporali Differenza del LoS tra inserzione e servizio Simulazione di un caso reale Tempo minimo di anticipo Conclusioni 55 Bibliografia 57

5 Capitolo 1 Introduzione 1.1 Sistemi di trasporto a chiamata I sistemi di trasporto a chiamata si possono adattare alle specifiche esigenze degli utenti e possono coprire la rilevante domanda di mobilità non sistematica. Un servizio di questo tipo è caratterizzato da una flotta di veicoli che fanno capo ad una centrale operativa; i percorsi e gli orari non sono prefissati ma vengono determinati in base alle richieste degli utenti che prenotano un viaggio specificandone l origine, la destinazione ed un orario indicativo di svolgimento. La centrale operativa raccoglie ed elabora le richieste, pianificando le rotte e le tabelle orarie in modo da soddisfare le esigenze dei clienti [23]. L ottimizzazione del servizio di un sistema di trasporto a chiamata rientra sia nella classe dei problemi di vehicle routing che di set partitioning. In generale i problemi di routing sono soggetti a vincoli di diverso tipo, i più comuni e trattati in letteratura sono quelli di capacità e di tempo. I primi si presentano quando i veicoli devono compiere, nei diversi punti, operazioni di carico o scarico (pickup & delivery) di cose o persone e i mezzi di trasporto (multi-vehicle) hanno un limite massimo di carico (capacitated). I secondi si manifestano quando, ad ogni punto appartenente alla richiesta, è associato un intervallo di tempo, solitamente definito finestra temporale (time windows), entro i cui limiti deve essere effettuata la corrispondente operazione oppure quando i veicoli sono disponibili solamente per un limitato periodo della giornata [22].

6 1.2 Obiettivo della tesi 5 Questo problema appartiene alla categoria capacitated multi-vehicle pickup & delivery problem with time windows. 1.2 Obiettivo della tesi Il punto di partenza del presente lavoro è il software DREAMS [2], sviluppato dal centro Poliedra, consorzio universitario creato dal Politecnico di Milano per promuovere e sviluppare la formazione continua e rafforzare i rapporti con le imprese. Una carenza riscontrata nel software riguarda l impossibilità di migliorare le soluzioni trovate poichè è presente solo l algoritmo di inserzione delle chiamate. Ciò può provocare il rifiuto di chiamate che sarebbero potute essere soddisfatte attraverso la ri-ottimizzione della soluzione. Il lavoro svolto in questa tesi consiste nell implementazione, all interno del software, di un algoritmo di ri-ottimizzazione che ha come funzione obiettivo il miglioramento del livello di servizio offerto all utenza e nella sua sperimentazione attraverso prove di efficienza e efficacia. Savelsbergh dimostrò [21] che trovare una soluzione ammissibile per il Travelling Salesman Problem with Time Windows (TSPTW) è un problema NPcompleto in senso forte per cui, a meno che NP = P, non esistono algoritmi pseudopolinomiali di risoluzione. La conseguenza di questo risultato è che trovare una soluzione ammissibile per il nostro problema è ugualmente NPcompleto in senso forte perchè è un caso particolare del TSPTW. A causa dell elevata complessità computazionale i metodi esatti non riescono a risolvere problemi di grandi dimensioni, cosa che limita fortemente la loro applicabilità a situazioni reali, caratterizzate quasi sempre da centinaia di richieste da soddisfare [14]. Per tale motivo l attività di ricerca in questo ambito si è focalizzata sugli algoritmi euristici. In particolare gli algoritmi sviluppati sono un adattamento di quelli proposti da Salani [20]. 1.3 Struttura dell esposizione Nel capitolo 2 viene descritto il funzionamento di un sistema di trasporto a chiamata evidenziandone i vantaggi rispetto ad un sistema di trasporto tradizionale. Viene inoltre presentato il modello matematico. Nel capitolo

7 1.3 Struttura dell esposizione 6 3 viene esposto il funzionamento del software DREAMS. Nel capitolo 4 vengono descritti gli algoritmi di inserzione, cancellazione e di ottimizzazione della soluzione. Nel capitolo 5 sono riportati i risultati ottenuti con i test effettuati per valutare la qualità degli algoritmi sviluppati. Infine, nel capitolo 6, vengono proposte alcune considerazioni finali e spunti di sviluppo futuro.

8 Capitolo 2 Sistemi di trasporto a chiamata 2.1 Il servizio Dial-a-Ride I livelli sempre più elevati di saturazione del traffico stradale, dovuti soprattutto sia alla crescita continua della domanda di mobilità che al cambiamento nell utilizzo dei modi di trasporto con il massiccio ricorso all autovettura privata, rendono sempre più difficile l accesso a molte città e la circolazione all interno delle stesse. Le conseguenze negative dei livelli di saturazione del traffico si manifestano in termini di aumento dell inquinamento atmosferico ed acustico, di spreco energetico, di aumento degli incidenti, di occupazione di spazio e di intrusione visiva. Lo scopo di un sistema di trasporto moderno è di offrire alla clientela efficienza e comfort ad un costo contenuto. Un tale sistema deve inoltre determinare la riduzione del traffico, del rumore, dell inquinamento e contribuire ad una gestione controllata dei costi. Nel trasporto pubblico tradizionale, basato sull utilizzo di tram, metropolitane, treni e bus, sono gli operatori del trasporto ad organizzare il servizio rendendo possibile il viaggio. Questi decidono dove e in quale modo offrire e gestire il servizio, attendendosi che gli utenti ne usufruiscano. I moderni sistemi di trasporto, come i servizi a chiamata, il taxi collettivo, il car pooling e il car sharing, si possono adattare alle specifiche esigenze degli utenti e

9 2.1 Il servizio Dial-a-Ride 8 possono coprire quella rilevante parte di domanda di mobilità a cui il servizio convenzionale non può dare risposta o per la quale l utilizzo del mezzo personale (taxi e automobile privata) può dimostrarsi non conveniente. Tali servizi sono complementari al trasporto tradizionale, potendo operare sia a livello locale che di connessione con le altre modalità di trasporto, collocandosi a livello intermedio, come si può vedere in figura 2.1, tra il trasporto pubblico di linea regolare ed a percorso fisso e quello personale, flessibile e a percorso variabile. Figura 2.1: confronto tra vari sistemi di trasporto I servizi a chiamata, noti come sistemi Dial-a-Ride (DaR), possono essere forniti con i mezzi più diversi (bus, minibus,... ), favoriti da una diffusa disponibilità delle piattaforme informatiche e dallo sviluppo delle tecnologie telematiche e costituiscono un sistema di trasporto pubblico nuovo, più flessibile, nella composizione dei percorsi e dei tempi e pronto a cogliere le esigenze personali di mobilità. Questa tipologia di servizio pubblico, riuscendo a costituire un accettabile compromesso tra le esigenze dell individuo e quelle più generali della pianificazione della città, appare in grado di coprire due ruoli importanti: fornire una buona alternativa all uso del mezzo di trasporto privato per contribuire ad una elevata qualità della città e della vita;

10 2.1 Il servizio Dial-a-Ride 9 offrire una mobilità di base a tutti con particolare attenzione ai soggetti con difficoltà motorie. I sistemi di trasporto a chiamata si rivolgono a tipologie di clienti con esigenze diversificate e irregolari rispetto a quelli dei sistemi tradizionali. Gli utenti del servizio possono essere: persone che circolano sistematicamente e periodicamente in giorni predefiniti (ad esempio nei giorni feriali per il tragitto casa-lavoro-casa); studenti per recarsi non solo a scuola, ma anche per attività parascolastiche e di tempo libero; persone che si muovono saltuariamente e che hanno bisogno del servizio per scopi personali e commerciali e per attività di tempo libero; persone con mobilità limitata o persone che vivono una particolare fase della loro vita (malattia, infortunio, gravidanza,... ); anziani; donne che necessitano di un trasporto nelle ore notturne; persone in condizioni tali da non potere accedere al servizio di linea; persone che non possono disporre di veicoli privati in zone e ore non servite da sistemi di trasporto pubblico tradizionale; turisti. I servizi a chiamata sono in grado di assicurare una vasta gamma di collegamenti: collegamenti porta a porta; collegamenti tra zone a domanda debole; servizi interni su particolari zone urbane o extraurbane; servizi nell area di uno o più comuni limitrofi; collegamenti con punti di interesse viario generale (centro storico, ospedali, stazioni ferroviarie, aeroporti,... ).

11 2.1 Il servizio Dial-a-Ride 10 Per adattarsi a tali esigenze, i veicoli si possono spostare liberamente di fermata in fermata, combinando le richieste dei clienti in modo da soddisfarle. Sono quindi in grado di rispondere ad una domanda di trasporto scarsa e asistematica. Il servizio Dial-a-Ride è un sistema di trasporto cosiddetto a chiamata e presuppone quindi la prenotazione (telefonica, via web,... ) del viaggio da parte dell utente. Questo processo può essere distinto in tre fasi successive tra loro: 1. formulazione della richiesta di viaggio da parte dell utente corredata dall indicazione dell origine e destinazione e dai tempi di partenza o arrivo desiderati; 2. la presentazione di una proposta di servizio all utente da parte dell - operatore; 3. la conferma della prenotazione da parte dell utente. Le richieste possono essere note in anticipo rispetto all istante iniziale del servizio (DaR statico) oppure arrivano durante il servizio stesso (DaR dinamico). Nel primo caso il sistema di gestione accetta solo prenotazioni per i giorni successivi; nel secondo le chiamate giungono durante il servizio. La prima configurazione corrisponde ad un servizio con percorso ed orario assegnati, come per i bus tradizionali: in questo caso si impone che le prenotazioni vengano formulate tutte in anticipo in modo tale che, a livello di centrale operativa, valutando tutte le richieste pervenute possa essere pianificato l intero servizio. L inconveniente del DaR statico è che non possono essere presi in considerazione gli eventi che accadono durante il periodo di servizio e che richiederebbero una rielaborazione delle chiamate (ritardi per ingorghi, utenti che mancano all appuntamento di carico,... ). La seconda configurazione (caso che verrà trattato nella tesi) corrisponde, invece, ad un servizio altamente flessibile molto più vicino al taxi; in questo contesto è fondamentale poter rispondere quasi all istante alla richieste che l utente può formulare con un certo anticipo sul viaggio. I sistemi DaR dinamici sono flessibili perché consentono di ri-ottimizzare le decisioni prese in precedenza, in seguito al verificarsi di eventi imprevisti.

12 2.1 Il servizio Dial-a-Ride 11 Lo studio di algoritmi efficienti per la soluzione di un problema di DaR dinamico si applica al trasporto dei passeggeri e anche al trasporto di merci non pianificato. La formulazione del problema è a molti obiettivi: minimizzare il numero di veicoli utilizzati: la dimensione della flotta determina i costi fissi di gestione del servizio, generati dal numero di bus e conseguentemente dal numero di autisti. Questi costi incidono molto in fase di pianificazione del servizio quando è necessario valutare l entità degli investimenti necessari. In fase di gestione, invece, risultano ormai praticamente fissati, per cui, in genere, non è un aspetto prioritario. minimizzare il tempo totale di viaggio: descrive i costi variabili di gestione del servizio. Si tratta di una componente del costo di esercizio decisamente meno importante: poiché però è l unica controllabile nella gestione quotidiana, se ne tiene conto nel determinare i percorsi e gli orari dei mezzi. massimizzare la qualità del servizio: la qualità del servizio fornito agli utenti viene intesa in senso puramente temporale, cioè riguarda solo aspetti come la durata del viaggio o l attesa iniziale del bus. Non si fa riferimento a fattori di comodità del viaggio. L indicatore che descrive il punto di vista dell utente può essere chiamato Level of Service (LoS) [12] e rappresenta il confronto tra la durata del viaggio effettivo che l utente compie e quella del viaggio ideale che il servizio teoricamente potrebbe offrirgli, senza alcuna attesa prima della salita e con il percorso di durata minima. In altri termini il LoS è il rapporto, necessariamente maggiore di 1, tra il tempo totale che l utente impiega per andare dall origine alla destinazione utilizzando il servizio Dial-a-Ride e il tempo teorico minimo necessario a compiere il viaggio. Massimizzare la qualità del servizio significa quindi minimizzare il LoS.

13 2.2 Riferimenti alla letteratura 12 Questi obiettivi sono tra loro conflittuali: il primo ed il secondo obiettivo soddisfano le esigenze del gestore del servizio a scapito della soddisfazione degli utenti. Il terzo comporta l aumento dei costi ma una maggiore soddisfazione degli utenti. 2.2 Riferimenti alla letteratura Di seguito vengono riportati alcuni riferimenti agli articoli, presenti in letteratura, che propongono metodi di soluzione diversi ai problemi riguardanti i sistemi di trasporto a chiamata. DaR Statico Psaraftis propone in [15] algoritmo esatto per il problema immediate request DaR. In questo problema l utente chiede di essere servito il più presto possibile. In [16] lo stesso autore propone un algoritmo per la soluzione esatta del problema DaR statico. Entrambi gli algoritmi di questo autore [15] e [16] risolvono problemi di piccole dimensioni, rispettivamente senza e con finestre temporali. In [13] gli autori presentano un algoritmo in tre fasi per risolvere il problema di DaR statico. La prima fase suddivide l orizzonte temporale di servizio in intervalli ed assegna a ciascun gruppo un insieme di chiamate. Le chiamate sono associate ai gruppi in base agli estremi della finestra temporale. La seconda fase ripartisce le chiamate di ciascun gruppo in sottoinsiemi ed assegna ciascun sottoinsieme ad un veicolo. La terza fase è identica alla soluzione di un problema single-vehicle. Anche in questo caso si assume che le chiamate siano note a priori. DaR Dinamico In [18] viene proposta una euristica per la soluzione del PickUp & Delivery Traveling Salesman Problem composta da due fasi: la prima costruttiva e la seconda di ri-ottimizzazione tramite un processo di cancellazione e reinserimento. In questo studio la funzione obiettivo consiste nel minimizzare la distanza totale percorsa e viene considerato un solo veicolo.

14 2.3 Formulazione del problema 13 In [8] viene introdotto il concetto di negoziazione delle chiamate. Con il termine negoziazione di una chiamata si intende l accettazione reciproca della richiesta di servizio da parte dell utente e da parte della centrale operativa. Viene presentato un modello che permette di capire quando un sistema di trasporto è sottoposto ad un carico di lavoro ragionevole e, quindi, in grado di accettare ulteriori chiamate. Inoltre questa valutazione permette di stabilire la frequenza della ri-ottimizzazione. In [7] viene analizzato un modello generale di dynamic vehicle dispatching, nel quale la congestione del sistema è la misura delle prestazioni. In tale modello un numero finito di percorsi viene associato ai veicoli, ogni chiamata attende in una coda fino a quando viene assegnata ad un percorso. Questo studio considera gli utenti in uno spazio Euclideo e non tiene conto di finestre temporali. In [17] è analizzato il problema del sistema di trasporto a chiamata dinamico, vengono inserite nei piani di carico dei mezzi solamente le chiamate il cui istante di carico è compreso in un orizzonte temporale prefissato. In [4] viene presentato un modello matematico e lo sviluppo di algoritmi per un problema di sistema di trasporto a chiamata dinamico multi-veicolo con finestre temporali. In [6] viene proposta una tabu search dove l obiettivo è minimizzare la flotta, il numero di persone lasciate a terra e LoS medio degli utenti. In [5] viene proposto un algoritmo euristico in cui il numero dei veicoli è fisso e sono previste finestre temporali. Viene utilizzata una funzione obiettivo gerarchizzata: l algoritmo, in primo luogo cerca di servire tanti più clienti possibili, quindi minimizza la disutilità dei clienti stessi espressa come tempi di attesa e di eccesso di tempo a bordo. 2.3 Formulazione del problema Volendo modellizzare fedelmente un sistema complesso, come un sistema di trasporto che risolve il problema DaR, si devono formulare delle ipotesi che semplifichino la complessità del problema. La formulazione più semplice, che si ritrova descritta in letteratura [3], non prende in considerazione la rete di trasporto reale, ma ricava da essa un grafo astratto dove l insieme dei

15 2.3 Formulazione del problema 14 vertici comprende solo i depositi dei mezzi e i punti di salita e discesa degli utenti mentre i pesi degli archi corrispondono ai costi dei cammini minimi fra di essi. Il grafo astratto permette una formulazione più compatta del problema, ma non è adatto al nostro caso, poiché il grafo è tempo-variante, e l insieme dei punti di carico e scarico non è noto a priori. Per la rappresentazione del sistema stradale è stato adottato un grafo orientato G = (N, A) costituito da N nodi e da A archi, questi ultimi pesati con i tempi di percorrenza. I tempi di percorrenza di un arco sono funzione delle condizioni di traffico, che a loro volta sono funzione dell orario. Per consentire quindi al modello una migliore rappresentazione delle reali condizioni di traffico, è necessario collegare ad una stessa struttura topologica diversi set di costi associati agli archi, a seconda della fascia oraria considerata. A ciascuna fascia oraria, definita da un orario di inizio e un orario di fine fascia, viene associato quindi un set di costi-arco. Se un arco corrisponde ad una strada le cui proprietà non sono omogenee, conviene perfezionare la rappresentazione, introducendo uno o più nodi lungo il suo corso, che lo spezzino in una sequenza di archi consecutivi con caratteristiche omogenee al proprio interno. Se ad esempio vogliamo modellizzare un incrocio, come quello proposto in figura 2.2, possiamo utilizzare un singolo nodo oppure possiamo dettagliare il modello spezzando il singolo nodo in un intero sottografo. Figura 2.2: esempio di incrocio

16 2.3 Formulazione del problema 15 La prima opzione, illustrata nella figura 2.3 sulla sinistra, non permette di indicare le svolte non consentite e distinguere tra i tempi di attesa associati alle diverse manovre, a differenza della seconda opzione, illustrata nella figura 2.3 sulla destra, dove ciò è possibile. Figura 2.3: modellizzazione di un incrocio su due diversi livelli di dettaglio Inoltre è necessario introdurre nella definizione del modello la definizione di stato del sistema [1]. Il passaggio da uno stato S t ad uno stato S t+1 implica la ri-ottimizzazione delle decisioni prese nello stato S t. Lo stato del sistema è rappresentato dall insieme P delle posizioni dei mezzi e dagli insiemi U k dei passeggeri a bordo di ciascun veicolo.

17 2.3 Formulazione del problema 16 DATI Sia C l insieme delle chiamate note con c = o c, d c, If pc, F f pc, If ac, F f ac, m c dove: o c e d c rappresentano i punti di origine e destinazione del viaggio; If pc e F f pc definiscono l inizio e la fine della finestra temporale di partenza; If ac e F f ac definiscono l inizio e la fine della finestra temporale di arrivo; m c rappresenta il numero di passeggeri, associati alla chiamata. Rimando al paragrafo 3.2 la descrizione della costruzione delle finestre temporali di partenza e arrivo. Sia M la flotta di veicoli aventi capacità q k, k M, sia L l insieme di depositi e l vk {0, 1}, una costante che indica se il veicolo k è nel deposito v, k M, v L. DEFINIZIONI Indichiamo con: mp rs la distanza tra due punti r e s del grafo; O il multi-insieme dei punti di carico degli utenti; D il multi-insieme dei punti di scarico degli utenti; V u il multi-insieme dei punti di carico e di scarico degli utenti V u = O D; V p il multi-insieme dei punti di localizzazione dei depositi; V il multi-insieme dei punti significativi V = V u V p.

18 2.3 Formulazione del problema 17 VARIABILI Indichiamo con: w ck la variabile binaria che indica se l utente c è già a bordo del veicolo k; x ijk la variabile binaria che indica se il veicolo k visita consecutivamente i punti i e j, i, j V, k M; tp ik la variabile continua che indica l istante di partenza dal punto i del veicolo k, i V, k M; ta ik la variabile continua che indica l istante di arrivo nel punto i del veicolo k, i V, k M; y ik la variabile intera che indica il numero di persone a bordo del veicolo k in partenza dal punto i, i V, k M. FUNZIONE OBIETTIVO Il livello di servizio viene rappresentato tramite un indicatore (LoS) che confronta il tempo di viaggio calcolato dal sistema con il tempo del viaggio ideale. Sia mp ocd c il tempo di viaggio diretto dal punto di origine al punto di destinazione dell utente c. Definiamo il livello di servizio los(c) come il rapporto tra il tempo di servizio e il tempo di viaggio ideale: los(c) = ta dck If pc mp ocdc dove k è il veicolo che trasporta l utente c. Nel calcolo del LoS non consideriamo l istante di partenza dal punto di origine ma l istante che indica l inizio della finestra temporale di partenza, poichè consideriamo anche l attesa da parte dell utente del bus. Massimizzare la qualità del servizio significa minimizzare il LoS. La funzione obiettivo adottata è quella di minimizzare il valore di LoS massimo che definiamo z, ovvero il valore di LoS dell utente peggio servito. Quindi: min z = max c C {los(c)}

19 2.3 Formulazione del problema 18 IL MODELLO MATEMATICO min z = max{los(c)} (2.1) c C se w ck = 1 los(c) = ta d ck If pc c C, k M (2.2) mp ocdc w ck = 1 c C (2.3) k M x ijk x jik = 0 i V, k M (2.4) j V j V x ocjk x jdck = 0 c C, k M (2.5) j V j V x vik l vk k M, v L (2.6) i V u y vk = 0 k M, v L (2.7) se w ck = 1 e x jock = 1 y ock = y jk + m c c C, j V, k M (2.8) se w ck = 1 e x jdck = 1 y dck = y jk + m c c C, j V, k M (2.9) se w ck = 1 e x jock = 1 y ock q k c C, j V, k M (2.10) se x ijk = 1 tp ik + mp ij ta jk (i, j) V, k M (2.11) se w ck = 1 If pc tp ock F f pc c C, k M (2.12) If ac ta dck F f ac c C, k M (2.13) ta ik lp ik i V, k M (2.14) x ocjk = w ck c C, k M (2.15) j V x jdck = w ck c C, k M (2.16) j V w uv(u) = 1 u U (2.17) y p(k),k = U k k M, p(k) P (2.18) w ik, x ijk {0, 1} (i, j) V, k M

20 2.3 Formulazione del problema 19 Il significato dei vincoli è il seguente: - definizione del livello di servizio (2.2). Vincolo di allocazione: - ogni utente è servito da un solo veicolo (2.3). Vincoli di flusso: - da ogni punto entra ed esce lo stesso numero di veicoli (2.4); - il medesimo mezzo uscente da un punto di salita di un utente deve entrare nel punto di discesa dello stesso (2.5); - ciascun mezzo esce dal proprio deposito (2.6). Vincoli di capacità: - il carico iniziale di ciascun veicolo è nullo (2.7); - il carico di un veicolo in uscita da un punto di carico aumenta della molteplicità della chiamata (2.8); - il carico di un veicolo in uscita da un punto di scarico diminuisce della molteplicità della chiamata (2.9); - il carico di un veicolo in uscita da un punto di carico deve rispettare la capacità del veicolo (2.10). Vincoli temporali: - l istante di partenza da un punto precede l arrivo in un altro punto di almeno la distanza tra i due punti (2.11); - i tempi di partenza dal punto di carico e di arrivo nel punto di scarico devono rispettare le rispettive finestre temporali (2.12 e 2.13); - l istante di arrivo in un punto precede l istante di partenza da quel punto (2.14). Infine il vincolo per le variabili: - legame tra le variabili di allocazione e le variabili di instradamento (2.15 e 2.16); - stato del sistema (2.17 e 2.18).

21 Capitolo 3 Il software DaR 3.1 Funzionamento del software DaR Dall analisi del servizio Dial-a-Ride risulta evidente che la realizzazione del software necessita di un appropriata infrastruttura tecnologica che renda possibile la gestione in modo automatico o almeno assistito, delle principali operazioni di pianificazione e amministrazione del servizio. Un software DaR deve, in particolare, consentire le seguenti operazioni: gestione della prenotazione e di tutte le informazioni ad essa correlate, quali punto di partenza e arrivo, ora del viaggio e tipologia di utente che formula la richiesta; elaborazione dei dati della richiesta e simulazione dell effetto della prenotazione nel quadro del servizio programmato: viene preparata la corrispondente modifica del percorso e valutato l effetto sulle corse già pianificate all interno dell itinerario del veicolo. Il risultato di questa simulazione è la proposta di un servizio per l utente; convalida della prenotazione, che può essere accettata o rifiutata dall utente. Nel secondo caso viene proposto all utente di variare l orario inizialmente comunicato; se egli accetta si apre un processo di contrattazione, che può nuovamente terminare con un accettazione o un rifiuto; aggiornamento del servizio, ossia viene eseguito l aggiornamento con

22 3.1 Funzionamento del software DaR 21 informazioni in tempo reale di tutti i dati riguardanti il servizio pianificato. Il software DaR DREAMS è in grado di svolgere tutte queste operazioni e consente di pianificare e gestire un sistema di trasporto di tipo Dial-a-Ride porta a porta in diverse configurazioni di flotta e di vincoli di qualità. Il software richiede in ingresso le seguenti informazioni: rete stradale e sue caratteristiche tempo-varianti; prenotazioni dei clienti; vincoli di qualità del servizio; veicoli disponibili per ogni fascia oraria e per ogni giornata; aggiornamenti sulla posizione reale dei veicoli della flotta. Il software fornisce in uscita i seguenti dati: tabelle di marcia per ogni veicolo; navigazione assistita agli autisti; lista passeggeri per ogni veicolo; risposte alle singole richieste di viaggio; statistiche del servizio per ogni veicolo, per l intera flotta, per ogni giornata o per un periodo; statistiche relative agli utenti. Per usufruire del servizio Dial-a-Ride è necessaria la registrazione al sistema, che può essere effettuata dall operatore di call center per conto dell utente, nel caso di chiamata telefonica, o dall utente stesso, attraverso l interfaccia on-line di cui dispone il software. Al momento dell iscrizione è necessario compilare alcuni campi obbligatori; al termine di questa operazione viene

23 3.1 Funzionamento del software DaR 22 assegnato username e password per l eventuale accesso futuro, come si può vedere in figura 3.1. Successivamente inserendo username e password si possono aggiungere nuove prenotazioni oppure eliminare quelle già esistenti. Figura 3.1: schermata di accesso al software DaR

24 3.2 Configurazione del software DaR Configurazione del software DaR La prima operazione da effettuare per configurare il servizio Dial-a-Ride è la determinazione delle flotte: questa funzionalità consente di inserire una nuova flotta e di modificarne o cancellarne una esistente. Ad ogni nuova flotta inserita viene assegnato automaticamente dal software un identificativo numerico mentre è obbligatoriamente richiesta la compilazione del campo relativo all indirizzo del deposito che costituisce il punto di stazionamento dei mezzi al di fuori dell orario di esercizio. Quest ultimo deve essere compreso all interno dell area interessata dal servizio. Inoltre, ad ogni flotta può essere associato un numero variabile di veicoli, per i quali devono essere definiti i seguenti parametri: codice, cioè un nome identificativo del mezzo; capacità di carico, ossia quanti passeggeri, disabili e non, possono essere trasportati dal mezzo; tipologia del veicolo; indirizzi dei punti di scambio, ossia i luoghi dove avviene lo scambio tra autisti (il software gestisce queste fermate come prenotazioni che devono essere obbligatoriamente soddisfatte: i mezzi, per effettuare lo scambio autista, si recheranno quindi, all ora stabilita, nel punto previsto); indirizzi dei parcheggi, ossia i luoghi presso i quali i veicoli stazioneranno nel momento in cui tra una richiesta e la successiva, ci sia un intervallo di tempo superiore al minimo tempo per lo stazionamento dei veicoli; intervallo temporale di esercizio del veicolo, definito selezionando i giorni di esercizio e, per ciascuno di questi, la fascia oraria di funzionamento. Il corretto dimensionamento di un sistema di trasporto Dial-a-Ride necessita, oltre alla configurazione delle flotte e dei veicoli che le compongono, di

25 3.2 Configurazione del software DaR 24 fissare alcuni parametri di esercizio e vincoli di qualità. I parametri di esercizio si articolano in: unità di misura adottate, relative a tempo, distanza e velocità; minimo intervallo di tempo per lo stazionamento dei veicoli; configurazione per prenotazioni simultanee: il software consente di gestire e controllare più chiamate simultanee, situazione che viene denominata concorrenza. Operativamente è possibile definire il tipo di concorrenza, il numero massimo di processi concorrenti simultanei e il tempo massimo di attesa di risposta del DaR e delle altre contrattazioni; configurazione per la contrattazione delle prenotazioni: nel momento in cui non sia possibile soddisfare una richiesta di viaggio, questa non viene automaticamente rifiutata ma, se l utente è d accordo, si avvia un processo di contrattazione. Questa è una procedura mediante la quale si tenta, una volta rifiutata una prenotazione, di trovare un accordo con l utente per variare la sua richiesta in modo da poterla servire. Operativamente consiste nel ricercare una soluzione valida, ad intervalli regolari (t i ), all interno di una finestra temporale centrata sull orario originale di richiesta di viaggio come mostrato in figura 3.2. E possibile impostare due parametri, rappresentati dalla semiampiezza della finestra di contrattazione e dal cadenzamento delle prove di ricerca della soluzione. Figura 3.2: funzionamento della contrattazione

26 3.2 Configurazione del software DaR 25 Con vincoli di qualità si intende che il gestore del sistema promette ad ogni utente di: non attendere troppo il bus prima di partire; non impiegare troppo tempo per l intero viaggio (attesa iniziale compresa). Il rapporto tra la durata totale del viaggio e quello ottimo, cioè il tempo minimo necessario per andare dall indirizzo di partenza a quello di destinazione, definisce la qualità del servizio. Per evitare fonti di insoddisfazione si impone un determinato livello di servizio a ciascun utente, cioè si garantisce che l attesa del bus alla partenza e la durata totale del viaggio non superino determinati valori. Questo si determina fissando intervalli di tempo basati sull orario richiesto dall utente, durante i quali devono avvenire la partenza e l arrivo dello stesso. Questi limiti vanno a formare le cosiddette finestre temporali, che possono essere di partenza e di arrivo. La finestra temporale di partenza è definita come l intervallo di tempo che intercorre tra l ora di partenza comunicata all utente e il tempo massimo di attesa del bus che il gestore ha dichiarato di non superare. La finestra temporale di arrivo è invece l intervallo di tempo nel quale il bus può lasciare l utente al nodo di arrivo senza andare in contraddizione con il livello di servizio dichiarato. La costruzione delle finestre temporali tiene conto dei seguenti parametri: tempo ottimo necessario per andare dal nodo di partenza a quello di arrivo, indicato con t ; massimo tempo di attesa in partenza (MWT ): rappresenta la durata massima dell attesa di un utente prima del passaggio del bus. Questo parametro è vincolante in quanto una prenotazione che non possa essere servita con un tempo di attesa minore o uguale a MWT sarà rifiutata dal sistema e a questo punto può incominciare o meno un processo di negoziazione; MaxLoS è il valore massimo che può assumere il LoS di un utente. E un valore vincolante: una prenotazione che non possa essere inserita

27 3.2 Configurazione del software DaR 26 con un LoS minore o uguale a MaxLoS verrà rifiutata e a questo punto potrà incominciare o meno un processo di negoziazione. La funzione MaxLoS utilizzata, che definisce la durata massima garantita del viaggio in funzione del tempo minimo previsto, è decrescente con il tempo di viaggio e viene calcolata nel modo seguente: Ma t + 1 se v c t v l MaxLoS = Ma v c + 1 se t < v c Ma v l + 1 se t > v l dove: Ma è il massimo tempo di anticipo in arrivo; v c è la soglia di viaggi corti; v l è la soglia di viaggi lunghi. Ogni finestra temporale è definita all interno dei seguenti intervalli: If p = inizio della finestra di partenza; F f p = fine della finestra di partenza; If a = inizio della finestra di arrivo; F f a = fine della finestra di arrivo; orapartenza = ora prima della quale l utente non vorrebbe partire; oraarrivo = ora entro la quale l utente vorrebbe arrivare. Le finestre temporali sono costruite in modo differente a seconda della modalità con la quale avviene la prenotazione che può essere: prenota partenza: modalità di prenotazione nella quale si indica l orario di partenza desiderato; prenota arrivo: modalità di prenotazione nella quale si indica l orario di arrivo desiderato.

28 3.2 Configurazione del software DaR 27 Nel caso di prenota partenza, la finestra temporale è calcolata nel modo seguente: If p = orap artenza; F f p = If p + MW T ; If a = If p + t ; F f a = If p + MaxLoS(t ). Nel caso di prenota arrivo, la finestra temporale è calcolata nel modo seguente: F f a = oraarrivo; If p = F f a MaxLoS(t ); F f p = If p + MW T ; If a = If p + t.

29 3.3 Statistiche Statistiche Per valutare il funzionamento del sistema e, conseguentemente, il livello di servizio offerto all utenza è necessario avere a disposizione i dati di esercizio, estrapolati dal database gestito dal software DaR. E stato sviluppato un apposito applicativo che consente di interrogare il database, su base temporale, ed estrarre una serie di dati, che possono essere esportati in un database MS Access. Il risultato di una interrogazione è rappresentato dall insieme di richieste di viaggio per l intervallo temporale impostato, al quale sono associate le seguenti informazioni: id prenotazione; nome utente; indirizzo di partenza e arrivo; bus sul quale è salito l utente; numero di persone; tempo ottimo, espresso in minuti, della prenotazione (t ); tempo effettivo, espresso in minuti, del percorso; Level of Service (LoS). Tra questi il parametro più importante è rappresentato dal LoS che è un indice dell effettivo livello di servizio offerto all utente e che, in parte, governa il successo di un sistema di trasporto a chiamata.

30 Capitolo 4 Algoritmi 4.1 Algoritmo di inserzione L algoritmo di inserzione si occupa dell assegnazione delle nuove chiamate ai veicoli, cioè il processo di ricerca di una soluzione valida alla richiesta di un utente. Ogni richiesta è caratterizzata: dall indirizzo di partenza, costituito da comune, via e civico; dall indirizzo di arrivo, anch esso formato da comune, via e civico; la data del viaggio; l ora del viaggio; dall indicazione se l ora indicata per il viaggio è quella di partenza o di arrivo. Se è di partenza significa che questi non vuole essere prelevato prima di quell ora, mentre se è di arrivo implica che non vuole arrivare a destinazione dopo quell ora; il numero di passeggeri, in termine di disabili e non; un numero di cellulare da richiamare nel caso si presentassero dei problemi per il viaggio prenotato. Ogni richiesta da inserire nel sistema è quindi caratterizzata dalle fermate di partenza e arrivo. Le fermate sono rappresentate dai valori [P, ] dove

31 4.1 Algoritmo di inserzione 30 P rappresenta l ora ottimale alla quale il bus dovrà essere alla fermata e è una misura di quanto può spostarsi P in avanti senza provocare lo sforamento delle finestre temporali successive. Data una singola fermata A, si definiscono le seguenti convenzioni: [PA, A ] orario di passaggio e ampiezza della finestra originali (definiti sulla base dalla richiesta dell utente e dal livello di servizio offerto); [PA 0, 0 A ] orario ottimale e ampiezza prevista prima dell inserzione in corso; [P A, A ] orario ottimale e ampiezza calcolata a seguito della inserzione. Le corse dei bus sono costruite inizialmente con due fermate di deposito d inizio e fine corsa, le quali sono rappresentate da I : [P I, 0] e F : [P F, 0]. Sia P una prenotazione, composta dalle fermate P : [P P, P ] (partenza) e A : [P A, A ] (arrivo), la sua inserzione nel sistema si realizza in quattro passi successivi: 1. si verifica la fattibilità dell inserzione della fermata di partenza P : [P P, P ] su tutti i bus disponibili. Se non è possibile l inserzione con l orario originariamente richiesto si domanda all utente se è disposto a variarlo (inizia dunque la contrattazione), altrimenti il processo finisce informando l utente che la sua prenotazione non può essere soddisfatta; 2. si inserisce e si aggiusta la fermata di partenza P : [P P, P ] sulla prima posizione fattibile; 3. si verifica la fattibilità nell inserzione della fermata d arrivo A : [P A, A ]. Se non è possibile l inserzione, si rimuove la fermata di partenza precedentemente inserita e si continua a cercare un altro posto dove inserirla. Se, invece, è possibile l inserzione, si informa l utente che la sua prenotazione è stata accettata. 4. si inserisce e si aggiusta la finestra d arrivo A : [P A, A ].

32 4.1 Algoritmo di inserzione 31 Per verificare la fattibilità dell inserzione di una fermata intermedia C : [P C, C ] su un bus tra le fermate A : [P A, A ] e B : [P B, B ] devono essere soddisfatti i seguenti vincoli: P A + t A,C + t C,B P B + B P A + t A,C P C + C Max(P A + t A,C, P C) + t C,B P B + B dove: t X,Y tempo ottimo di viaggio tra le fermate X e Y. Dopo aver verificato i vincoli d inserzione di C tra A e B, si procede dunque all inserzione di C : [P 0 C, 0 C ] e al calcolo dei nuovi valori P C e C : P C = Max(P A + t A,C, P 0 C ) C = Min(P B + B P C t C,B, P 0 C + 0 C P C) Successivamente inizia il processo di aggiustamento in avanti e indietro delle fermate. Aggiustamento verso l inizio: sia A : [PA 0, 0 A ] la fermata da aggiustare e C : [P C, C ] la finestra di riferimento, per calcolare P A e A : P A = P 0 A A = Min(P C + C P 0 A t A,C, 0 A ) Se il nuovo valore P A è diverso del vecchio PA 0, allora il processo continua prendendo come riferimento A e aggiustando la finestra anteriore se questa non é il deposito d inizio corsa; nel caso contrario, la procedura termina e in questa direzione nessun altra finestra avrà bisogno di essere ricalcolata. Aggiustamento verso la fine: sia B : [PB 0, 0 B ] la fermata da aggiustare e C : [P C, C ] la fermata di riferimento, per calcolare P B : P B = Max(P C + t C,B, P 0 B ) Se il nuovo valore P B è diverso del vecchio P 0 B, allora calcolare B: B = P 0 B + 0 B P B

33 4.1 Algoritmo di inserzione 32 e continuare il processo prendendo adesso come riferimento a B e aggiustando la fermata successiva se quest ultima non è il deposito di fine corsa. Nel caso contrario, la procedura termina e nessuna altra fermata, in questa direzione, avrà bisogno di essere ricalcolata. Lo stesso procedimento di inserimento per la fermata C viene ripetuto per la corrispondente fermata di arrivo D, costruita sulla base del valore di Max- LoS impostato e del tempo ottimo t. In figura 4.1 viene mostrata la rappresentazione grafica del processo di aggiustamento delle finestre temporali a seguito di un inserzione. Figura 4.1: rappresentazione grafica del processo di aggiustamento

34 4.2 Algoritmo di cancellazione Algoritmo di cancellazione L operazione di cancellazione di una prenotazione rimuove le fermate di partenza e di arrivo dal piano di carico e scarico del veicolo che avrebbe servito l utente. Dopo aver rimosso dalla corsa la fermata C : [P C, C ], inserita tra le fermate A : [P A, A ] e B : [P B, B ], si procede ad aggiustare le altre fermate, lasciandole più ampie possibile sempre soddisfacendo i limiti temporali originali [P, ]. La procedura consiste nel ricalcolare, dalla fermata B verso la fine, i valori P i di tutte le fermate modificate dall inserimento della fermata C (ora cancellata). Dopo che sono stati calcolati i nuovi valori P i, si ricalcolano i valori i in senso contrario, partendo dall ultima fermata calcolata (o al deposito finale) fino all ultima modificata dall inserimento di C. Aggiustamento verso la fine: siano B : [PB 0, 0 B ] la fermata da aggiustare e [PB, B ] i sui limiti temporali originali, sia A : [P A, A ] la fermata precedente a B nella sul percorso del bus, per calcolare P B : P B = Max(P A + t A,B, P B ) Se il nuovo valore P B è uguale al vecchio PB 0, allora, la fermata B non è stata corretta nell inserzione della fermata rimossa C. Il processo prosegue aggiustando le fermate verso l inizio. Se non è questo il caso, continuare il processo con la fermata successiva a B. Aggiustamento verso l inizio: siano A : [PA 0, 0 A ] la fermata da aggiustare e [PA, A ] i suoi limiti temporali originali, sia B : [P B, B ] la fermata successiva ad A sul percorso del bus. Per calcolare A : A = Min(P B + B P 0 A t A,B, A ) Se il nuovo valore A è uguale al vecchio 0 A, allora, la fermata A non è stata corretta nell inserzione della fermata rimossa C; la procedura termina, nessun altra fermata precedente dovrà essere corretta. Se non è questo il caso, continuare il processo con la fermata precedente ad A.

35 4.3 Algoritmo di ricerca locale Algoritmo di ricerca locale L algoritmo di ricerca locale è definito con priorità bassa di esecuzione e ha luogo quando non c è nessuna richiesta a priorità superiore (inserzione o cancellazione di una prenotazione). L algoritmo, partendo dalla soluzione corrente costituita dall insieme dei piani di carico dei veicoli, esamina le soluzioni adiacenti mediante la ri-allocazione di una chiamata da un veicolo ad un altro. Definiamo P k, piano di carico del veicolo k, la sequenza di punti che il veicolo deve visitare, il primo e l ultimo dei quali sono sempre la posizione corrente e il deposito. Data una flotta M definiamo il veicolo critico k come il veicolo tale che LoS(k) = max k M (LoS(k)). Il LoS di un veicolo è il LoS dell utente peggio servito allocato su quel veicolo. Per ciascuna chiamata c allocata al veicolo critico k, tale che l utente non è ancora a bordo del veicolo, viene generata una soluzione adiacente cancellando le tappe di carico e scarico dell utente c dal piano di carico P k, ed inserendole in ciascuno dei piani di carico P k, k k, rispettando il vincolo di capacità. Per ciascuna soluzione è stimato il valore di LoS dei due veicoli coinvolti nello scambio. L operazione di cancellazione delle tappe di carico e scarico dell utente c dal veicolo critico k è sempre non-peggiorante ed è ottenuta mediante la funzione EvalDel(in: P k, c; out: LosBusDel). L operazione di inserimento su un veicolo delle tappe di carico e scarico dell utente c è sempre non-migliorante ed è ottenuta mediante la funzione EvalIns(in: P k, c; out: LosBusIns, LosU ser) che riporta in uscita, oltre al LoS del veicolo, il LoS dell utente spostato. La soluzione valutata (spostamento dell utente c dal veicolo critico k al veicolo k) diventa la soluzione corrente se: si riduce il valore della funzione obiettivo (il LoS dell utente peggio servito), oppure il valore della funzione obiettivo rimane invariato e il veicolo k assume un valore di LoS inferiore a quello del veicolo k prima dell inserzione, oppure mantiene invariato il valore della funzione obiettivo, mantiene invariati

36 4.3 Algoritmo di ricerca locale 35 i valori di LoS dei veicoli coinvolti nello scambio e il valore di LoS dell utente spostato diminuisce. Valutare per ciascun utente a bordo del veicolo critico lo spostamento su tutti gli altri veicoli della flotta è piuttosto oneroso, perciò, per ridurre i tempi di calcolo, è necessario limitare la dimensione dell intorno della soluzione corrente. Prima di procedere alla valutazione dello spostamento di una chiamata dal veicolo critico sugli altri veicoli l algoritmo effettua un ordinamento delle chiamate c allocate a k per valori decrescenti di LoS c ; in questo modo vengono valutate prima le chiamate peggio servite. Inoltre attraverso un test di dominanza viene ridotto il numero di utenti di cui valutare la cancellazione dal veicolo critico. Dato che la politica di esplorazione adottata è quella best improve, cioè ad ogni iterazione si esplora tutto l intorno e si applica lo scambio che porta il massimo guadagno, le soluzioni adiacenti ottenute mediante la ri-allocazione di un utente sono generate solo se: EvalDel(in : P k, c; out : LosBusDel) < EvalDel(in : P k, c ; out : LosBusDel) EvalIns(in : P k, c ; out : LosBusIns, LosUser) dove c è l utente che realizza sino a questo momento lo scambio migliore. La funzione EvalIns(in: P k, c; out: LosBusIns, LosUser), nel criterio di dominanza, indica come unico valore di output il LosBusIns. L algoritmo valuta solo lo spostamento dei primi Nu utenti, dove Nu è un parametro che può variare in modo adattativo come sarà spiegato nel paragrafo Scelto un utente c da ri-allocare, prima di effettuare la valutazione dello spostamento sugli altri veicoli della flotta, l algoritmo procede al loro ordinamento in base alla distanza minima tra le tappe di carico e scarico dell utente e le tappe del piano di instradamento comprese nell intervallo che va dall inizio della finestra temporale di partenza alla fine della finestra temporale di arrivo. L algoritmo considera solo i primi Nb veicoli, dove Nb è un parametro che può variare in modo adattativo analogamente a N u. Ad ogni iterazione dell algoritmo di ricerca locale viene eseguito un algoritmo che calcola il piano di carico di ciascun veicolo coinvolto nello spostamento dell utente c. Gli algoritmi sviluppati sono due. Il primo algoritmo, evolutivo, cancella le azioni di carico e scarico delle chiamate deallocate dal veicolo, e aggiunge le azioni

37 4.3 Algoritmo di ricerca locale 36 di carico e scarico delle chiamate allocate al veicolo. Il secondo algoritmo, costruttivo, parte da una soluzione vuota e ricostruisce da capo il piano di carico del veicolo da cui è stato deallocato l utente. Nel caso in cui si giunga ad un ottimo locale, si applica l algoritmo costruttivo sul veicolo critico con l obiettivo di ridurne il valore del LoS. Riducendo il valore del LoS il veicolo critico potrebbe cambiare e quindi è possibile applicare nuovamente la ricerca locale. Si riporta in figura 4.2 lo pseudocodice della ricerca locale Algoritmo evolutivo L algoritmo evolutivo riceve in input i piani di carico P k e P k dei veicoli coinvolti nello scambio calcolati all iterazione precedente dell algoritmo di ricerca locale e l utente c che deve essere deallocato dal veicolo P k e allocato al veicolo P k. L algoritmo è costituito dalle funzioni Del(in: P k, c) e Ins(in: P k, c). La complessità del problema è pari a O(N 3 ) dove N è il numero delle tappe presenti nel piano di carico P k Algoritmo costruttivo I dati di input dell algoritmo sono costituiti da: elenco delle tappe da ordinare: nel piano di carico del veicolo k sono inserite le tappe di carico e scarico nel caso in cui l utente non sia ancora a bordo e solamente la tappa di scarico nel caso in cui utente sia a bordo del veicolo; posizione corrente del veicolo: questa informazione serve per calcolare i cammini minimi tra le tappe di carico e di scarico e valutare gli istanti in cui verranno effettuate le azioni di carico e di scarico; numero di posti liberi sul veicolo: l ammissibilità della soluzione comporta il rispetto del vincolo relativo alla capacità del veicolo. La costruzione del piano di carico P k parte da una situazione in cui da 0 a q k persone sono già a bordo. L algoritmo produce in output una sequenza ordinata di tappe P k che il veicolo k dovrà eseguire e il valore di LoS degli utenti. L algoritmo aggiunge

38 4.3 Algoritmo di ricerca locale 37 iterativamente le tappe di carico e di scarico di una chiamata allocata al veicolo ad un piano di carico parziale P k, inizialmente vuoto, finché tutte le tappe sono state inserite. Le chiamate sono ordinate in base all istante di inizio della finestra temporale di partenza originale. La sequenza P k di tappe già inserite non viene più modificata. L obiettivo dell algoritmo è di minimizzare, per ciascun utente c, per ciascun inserimento possibile, il LoS del veicolo nel rispetto del vincolo di capacità. La complessità di questo algoritmo, è O(N 4 ) dove N è il numero delle tappe presenti nel piano di carico P k.

39 4.3 Algoritmo di ricerca locale 38 /* inizializzazione */ los(k) := max k M (los(k)) W orstlos := los(k) BestBus := null BestCall := null OrderCallsForLos(in: c k; out: N) /* in questo ciclo possiamo limitare la scansione delle chiamate */ for each c N do OldLosUser := los c EvalDel(in: P k, c; out: LosBusDel) if LosBusDel W orstlos then OrderBusForDistance(in: c, k k M; out: P ) /* in questo ciclo possiamo limitare la scansione dei bus */ for each x P do EvalIns(in: P x, c; out: LosBusIns, LosUser) LosRete := max(losbusdel, LosBusIns) for each k M do if k k and k x and los(k) > LosRete then LosRete := los(k) if LosRete < W orstlos or LosRete = W orstlos and LosBusDel < LosRete and LosBusIns < LosRete or LosRete = W orstlos and max(losbusdel, LosBusIns) = LosRete and LosUser < OldLosUser then W orstlos := LosRete BestBus := x BestCall := c if BestBus null and BestCall null then Del(in: P k, BestCall) Ins(in: P BestBus, BestCall) AlgortimoCostruttivo(in: P k, P oscorr k, y P oscorrk k ) else AlgoritmoCostruttivo(in: P k, P oscorr k, y P oscorrk k ) Figura 4.2: pseudocodice della ricerca locale

40 4.3 Algoritmo di ricerca locale Taratura dinamica degli intorni Per poter tarare al meglio la dimensione dell intorno nell algoritmo di ricerca locale è stato condotto un test utilizzando un insieme di 20 chiamate distribuite in modo uniforme in un intervallo di tempo di circa 45 minuti. Le richieste sono state effettuate con un anticipo di almeno 20 minuti. Per ciascuna elaborazione è stata considerata una flotta costituita rispettivamente da 4,6 e 8 veicoli con capacità pari a 9 unità. Le grandezze valutate sono la qualità della soluzione e il tempo di esecuzione dell algoritmo. Veicoli Senza Nu=2 Nu=4 Nb=2 Nu=4 Nu=Nb=2 Nu=Nb=4 4 3,128 3,468 3,234 3,382 3,128 3,478 3, ,533 2,927 2,782 2,891 2,742 2,987 2, ,232 2,421 2,349 2,412 2,289 2,423 2,232 Tabella 4.1: valutazione del livello di servizio massimo Veicoli Senza Nu=2 Nu=4 Nb=2 Nu=4 Nu=Nb=2 Nu=Nb=4 4 98,37 36,42 52,11 48,37 57,07 27,81 70, ,18 43,87 55,15 51,23 63,51 38,74 82, ,48 48,02 60,16 54,12 71,22 56,72 97,14 Tabella 4.2: valutazione dei tempi di calcolo Dai risultati ottenuti, riportati nelle tabelle 4.1 e 4.2, notiamo come le limitazioni introdotte riducono notevolmente i tempi di calcolo mantenendo un LoS adeguato. In particolare la limitazione degli utenti riduce i tempi di calcolo quando il numero dei veicoli è basso mentre la limitazione dei veicoli riduce i tempi di calcolo quando il numero di veicoli alto. La combinazione delle due limitazioni riduce in ogni caso i tempi di calcolo. In tutti i test sucessivi verranno utilizzati i parametri Nu e Nb pari a 4, con la seguente limitazione adattativa: quando giunge una nuova chiamata al sistema entrambi i parametri si riducono a 2. Una volta che la chiamata è stata servita si riportano i parametri a 4. In questo modo, durante l inserimento di una chiamata, si bloccano un numero minore di veicoli, e quelli bloccati vengono utilizzati per meno tempo.

41 4.4 Cammini minimi Cammini minimi La mappa stradale di Milano utilizzata nel database è stata trasformata digitalmente in un insieme di segmenti, delimitati da due nodi che rappresentano delle parti di carreggiata, intersezioni o singole strade in cui possono circolare mezzi o pedoni. Queste informazioni sono state raccolte in un database fornito da Navteq [11]. Tutte le informazioni che contraddistinguono ciascun segmento vengono rappresentate mediante una t-upla. In particolare le informazioni utili sono le seguenti: ID univoco e non duplicabile per identificare il tratto sulla mappa; ID dei nodi adiacenti; indirizzo, composto da via, range di numeri civici, CAP e zona; tipo di arco (incrocio, rotonda, soprelevata, galleria, strada piana,... ); tipo di strada (interna, di collegamento tra isolati, di collegamento tra aree urbane, di scorrimento, autostrada); velocità massima di percorrenza (utile dato da cui iniziare a calcolare le velocità di percorrenza medie); informazioni aggiuntive (privata, a pedaggio, riservata a taxi, filobus o bus). Queste informazioni permetto di riconoscere ed identificare ogni strada nel pieno delle sue caratteristiche. Il database manca però di realismo, in quanto non riporta dati di traffico e di velocità media di percorrenza, ma solo le informazioni sulla geometria e sulla tipologia delle strade, a partire dalle quali, mediante coefficienti e statistiche, cerca di derivare i tempi verosimili di percorrenza. Per integrare le informazioni dei database sono state create delle matrici che contengono le informazioni sui tempi di percorrenza e i percorsi da un nodo all altro. Le matrici sono generate off-line su l intera rete una sola volta per tutta la simulazione, di conseguenza l algoritmo non deve spendere cicli di clock in real time per calcolare cammini ottimi tra gli archi e i nodi del grafo, soprattutto considerando che l algoritmo non

42 4.4 Cammini minimi 41 deve trovare un solo cammino ottimo, ma deve confrontare molti cammini possibili, in tempo reale. Gli aspetti negativi di questo approccio sono che la dimensione delle matrici bidimensionali tende a crescere quadraticamente e che non possono essere aggiornate in tempo reale. Figura 4.3: mappa completa dell area di Milano La figura 4.3, presa dal programma ArcGIS [10], rappresenta l area, evidenziata in giallo, memorizzata nel database. In azzurro sono evidenziate le strade che interessano le simulazioni successivamente esposte; le variazioni verso l azzurro più chiaro fino al bianco evidenziano la tipologia di strade, da quelle interne a quelle più scorrevoli fino ad arrivare a quelle inaccessibili ai pedoni come le autostrade e le tangenziali. In arancio è evidenziata la rete ferroviaria, ai vertici della quale sono presenti varie zone di interscambio di trasporti.

43 Capitolo 5 Risultati sperimentali 5.1 Simulatore Dial-a-Ride Il simulatore permette di eseguire automaticamente delle prenotazioni a partire da un insieme di richieste create o caricate. Per creare una prenotazione si devono riempire tutti i campi del modulo riportato in figura 5.1. Figura 5.1: modulo di creazione di una prenotazione

44 5.1 Simulatore Dial-a-Ride 43 E possibile creare delle simulazioni esternamente al software (ad esempio con Excel o con il programma tripgen). Il caricamento delle prenotazioni avviene con tre differenti modalità: File: carica un insieme di prenotazioni precedentemente salvate; ATMDatabase: carica un insieme di prenotazioni in un formato concordato con la società ATM per il servizio Radio Bus [9] da un file MS Access con la struttura definita in tabella 5.1; Database: carica un insieme di prenotazioni da un file MS Access con la struttura definita in tabella 5.2. ID RappresentazioneFermata Indirizzo NPersone NDisabili OrarioDesiderato Vincolo IndirizzoDesiderato CivicoDesiderato OrarioDiCalcolo Codice int string string int int string string string string datetime int Tabella 5.1: struttura prenotazione ATM

45 5.1 Simulatore Dial-a-Ride 44 ID IDSimulazione IDPrenRef CodiceUtente StradaPartenza CivicoPartenza IDComunePartenza StradaArrivo CivicoArrivo IDComuneArrivo Data IsPartenza Richiamata RichiamataBis IDFascia NumeroPersoneNormale NumeroPersoneDisabili ComunePartenza ComuneArrivo Fascia IndirizzoPartenza IndirizzoArrivo StradaPartenzaNome StradaArrivoNome NumeroPersone AcceptSolution Renegotiate AcceptRenegotiateSolution PrenotationDate int int int string string int int string int int datetime boolean string string int short short string string string string string string string string boolean boolean boolean datatime Tabella 5.2: struttura prenotazione Ogni prenotazione, prima di essere caricata nel sistema, viene validata sugli indirizzi di partenza e arrivo della rete caricata nel sistema DaR. Le preno-

46 5.1 Simulatore Dial-a-Ride 45 tazioni non valide non vengono caricate nel simulatore. Prima di eseguire una simulazione viene visualizzata la schermata di configurazione nella quale si devono impostare alcuni parametri di simulazione come la velocità di esecuzione (1x, il tempo trascorre normalmente, 2x ogni secondo di simulazione equivale a 2 secondi di tempo normale, ecc), la data e l ora di partenza della simulazione. Una volta avviata la simulazione viene visualizzata una schermata di Log nella quale è possibile controllare l andamento della simulazione e le statistiche finali al termine dell esecuzione. Il tool tripgen è un programma che permette di creare una simulazione per il software DaR, secondo parametri che l utente può variare tramite un file di configurazione dato come input al programma. I parametri variabili dall utente sono: distribuzione temporale delle chiamate telefoniche al call center per prenotare i viaggi; distribuzione temporale dei viaggi prenotati dai clienti; date dei viaggi e delle chiamate; distribuzione numerica dei passeggeri sugli autobus, compresi i disabili; selezione di alcune opzioni per il buon fine delle contrattazioni (accettazione soluzione, rinegoziamento).

47 5.2 Risultati Risultati L analisi delle prestazioni di un sistema richiede di definire opportuni criteri di valutazione. Per la valutazione di un algoritmo, tipicamente si considerano due punti di vista: efficacia e efficienza. L efficacia rappresenta un indice dei risultati prodotti, in questo lavoro è stata valutata in termini di: percentuale di richieste servite; LoS dell utente peggio servito; LoS medio. L efficienza descrive le prestazioni di un algoritmo in termini di velocità: ha un ruolo fondamentale quando la qualità di una soluzione dipende anche dalla velocità con cui essa viene determinata Configurazione di prova I test sono stati condotti su un PC con processore Pentium 4 a 2.40 Ghz, dotato di 1.00 GB di RAM, sistema operativo Windows XP Professional. Il progetto è stato realizzato in C# [19] utilizzando come ambiente di sviluppo Microsoft Visual Studio.NET. Verranno ora descritti brevemente i principali parametri attraverso i quali sono state definite le varie configurazioni di test, utilizzate poi per le prove. La diversa ampiezza delle finestre temporali, associate alle richieste di un problema, dipende dal valore assegnato a due parametri: il livello di servizio minimo garantito e il massimo tempo di attesa (MWT ). La riduzione di tale ampiezza corrisponde ad una maggiore qualità di servizio ma vincola più strettamente il problema, accrescendo la difficoltà di costruzione della soluzione e riducendo il numero di scambi possibili con la ricerca locale. Il livello di servizio minimo offerto al cliente è determinato dal valore del MaxLoS, introdotto nel paragrafo 3.2. Fatta eccezione per alcuni test mirati a valutare l impatto della diversa ampiezza delle finestre temporali sulle prestazioni dell algoritmo, il parametro MWT è stato impostato a 15 minuti, Ma a 50 minuti,v c e v l a 10 minuti (MaxLoS costante). Le chiamate richiedono il servizio con un anticipo minimo di 20 minuti.

48 5.2 Risultati Confronto tra algoritmi Questo test permette di verificare quanto l algoritmo di ottimizzazione sviluppato migliori la soluzione trovata con la semplice inserzione. Ho utilizzato un insieme di 30 chiamate (selezionate in modo che venissero tutte accettate) distribuite uniformemente in un ora con destinazioni distribuite nel grafo. La configurazione della flotta varia in modo tale che il numero di posti a sedere sia costante. Flotta LoS LoS Tempo di (veicoli,capacità) Massimo Medio esecuzione (s) M=8, q k =4 4,914 3,868 34,42 M=4, q k =8 5,847 4,982 21,09 M=2, q k =16 6,512 5,712 16,39 Tabella 5.3: algoritmo di sola inserzione Flotta LoS LoS Tempo di (veicoli,capacità) Massimo Medio esecuzione (s) M=8, q k =4 2,436 1, ,70 M=4, q k =8 3,172 2, ,61 M=2, q k =16 3,925 3, ,94 Tabella 5.4: algoritmo di ottimizzazione Dalla tabella 5.4 notiamo come il LoS massimo e il LoS medio migliorino rispetto ai medesimi valori della tabella 5.3. Per garantire il livello di servizio ottenuto con l algoritmo di ottimizzazione anche con il solo algoritmo di inserzione, si deve ridurre il valore di Ma. Flotta Ma Richieste LoS LoS (veicoli,capacità) Impostato rifiutate Massimo Medio M=8, q k = ,478 2,286 M=4, q k = ,101 3,009 M=2, q k = ,954 3,729 Tabella 5.5: chiamate perse

49 5.2 Risultati 48 Dalla tabella 5.5 si evince che, nonostante il numero dei posti a sedere sia costante, il numero delle chiamate rifiutate aumenta con la diminuzione dei veicoli disponibili. Nell ultimo caso oltre il 50 % di richieste sono state rifiutate: il loro inserimento avrebbe peggiorato troppo il livello di servizio degli utenti già allocati sul veicolo oppure le inserzioni possibili non permettevano di ottenere il livello di servizio garantito. In tutti i casi la soluzione migliora con l aumentare dei veicoli utilizzati, nonostante il numero di posti a sedere sia costante. Questo significa che per un servizio di questo tipo è preferibile utilizzare diversi veicoli di dimensioni ridotte che pochi veicoli con un maggior numero di posti Destinazioni comuni e distribuite Utilizziamo un insieme di 40 chiamate (selezionate in modo che vengano tutte accettate) distribuite uniformemente nell arco temporale di un ora con destinazioni distribuite nel grafo e con destinazioni comuni posizionate alla sede del Poliedra. Come nel test precedente, la configurazione della flotta varia in modo tale che il numero di posti a sedere sia costante. Flotta LoS LoS Tempo di (veicoli,capacità) Massimo Medio esecuzione (s) M=10, q k =4 2,801 2, ,70 M=4, q k =10 3,322 2, ,67 M=2, q k =20 4,215 3, ,81 Tabella 5.6: destinazioni distribuite Flotta LoS LoS Tempo di (veicoli,capacità) Massimo Medio esecuzione (s) M=10, q k =4 2,458 2, ,94 M=4, q k =10 2,912 2, ,75 M=2, q k =20 3,575 3, ,83 Tabella 5.7: destinazioni comuni Come ci attendevamo i risultati migliori si ottengono con le destinazioni comuni (tabella 5.7) rispetto a quelle distribuite nel grafo (tabella 5.6). Anche

50 5.2 Risultati 49 i tempi di esecuzione nel caso delle destinazioni comuni sono minori: il problema risulta maggiormente vincolato e quindi l algoritmo viene arrestato in tempi più brevi Posizione della fermata di scambio Nei test condotti precedentemente è stato considerato un unico turno di lavoro: in una situazione reale questo non è consentito, è necessario uno scambio di autisti. Il software DREAMS permette di inserire fermate di scambio che devono essere obbligatoriamente soddisfatte nell ora e nel luogo previsto. Lo scopo di questo test è di dimostrare come l ubicazione delle fermate di scambio possano influire sul livello di servizio degli utenti. Sono state condotte due prove, entrambe con 30 chiamate (selezionate in modo che venissero tutte accettate) che richiedono il servizio nell ora in cui avviene lo scambio tra autisti. Nella prima prova (tabella 5.8) la fermata di scambio è posizionata in un punto periferico rispetto al baricentro della rete stradale, nella seconda (tabella 5.9) in punto centrale. Flotta LoS LoS Tempo di (veicoli,capacità) Massimo Medio esecuzione (s) M=8, q k =6 4,801 3, ,20 M=6, q k =8 5,322 4, ,38 M=4, q k =12 6,215 5, ,65 Tabella 5.8: scambio periferico Flotta LoS LoS Tempo di (veicoli,capacità) Massimo Medio esecuzione (s) M=8, q k =6 3,458 2, ,57 M=6, q k =8 4,212 3, ,55 M=4, q k =12 4,875 4, ,34 Tabella 5.9: scambio centrale Analizzando i risultati ho constatato che gli utenti peggio serviti sono quelli che hanno, durante il loro tragitto, la fermata di scambio. Essi devono compiere infatti un tragitto maggiore per andare alla loro destinazione.

51 5.2 Risultati Dimensione delle finestre temporali In questo test si intende verificare la dipendenza della qualità dei risultati ottenuti dalle caratteristiche dei dati forniti in ingresso al sistema; saranno analizzate le soluzioni al variare dell ampiezza delle finestre temporali. Utilizziamo un insieme di 100 chiamate distribuite nell arco temporale di due ore. Nella prima prova (tabella 5.10) è stato impostato a 10 minuti il parametro MWT, a 20 minuti Ma, a 10 minuti v c e a 20 minuti v l. Flotta Richieste LoS LoS Tempo di (veicoli,capacità) rifiutate Massimo Medio esecuzione (s) M=10, q k =6 43 2,301 1, ,62 M=6, q k = ,523 2, ,91 M=3, q k = ,918 2, ,57 Tabella 5.10: qualità del servizio alta Nella seconda prova (tabella 5.11) è stato impostato a 15 minuti il parametro MWT, a 35 minuti Ma, a 10 minuti v c e a 20 minuti v l. Flotta Richieste LoS LoS Tempo di (veicoli,capacità) rifiutate Massimo Medio esecuzione (s) M=10, q k =6 28 2,609 2, ,72 M=6, q k = ,854 2, ,55 M=3, q k = ,756 3, ,21 Tabella 5.11: qualità del servizio media Nella terza prova (tabella 5.12) è stato impostato a 20 minuti il parametro MWT, a 50 minuti Ma, a 10 minuti v c e a 20 minuti v l. Flotta Richieste LoS LoS Tempo di (veicoli,capacità) rifiutate Massimo Medio esecuzione (s) M=10, q k =6 12 3,001 2, ,91 M=6, q k = ,898 3, ,01 M=3, q k = ,315 3, ,84 Tabella 5.12: qualità del servizio bassa

52 5.2 Risultati 51 Dal seguente test emerge che le istanze con finestre temporali più strette danno origine ad un problema più vincolato che lascia all algoritmo minori margini di ottimizzazione. Al contrario se si considerano dei vincoli temporali più laschi si possono costruire, in primo luogo, rotte che servono un maggior numero di richieste e, in secondo luogo, il problema risulta meno vincolato quindi si hanno maggiori margini di ottimizzazione. Da questa considerazione si comprende la differenza dei tempi richiesti per l ottimizzazione Differenza del LoS tra inserzione e servizio In questo test è stato utilizzato un insieme di 19 chiamate, distribuite nell arco temporale di mezz ora. La flotta utilizzata è composta da 4 veicoli con 7 posti. Lo scopo di questa analisi è verificare quanto cambia il LoS dalla fase di inserzione a quando viene effettivamente servito l utente, attraverso l algoritmo di ottimizzazione. Dalla figura 5.2 si evince che gli utenti meglio serviti nella fase di inserzione sono i primi mentre gli ultimi hanno un livello di servizio peggiore. Il LoS peggiore, però, cala attraverso l algoritmo sviluppato peggiorando il LoS di altri utenti equilibrando, per quanto possibile, il livello di servizio di tutti gli utenti. Questo fa si che che la differenza tra il LoS massimo e il LoS medio sia ridotta, nel caso si applichi l algoritmo di ottimizzazione. Figura 5.2: differenza del LoS di inserzione e il LoS dopo l ottimizzazione

53 5.2 Risultati Simulazione di un caso reale Nel seguente test si è cercato di emulare un caso reale: è stato utilizzato un insieme di 450 chiamate distribuite nell arco temporale di 15 ore. La richiesta del servizio è concentrata al mattino, dalle 8:00 alle 10:00, a mezzogiorno, dalle 12:00 alle 14:00, e alla sera, dalle 21:00 alle 23:00. Nel resto della giornata la domanda è più bassa e costante. I parametri utilizzati sono i seguenti: il parametro MWT è stato impostato a 20 minuti, Ma a 50 minuti,v c e v l a 10 minuti. I veicoli utilizzati sono 10 con 10 posti. Le chiamate non hanno un anticipo minimo di richiesta del servizio: questo parametro risulterà decisivo ai fini della simulazione. Delle 450 chiamate sottoposte ne sono state accettate 416. Il tempo di esecuzione totale dell algoritmo di ottimizzazione è stato di 19875,15 secondi. Veicolo LoS LoS N Massimo Medio Tabella 5.13: LoS massimo e LoS medio per veicolo Dalla tabella 5.13 possiamo notare come il LoS massimo e il LoS medio siano differenti; questo risultato va in contraddizione con gli esiti ottenuti nel paragrafo Il motivo è il seguente: gli utenti che hanno ottenuto un LoS scarso hanno richiesto il servizio pochi minuti prima del viaggio, non consentendo all algoritmo di ottimizzazione di migliorare il loro LoS, mantenendo quello di inserzione.

54 5.2 Risultati Tempo minimo di anticipo Dal test precedente è emerso quanto è influente il tempo di anticipo delle chiamate rispetto al viaggio richiesto. Questo test vuole dimostrare quanto il tempo di anticipo delle chiamate influisca sul LoS massimo e sul tempo di calcolo degli algoritmi. Ho utilizzato un insieme di 30 chiamate distribuite uniformemente nell arco temporale di un ora con una flotta di 5 veicoli con capacità pari a 8. Ho valutato le prestazioni variando l anticipo con cui vengono effettuate le richieste di viaggio da 50 minuti a 5 minuti. Tempo di Richieste LoS LoS Tempo di anticipo rifiutate Massimo Medio esecuzione (s) ,381 2, , ,673 2, , ,114 2, , ,215 4,793 53,14 Tabella 5.14: variazione del tempo di richiesta del servizio Dalla tabella 5.14 notiamo che se la richiesta viene elaborata con maggiore anticipo viene servita meglio. Inoltre il tempo di calcolo aumenta perchè vengono servite un maggior numero di chiamate e quindi sono possibili un maggior numero scambi. Al contrario quando una richiesta viene elaborata con un minore anticipo viene servita peggio o non viene servita affatto. Il motivo è il seguente: se la posizione corrente del mezzo è talmente distante da non raggiungere l utente senza andare in contraddizione con il livello di servizio minimo offerto viene rifiutata. Se viene accettata significa che il veicolo è nelle vicinanze dell utente e quindi è possibile servirlo. In una città grande e trafficata come Milano questa situazione è piuttosto rara soprattutto con un numero di veicolo ridotti come in questo test. In figura 5.3 è mostrato l andamento del LoS massimo, quindi della funzione obiettivo, in funzione dell arrivo delle chiamate.

55 5.2 Risultati 54 Figura 5.3: andamento del LoS massimo in funzione dell arrivo delle chiamate