Capitolo 5

(1)

Capitolo 5

La simulazione

(2)

228

La simulazione

Il programma

Il programma utilizzato è stato realizzato in linguaggio Python. Python è un linguaggio di programmazione ad alto livello, interpretato, orientato agli oggetti, adatto, tra gli altri usi, per sviluppare applicazioni distribuite, scripting, computazione numerica e system testing. Rilasciato pubblicamente per la prima volta nel 1991 dal suo creatore Guido Van Rossum, programmatore olandese attualmente operativo in Google, deriva il suo nome dalla commedia Monty Python's Flying Circus dei celebri Monty Python, in onda sulla BBC nel corso degli anni 70. Attualmente, lo sviluppo di Python (grazie e soprattutto all'enorme e dinamica comunità internazionale di sviluppatori) viene gestito dall'organizzazione no-profit Python Software Foundation. Python supporta diversi paradigmi di programmazione, come quello object - oriented (con supporto all'ereditarietà multipla), quello imperativo e quello funzionale, ed offre una tipizzazione dinamica forte. È fornito di una libreria built - in estremamente ricca, che unitamente alla gestione automatica della memoria e a robusti costrutti per la gestione delle eccezioni fa di Python uno dei linguaggi più ricchi e comodi da usare.

Comodo, ma anche semplice da usare e imparare. Python, nelle intenzioni di Guido Van Rossum, è nato per essere un linguaggio immediatamente intuibile ed altamente leggibile. Visivamente si presenta in modo molto semplice, la sua sintassi è pulita e snella così come i suoi costrutti, decisamente chiari e non ambigui, a differenza ad esempio di altri linguaggi strutturati come C, Perl o Pascal. I blocchi logici vengono costruiti semplicemente allineando le righe allo stesso modo, incrementando la leggibilità e l'uniformità del codice anche se vi lavorano diversi autori.

(3)

229

Python è un linguaggio multi - paradigma, infatti permette in modo agevole di

scrivere programmi seguendo il paradigma object - oriented, la

programmazione strutturata oppure la programmazione funzionale. Il controllo dei tipi è forte (strong typing) e viene eseguito al runtime (dynamic typing). In altre parole una variabile non è altro che un contenitore (che nella sua storia può assumere valori sempre dello stesso tipo) al quale viene associata un'etichetta (il nome) che, durante l'esecuzione del programma (runtime), può essere spostata e associata a diversi contenitori anche di tipo diverso. Quindi Python è un linguaggio pseudo compilato: un interprete si occupa di analizzare il codice sorgente (semplici file testuali con estensione .py) e, se sintatticamente corretto, di eseguirlo. In Python, non esiste una fase di compilazione separata (come avviene in C, per esempio) che generi un file eseguibile partendo dal sorgente.

L'esser pseudo interpretato rende Python un linguaggio portabile. Una volta scritto un codice sorgente, esso può essere interpretato ed eseguito sulla gran parte delle piattaforme attualmente utilizzate, siano esse di casa Apple (Mac) che PC (Microsoft Windows e GNU/Linux). Semplicemente, basta la presenza della versione corretta dell'interprete.

Infine, Python è free software: non solo il download dell'interprete per la propria piattaforma, così come l'uso di Python nelle proprie applicazioni, è completamente gratuito; ma oltre a questo Python può essere liberamente modificato e così ridistribuito, secondo le regole di una licenza pienamente open - source.

Queste caratteristiche hanno fatto di Python il protagonista di un enorme diffusione in tutto il mondo, e anche in Italia, negli ultimi anni. Questo perché garantisce lo sviluppo rapido di applicazioni di qualsiasi complessità in tutti i contesti: dal desktop al web, passando dallo sviluppo di videogiochi e dallo scripting di sistema. Comunque pur essendo utile per scrivere script di sistema (in alternativa ad esempio a bash), la grande quantità di librerie disponibili e la facilità con cui questo linguaggio permette di scrivere software modulare favoriscono anche lo sviluppo di applicazioni molto complesse.

(4)

230

Dati di Input

I dati di input che il programma richiede sono: - la domanda suddivisa per fasce orarie

- la probabilità di arrivo ai sette parcheggi della cintura

- le coordinate dei nove parcheggi e dei centroidi delle unità in cui sono state suddivise le strade del centro storico

- la capacità attrattiva dei nove parcheggi e dei centroidi delle unità in cui sono state suddivise le strade del centro storico

Parametro del modello è invece il numero di veicoli PICAV previsto e la loro redistribuzione sui nove parcheggi, cioè l’organizzazione in termini di numero e disposizione della flotta dei veicoli. In Python, ogni classe di oggetti è caratterizzata da attributi e metodi.

Le classi considerate sono:

- Coordinate, i cui oggetti sono i centroidi delle centoventi unità in cui è

stato suddiviso il centro storico di Genova, e i nove ParkingLot

- Utenti, cioè la domanda in ingresso e in uscita dal centro storico

- Veicoli: PICAV

- Parcheggi: ParkingLots

- Gestore: Supervisore

Dato il loro esiguo numero, i parcheggi vengono creati uno ad uno. Invece gli utenti, i veicoli e le coordinate vengono creati mediante un ciclo “for” ed immediatamente inseriti in tre dizionari, uno per ogni classe, in modo tale da poter essere vagliati agevolmente.

Gli utenti sono stati divisi in due categorie: quelli che sono diretti all’interno del centro storico e quelli che invece escono dal suddetto centro storico.

(5)

231

Gli oggetti PICAV, Supervisore e coordinate sono entità permanenti, cioè sono esterne al tempo della simulazione, e rimangono “in vita” per tutta la durata della stessa. I veicoli PICAV si possono trovare in tre stati:

- stato 1 = occupati dall’utente

- stato 2 = in carica

- stato 0 = a disposizione dell’utente

Gli oggetti utenti invece sono entità temporanee. Infatti vengono generati, ed hanno inizialmente uno stato 0, cioè non sono ancora entrati nella simulazione. L’utente generico si trova nello stato 1 quando è in viaggio, cioè occupa un veicolo PICAV. Si trova invece nello stato 2 quando è in coda, e nello stato 5 quando è ancora in coda, ma gli è già stato assegnato un veicolo. Si trova infine nello stato 4 quando è uscito dalla simulazione.

In pratica, l’utente diretto al centro storico arriva ad uno dei parcheggi della cintura esterna. Se vi sono veicoli disponibili, entra in un PICAV. Altrimenti, si mette in coda, fino a quando non arriva il suo turno. L’utente può recarsi direttamente in un parcheggio del centro storico, oppure può svolgere una catena di spostamenti per effettuare una serie di attività, e ritornare a casa, e quindi lasciare il PICAV in uno dei sette parcheggi della cintura esterna. Nel primo caso, l’utente “scompare” finché non “riappare” nel parcheggio del centro storico più vicino alla sua destinazione, e in questo parcheggio lascia il PICAV. Poi, esce definitivamente dalla simulazione. Nel secondo caso, invece, l’utente “riappare” nella posizione in cui ha svolto l’ultima attività, dopo un tempo compreso tra 30 e 60 minuti. Nel nostro sistema di trasporto, abbiamo previsto che a questo punto l’utente effettui la chiamata al Supervisore: l’utente dà al supervisore indicazione sulla sua provenienza (Levante, Monte e Ponente: sono queste le possibili scelte) e questo gli assegna il parcheggio di destinazione da cui l’utente sarà in grado di prendere una linea del trasporto pubblico con cui tornare a casa. Questo è possibile perché l’utente raggiunge la cintura del centro storico utilizzando le linee del trasporto collettivo, che attraversano più parcheggi dei PICAV. Dopo aver effettuato la chiamata al

(6)

232

supervisore, l’utente “scompare” nuovamente e “riappare” nel parcheggio di destinazione assegnatogli dal Supervisore, dopo un tempo pari al tempo di viaggio.

Se l’utente invece proviene dal centro storico, e ritorna a casa, effettua immediatamente la chiamata al supervisore, poi “scompare” e “riappare”, dopo un tempo pari al tempo di viaggio, nel parcheggio di destinazione. Raggiunta la destinazione, esce definitivamente dalla simulazione.

Il servizio incomincia alle ore 6 della mattina, e tutti i veicoli PICAV sono disponibili ai nove parcheggi, già carichi, e quindi nello stato 0. Ciascun PICAV eredita gli attributi dell’utente che lo occupa, per poi azzerarli nuovamente una volta che l’utente, terminato il suo spostamento o le sue attività, esce dal sistema. Quindi il PICAV viene messo sotto carica, per un tempo pari a tre minuti se ha semplicemente compiuto lo spostamento da un parcheggio all’altro, oppure pari a dieci minuti se è stata compiuta una catena di spostamenti. La durata del tempo di ricarica è molto approssimativa, e lo stesso dicasi del fatto che il veicolo viene caricato tutte le volte che raggiunge un parcheggio. D’altra parte, è un po’ una scelta obbligata non avendo ancora a disposizione la legge di ricarica e di scarica delle batterie. I tempi di ricarica sono stati scelti considerando che la durata media degli spostamenti da parcheggio a parcheggio è nell’intervallo da 1 a 7 minuti, mentre la durata delle catene di attività è stato ipotizzato (sulla base anche delle interviste effettuate nelle due giornate di indagine sul territorio) nell’intervallo da 30 a 60 minuti.

Terminata la ricarica, il veicolo è nuovamente disponibile per un altro utente. Il servizio termina a mezzanotte. Successivamente, un operatore provvederà a riequilibrare la distribuzione dei PICAV, fino a riportarli nella disposizione che si aveva all’inizio della simulazione, pronti per effettuare un’altra giornata di servizio.

(7)

233

Differenze con il modello di sistema proposto

Nella seguente simulazione del sistema di trasporto proposto, attraverso il programma Python, sono state apportate alcune variazioni rispetto alla modellazione del sistema descritta nel Capitolo 2.

Queste differenze tra la modellazione teorica e la simulazione pratica sono: -

Primo

. Ho tenuto conto del fatto che il veicolo PICAV si avvale di una

propulsione ad alimentazione elettrica. Quindi sarà dotato di batterie che avranno una certa durata e che necessiteranno di essere ricaricate al termine del viaggio per poter rendere il veicolo pronto ad un successivo utilizzo. Chiaramente la legge di ricarica e di scarica delle batterie dipenderà dalla loro tipologia. Siccome ad oggi non abbiamo tali informazioni, abbiamo ipotizzato che sarà necessario caricare le batterie del veicolo al termine di ciascun viaggio, indipendentemente dalla sua durata, e abbiamo ipotizzato che per completare tale operazione saranno sufficienti 3 minuti nel caso di uno spostamento del tipo “Single Mission” e 10 minuti nel caso invece del tipo “Multi Missions” (essendo questo generalmente più lungo). Nell’ambito della simulazione è stato ritenuto necessario precisare questo dato perché chiaramente, mentre la durata della batteria la si ritiene assolutamente sufficiente per effettuare uno spostamento, di qualsiasi tipo, all’interno del centro storico, il tempo necessario a ricaricare le batterie influisce invece sulla lunghezza delle code e sui relativi tempi di attesa. Cioè un veicolo, di ritorno da una missione, arrivato ad un ParkingLot, non può essere ritenuto disponibile e quindi utilizzabile da parte di un utente che è appena arrivato al parcheggio o si trovava già lì in coda, fino a quando non avrà le sue riserve di batteria cariche in maniera sufficiente da poter

effettuare un altro viaggio all’interno del centro storico. Di

conseguenza questa operazione di ricarica ed il relativo tempo necessario incide direttamente sul tempo che l’utente è chiamato ad attendere prima di poter usufruire del servizio. Quindi ai fini di una simulazione che

(8)

234

fosse la più realistica possibile si è ritenuto necessario considerare tale aspetto.

-

Secondo

. Relativamente agli utilizzatori di PICAV appartenenti alla categoria A: “Multi Missions”, ho effettuato la seguente modifica. Nella modellazione ho ipotizzato che, una volta preso il PICAV, questi utenti venissero diciamo persi dal sistema fino a quando, una volta terminata la loro catena di spostamenti, non ricompaiono effettuando la chiamata al Supervisore, per sapere in quale ParkingLot devono riconsegnare il veicolo. Quindi ho creato la relativa domanda di PICAV in ritorno, cioè dall’interno del centro verso la cintura esterna, in termini di chiamate al Supervisore, sulla base di una distribuzione uniforme nel tempo sapendo quanti utenti appartenenti a tale categoria sono entrati nell’arco di un’ora e quindi dovranno anche uscire. Così facendo però conosco in quale istante ed ogni quanti minuti arriva una chiamata ma non so assolutamente da quale PICAV arrivi tale chiamata. Quindi rendo il tutto assolutamente casuale, cercando di riprodurre nel modo più realistico possibile il comportamento effettivo dell’utente. Nella simulazione invece abbiamo eliminato questo periodo di buco, questo periodo nel quale in pratica perdiamo l’utente e di conseguenza il PICAV in suo possesso. In pratica abbiamo fatto una ipotesi circa la durata della sua catena di spostamenti all’interno del centro storico. In questo modo una volta che il PICAV si è inoltrato all’interno del centro, sappiamo, sulla base di una pura approssimazione, dopo quanto tempo tale utente effettuerà la chiamata al Supervisore. Quindi in questo modo siamo in grado di tracciare il PICAV durante tutto il suo tragitto, dal ParkingLot di origine a quello di destinazione, seguendo i suoi spostamenti minuto dopo minuto. Questo, insieme ad una serie di altri parametri, ci ha permesso di controllare la correttezza della simulazione.

-

Terzo

. Per quanto riguarda la durata del servizio e quindi l’intervallo di

tempo

T

all’interno del quale andiamo a generare la domanda di PICAV in

(9)

235

preso in considerazione tutta la giornata cioè le ventiquattro ore, nella simulazione invece ho preso in esame solo l’intervallo di tempo che va dalle 6 del mattino alle 24 di sera. All’interno di questo intervallo

T

la suddivisione in fasce orarie è sempre la medesima, l’unica cosa che cambia è il fatto che l’ultima fascia anziché iniziare alle 20 e terminare il mattino seguente alle ore 6, inizia sempre alle 20 ma termina dopo solo quattro ore, alle 24 dello stesso giorno. In questo modo andiamo ad interrompere il servizio durante le ore notturne, come generalmente accade negli altri sistemi di trasporto pubblico, cioè nelle ore in cui comunque la domanda di PICAV è bassa, è ritenuta “morbida”. In pratica, nelle sei ore che così facendo non prendiamo in considerazione, andiamo a perdere, nel senso che non offriamo il servizio, una domanda pari a sole 56 persone, che corrisponderebbero all’incirca ad una richiesta di PICAV ogni sette minuti e mezzo. Questa interruzione del servizio è stata ritenuta opportuna, una volta constatato che comunque non crea particolari disagi, in quanto questo periodo è necessario, almeno in parte, per andare a ridistribuire la flotta dei veicoli sui nove ParkingLot. Cioè, come abbiamo appunto visto attraverso la simulazione, al termine della giornata di servizio, i PICAV risultano essere distribuiti in maniera assolutamente casuale tra i parcheggi previsti. In particolare generalmente si presenta la situazione critica in cui alcuni ParkingLot si ritrovano con un numero molto elevato di veicoli mentre la maggior parte ne hanno a disposizione un numero molto esiguo. Quindi si rende assolutamente necessario l’intervento del gestore, sotto forma di uno o più operatori, per ristabilire la condizione iniziale, di partenza. Questo significa che il gestore deve far si che alle ore 6 del mattino successivo, all’inizio del nuovo servizio, tutti i nove ParkingLot abbiano a disposizione il numero di PICAV appositamente previsto per poter effettuare il servizio richiesto in maniera ottimale.

(10)

236

Dati di output

La simulazione è stata programmata in maniera tale da avere come punti di riferimento fissi i seguenti dati di input:

- Numero e posizione dei ParkingLots

- Domanda in ingresso nel centro storico dal cordone esterno, con differenti frequenze a seconda della fascia oraria considerata

- Probabilità di arrivo a ciascuno dei ParkingLots previsti

- Capacità attrattiva di ciascuno dei ParkingLots previsti e di ognuna delle unità in cui sono state suddivise le strade del centro storico

La procedura con cui sono stati ottenuti questi dati ed il relativo valore sono stati ampiamente descritti nel Capitolo 4.

Ora, sulla base di questi parametri definiti e mantenuti fissi nel corso della simulazione, il programma è stato fatto girare: “runnare”, cambiando di volta in volta un’unica variabile, sempre la stessa, ovvero: la flotta dei veicoli PICAV a disposizione degli utenti, in particolare il numero e la loro distribuzione tra i vari ParkingLots previsti. In particolare sono stati previsti, come descritto nel prossimo paragrafo, tre possibili scenari, tre possibili differenti disposizioni dei PICAV. Il simulatore è stato chiamato ad analizzare ciascuno dei tre scenari per ben cinque volte, questo significa che per ognuno dei tre scenari il simulatore è stato fatto “runnare” per cinque volte consecutive.

Quindi, una volta definiti i dati di ingresso, il simulatore è stato programmato in maniera tale da fornire dei ben precisi dati di output. Questi dati sono stati scelti in funzione del parametro che è stato ritenuto significativo ai fini della valutazione, positiva o negativa, del funzionamento del sistema di trasporto proposto. Questo parametro è il tempo di attesa medio che i possibili utenti del sistema sarebbero chiamati a sopportare nel corso del servizio. Cioè mediamente quanto tempo, un utente che è arrivato ad uno dei ParkingLot, si trova costretto ad aspettare per poter prendere uno dei PICAV e quindi poter

(11)

237

iniziare il suo viaggio all’interno del centro storico. Chiaramente si presume che più basso sarà questo tempo di attesa medio e di conseguenza più alto sarà il grado di soddisfazione dell’utente al termine della corsa e quindi più elevata sarà la qualità del servizio proposto dal gestore.

Allora i dati di output che il simulatore è chiamato a fornire al termine della sua corsa, della sua elaborazione, sono:

- La lunghezza delle code, per ciascun ParkingLots, in ogni minuto dell’arco temporale della simulazione (dalle ore 6:00 alle ore 24:00), espressa in numero di persone. Cioè per ciascuno dei nove ParkingLots previsti, allo scorrere della barra del tempo, scandito in minuti, si ottiene il numero delle persone che sono in coda a quel parcheggio. Quindi il numero delle persone che arrivate al ParkingLot non hanno trovato un PICAV disponibile o comunque pronto all’utilizzo, e quindi sono state costrette a mettersi in coda per aspettare il loro turno.

- Il numero dei veicoli presenti, in ciascuno dei ParkingLots, in ogni minuto dell’arco temporale della simulazione (dalle ore 6:00 alle ore 24:00), espresso in unità. Cioè per ciascuno dei nove ParkingLots previsti, allo scorrere della barra del tempo, scandito in minuti, si ottiene il numero dei veicoli PICAV presenti al parcheggio. Quindi il numero dei veicoli a disposizione dei possibili utenti che nell’arco della giornata si presentano al ParkingLot per usufruire del servizio.

- L’elenco dei tempi di attesa, in ciascuno dei ParkingLots, che gli utenti, stati effettivamente in coda, sono stati costretti a sopportare, nell’arco temporale della simulazione (dalle ore 6:00 alle ore 24:00), espressi in minuti. Cioè per ciascuno dei nove ParkingLots previsti, il simulatore fornisce tutti gli utenti che nell’arco della giornata sono stati effettivamente in coda a quel parcheggio e per ognuno di questi utenti il relativo tempo di attesa espresso in minuti.

- Una serie di parametri che fotografano, nell’istante temporale finale della simulazione, le caratteristiche di ciascun veicolo utilizzato, come da

(12)

238

esempio: il numero identificativo del PICAV, il ParkingLot in cui si trova o non si trova se è ancora in viaggio, lo stato fisico che lo contraddistingue (occupato:1, in carica:2, a disposizione dell’utente:0). Questi parametri sono necessari esclusivamente per effettuare una abituale operazione di controllo, di check, sugli altri dati forniti in output, al fine di annullare o comunque ridurre al minimo eventuali errori che comunque potrebbero verificarsi all’interno di un siffatto sistema.

Chiaramente questi dati grezzi, forniti in output dal simulatore al termine di ciascuna delle cinque elaborazioni fatte eseguire dal programma per ognuno dei tre scenari presi in considerazione, sono stati successivamente elaborati. In una prima fase, per ciascuna delle cinque simulazioni eseguite dal programma per ognuno dei tre possibili scenari presi in considerazione, sono stati ottenuti i seguenti parametri:

- Relativamente alla lunghezza delle code, per ciascun ParkingLots, ho ricavato:

• la coda con la massima lunghezza, cioè il numero massimo di

persone che in un determinato minuto nell’arco della giornata sono state contemporaneamente in coda

• la sommatoria di tutte le code, cioè il numero complessivo delle

persone che durante il servizio sono state costrette a mettersi e a rimanere in coda

• la lunghezza media della coda, cioè il numero delle persone che

mediamente in ogni minuto, nell’arco della giornata, sono state costrette ad aspettare in coda un PICAV disponibile

- Relativamente al numero dei veicoli presenti, in ciascuno dei ParkingLots,

ho ricavato:

• il numero massimo di PICAV presenti, cioè il numero massimo di

veicoli che in un determinato minuto nell’arco della giornata sono stati disponibili in quel parcheggio

(13)

239

• la sommatoria di tutti i PICAV presenti, cioè il numero complessivo

dei veicoli che durante il servizio sono stati disponibili in quel parcheggio

• il numero medio di PICAV presenti, cioè il numero dei veicoli che

mediamente in ogni minuto, nell’arco della giornata, sono stati disponibili in quel parcheggio

- Relativamente ai tempi di attesa registrati, in ciascuno dei ParkingLots,

ho ricavato:

• il numero complessivo di utenti che nell’arco della giornata sono

stati costretti a mettersi in coda per poter disporre di un PICAV a quel ParkingLot

• il tempo di attesa massimo, cioè fra tutti gli utenti che sono stati

effettivamente in coda a quel parcheggio, il valore massimo, espresso in minuti, del tempo di attesa che hanno dovuto sopportare

• la sommatoria di tutti i tempi di attesa, cioè il tempo complessivo

che gli utenti durante il servizio sono stati costretti ad aspettare per poter disporre di un PICAV a quel ParkingLot

• il tempo di attesa medio, cioè il tempo che mediamente, nell’arco

della giornata, un utente presentatosi a quel ParkingLot, è stato costretto a sopportare per poter usufruire del servizio proposto In una seconda fase, per ciascuno dei tre possibili scenari presi in considerazione, sono stati aggregati ed elaborati i dati ottenuti per ognuna delle relative cinque simulazioni. Sono stati quindi determinati i seguenti parametri:

- La lunghezza delle code, per ciascun ParkingLots, espressa in numero di

persone che si sono trovate in attesa. In particolare la lunghezza massima della coda e la lunghezza media della coda. Chiaramente tali valori sono stati ottenuti mediando sulle simulazioni effettuate, cioè

(14)

240

aggregando i risultati ottenuti nelle cinque simulazioni effettuate per ciascun scenario.

Quindi, mediando su tutti e nove i ParkingLots, è stato ricavato il numero medio di utenti che teoricamente si potrebbero trovare in coda, in attesa di un PICAV, in ogni minuto, sui nove ParkingLots previsti, in quel particolare scenario.

- Il numero dei veicoli presenti, per ciascun ParkingLots, espresso in unità

di PICAV disponibili per essere utilizzati. In particolare il numero massimo ed il numero medio di veicoli presenti contemporaneamente in ogni parcheggio. Chiaramente tali valori sono stati ottenuti mediando sulle simulazioni effettuate, cioè aggregando i risultati ottenuti nelle cinque simulazioni effettuate per ciascun scenario.

Quindi, mediando su tutti e nove i ParkingLots, è stato ricavato il numero medio di PICAV che teoricamente potrebbero essere disponibili in ogni minuto, sui nove ParkingLots previsti, in quel particolare scenario.

- I tempi di attesa, in ciascuno dei ParkingLots, che gli utenti, stati

effettivamente in coda, sono stati costretti a sopportare, espressi in minuti. In particolare il valore massimo ed il valore medio dei tempi di attesa registrati ad ognuno dei nove parcheggi. Chiaramente tali valori sono stati ottenuti mediando sulle simulazioni effettuate, cioè aggregando i risultati ottenuti nelle cinque simulazioni effettuate per ciascun scenario.

Quindi, mediando su tutti e nove i ParkingLots, è stato ricavato il valore medio del tempo di attesa sui nove ParkingLots previsti, considerando solo gli utenti che sono stati effettivamente in coda ed infine il valore medio del tempo di attesa di tutti gli utilizzatori di PICAV, cioè considerando anche tutti quegli utenti che non sono stati in coda e che comunque fanno parte della domanda, sempre in relazione a ciascuno dei tre scenari previsti.

Infine in una terza ed ultima fase di elaborazione dei dati forniti dal programma, per ciascuno dei tre possibili scenari presi in considerazione, è

(15)

241

stato costruito un istogramma delle frequenze dei tempi di attesa, espressi in minuti, sopportati dagli utenti (in numero complessivo pari a 1414 unità). In pratica sono state eseguite le seguenti operazioni:

- sono state individuate sette classi a cui corrispondono altrettanti

intervalli temporali di tempi di attesa sopportati dagli utenti. Ovvero:

• Classe 1. Tempo di attesa pari a zero

• Classe 2. Tempo di attesa compreso tra 1 e 4 minuti

• Classe 7. Tempo di attesa superiore a 30 minuti

- ho individuato il numero degli utilizzatori di PICAV appartenenti ad

ognuna delle suddette sette classi

- ho individuato il numero degli utilizzatori di PICAV appartenenti ad

ognuna delle suddette sette classi in termini di percentuale rispetto al numero complessivo di utenti

- ho costruito l’istogramma riportando lungo l’asse delle ascisse le sette

differenti classi identificate dalle relative fasce di tempo di attesa e lungo l’asse delle ordinate le relative percentuali di utenti

Allora analizzando tutti questi risultati, confrontando tra loro i tre possibili scenari proposti, è stato possibile avanzare un progetto di distribuzione della flotta di veicoli PICAV tra i nove ParkingLot, che possa essere ritenuta idonea a fornire all’utente un servizio di qualità soddisfacente almeno in termini di tempi di attesa.

(16)

242

Scenari

In questo studio sono stati presi in considerazione tre possibili differenti scenari. Per scenario si intende una determinata distribuzione della flotta dei veicoli PICAV tra i nove ParkingLots previsti. Cioè i tre scenari si differenziano tra loro esclusivamente per la variazione di un solo parametro che è appunto il numero complessivo di PICAV che formano la flotta dei veicoli a disposizione degli utenti e di conseguenza il numero di PICAV assegnati a ciascuno dei nove ParkingLots. Quindi si passa da uno scenario all’altro modificando solamente il numero di PICAV che all’inizio del servizio, cioè alle ore 6:00 del mattino, si trovano parcheggiati in ciascun ParkingLot. Un aspetto molto importante è che all’interno di uno stesso scenario non cambia il numero di PICAV a disposizione di ogni parcheggio, cioè prendo in esame solo il caso di distribuzione uniforme dei veicoli, ovvero i ParkingLots sono tutti dotati dello stesso numero di PICAV. Tutti gli altri parametri, tutti gli altri dati di input, come ad esempio la domanda in ingresso e la sua suddivisione nelle due tipologie di “Multi Missions” e “Single Mission” non sono soggetti a variazione nel passaggio da uno scenario all’altro, cioè come già detto non fungono da variabili ma restano, almeno in questa ricerca, come condizioni al contorno fisse.

Per ciascuno dei tre scenari sono state effettuate, tramite il programma Python, 5 differenti e successive simulazioni, chiamate “run”, che ci hanno permesso di ottenere i dati di output descritti in precedenza.

Quindi di seguito vado ad analizzare i tre differenti scenari, cercando di individuare, mettendone in luce pregi e difetti, quello che meglio si adatta a fornire un servizio soddisfacente per i possibili utilizzatori di PICAV.

(17)

243

Scenario 1

Lo scenario numero 1 prevede una flotta complessiva di 36 PICAV (quella con il minor numero di veicoli), distribuita in maniera uniforme, cioè 4 veicoli PICAV per ciascuno dei 9 ParkingLots previsti.

Come si può vedere dal Grafico 5.1 solo il 26,1% dei possibili utenti del sistema di trasporto proposto, in questo possibile scenario, sarebbe chiamato ad aspettare in coda, in media sui 9 ParkingLots previsti, per un intervallo di tempo inferiore a 15 minuti. Di questa percentuale di persone, circa un 89% rimarrebbe in coda per un intervallo di tempo minore di 5 minuti.

A fronte di questo 26,1% la cui attesa è sicuramente da ritenersi accettabile, il restante 73,9% dei possibili utenti, quindi la stragrande maggioranza della domanda, sarebbe chiamato ad aspettare in coda per un intervallo di tempo superiore a 15 minuti. Questa possibilità non può assolutamente essere presa in considerazione se si vuole progettare un sistema di trasporto che soddisfi la domanda in maniera almeno soddisfacente, cioè se si vuole che il probabile utente possa ritenersi soddisfatto al termine del servizio.

Ad ulteriore avvallo di questa situazione chiaramente negativa si registrano ad esempio i seguenti dati:

- su di un totale di 7120 possibili utenti, ben 5507 di questi, cioè circa un

77%, sarebbe costretto una volta giunto al ParkingLot a mettersi in coda!

- ciascuno dei 7120 possibili utenti sarebbe destinato a restare in coda

mediamente per un tempo pari a circa 86 minuti, quindi addirittura per più di un’ora!

- ogni minuto, a ciascuno dei nove ParkingLots, si avrebbero mediamente

delle code costituite da ben 12 persone!

Tutte queste considerazioni ci portano senza ombra di dubbio a constatare che il suddetto scenario numero 1, che prevede il numero minimo di 4 PICAV per ogni ParkingLot, è assolutamente non accettabile.

(18)

244

(19)

245

(20)

246

(21)

247

(22)

248

(23)

249

(24)

250

(25)

251

(26)

252

Scenario 2

Lo scenario numero 2 prevede una flotta complessiva di 63 PICAV, distribuita in maniera uniforme, cioè 7 veicoli PICAV per ciascuno dei 9 ParkingLots previsti.

Come si può vedere dal Grafico 5.2 l’83,2% dei possibili utenti del sistema di trasporto proposto, in questo possibile scenario, sarebbe chiamato ad aspettare in coda, in media sui 9 ParkingLots previsti, per un intervallo di tempo inferiore a 15 minuti. Di questa percentuale di persone, ben un 75% rimarrebbe in coda per un intervallo di tempo addirittura minore di 5 minuti. A fronte di questo però un 16,8% dei possibili utenti sarebbe chiamato ad aspettare in coda per un intervallo di tempo superiore a 15 minuti. Questa possibilità non può sicuramente essere accettata se si vuole progettare un sistema di trasporto che soddisfi la domanda in maniera il più possibile ottimale, cioè se si vuole che il probabile utente possa ritenersi soddisfatto al termine del servizio.

Però, detto questo, se (come ad esempio accade già in alcune realtà alle fermate delle linee dell’autobus) fosse possibile, tramite appositi pannelli informativi, avvertire gli utenti in coda sulla durata della loro attesa, allora ai fini della realizzazione di un buon servizio potrebbe essere ritenuto accettabile che quasi un 17% della popolazione degli utenti aspetti per più di 15 minuti. Cioè se fosse possibile, una volta che l’utente arrivato al ParkingLot è costretto a mettersi in coda perché non ci sono PICAV disponibili all’utilizzo, comunicare al suddetto utente il numero dei minuti che sarebbe costretto ad attendere per poter disporre di un veicolo, allora potremmo ritenere di essere in grado di offrire all’utente un servizio almeno soddisfacente. Questo perché avremmo comunque messo quel 17% della domanda nella situazione di poter scegliere liberamente, ma soprattutto coscientemente, se aspettare o meno e quindi se utilizzare o meno il servizio da noi proposto. Perciò possiamo pensare che l’utente alla fine del servizio, almeno da questo punto di vista, potrà ritenersi soddisfatto o comunque non scontento del servizio stesso.

(27)

253

Quindi se fosse possibile mettere in pratica il suddetto accorgimento, per andare in contro alle esigenze di questo 17% della domanda, questo scenario numero 2 potrebbe essere ritenuto il migliore dei tre scenari proposti, se li andassimo a giudicare da un punto di vista complessivo, cioè considerando sia le esigenze degli utenti, sia le esigenze del gestore. Perché dal primo punto di vista: utente, sarebbe comunque in grado di garantire un tempo medio di attesa di poco superiore ai 6 minuti e con più dell’80% della domanda chiamata ad aspettare meno di 15 minuti; dal secondo punto di vista: gestore, richiederebbe un numero totale di PICAV pari a 63, che è superiore al dato relativo al primo scenario 36, ma decisamente inferiore a quello del terzo scenario 90, il quale come vedremo abbatte notevolmente i tempi di attesa per gli utenti ma a fronte appunto di una flotta numerosa e quindi molto più onerosa in termini di costi di acquisizione e gestione.

(28)

254

(29)

255

(30)

256

(31)

257

(32)

258

(33)

259

(34)

260

(35)

261

(36)

262

Scenario 3

Lo scenario numero 3 prevede una flotta complessiva di 90 PICAV (quella con il maggior numero di veicoli), distribuita in maniera uniforme, cioè 10 veicoli PICAV per ciascuno dei 9 ParkingLots previsti.

Come si può vedere dal Grafico 5.3 ben il 96,5% dei possibili utenti del sistema di trasporto proposto, in questo possibile scenario, sarebbe chiamato ad aspettare in coda, in media sui 9 ParkingLots previsti, per un intervallo di tempo inferiore a 15 minuti. Di questa percentuale di persone, circa un 90% rimarrebbe in coda per un intervallo di tempo addirittura minore di 5 minuti. A fronte di questo 96,5%, la cui attesa è da ritenersi non solo accettabile ma addirittura quasi inesistente, il restante 3,5% dei possibili utenti, quindi una piccolissima parte della domanda, sarebbe chiamato ad aspettare in coda per un intervallo di tempo superiore a 15 minuti. Questo scenario va sicuramente nella direzione giusta, nel senso che è assolutamente in grado di offrire un servizio che soddisfi la domanda in maniera ottimale, cioè è molto elevata la probabilità che l’utente possa ritenersi quantomeno soddisfatto al termine del servizio.

Ad ulteriore avvallo di questa situazione chiaramente positiva si registrano ad esempio i seguenti dati:

- su di un totale di 7120 possibili utenti, solo 1450 di questi, cioè circa un

20%, sarebbe costretto una volta giunto al ParkingLot a mettersi in coda!

- ciascuno dei 7120 possibili utenti sarebbe destinato a restare in coda

mediamente per un tempo pari a circa 2 minuti, praticamente un tempo irrisorio!

- ogni minuto, a ciascuno dei nove ParkingLots, si avrebbero mediamente

delle code costituite da sole 0,2 persone!

Tutte queste considerazioni ci portano senza ombra di dubbio a constatare che il suddetto scenario numero 3, che prevede il numero massimo di 10 PICAV per ogni ParkingLot, è assolutamente il migliore dal punto di vista dell’utente: in

(37)

263

quanto abbatte drasticamente i tempi di attesa in coda. Però se lo guardiamo dal punto di vista del gestore del sistema allora presenta senza dubbio il problema di richiedere un elevato numero di PICAV, ben 90 veicoli, determinando quindi un elevato costo sia in termini di acquisizione che di gestione della flotta.

Proprio per questo, lo scenario numero 2 sembra essere proprio il giusto compromesso tra lo scenario numero 1 (flotta di 36 PICAV), assolutamente non accettabile visto gli enormi tempi di attesa che impone agli sventurati utilizzatori di PICAV e lo scenario numero 3 (flotta di 90 PICAV) che invece, pur soddisfacendo pienamente la domanda, risulta non accettabile in termini di costi sostenuti dal gestore del sistema di trasporto.

(38)

264

(39)

265

(40)

266

(41)

267

(42)

268

(43)

269

(44)

270

(45)

271

(46)

272

Peculiarità e criticità

Analizzando i dati di output ottenuti nelle 15 simulazioni (5 simulazioni per ciascuno dei 3 scenari) eseguite, sono state evidenziate alcune peculiarità e/o criticità di un siffatto modello del sistema di trasporto proposto.

Ovvero:

- Il ParkingLot numero 3, situato in Piazza de Ferrari, presenta sempre, in

tutte le 15 simulazioni eseguite, il maggior numero di utenti che una volta giunti al parcheggio sono costretti a mettersi in coda per aspettare un PICAV disponibile. Questo non significa che presenta code sempre molto lunghe, se non le più lunghe, ma che al termine della giornata presenta il più alto numero di utenti che effettivamente sono stati in coda. Però a fronte di questo, tale ParkingLot non presenta mai tempi di attesa molto elevati, cioè sia il valore massimo che il valore medio dei tempi di attesa registrati, sono sempre contenuti o comunque in media con quelli degli altri parcheggi. Questa peculiarità sembra spiegabile dal fatto che: da un lato questo ParkingLot è caratterizzato da una elevata probabilità di arrivo di possibili utilizzatori di PICAV (la più alta tra i parcheggi della cintura esterna), quindi un elevato numero di persone che vi arrivano per richiedere un PICAV; dall’altro lato è comunque contraddistinto da una elevata capacità attrattiva e dal fatto di essere possibile ParkingLot di destinazione di tutti gli utenti in ritorno in quanto è inserito all’interno dell’insieme delle possibili destinazioni per tutte e tre le aree di Genova, quindi è comunque soggetto ad un discreto numero di PICAV in ritorno. Perciò pur essendo soggetto ad una domanda elevata riesce comunque, anche grazie all’intervento del Supervisore, a far fronte ad essa senza provocare elevati tempi di attesa.

- Il ParkingLot numero 5, situato in Sant’Agostino, presenta sempre, in

tutte le 15 simulazioni eseguite, il più elevato (scenario numero 1 e 3) o comunque il secondo più elevato (scenario numero 2) tempo di attesa da parte degli utenti che sono stati effettivamente in coda, sia in termini di

(47)

273

tempo di attesa massima sia in termini di tempo di attesa medio. Chiaramente risulta sempre in testa anche nella classifica dei ParkingLot dove si sono registrate le code più lunghe, cioè è il parcheggio dove nell’arco della giornata, ogni singolo minuto, si registra il maggior numero di utenti contemporaneamente in coda in attesa di un PICAV disponibile. A tutto questo si contrappone il fatto che presenta sempre un numero elevato di veicoli presenti al parcheggio. Questa criticità sembra spiegabile dal fatto che: da un lato questo ParkingLot è caratterizzato da una probabilità di arrivo di possibili utilizzatori di PICAV che potremmo definire medio – alta (la terza più alta tra i sette parcheggi della cintura esterna), quindi un numero abbastanza consistente di persone che vi arrivano per richiedere un PICAV; dall’altro lato è comunque contraddistinto da una bassissima capacità attrattiva (la più bassa tra i nove parcheggi previsti) e dal fatto di essere possibile ParkingLot di destinazione solamente degli utenti in ritorno che hanno come destinazione finale l’area di Genova classificata come “Monte”, che fra l’altro rappresentano solo un 31% dell’intera domanda, quindi è soggetto ad un bassissimo numero di PICAV in ritorno. Perciò essendo soggetto ad una domanda mediamente elevata non riesce quasi mai, anche a causa della minima possibilità di intervento del Supervisore, a far fronte ad essa senza provocare elevati tempi di attesa.

- Il ParkingLot numero 7, situato in Piazza Cavour, presenta le stesse

caratteristiche negative del ParkingLot numero 5, cioè: bassissima capacità attrattiva (la seconda più bassa tra i nove parcheggi previsti) ed il fatto di essere possibile ParkingLot di destinazione solamente degli utenti in ritorno che hanno come destinazione finale l’area di Genova classificata come “Monte”, che fra l’altro rappresentano solo un 31% dell’intera domanda, quindi risulta essere soggetto ad un bassissimo numero di PICAV in ritorno. Però, nonostante queste criticità, non presenta mai un elevato tempo di attesa da parte degli utenti che sono stati effettivamente in coda, sia in termini di tempo di attesa massima sia in termini di tempo di attesa medio, anzi dà sempre origine a tempi di

(48)

274

attesa inferiori alla media. Questa assoluta migliore condizione rispetto al ParkingLot numero 5 è da riconoscere al fatto che è caratterizzato da una bassissima probabilità di arrivo di possibili utilizzatori di PICAV (la più bassa tra i sette parcheggi della cintura esterna), quindi un numero praticamente irrisorio di persone che vi arrivano per richiedere un PICAV.

- I ParkingLots numero 10 e 11, ubicati all’interno del centro storico di

Genova, presentano sempre, in tutte le 15 simulazioni eseguite, la seguente criticità: con il trascorrere del tempo, nell’arco della giornata, tende a crescere notevolmente il numero di PICAV che vi vengono riconsegnati e che soprattutto vi rimangono parcheggiati, disponibili e non utilizzati. Tanto è vero che al termine del servizio, un numero molto elevato di PICAV si trova proprio in questi parcheggi, determinando un notevole squilibrio della flotta e richiedendo quindi l’intervento di un addetto per ripristinare le condizioni di partenza. Chiaramente in contemporanea a questo fatto, soprattutto nei ParkingLots numero 2, 3 e 4, si vanno formando code molto lunghe di utenti in attesa di un PIVCAV disponibile, generando in alcuni casi elevati tempi di attesa. Questa peculiarità dei suddetti due parcheggi, che si trasforma in una criticità per l’intero sistema, sembra spiegabile dal fatto che: da un lato questi ParkingLots, trovandosi all’interno del centro storico, non sono soggetti ad alcuna probabilità di arrivo di possibili utilizzatori di PICAV in ingresso nel suddetto centro ma sono soggetti esclusivamente alla domanda di PICAV da parte di quegli utenti (tipologia C: “Return from Single Mission”) che escono dal centro cioè effettuano il viaggio di ritorno, quindi un basso numero di persone che vi arrivano per richiedere un PICAV; dall’altro lato, proprio trovandosi nel cuore del centro storico, sono comunque contraddistinti da una elevata capacità attrattiva (le due più alte tra i nove parcheggi previsti) e quindi sono sede di un numero comunque elevato di PICAV in arrivo. Inoltre la situazione è ulteriormente aggravata dal fatto di non poter mai essere possibile ParkingLot di destinazione degli utenti in ritorno in quanto appunto si trovano all’interno del centro storico e quindi lontani dalle fermate delle

(49)

275

linee del trasporto pubblico, perciò non possono in alcun modo essere aiutati dal Supervisore, nel senso che il gestore non può intervenire indirizzando i PICAV diretti su quei parcheggi verso altri ParkingLot dove invece ce ne sarebbe bisogno in base ai tempi di attesa. Quindi si viene a creare la situazione assurda di avere, da un determinato momento in poi della giornata, praticamente un elevato numero di PICAV che rimangono intrappolati all’interno del centro storico perché da un lato vi si registra una bassa richiesta di PICAV e dall’altro lato invece un elevato numero di arrivi. Questo comunque sembra essere imputabile al fatto che in questa ricerca non abbiamo quantificato la domanda di PICAV generata dall’interno del centro storico cioè da quei residenti che comunque potrebbero utilizzare il PICAV per spostarsi verso l’esterno.

- A titolo esemplificativo, sono state effettuate alcune simulazioni in cui,

rispetto agli scenari effettivamente analizzati nel presente studio, è stata modificata la domanda. Nello specifico, mantenendo sempre lo stesso intervallo di riferimento cioè dalle ore 6:00 del mattino alle ore 24:00 della sera, abbiamo sfalsato di tre ore l’inizio della domanda di ritorno dal centro storico verso l’esterno rispetto alla domanda di PICAV in ingresso nel centro che inizia come sempre alle ore 6:00. Questa decisione è stata presa in considerazione del fatto che, non avendo quantificato effettivamente la domanda originata dai residenti del centro storico, poteva non essere plausibile l’ipotesi secondo la quale la domanda in ingresso e quella in uscita son o identiche fin dalle prime ore del mattino. Cosi facendo però la simulazione ha fornito dati altamente negativi, soprattutto in termini di tempi di attesa sopportati dagli utenti. Questo a dimostrazione del fatto che il sistema funziona solo davanti ad una situazione di perfetto equilibrio, all’interno di ciascuna epoca considerata, tra la domanda in ingresso e quella in uscita dal centro storico.

(50)

276

Possibili sviluppi futuri

Infine termino il presente studio, concedendomi la licenza di proporre alcuni aspetti che potrebbero essere oggetto si eventuali futuri approfondimenti, sempre nell’ottica di ottimizzare il sistema di trasporto proposto.

Nello specifico studiare come si comporta il sistema di trasporto andando ad analizzare i dati di output, in particolare la distribuzione dei tempi di attesa, che si ottengono:

- Prevedendo scenari diversi da quelli proposti. Tale diversità dovrebbe

esser intesa nel senso, non tanto del numero complessivo dei veicoli della flotta, quanto piuttosto della loro effettiva distribuzione tra i nove ParkingLots (in questa ricerca si è fatto riferimento esclusivamente ad una distribuzione uniforme). Quindi, anche utilizzando un apposito programma di iterazione, andare a cercare di calibrare la distribuzione della flotta dei PICAV, tenendo conto il più possibile delle effettive peculiarità di ciascun ParkingLot. L’obiettivo di una siffatta analisi dovrebbe essere quella di ridurre al contempo il numero dei PICAV della flotta ed i tempi di attesa degli utenti.

- Diminuendo quella percentuale di utenti, classificati come categoria A:

“Multi Missions”, che abbiamo ritenuto essere flessibili. Cioè andando a ridurre il numero degli utenti e quindi dei PICAV che risultano essere sotto il controllo del Supervisore, nel senso che su di essi può intervenire indirizzandoli, in fase di uscita dal centro storico, verso quei ParkingLots, ubicati sul cordone esterno, dove si registrano i più elevati tempi di attesa. Abbiamo visto come questo intervento dell’alto del gestore è sicuramente fondamentale per ridurre gli squilibri che naturalmente altrimenti verrebbero a crearsi. Quindi con una netta diminuzione del numero di utenti flessibili andremmo sicuramente a perdere una quota dei vantaggi di un siffatto sistema di trasporto, tendendo verso i risultati di un sistema di tipo bike – sharing che nell’arco della giornata può

(51)

277

necessitare dell’intervento di un apposito addetto per ripristinare l’equilibrio all’interno della flotta dei veicoli.

- Aumentando il numero dei possibili utilizzatori di PICAV. Ricordando che

l’aumento della domanda