R.3.4 Documento sull’analisi delle sperimentazioni StrumentI e Modelli Per La mobilità sostenibilE

(1)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 1 di 51

Realizzato dall’Università degli Studi di Cagliari

StrumentI e Modelli Per La mobilità sostenibilE

R.3.4 Documento sull’analisi delle sperimentazioni

Progetto finanziato con fondi POR FESR 2014/2020 - ASSE PRIORITARIO I

“RICERCA SCIENTIFICA, SVILUPPO TECNOLOGICO E INNOVAZIONE”.

(2)

I

NFORMAZIONI DEL

P

ROGETTO

Numero del progetto N/A Acronimo SIMPLE

Titolo completo StrumentI e Modelli per La mobilità sostenibilE

Soggetto Progetto CLUSTER ICT

Data di inizio 01/02/2018

Durata in mesi 30

Coordinatore UniCA – Università degli Studi di Cagliari URL del progetto http://www.simple-cluster.it

I

NFORMAZIONI DEL

D

OCUMENTO

Numero del deliverable R.3.4 Titolo Documento sull’analisi delle sperimentazioni Numero del workpackage WP3 Titolo Sperimentazione

Data prevista di terminazione 30/11/2020 Data di sottomissione del

deliverable

30/11/2020

Autore/i responsabile/i Giovanni Tuveri e Marco Garau Livello di diffusione Non applicabile

M

ODIFICHE DEL

D

OCUMENTO

Data Autori Modifiche Versione

14/10/2020 Lucia Pintor Creazione del documento e

scrittura dei primi capitoli v0.0

22/10/2020 Giovanni Tuveri Descrizione test Beep4Me e

analisi risultati v0.1

23/10/2020 Marco Garau Descrizione test Beep4Me,

problematiche riscontrate e soluzioni proposte

v0.2

26/10/2020 Lucia Pintor Analisi dei questionari di PoolBus v0.3

06/11/2020 Lucia Pintor Analisi delle sperimentazioni

virtuali

v0.4

virtuali

v0.5

virtuali

v0.5

(3)

13/11/2020 Lucia Pintor Appendice e ulteriori sviluppi v0.6

16/11/2020 Giovanni Tuveri Revisione v0.7

24/11/2020 Lucia Pintor Aggiornamento tabelle v0.8

(4)

Tavola dei contenuti

Sommario 6

Beep4Me 6

Fasi dei test sul campo 6

Sintesi dei risultati ottenuti 7

PoolBus 9

Fase preliminare: Divulgazione del questionario e raccolta dei dati 10

Divulgazione del questionario 10

Fac-simile del questionario 11

Analisi dei dati del questionario 12

Caratteristiche socioeconomiche (17 individui) 12

Propensione alla sperimentazione del prototipo (17 individui) 13 Caratteristiche spostamenti per lavoro/studio (12 individui) 14

Caratteristiche spostamenti (19 individui) 14

Fase virtuale: Sperimentazione interna del prototipo 16

Parametri di ingresso 16

Simulazione del comportamento degli utenti 17

Generazione di uno scenario giornaliero prelevando campioni di richieste da un dataset 18

Generazione di una richiesta di piano di viaggio 19

Selezione di un itinerario 19

Generazione della richiesta per prenotare l’itinerario selezionato 19 Invio di una richiesta al server per finalizzare i viaggi delle navette 20 Invio di una richiesta per calcolare le statistiche di richieste e prenotazioni 20

Salvataggio dei dati della simulazione 20

Analisi generali delle simulazioni 21

Oggetti generati dalle simulazioni 21

Matrice origine destinazione 22

Fasce orarie 23

Tariffe degli utenti 24

(5)

Ritardi 24

Durate dei percorsi degli utenti 24

Lunghezze dei percorsi degli utenti 25

Passeggeri delle navette 25

Durate dei percorsi delle navette 25

Lunghezze dei percorsi delle navette 26

Tempi di risposta del server per le richieste di piani di viaggio 26 Tempi di risposta del server per le richieste di prenotazione 26 Analisi dettagliata della simulazione con maggiore aggregazione di richieste 26

File requests 27

File plans 27

File reservations 28

File trips 29

File trips_details 30

File od 31

File time_slots 31

File summary 32

Ulteriori sviluppi 33

Conclusioni 34

Appendice 35

Tabelle delle sperimentazioni di PoolBus 35

Tabella “Oggetti generati dalle simulazioni” 35

Tabella “Tariffe degli utenti” 36

Tabella “Ritardi” 37

Tabella “Durate dei percorsi degli utenti” 38

Tabella “Lunghezze dei percorsi degli utenti” 39

Tabella “Passeggeri delle navette” 40

Tabella “Durate dei percorsi delle navette” 41

Tabella “Lunghezze dei percorsi delle navette” 42

Tabella “Tempi di risposta del server per le richieste di piani di viaggio” 44 Tabella “Tempi di risposta del server per le richieste di prenotazione” 46

(6)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 6 di 51 Tabella “Richieste della sperimentazione con 50 richieste concentrate in un giorno” 48

1 Sommario

Questo documento ha l’obiettivo di descrivere le sperimentazioni dei prototipi introdotte nel deliverable R.3.3 Documento di definizione della sperimentazione e testing.

Una sintesi dell’analisi dei risultati presentati in questo documento è invece riportata nel deliverable M.3.1 Analisi dei risultati di test.

I due capitoli successivi di questo documento sono dedicati rispettivamente ai prototipi Beep4Me e PoolBus.

2 Beep4Me

Questo prototipo ha come obiettivo incentivare gli utenti ad utilizzare il trasporto pubblico e supportare in modo semplice la ripartizione degli introiti (clearing) tra le aziende che forniscono i servizi di mobilità. Le sperimentazioni prevedono l’uso delle tecnologie Bluetooth e lo sviluppo di nuove funzionalità all’interno di applicazioni per tablet e smartphone. Il team SIMPLE ha sviluppato dei moduli da integrare ad applicazioni iOS e server Django.

2.1 Fasi dei test sul campo

I test per il prototipo Beep4me hanno seguito lo schema presentato nel deliverable R.3.3 Documento di definizione della sperimentazione e testing (3.1.4 Descrizione dei test cases). La maggior parte dei test sono stati svolti utilizzando due dispositivi (un iPhone 6 e un iPhone XS Max) in modalità mista: sia con i mezzi in esercizio sulle linee (principalmente la linea M), sia con i mezzi in deposito. Questo ha permesso di ottenere più run contemporaneamente e di evidenziare una migliore reattività di rilevazione dei beacon, oltre a una migliore ricezione (maggior copertura) del loro segnale, da parte del dispositivo più recente. Questo è dovuto anche alle diverse tecnologie utilizzate sui due dispositivi, dal momento che l’iPhone 6 è stato rilasciato da circa 6-7 anni, mentre l’iPhone XS Max è stato rilasciato circa 2 anni fa.

Il 17 Giugno 2020 si è svolto il primo sopralluogo per stabilire in quali posizioni installare i beacon all'interno dei bus Citaro e per conoscere il personale del laboratorio di assistenza elettronica CTM che avrebbe supportato il team SIMPLE durante i test. Anche grazie ai loro consigli, si è deciso per l'installazione nel lato interno degli sportelli in materiale plastico per la copertura degli impianti sul soffitto del bus. Sono stati installati 3 beacon per ogni bus, disposti omogeneamente secondo la lunghezza degli stessi. La settimana successiva sono stati installati i beacon sulle prime 5 vetture (vetture numero 343, 342, 410, 330, 401).

Dopo aver terminato tutti i passaggi necessari alla preparazione lato server per i test, i primi giorni di Luglio 2020 sono stati eseguiti dei test sul campo nei bus in esercizio, individuati grazie alle informazioni sulle assegnazioni dei bus alle varie linee. Purtroppo, data la bassa probabilità di incrociare i pochi bus attrezzati con i beacon, sono state ottenute solo poche run dei test programmati, quindi si è deciso di installare i beacon su ulteriori 5 mezzi CTM. Durante queste nuove installazioni sono continuate le prove sui mezzi in linea, consentendo di individuare e risolvere qualche altro bug del sistema.

(7)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 7 di 51 Il 17 Luglio 2020 sono stati installati i beacon sugli altri mezzi (vetture numero 301, 302, 303, 304, 305). Sono stati effettuati dei primi test con mezzo in movimento all’interno del deposito CTM. In questa occasione è stato possibile registrare un numero consistente di run di vari test. Questa prima sessione di test “in deposito” è stata utilissima per evidenziare il comportamento del sistema rispetto alla rilevazione dell’attività di movimento dell’utente, che è uno dei sensing utilizzati sia per il check-in sia per il check-out.

Nei giorni successivi sono stati analizzati i dati registrati nei test e sono state di conseguenza modificate alcune impostazioni di soglie di potenza per la rilevazione dei beacon. Nei giorni successivi sono stati eseguiti altri esperimenti sui mezzi in esercizio, per verificare queste modifiche alle impostazioni.

I giorni 29 e 30 Luglio sono stati effettuati gli ultimi test in deposito. Si è preferito continuare con questa metodologia in quanto risultava un buon compromesso, soprattutto considerando il fatto che l’utilizzo dei mezzi pubblici “di linea” risultava ancora limitato in termini di capacità a causa della pandemia COVID19. Per semplificare e velocizzare i test, in questi giorni sono stati utilizzati dei biglietti “fittizi”, equivalenti a quelli reali corsa semplice (da 90 minuti), se non per la durata che è stata settata a valori inferiori (nel range di 2-5 minuti).

Questo perché gli stessi biglietti non fossero più validi dopo qualche minuto, permettendoci di testare più facilmente le condizioni “più biglietti disponibili, di cui nessuno già validato” e “nessuno biglietto disponibile”

(si veda la descrizione dell’algoritmo di scelta del biglietto in D3.1). L’acquisto dei singoli biglietti è stato simulato abilitando manualmente lato server i biglietti sugli account di test degli utenti che ricevevano la notifica “Non hai biglietti disponibili per la validazione” all’ingresso sul bus.

Durante questi test in deposito (SALITA_3: presenza di più biglietti diversi non validati) è stato verificato il comportamento del sistema nel caso in cui siano presenti due autobus affiancati dotati entrambi di beacon.

Il sistema si è rivelato affidabile in quanto la validazione è avvenuta correttamente solo nel mezzo in cui era salito l’operatore, e non sul mezzo vicino. Non sono state rilevate altre validazioni o trasbordi dovuti ai beacon presenti nel bus affianco.

2.2 Sintesi dei risultati ottenuti

Nella tabella seguente sono sintetizzati i risultati ottenuti durante i test. È possibile notare come gli obiettivi prefissati sono stati raggiunti nella maggior parte dei casi. A livello di app l’utente riceveva correttamente la notifica opportuna nel caso di check-in e nei casi di biglietti multipli e di assenza di biglietti (ma anche nel caso di check-out, per il quale si è deciso di attivare la notifica per i test interni in modo da verificare meglio la prestazione del sistema nella rilevazione della fine della corsa). A livello di server tutti gli eventi di validazione / trasbordo / check-out venivano associati correttamente all’account e al biglietto in uso.

Nella tabella viene riportata una sintesi dei risultati dei test effettuati. Il “Nome del test” codifica la tipologia di test effettuato in accordo con le definizioni date nel report R3.3. Per ogni tipologia si può notare che sono stati eseguiti dei run numerosi, tipicamente 10 o 20. Si può osservare come dopo aver risolto i primi bug individuati ed aver svolto la corretta calibrazione è stato raggiunto un successo del 100%, eccetto nel caso in cui la funzionalità di identificazione dell’activity fosse stato disabilitato come discusso più avanti.

(8)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 8 di 51 Nome test Data N° run Obiettivi Raggiungim.

obiettivi Commenti

SALITA_1 29/07/2020 20

Notifica all’utente

(validazione avvenuta) 100%

Validazione sul server 100%

SALITA_2 29/07/2020 10

(trasbordo avvenuto) 100%

SALITA_3 29/07/2020 20

(scelta tra più biglietti ) 100%

SALITA_4 30/07/2020 20

Notifica utente (nessun

biglietto disponibile) 100%

SALITA_5 29/07/2020 20

DISCESA_1 29/07/2020 30/07/2020 20

(check-out) 100% Diversamente da quanto indicato nel deliverable R.3.3, per verificarne il corretto funzionamento, si è scelto di mostrare una notifica anche nel caso di check-out.

Check-out sul server 100%

DISCESA_2 29/07/2020 20

(check-out) 100% Diversamente da quanto indicato nel deliverable R.3.3, per verificarne il corretto funzionamento, si è scelto di mostrare una notifica anche nel caso di check-out.

Check-out sul server 100%

ATTESA 16/07/2020

29/07/2020 10 Nessuna notifica

all’utente 50%

Gli ultimi test sono stati effettuati senza tenere conto della “activity” e in questo caso il sistema non ha funzionato come

(9)

previsto.

Nessuna validazione

sul server 50%

Gli ultimi test sono stati effettuati senza tenere conto della “activity” e in questo caso il sistema non ha funzionato come previsto.

L’unica problematica è stata rilevata durante i test di “ATTESA” in cui il tester restava alla fermata, molto vicino alla parete del bus, o affacciandosi alla porta dello stesso, ma senza salirci (come farebbe per esempio un utente che chiede informazioni all’autista). Nei primi test non vengono rilevati falsi positivi se l’utente è fermo o cammina vicino al bus. I primi test sono stati effettuati utilizzando sia la stima della prossimità con i beacon sia la rilevazione dell’attività di moto (tramite l’accelerometro, il giroscopio, e vari sensori dello smartphone), che doveva essere categorizzata come “Automotive” per poter richiedere un check-in.

Per gli ultimi test, è stato invece provato il sistema con la rimozione del controllo sulla “activity” (che potrebbe essere considerata “superflua” per tutti gli altri casi, ed era risultata di difficile rilevazione nel caso della determinazione dello stato “Automotive”). Purtroppo in questo modo (senza la verifica dell’activity) in diversi casi avveniva - erroneamente - la validazione del biglietto. E’ risultato quindi fondamentale mantenere questa funzionalità attiva.

Il problema del test ATTESA era legato solamente al fatto di aver disattivato la rilevazione dell’activity (lenta e difficile in alcuni momenti, specie se il mezzo si muove a velocità inferiore a 30 km/h). Si ritiene invece che sia necessaria perché il sistema possa decidere se l’utente è salito o meno sul bus, ed è stata modificata la tecnica di rilevazione della stessa, dando una priorità maggiore alla rilevazione dell’attività “Automotive”.

Questa infatti, dai test effettuati, è risultata essere la più difficile da rilevare (a bassissime velocità del mezzo).

Alcuni test effettuati ad Agosto 2020 dal team SIMPLE, per verificare questa sola modifica, hanno confermato che le ultime impostazioni migliorano la prestazione della rilevazione dell’attività “Automotive”, in particolare la reattività nel passaggio da “Walking” (o “Stationary”) a “Automotive”, che è una delle condizioni necessarie per richiedere un check-in. Questo risolverebbe definitivamente anche il problema rilevato nella gestione del caso di “ATTESA alla fermata” evidenziato dai test in cui non veniva tenuto conto del contributo della “activity”.

3 PoolBus

Questo prototipo consente agli utenti di prenotare dei servizi di trasporto su richiesta, in modo semplice e con costi contenuti. L’obiettivo è sostenere quelle aree della Sardegna in cui il trasporto di linea tradizionale non è sufficiente per soddisfare le necessità della popolazione. Il prototipo è la base per un sistema completo che include diversi tipi di servizi di mobilità integrati: car-sharing, car-pooling, trasporto pubblico e servizi di trasporto a chiamata. Sono stati sviluppati un’applicazione mobile Android e dei moduli server Django.

A seguire, una tabella descrittiva della durata delle macro-fasi della sperimentazione:

Fase della sperimentazione Durata

1. Fase preliminare

- Divulgazione del questionario e raccolta dei dati 3 mesi

2. Fase virtuale 2 settimane

(10)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 10 di 51 - Sperimentazione interna del prototipo

Purtroppo, a causa della pandemia, non è stato possibile portare avanti la fase fisica della sperimentazione, che avrebbe combinato l’uso del prototipo lato server con quello del prototipo di applicazione mobile.

3.1 Fase preliminare: Divulgazione del questionario e raccolta dei dati

La fase preliminare è iniziata con la realizzazione di un questionario da somministrare a dei potenziali tester che abitualmente viaggiano all’interno di aree a domanda debole.

3.1.1 Divulgazione del questionario

Il questionario è stato quindi divulgato tramite email alle unioni dei comuni di “Alta Marmilla” e “Parte Montis” e tramite i social facendo richiesta nelle seguenti pagine:

Link Nome

https://www.facebook.com/groups/141735114624/?ref=br_rs Alta Marmilla (gruppo) https://www.facebook.com/groups/971949262901733/?ref=br_rs Gente di Marmilla (gruppo) https://www.facebook.com/groups/129174959398/?hc_location=group Pau (gruppo)

https://www.facebook.com/groups/133212118185/?hc_location=group Ales (gruppo)

https://www.facebook.com/groups/1400304453558918/?ref=br_rs Ales (gruppo) https://www.facebook.com/groups/588871451193531/?ref=br_rs Baressa (gruppo) https://www.facebook.com/groups/182637741947145/?ref=br_rs Albagiara (gruppo) https://www.facebook.com/groups/52548309920/?ref=br_rs Asuni (gruppo) https://www.facebook.com/groups/592845337451793/ Curcuris (gruppo) https://www.facebook.com/Gonnoscodina-45591656940/ Gonnoscodina (pagina) https://www.facebook.com/groups/233976896773912/ Gonnoscodina (gruppo) https://www.facebook.com/comune.gonnosno/?ref=br_rs Gonnosnò (pagina comunale) https://www.facebook.com/groups/47646943006/ Mogorella (gruppo)

https://www.facebook.com/groups/672245492879798/ Morgongiori (gruppo) https://www.facebook.com/groups/720953231262081/ Nureci (gruppo) https://www.facebook.com/groups/1605358539697054/ Ruinas (gruppo) https://www.facebook.com/groups/53870698710/?ref=br_rs Usellus (gruppo)

(11)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 11 di 51 https://www.facebook.com/groups/466383846796167/?ref=br_rs Gonnostramatza (gruppo) https://www.facebook.com/groups/131001606956563/?ref=br_rs Masullas (gruppo)

https://www.facebook.com/groups/422210291243327/ Mogoro (gruppo) https://www.facebook.com/groups/1735655233328056/ Pompu (gruppo) https://www.facebook.com/groups/1524787924412039/ Simala (gruppo)

Il testo utilizzato per promuovere il questionario sui social è stato:

Ciao

Sono _____ e faccio parte del team del Progetto Simple, un progetto portato avanti dall'Università di Cagliari verso le imprese e le persone interessate al tema della mobilità

sostenibile. Il tema è molto attuale soprattutto in questo periodo difficile in cui dobbiamo rivedere il nostro modo di spostarci.

Vi chiediamo una mano e due secondi del vostro tempo per compilare un breve questionario sulle vostre abitudini di viaggio per cercare di studiare e pianificare un servizio di trasporto a chiamata nella vostra zona.

Questo il link al questionario https://metrostyles.wufoo.com/forms/q154dj7p0k0mj9n/

Vi ringrazio tanto e se avete necessità scrivetemi pure.

Buona giornata

Il questionario è stato disponibile per 3 mesi dopo la pubblicazione del link.

3.1.2 Fac-simile del questionario

Domanda

1.0 Fornisco il mio indirizzo e-mail e presto il mio consenso ad essere ricontattato per le prossime iniziative previste dal progetto e in particolare:

i) coinvolgimento per la fase di sperimentazione del prototipo ii) comunicazione dei risultati dell’indagine

1.1 Indichi il proprio comune di RESIDENZA

1.2 Indichi il comune della destinazione più frequente per gli spostamenti per: SHOPPING 1.3 Che modalità di trasporto utilizza più frequentemente per gli spostamenti per SHOPPING?

1.4 Indichi quante volte alla SETTIMANA effettua spostamenti per motivo: SHOPPING 1.5 Indichi la fascia oraria più ricorrente per gli spostamenti per motivo: SHOPPING

1.6 Indichi il comune della destinazione più frequente per gli spostamenti per: VISITE MEDICHE 1.7 Che modalità di trasporto utilizza più frequentemente per gli spostamenti per VISITE MEDICHE?

1.8 Indichi quante volte al MESE effettua spostamenti per motivo: VISITE MEDICHE 1.9 Indichi la fascia oraria più ricorrente per gli spostamenti per motivo: VISITE MEDICHE

(12)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 12 di 51 1.10 Indichi il comune della destinazione più frequente per gli spostamenti per: SERVIZI POSTA/BANCA 1.10 Che modalità di trasporto utilizza più frequentemente per gli spostamenti per SERVIZI POSTA/BANCA?

1.11 Indichi quante volte alla SETTIMANA effettua spostamenti per motivo: SERVIZI POSTA/BANCA 1.12 Indichi la fascia oraria più ricorrente per gli spostamenti per motivo: SERVIZI POSTA/BANCA 1.13 Indichi il comune della destinazione più frequente per gli spostamenti per: ATTIVITÀ RICREATIVE 1.14 Che modalità di trasporto utilizza più frequentemente per gli spostamenti per ATTIVITÀ' RICREATIVE?

1.15 Indichi quante volte alla SETTIMANA effettua spostamenti per motivo: ATTIVITÀ RICREATIVE 1.16 Indichi la fascia oraria più ricorrente per gli spostamenti per motivo: ATTIVITÀ RICREATIVE 2.1 Quale tra queste opzioni corrisponde meglio alla sua occupazione?

2.2 Indichi il COMUNE del proprio posto di lavoro/studio

2.3 Indichi in quale fascia oraria inizia lo spostamento per motivo lavoro/studio 2.4 Che modalità di trasporto utilizza abitualmente per recarsi a lavoro/studio?

3.3 Sarebbe disposto a partecipare alla sperimentazione per testare il sistema progettato?

4.1 Indichi la sua fascia d’età 4.2 Indichi il suo genere

4.3 Indichi la composizione del suo nucleo familiare 4.4 Quanti figli vivono nel suo nucleo familiare?

4.5 Ha la patente?

4.6 In totale, di quante auto disponete in famiglia?

4.7 Utilizza abitualmente il trasporto pubblico?

4.8 Indichi il sistema operativo del suo smartphone

3.1.3 Analisi dei dati del questionario

I questionari compilati tra maggio e agosto sono 22, e tra questi solo alcuni sono rilevanti per l’indagine. Di seguito sono riportate le statistiche dei dati raccolti.

Caratteristiche socioeconomiche (17 individui)

Genere Uomo 41%

Donna 59%

Età 18 - 29 anni 18%

30 - 39 anni 29%

40 - 49 anni 35%

60+ anni 18%

Occupazione Lavoratore dipendente 47%

Lavoratore autonomo 18%

Studente 6%

(13)

Pensionato 6%

Casalinga/o 12%

Disoccupato 12%

Membri del nucleo familiare 1 6%

2 29%

3 18%

4+ 47%

Figli nel nucleo familiare 0 65%

1 12%

2 24%

Possesso patente - 100%

Auto in famiglia 1 35%

2 47%

3 18%

Propensione alla sperimentazione del prototipo (17 individui)

Utilizza abitualmente il trasporto pubblico?

Si 12%

No 88%

Sarebbe disposto a partecipare alla sperimentazione?

Si 65%

No 35%

Le piacerebbe usufruire di un servizio

di trasporto a chiamata per …? Lavoro Shopping Visite mediche

Posta / banca

Attività ricreative

Assolutamente no 18% 6% 6% 24% 18%

Improbabile 24% 29% 6% 29% 18%

Forse 24% 24% 18% 6% 12%

Probabile 18% 18% 24% 24% 18%

Assolutamente sì 18% 24% 47% 18% 35%

(14)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 14 di 51 Quanto sarebbe disposto a pagare

per uno spostamento di …?

Meno di 10 km

10 – 20 km

20 – 30 km

Più di 30 km

1 - 2 € 82% 35% 18% 12%

2 - 4 € 18% 47% 29% 18%

4 - 6 € 0% 18% 41% 18%

6 - 8 € 0% 0% 12% 29%

Più di 8 € 0% 0% 0% 24%

Caratteristiche spostamenti per lavoro/studio (12 individui)

Comune

Destinazione Nr (%) Mezzo utilizzato Nr (%) Fascia oraria

partenza Nr (%) Oristano 3 (25%) Auto conducente 8 (67%) Prima delle 7:30 3 (25%) Ales 2 (17%) Auto passeggero 1 (8%) 7:30 - 8:30 6 (50%)

Mogoro 2 (17%) Treno 1 (8%) 08:30 – 09:30 2 (17%)

Cagliari 1 (8%) Piedi 2 (17%) Dopo le 19:30 1 (8%)

Gonnosnò 1 (8%)

Mogorella 1 (8%)

Nuoro 1 (8%)

Pau 1 (8%)

Caratteristiche spostamenti (19 individui)

Comune di residenza Nr (%)

Pompu 3 (18%)

Masullas 2 (12%)

Mogorella 2 (12%)

Villa Sant'Antonio 2 (12%)

Ales 1 (6%)

Baradili 1 (6%)

Gonnosnò 1 (6%)

Lunamatrona 1 (6%)

Mogoro 1 (6%)

Pau 1 (6%)

Usellus 1 (6%)

Shopping / Spese Comune

Destinazione Mezzo utilizzato Fascia oraria partenza **

Frequenza settimanale

(15)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 15 di 51 Oristano 33% Auto conducente 79% 08:00 - 10:00 37% 1 58%

Ales 19% Auto passeggero 16% 10:00 - 13:00 53% 2 21%

Cagliari 14% Autobus 5% 13:00 - 15:00 16% 3 11%

Mogoro 14% 15:00 - 18:00 37% 4+ 11%

Sanluri 5% 18:00 - 20:00 21%

Simaxis 5%

** era possibile dare risposte multiple

Visite mediche Comune

Ales 47% Auto conducente 84% 08:00 - 10:00 58% 1 68%

Oristano 32% Auto passeggero 16% 10:00 - 13:00 63% 2 11%

Cagliari 16% 13:00 - 15:00 11% n.d. 21%

Sanluri 5% 15:00 - 18:00 21%

18:00 - 20:00 5%

Servizi posta / banca Comune

Ales 26% Auto conducente 84% 08:00 - 10:00 32% 1 53%

Mogoro 21% Auto passeggero 5% 10:00 - 13:00 68% 2 11%

Usellus 21% Piedi 11% 13:00 - 15:00 11% 3 11%

Masullas 11% 15:00 - 18:00 21% n.d. 26%

Baressa 5% 18:00 - 20:00 5%

Lunamatrona 5%

Oristano 5%

Ruinas 5%

** era possibile dare risposte multiple Attività ricreative

Comune

Cagliari 21% Auto conducente 74% 08:00 - 10:00 11% 1 37%

Mogoro 21% Auto passeggero 16% 10:00 - 13:00 32% 2 32%

(16)

Oristano 21% Piedi 11% 13:00 - 15:00 16% 4+ 16%

Ales 16% 15:00 - 18:00 42% n.d. 16%

Baradili 5% 18:00 - 20:00 58%

Mogorella 5%

Pompu 5%

Usellus 5%

3.2 Fase virtuale: Sperimentazione interna del prototipo

In questa fase è stato utilizzato il prototipo lato server descritto nel deliverable R.3.2.2 Codice sorgente Dimostratore 2 (server PoolBus), che si è interfacciato con programma Python che simula il comportamento degli utenti.

3.2.1 Parametri di ingresso

Nella simulazione sono stati impostati i parametri di ingresso illustrati in tabella.

Parametro di ingresso Descrizione

Carico del sistema: In ciascuna simulazione sono state effettuate 50 richieste distribuite in 3 giorni.

Velocità del bus in movimento È stata ipotizzata una velocità media di 30 km/h.

Finestre temporali per le navette Un utente che vuole prenotare una navetta accetta un ritardo o anticipo di massimo mezz’ora.

Numero di veicoli Sono stati utilizzati 14 veicoli di varia capienza (4, 5 o 9 posti).

Costo del servizio È stato ipotizzato un costo di 1.5 €/km per la prenotazione dell’intero veicolo¹.

È stato previsto un contributo regionale del 35 %².

Ripartizione dei costi tra gli utenti Il costo di ciascuna tratta (percorso della navetta tra una fermata e la successiva) è distribuito equamente tra i passeggeri.

La tariffa di un passeggero è data dalla somma delle tariffe delle tratte del suo viaggio.

1 Tariffa comunemente applicata per il Noleggio Con Conducente

2 Contributo regionale previsto per il Trasporto Pubblico (Decreto Legislativo 19 novembre 1997, n. 422)

(17)

3.2.2 Simulazione del comportamento degli utenti

I dati raccolti tramite i questionari non sono stati sufficienti per degli scenari che potessero generare delle simulazioni con risultati di accuratezza sufficienti. Per tale ragione è stato necessario generare ulteriori campioni sintetici sulla base dei dati collezionati.

Il programma che simula le richieste degli utenti esegue i seguenti step:

1. Genera uno scenario giornaliero prelevando campioni di richieste dal dataset 2. Per ciascuna richiesta dello scenario:

a. Genera la rispettiva richiesta di piano di viaggio

b. Ricevuto il piano di viaggio, lo analizza e seleziona uno degli itinerari c. Genera poi la richiesta per prenotare l’itinerario selezionato

3. Invia una richiesta al server per finalizzare i viaggi delle navette

4. Invia una richiesta per calcolare le statistiche di richieste e prenotazioni 5. Salva in file i dati della simulazione

In particolare nel punto 2 viene replicato il comportamento di un utente che utilizza l’app mobile: per generare la richiesta di viaggio viene utilizzata la schermata “Selezione OD” e per prenotare quella “Dettaglio itinerario”.

(18)

Selezione OD Dettaglio itinerario

Step 1: Generazione di uno scenario giornaliero prelevando campioni di richieste da un dataset

Il dataset per creare lo scenario giornaliero è suddiviso in quattro sezioni di spostamenti per i differenti 4 motivi di viaggio: Shopping (S), Visite mediche (V), Posta/Banca (P) e Attività ricreative (A).

Per ogni motivo di viaggio, sono stati ricostruiti 10 scenari di riferimento (es. Shopping: S1, S2, S3, …), ottenuti valutando tutte le combinazioni Origine/Destinazione/fascia oraria possibili e assegnando loro una probabilità. Le probabilità di ciascuna combinazione ha peso maggiore tanto più le motivazioni considerate sono frequenti nei questionari somministrati.

Di seguito è mostrato un esempio di tabella del dataset:

origin name

destination name

origin destination time date passenger Number Villa

Sant'Antonio

Ales 39.858197, 8.901308

39.768916, 8.813526

13:00 15:00

01/07/2020 1

(19)

Morgongiori Ales 39.746878,

8.771539

39.768916, 8.813526

15:00 18:00

01/07/2020 1

Ales Mogoro 39.768916,

8.813526

39.683361, 8.777858

10:00 13:00

01/07/2020 1

Ales Mogoro 39.768916,

8.813526

39.683361, 8.777858

8:00 10:00

01/07/2020 1

Gli scenari indipendenti per i differenti motivi di viaggio, vengono combinati tra loro dall’algoritmo per ottenere uno scenario giornaliero: ciascuno scenario giornaliero contiene uno scenario di riferimento (scelto randomicamente) per lo shopping, uno per le visite mediche, uno per andare in banca o alle poste e uno per attività ricreative (es. Scenario giornaliero = S3 + V1 + P7 + A2).

Gli spostamenti per scuola e lavoro sono stati esclusi perché dai dati dei questionari risulta che questi sono richiesti principalmente prima delle 8.30 e dopo le 19.30, quindi si tratta di fasce orarie già abbondantemente servite dai mezzi pubblici e per questo non contemplate nelle prime sperimentazioni.

Step 2a: Generazione di una richiesta di piano di viaggio

Ciascuna riga dello scenario giornaliero generato viene convertita in richiesta per il server, ad esempio:

host:8080/otp?origin=39.683214,8.7756495&destination=39.7001853,8.8354817&time=11:10&date=29- 09-2020&passengerNumber=1&format=json

Nella richiesta sono quindi riportati i campi della tabella: origin (parametro origin della query), destination (parametro destination della query), time (parametro time della query), date (parametro date della query) e passengerNumber (parametro passengerNumber della query).

Il parametro time, che nella tabella del dataset è un intervallo temporale, viene convertito in un orario selezionando un minuto all’interno dell’intervallo in modo randomico (ciascun minuto ha probabilità uniforme di essere scelto).

Step 2b: Selezione di un itinerario

Quando l’algoritmo riceve la risposta del server la analizza e seleziona un itinerario del piano di viaggio proposto che contenga un servizio di navetta.

Per la selezione dell’itinerario migliore viene utilizzata una funzione che assegna un punteggio a ciascun itinerario e questo punteggio è una combinazione lineare di tariffa, durata dell’itinerario e differenza tra orario richiesto e orario proposto. L’itinerario con punteggio maggiore sarà quello selezionato.

Step 2c: Generazione della richiesta per prenotare l’itinerario selezionato

Una volta selezionato l’itinerario, l’algoritmo si occupa di prenotarlo. Ciò avviene interagendo con un’apposita API del server, con cui viene segnalato l’identificativo del piano di viaggio e quello dell’itinerario scelto, ad esempio:

(20)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 20 di 51 host:8080/select-itinerary?planId=693&itineraryId=1

Step 3: Invio di una richiesta al server per finalizzare i viaggi delle navette

I viaggi e le prenotazioni sono aggiornati dopo essere finalizzati, per cui, per avere statistiche non sfalsate, è bene prima finalizzare tutti i viaggi. Con la finalizzazione di un viaggio viene bloccato l’inserimento di nuovi utenti e vengono calcolati orari di passaggio e tariffe definitive.

Step 4: Invio di una richiesta per calcolare le statistiche di richieste e prenotazioni

A questo punto vengono richieste le seguenti informazioni al server: le liste di veicoli e fermate usati e le liste di piani, viaggi e prenotazioni generate.

Ricevuti questi dati, l’algoritmo li rielabora e genera delle statistiche della simulazione.

Step 5: Salvataggio dei dati della simulazione

Le statistiche vengono infine salvate in dei file csv. La tabella riporta i nomi dei file e il loro contenuto.

Nome Contenuto

csv_request In ciascuna riga sono riportate le informazioni di una richiesta per un piano di viaggio: nome e coordinate dell’origine dello spostamento, nome e coordinate della destinazione dello spostamento, orario e giorno desiderati, numero di passeggeri, is successfully booked (valore booleano che indica se la

prenotazione ha avuto successo), id del piano e delle prenotazioni, errori, tempo di risposta per la query di richiesta del piano (qi_time) e per quella di prenotazione (qb_time).

csv_plan In ciascuna riga sono riportate le informazioni di un piano di viaggio: id del piano, orario e giorno della richiesta, arrive by (valore booleano per indicare se l’orario della richiesta si riferisce alla partenza o all’arrivo), numero di

passeggeri, id dell’itinerario scelto del piano, orario di partenza e di arrivo, durata e distanza del percorso, nome e coordinate della fermata di origine dello spostamento e nome e coordinate della fermata di destinazione dello

spostamento.

csv_trips In ciascuna riga sono riportate le informazioni di un viaggio: id del viaggio, durata in minuti, distanza percorsa in metri, orario e giorno di inizio del servizio, orario e giorno di fine del servizio, numero massimo di passeggeri a bordo contemporaneamente, numero totale di passeggeri.

csv_trips_detail In ciascuna riga sono riportate le informazioni di un segmento di viaggio (tratta tra una fermata e la successiva): id del viaggio, id del segmento di viaggio, id e nome della fermata di partenza del segmento, giorno del viaggio, orario di arrivo e di partenza dalla fermata, numero di passeggeri a bordo prima della fermata, numero di passeggeri in ingresso e in uscita alla fermata, capacità del veicolo, occupazione del veicolo (includendo l’autista), durata e distanza del percorso dalla fermata precedente.

(21)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 21 di 51 csv_reservations In ciascuna riga sono riportate le informazioni di una prenotazione: id della

prenotazione, id del piano di viaggio, id del viaggio, tariffa, numero di

passeggeri, durata e distanza del percorso prenotato, id e nome della fermata di partenza, id e nome della fermata di arrivo, orario e giorno della partenza, orario e giorno dell’arrivo, orario di riferimento della richiesta, arrive by (valore booleano per indicare se l’orario della richiesta si riferisce alla partenza o all’arrivo) e ritardo del viaggio rispetto all’orario richiesto

csv_timeslots Ciascuna riga si riferisce ad una fascia oraria di due ore: sono quindi contate le occorrenze degli spostamenti che sono richiesti per ciascuna fascia e le occorrenze delle prenotazioni con orario di partenza confermato in ciascuna fascia.

csv_od In questo file è riportata la matrice di origine destinazione: ciascuna riga si riferisce ad un’origine e ciascuna colonna ad una destinazione.

csv_summary In questo file sono riportate alcune statistiche: valore minimo e massimo, media, deviazione standard e confidence interval. Per ciascuna statistica è indicato il nome del file csv da cui è estratta e il rispettivo campo. I campi considerati sono: tariffa, durata in minuti (utente), ritardo in minuti (utente), distanza in km (utente), durata in minuti (navetta), distanza in km (navetta), totale passeggeri, tempo di risposta per la query di richiesta del piano in secondi, tempo di risposta per la query di prenotazione in secondi.

3.2.3 Analisi generali delle simulazioni

Vengono riepilogate infine alcune statistiche che tengono conto di tutte le singole istanze di ciascuna simulazione, con un totale di 1000 richieste, 1000 piani di viaggio, 1000 prenotazioni e 579 viaggi.

Oggetti generati dalle simulazioni

Sono state effettuate 20 simulazioni con 50 richieste ciascuna distribuite in 3 giorni lavorativi, con un totale di 1000 piani di viaggio, 1000 prenotazioni e 597 viaggi.

Analizzando la tabella dell’appendice ‘Oggetti generati dalle simulazioni’ si può quindi notare che ciascuna richiesta è stata soddisfatta: l’utente (simulato) ha ottenuto un piano di viaggio e ha potuto prenotare un servizio di navetta.

Il rapporto tra il numero di viaggi e il numero di prenotazioni è sempre minore di 1, per cui in ciascuna simulazione sono state aggregate delle richieste e più utenti viaggiano nella stessa navetta in alcuni viaggi.

La simulazione in cui si è verificata la maggiore aggregazione è la simulazione numero 20 (23 viaggi di navette a fronte di 50 prenotazioni di utenti), invece la simulazione con minore aggregazione è stata la prima (37 viaggi di navette a fronte di 50 prenotazioni di utenti).

(22)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 22 di 51 Matrice origine destinazione

La matrice origine destinazione sottostante presenta il numero di occorrenze di ciascuna coppia origine destinazione nelle 20 simulazioni. Sono evidenziati in giallo i casi in cui si verificano meno di 10 occorrenze e in verde quelli in cui si verificano più di 10 occorrenze. La coppia origine destinazione più frequente è quella con origine Ales e destinazione Oristano (79 occorrenze), seguita da quella con origine Ruinas e destinazione Ales (58 occorrenze). In tutti gli altri casi il numero di occorrenze è minore o uguale a 40.

Nella matrice è evidente che l’origine più richiesta è Ales (con un totale di 152 richieste con origine in questo comune) e le destinazioni più richieste sono Oristano (387), Ales (280) e Mogoro (202).

Per maggiore chiarezza sotto è riportata la stessa matrice origine destinazione ripulita dalle righe e colonne completamente nulle.

(23)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 23 di 51 Fasce orarie

L’istogramma sottostante presenta la distribuzione degli orari delle richieste e delle partenze confermate degli utenti. Sono stati considerati tutti i piani di viaggio delle 20 simulazioni (per individuare la fascia oraria richiesta) e tutte le prenotazioni delle 20 simulazioni (per individuare la fascia oraria confermata).

Si può notare che la fascia oraria più richiesta e confermata è quella tra le 7:30 e le 8:30.

(24)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 24 di 51 Tariffe degli utenti

Nella tabella dell’appendice ‘Tariffe degli utenti’ sono indicate le statistiche delle 20 simulazioni riguardo le tariffe degli utenti. Tutte le tariffe sono espresse in euro. Di seguito un breve riepilogo.

Valore Minimo Massimo Media

Tariffa 0.40 € 34.41 € 11.03 €

Tariffa al km 0.09 €/km 0.53 €/km 0.37 €/km

Ritardi

Nella tabella dell’appendice ‘Ritardi’ sono indicate le statistiche delle 20 simulazioni riguardo i ritardi, intesi come differenza tra l’orario di partenza richiesto dall’utente in fase di prenotazione e l’orario confermato dall’azienda. Tutte le durate sono espresse in minuti. Di seguito un breve riepilogo.

Orario confermato in ritardo rispetto a quello richiesto

1 minuto 30 minuti 16 minuti

Orario confermato in ritardo rispetto a quello richiesto

1 minuto 60 minuti 22 minuti e mezzo

Durate dei percorsi degli utenti

Nella tabella dell’appendice ‘Durate dei percorsi degli utenti’ sono indicate le statistiche delle 20 simulazioni riguardo le durate dei percorsi degli utenti. Tutte le durate sono espresse in minuti. Di seguito un breve riepilogo.

(25)

Durata del percorso dell’utente

7 minuti 2 ore e 2 minuti 52 minuti

Tempo impiegato a percorrere 1 km

52 secondi 19 minuti 2 minuti e mezzo

Lunghezze dei percorsi degli utenti

Nella tabella dell’appendice ‘Lunghezze dei percorsi degli utenti’ sono indicate le statistiche delle 20 simulazioni riguardo le lunghezze dei percorsi degli utenti. Tutte le distanze sono espresse in km. Di seguito un breve riepilogo.

Lunghezza del percorso dell’utente

3.29 km 82.74 km 30.36 km

Passeggeri delle navette

Nella tabella dell’appendice ‘Passeggeri delle navette’ sono indicate le statistiche delle 20 simulazioni riguardo il numero dei passeggeri sulle navette. Di seguito un breve riepilogo.

Numero di passeggeri di una navetta

1 8 1.68

Un valore medio di passeggeri inferiore a 2 potrebbe essere dovuto alla dispersione delle richieste (50 richieste distribuite in diverse fasce orarie di 3 giorni) e delle coppie origine destinazione (non sempre compatibili con l’inserimento di nuovi utenti ad un viaggio pre-esistente). Comunque questo risultato è accettabile e prevedibile, considerando che lo studio è concentrato su aree a domanda debole, per le quali raramente sarà possibile ottenere alti coefficienti di occupazione dei veicoli.

Durate dei percorsi delle navette

Nella tabella dell’appendice ‘Durate dei percorsi delle navette’ sono indicate le statistiche delle 20 simulazioni riguardo le durate dei percorsi delle navette. Tutte le durate sono espresse in minuti. Di seguito un breve riepilogo.

Durata del percorso della navetta

10 minuti 3 ore e 36 minuti 54 minuti

(26)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 26 di 51 Tempo impiegato a

percorrere 1 km

42 secondi 12 minuti 2 minuti

Lunghezze dei percorsi delle navette

Nella tabella dell’appendice ‘Lunghezze dei percorsi delle navette’ sono indicate le statistiche delle 20 simulazioni riguardo le lunghezze dei percorsi delle navette. Tutte le distanze sono espresse in km. Di seguito un breve riepilogo.

Lunghezza del percorso della navetta

3.29 km 181.22 km 37.31 minuti

Tempi di risposta del server per le richieste di piani di viaggio

Nella tabella dell’appendice ‘Tempi di risposta del server per le richieste di piani di viaggio’ sono indicate le statistiche delle 20 simulazioni riguardo i tempi di risposta del server per le richieste di piani di viaggio. Tutti i tempi sono espressi in secondi. Di seguito un breve riepilogo.

Tempi di risposta del server per le richieste di piani di viaggio

0.09 secondi 0.54 secondi 0.11 secondi

Tempi di risposta del server per le richieste di prenotazione

Nella tabella dell’appendice ‘Tempi di risposta del server per le richieste di prenotazione’ sono indicate le statistiche delle 20 simulazioni riguardo i tempi di risposta del server per le richieste di prenotazione di un itinerario di un piano di viaggio. Tutti i tempi sono espressi in secondi. Di seguito un breve riepilogo.

Tempi di risposta del server per le richieste di prenotazione

2.77 secondi > 7 minuti e mezzo 4.84 secondi

Il massimo tempo di richiesta riscontrato è superiore a 7 minuti (ma si tratta di un caso isolato, tutti gli altri sono inferiori a 2 minuti e mezzo).

3.2.4 Analisi dettagliata della simulazione con maggiore aggregazione di richieste

Di seguito è riportato un approfondimento della simulazione 20, la simulazione in cui si è verificata una maggiore aggregazione di passeggeri nei viaggi.

(27)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 27 di 51 Le righe mostrate nelle tabelle sono state selezionate in modo da approfondire il viaggio numero 9731, in cui sono aggregate 5 prenotazioni.

I file di output analizzati sono i seguenti:

- FIle requests - File plans - File reservations - File trips

- File trips_details

- File od (matrice origine destinazione)

- File time_slots (istogramma degli orari di partenza) - File summary

File requests

Ciascuna simulazione è iniziata con la generazione delle richieste.

La tabella sottostante riporta un estratto del file csv_requests della 20ma simulazione. Sono state omesse le colonne con le coordinate delle fermate, il numero di passeggeri (sempre pari a 1), is successfully booked (valore booleano che indica se la prenotazione ha avuto successo), l’id della prenotazione (che è recuperabile dalle tabelle successive) e gli errori (sempre nulli).

origine destinazione orario data id piano di viaggio

tempo di risposta per la query di richiesta del piano

tempo di risposta per la query di prenotazione

Assolo Oristano 14:56 24/11 10300 0.115141 2.93385

Assolo Oristano 14:52 24/11 10289 0.117641 2.856605

Gonnosnò Oristano 14:35 24/11 10282 0.108387 2.834179

Si può notare come l’ultima richiesta richieda diversi minuti per essere prenotata correttamente: purtroppo ciò è dovuto al fatto che vengono valutate tutte le combinazioni di viaggi pre-esistenti compatibili con la richiesta prima di scegliere la migliore.

File plans

Ciascuna richiesta genera un piano di viaggio.

(28)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 28 di 51 La tabella riporta un estratto del file csv_plans della 20ma simulazione. Sono state omesse le colonne con le coordinate delle fermate, il numero di passeggeri (sempre pari a 1), arrive by (valore booleano in questo caso sempre False, per indicare che l’orario richiesto si riferisce alla partenza) e l’id dell’itinerario selezionato del piano di viaggio (in questo caso sempre pari a 0).

Da notare che nel piano di viaggio la durata e la distanza del percorso sono quelle minime, ovvero, nel caso in cui nessun altro utente si unisca al viaggio, il percorso diretto tra origine e destinazione ha quella durata e

della lunghezza.

SI è scelto questo estratto per mostrare quattro piani compatibili e aggregabili in uno stesso viaggio.

id ora

richiesta

giorno richiesto

partenza arrivo durata minima in minuti

distanza minima in metri

origine destinazione

10300 14:56 24/11 14:56 15:55 59 57090 Assolo Oristano

10289 14:52 24/11 14:52 15:51 59 57090 Assolo Oristano

10282 14:35 24/11 14:35 15:29 54 51620 Gonnosnò Oristano

Le richieste mostrate in tabella riguardano viaggi che partono lo stesso giorno in orari vicini tra loro e che hanno la stessa destinazione. Continuando l’analisi si potrà notare che l’algoritmo di aggregazione unisce correttamente le richieste in un unico viaggio di navetta.

File reservations

Quando l'utente seleziona un itinerario del piano di viaggio, viene effettuata una richiesta di prenotazione.

La tabella riporta un estratto del file csv_reservations della 20ma simulazione, focalizzandosi sulle prenotazioni corrispondenti ai piani di viaggio mostrati nel precedente paragrafo. Sono state omesse le colonne con gli id delle fermate, il numero di passeggeri (sempre pari a 1), arrive by (valore booleano in questo caso sempre False, per indicare che l’orario richiesto si riferisce alla partenza) e il giorno di arrivo (uguale a quello della partenza).

La tabella è stata divisa in due parti per una maggiore facilità di lettura.

id prenotazione id piano id viaggio tariffa in euro durata in minuti distanza in km

(29)

10775 10300 9731 5.99 59 57.090

10764 10289 9731 5.99455 59 57.090

10757 10282 9731 7.90 95 67.957

10770 10295 9731 7.896195 95 67.957

10796 10321 9731 7.896195 95 67.957

Di seguito è riportata la seconda metà della tabella.

Per quanto riguarda i ritardi, si può notare che in tutti i piani è stato impostato arrive_by = False, per cui l’orario si riferisce alla partenza.

id

prenotazio ne

origine ora di partenza

giorno di partenza

destinazione ora di arrivo

ora richiesta (partenza)

ritardo in minuti

10775 Assolo 15:07 24/11/2020 Oristano 16:06 14:56 11

10764 Assolo 15:07 24/11/2020 Oristano 16:06 14:52 15

10757 Gonnosnò 14:31 24/11/2020 Oristano 16:06 14:35 -4

10770 Gonnosnò 14:31 24/11/2020 Oristano 16:06 14:50 -19

10796 Gonnosnò 14:31 24/11/2020 Oristano 16:06 14:31 0

File trips

Un viaggio viene generato quando c’è almeno un utente che vuole un servizio di navetta.

La tabella riporta un estratto del file csv_trips della 20ma simulazione. Si può notare che ci sono diversi viaggi con 3 o 4 passeggeri nella stessa navetta e uno con 5 passeggeri.

Ad esempio nel viaggio 9731 ci sono 5 passeggeri: andando a verificare nel file reservations infatti si trovano le prenotazioni numero 10775, 10764, 10757, 10770 e 10796.

id viaggio

durata in minuti

distanza in metri

ora inizio servizio

giorno inizio servizio

ora fine servizio

max passeggeri contemporanei

totale passeggeri

(30)

9731 76 67957 14:50 24/11/2020 16:06 5 5

9732 66 63706 09:37 23/11/2020 10:43 1 1

9726 136 87929 12:26 24/11/2020 14:42 2 4

File trips_details

Questo file contiene una visione più dettagliata dei viaggi: infatti sono analizzati i segmenti di percorso tra una fermata e la successiva.

Anche in questo caso l’estratto del file è diviso in due tabelle per agevolarne la lettura.

id viaggio

id

segmento

nome fermata giorno del viaggio

partenza passeggeri a bordo

passeggeri in ingresso

passeggeri in uscita

9731 0 Gonnosnò 24/11/2020 14:50 0 3 0

9731 1 Assolo 24/11/2020 15:07 3 2 0

9731 2 Oristano 24/11/2020 16:06 5 0 5

Di seguito la seconda parte della tabella.

Da notare che l’occupazione è data dal rapporto tra il numero di persone a bordo (passeggeri + autista) diviso la capacità del veicolo. I veicoli usati nella simulazione hanno 4 o 5 o 9 posti.

id viaggio

id

segmento

passeggeri a bordo

capacità del veicolo

occupazione minuti dalla fermata precedente

km dalla fermata precedente

9731 0 0 9 0.11 0 0

9731 1 3 9 0.44 17 10.866

9731 2 5 9 0.67 59 57.090

Il veicolo parte da Gonnosnò alle 14:50 con a bordo i primi tre passeggeri (prenotazioni 10757, 10770 e 10796), poi arriva ad Assolo e fa salire gli altri due passeggeri (prenotazioni 10775, 10764). Riparte alle 15:17 e giunge alla destinazione Oristano alle 16:06.

(31)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 31 di 51 File od

Questo file contiene la matrice delle occorrenze delle coppie origine destinazione.

File time_slots

Questo file contiene la matrice delle occorrenze delle fasce orarie richieste (quando viene generato il piano di viaggio) e confermate (quando viene confermato il viaggio delle navette).

fascia oraria richieste prenotazioni

06:30 - 07:29 7 9

07:30 - 08:29 9 7

08:30 - 09:29 4 3

09:30 - 10:29 0 1

(32)

10:30 - 11:29 4 4

11:30 - 12:29 6 6

12:30 - 13:29 4 5

13:30 - 14:29 10 9

14:30 - 15:29 3 3

15:30 - 16:29 1 1

16:30 - 17:29 2 2

File summary

Questo file contiene un riepilogo delle statistiche più importanti della simulazione. Sono riportati i valori minimi, massimi, medi, deviazione standard e gli estremi inferiore e superiore del confidence interval 95.

campo min max media std

tariffa 0.86 33.45 11.04 8.25

durata in minuti (utente) 11.00 122.00 57.44 26.26

ritardo in minuti (utente) -48.00 27.00 -1.60 16.12

distanza in km (utente) 3.29 67.96 35.87 22.10

durata in minuti (navetta) 11.00 164.00 63.48 41.87

distanza in km (navetta) 14.34 129.34 50.34 32.06

totale passeggeri 1.00 5.00 2.17 1.34

tempo di risposta per la query di richiesta del piano in secondi

0.10 0.14 0.11 0.01

tempo di risposta per la query di 2.79 460.65 12.25 64.71

(33)

R.3.4 Documento sull’analisi delle sperimentazioni Pag. 33 di 51 prenotazione in secondi

3.3 Ulteriori sviluppi

Il prototipo funziona, ma è evidente che concentrare più richieste in una stessa fascia oraria provoca un aumento del tempo necessario al server per rispondere. Questo è dovuto al fatto che ogni nuova richiesta viene confrontata con tutti i viaggi pre-esistenti e le loro combinazioni.

Nella tabella dell’appendice ‘Richieste della sperimentazione con 50 richieste concentrate in un giorno’ è mostrata una sperimentazione addizionale in cui sono state mandate 50 richieste in diverse fasce orarie della stessa giornata.

Nella tabella è evidente che si sono verificati 3 errori, quindi 3 utenti non hanno potuto prenotare un itinerario del loro viaggio, inoltre i tempi per elaborare la prenotazione aumentano fino a quasi 10 minuti.

D’altra parte il sistema genera solo 19 viaggi a fronte di 47 prenotazioni avvenute con successo, per cui il coefficiente di occupazione è superiore rispetto a qualunque delle 20 simulazioni della sperimentazione precedente. Se nella precedente sperimentazione, in tutte le simulazioni, il numero medio di passeggeri per viaggio era sempre inferiore a 2, in questo caso si raggiunge un numero medio di passeggeri per viaggio pari a 2.5.

Il sistema attualmente è limitato per quanto riguarda l’aggregazione degli utenti ai viaggi, per cui il calcolo del percorso richiede più tempo e in certi casi diventa troppo complesso per essere risolto in breve tempo dall’algoritmo attualmente utilizzato.

Il problema può essere risolto o almeno arginato in più modi:

1) sostituendo l’algoritmo di ricerca del percorso ottimale per la navetta con uno ad hoc;

2) accorpando finestre temporali di pickup e dropoff di più utenti in modo da presentare un problema meno complesso all’algoritmo (attualmente per ciascuna richiesta sono utilizzate due finestre temporali distinte, una per il pickup e una per il dropoff);

3) limitando almeno in una prima fase il numero di viaggi a cui l’utente può aggregarsi e ottimizzando in un secondo momento la pianificazione dei viaggi (processo di organizzazione dei viaggi in due fasi).

Infine un altro problema è dovuto alla gestione dei ritardi (e degli anticipi), che è possibile risolvere facilmente filtrando le soluzioni di viaggio con un ulteriore controllo per evitare ritardi eccessivi.

(34)

4 Conclusioni

Entrambi i prototipi sono stati testati e hanno prodotto risultati misurabili. Il presente documento sintetizza le sperimentazioni effettuate e le analizza nel dettaglio.

Per quanto riguarda il prototipo Beep4Me le sperimentazioni programmate per i casi d’uso individuati sono state eseguite in modo esaustivo verificando il corretto funzionamento del sistema. In particolare il funzionamento è risultato corretto in termini di notifiche ricevute dall’utente sullo smartphone e di aggiornamenti lato server nel database biglietti della “azienda di trasporto”. Sono state individuate ed affrontate alcune problematiche ed è stata eseguita una prima calibrazione del sistema.

Il prototipo Poolbus invece consente di ottenere mediamente in breve tempo una soluzione di viaggio che rispecchia la necessità di un utente. Tuttavia la flessibilità di orario e di percorso potrebbe non essere sufficientemente attrattiva, per questo motivo il servizio di navette prevede un contributo regionale per ridurre le tariffe degli utenti. Il prototipo PoolBus può adattarsi ad un’area a domanda debole in cui sono necessarie alternative di viaggio diverse da quelle tradizionali. Naturalmente si possono svolgere ulteriori simulazioni con obiettivi diversi (es. dimensionare il numero di veicoli necessari, dare priorità ad altre funzioni obiettivo come minimizzare i tempi di attesa o i percorsi delle navette).

(35)

5 Appendice

5.1 Tabelle delle sperimentazioni di PoolBus

In questa parte dell’appendice sono riportate le tabelle che riguardano l’analisi generale delle 20 simulazioni della fase di sperimentazione virtuale.

5.1.1 Tabella “Oggetti generati dalle simulazioni”

id della simulazione piani di viaggio generati prenotazioni generate viaggi generati

1 50 50 37

2 50 50 30

3 50 50 30

4 50 50 29

5 50 50 32

6 50 50 28

7 50 50 32

8 50 50 26

9 50 50 33

10 50 50 29

11 50 50 25

12 50 50 32

13 50 50 31

14 50 50 30

15 50 50 31

16 50 50 34

17 50 50 27

18 50 50 33

19 50 50 25

20 50 50 23

(36)

5.1.2 Tabella “Tariffe degli utenti”

numero simulazione

valore minimo tariffa in €

valore massimo tariffa in €

valore medio tariffa in €

deviazione standard

1 0.86 33.45 14.31 7.86

2 0.94 26.27 10.69 7.69

3 1.14 26.27 10.38 6.75

4 0.85 27.10 9.97 7.46

5 0.94 33.45 10.74 7.74

6 0.56 33.45 10.84 8.51

7 0.86 33.45 11.95 8.85

8 0.86 25.46 9.07 7.33

9 0.94 25.89 11.59 7.56

10 2.14 29.39 12.01 7.92

11 1.43 33.45 10.93 8.29

12 1.41 27.10 10.24 8.00

13 2.55 28.12 11.20 7.81

14 0.58 33.45 9.73 8.19

15 0.40 33.45 10.90 8.95

16 2.55 34.41 10.20 7.03

17 0.86 33.45 11.12 7.72

18 0.86 34.41 12.22 8.55

19 0.43 33.45 11.41 9.42

20 0.86 33.45 11.04 8.25

(37)

5.1.3 Tabella “Ritardi”

numero simulazione

valore minimo ritardo in minuti

valore massimo ritardo in minuti

valore medio ritardo in minuti

deviazione standard

1 -49 22 -2.06 9.86

2 -54 29 -5.5 16.79

3 -30 19 -0.6 8.81

4 -58 27 -1.64 15.46

5 -50 26 -1.3 12.18

6 -49 30 -1.52 15.51

7 -14 27 2.78 8.19

8 -56 24 -5.9 17.86

9 -60 28 -0.78 12.87

10 -48 28 -1.32 12.86

11 -51 26 -1.42 16.37

12 -30 26 -1.32 9.82

13 -57 29 -3.14 16.99

14 -38 29 -0.76 12.49

15 -52 23 -0.46 11.69

16 -36 21 -3.18 9.82

17 -57 27 -0.34 14.72

18 -29 29 0.48 10.84

19 -48 24 -4.32 14.00

20 -48 27 -1.6 16.12

(38)

5.1.4 Tabella “Durate dei percorsi degli utenti”

numero simulazione

valore minimo della durata in minuti

valore massimo della durata in minuti

valore medio della durata in minuti

deviazione standard

1 8 106 52.84 25.56

2 13 96 56.62 21.73

3 13 110 51.36 27.27

4 9 107 49.82 24.92

5 7 103 50.18 26.33

6 7 117 52.3 25.85

7 7 92 46.78 18.74

8 7 106 55.88 23.80

9 13 110 52.12 24.80

10 13 102 51.08 22.01

11 9 105 53.08 22.24

12 7 122 45.2 18.39

13 8 107 54.52 26.29

14 7 96 44.74 23.87

15 8 95 46.98 25.40

16 9 93 50.66 22.17

17 13 114 50.9 24.57

18 13 104 49.1 24.75

19 9 110 60.04 26.06

20 11 122 57.44 26.26

(39)

5.1.5 Tabella “Lunghezze dei percorsi degli utenti”

numero simulazione

valore minimo della lunghezza in km

valore massimo della lunghezza in km

valore medio della lunghezza in km

deviazione standard

1 3.29 65.71 36.43 19.19

2 5.37 60.54 29.54 17.32

3 6.49 66.73 32.42 17.10

4 6.37 66.31 27.22 17.70

5 3.29 63.71 28.63 16.53

6 3.29 73.03 31.08 19.98

7 3.29 63.71 32.77 18.11

8 3.29 73.72 25.24 15.64

9 5.37 60.11 30.43 15.66

10 6.49 69.09 33.82 17.35

11 3.29 65.55 30.87 17.98

12 3.29 51.62 23.06 14.59

13 6.17 74.12 29.48 16.54

14 3.29 63.71 24.55 18.01

15 3.83 63.71 28.31 17.87

16 5.37 65.55 29.67 16.84

17 3.29 76.92 32.33 20.27

18 3.29 82.74 32.54 22.67

19 3.29 64.47 32.93 20.25

20 3.29 67.96 35.87 22.09

(40)

5.1.6 Tabella “Passeggeri delle navette”

numero simulazione

numero minimo dei passeggeri

numero massimo dei passeggeri

numero medio di passeggeri

deviazione standard

1 1 3 1.35 0.59

2 1 4 1.67 0.80

3 1 4 1.67 1.06

4 1 4 1.72 0.92

5 1 4 1.56 0.88

6 1 8 1.79 1.57

7 1 5 1.56 0.98

8 1 7 1.92 1.47

9 1 6 1.52 0.97

10 1 4 1.72 0.88

11 1 5 2.00 1.22

12 1 4 1.56 0.67

13 1 4 1.61 0.88

14 1 4 1.67 0.92

15 1 5 1.61 1.02

16 1 4 1.47 0.79

17 1 4 1.85 1.03

18 1 3 1.52 0.76

19 1 6 2.00 1.22

20 1 5 2.17 1.34