Simulazione Pedonale Anylogic Bozza

Universit degli Studi di Trieste Facolt di Ingegneria Corso di Laurea Magistrale in Ingegneria Civile Corso di Impianti e Terminali di Trasporto
Esercitazione sullanalisi di simulazione della mobilit pedonale con il software AnyLogic
Docenti:
Prof. ing. Giuliano Stabon Ing. Giorgio Medeossi
Studentessa: Francesca Iurasek - matr. IN1100042
Anno Accademico 2011-2012
Esercitazione sullanalisi di simulazione della mobilit pedonale con il software AnyLogic Corso di Impianti e Terminali di Trasporto Studentessa: Francesca Iurasek
Scopo dellesercitazione.
Obiettivo della presente esercitazione comprendere il funzionamento dellanalisi di simulazione con riferimento alla mobilit pedonale allinterno di un terminale di trasporto con lausilio di un apposito programma di microsimulazione. Si utilizza il software AnyLogic (Professional Edition versione trial). Per quanto riguarda il terminale considerato, si fa riferimento ad una planimetria gi presente nella cartella relativa al programma stesso - che rappresenta una stazione di una metropolitana.
Il software utilizzato e la costruzione del modello.

Introduzione ai modelli di simulazione: approcci e livelli di astrazione. Un modello di simulazione pu essere considerato come una serie di regole (ad esempio equazioni, diagrammi di flusso ecc..) che definiscono quali modifiche subir il sistema oggetto di modellazione, una volta noto lo stato iniziale del sistema stesso. Lesecuzione del modello di simulazione descrive quindi gli stati assunti dal sistema in una distribuzione (continua o discreta) di istanti temporali. I modelli di simulazione possono essere utilizzati per descrivere un gran numero di situazioni anche molto diverse tra loro, e sono caratterizzati da diversi livelli di astrazione. Nella figura seguente sono indicate diverse categorie di problemi affrontabili con modelli di simulazione, affiancate al corrispondente livello di astrazione.
Correlati al livello di astrazione, si possono distinguere tre approcci allanalisi di simulazione: gli approcci tradizionali, SD (System Dynamics) e DE (Discrete Event), caratterizzati da un pi alto livello di astrazione, e lultimo approccio sviluppato, AB (Agent Based), caratterizzato da un processo bottom-up (dal basso verso lalto) ossia focalizzato sul comportamento del singolo oggetto facente parte del modello.
2
Le caratteristiche dei diversi paradigmi di simulazione sono descritte pi precisamente nei punti seguenti. Approccio SD (System Dynamics): consente di comprendere le dinamiche di funzionamento di sistemi complessi. Prevede lo studio di cicli retroattivi (feedback loops) che descrivono linterazione tra struttura organizzativa del modello e ritardi temporali. Unaltra caratteristica basilare dei modelli SD lutilizzo di variabili stocks and flows [dove i primi rappresentano quantit misurate in un dato istante temporale (possono quindi accumularsi nel tempo), mentre i secondi rappresentano quantit caratteristiche di un dato intervallo di tempo.] di fondamentale importanza ricordare che elementi appartenenti ad uno stesso stock sono indistinguibili (non hanno individualit). Lapproccio SD adatto per scenari di lungo periodo, per una programmazione a livello strategico e macroscopico. Approccio DE (Discrete Event): prevede la definizione di entit passive (che possono rappresentare persone, documenti eccetera), inserite allinterno di un processo, ossia una sequenza di operazioni. Lo scorrere continuo del tempo viene in questo modo discretizzato, e si ottiene un numero finito di istanti caratterizzati dallo svolgimento di diverse operazioni. importante notare che, sebbene ogni oggetto del modello sia concepito individualmente come un entit, ne vengono ignorati diversi dettagli, quali lesatta geometria, laccelerazione/decelerazione che subisce, eccetera. Lapproccio DE adatto per risolvere problematiche di tipo tattico, in cui risulti chiara e sensata la definizione di una sequenza di operazioni da seguire. Approccio AB (Agent Based): un approccio individuo centrico, che si colloca quindi allestremo opposto dellapproccio SD nella scala dellastrazione. Vengono definiti gli agenti (persone, veicoli, eccetera) e il loro comportamento; gli agenti vengono poi inseriti in un certo ambiente. Il comportamento globale del sistema viene determinato quindi come risultato delle mutue interazioni di molti comportamenti individuali. Lapproccio AB adatto alla risoluzione di problematiche a livello microscopico e operativo.
Breve descrizione del software AnyLogic. Il software AnyLogic pu essere utilizzato secondo tutti i paradigmi di simulazione appena descritti. In questa esercitazione si sperimenta lutilizzo del paradigma AB (Agent Based), che fra i tre esistenti il pi adatto alla simulazione della mobilit pedonale in una determinata area. AnyLogic provvisto di una apposita libreria per la modellazione della mobilit pedonale: la Pedestrian Library. Introduzione alla Pedestrian Library. La Pedestrian Library una libreria di oggetti e funzionalit che consentono di simulare il flusso pedonale in un ambiente fisico reale definito da una planimetria, che viene caricata nellambiente di lavoro del programma. Nel modello di simulazione costruito con la Pedestrian Library, i pedoni si muovono in unarea definita dallutente e interagiscono con diversi tipi di ostacoli e con gli altri pedoni. In seguito allesecuzione del modello si ottengono svariate informazioni: ad esempio, possibile stimare il tempo di attesa in determinate aree, per evidenziare eventuali difetti geometrici delledificio o dellinfrastruttura considerati, o eventuali difetti nella modellazione. Pedestrian Library Tutorial Subway Entrance Model. La costruzione del modello descritto in questa esercitazione viene svolta seguendo punto per punto le istruzioni dellapposito tutorial Pedestrian Library Tutorial Subway Entrance Model. Con questo tutorial possibile apprendere lutilizzo delle funzionalit base della Pedestrian Library. In seguito vengono riportate le fasi della procedura seguita. 1. 2. 3. 4. Creazione del nuovo modello e visualizzazione dellambiente di lavoro di AnyLogic Disegno degli elementi dellanimazione del modello Creazione di un flusso pedonale Regolazione delle impostazioni del modello
4
5. 6. 7. 8.
Prima esecuzione del modello Aggiunta di tornelli di controllo ticket Aggiunta di un sistema di modifica interattiva del numero di pedoni in ingresso Aggiunta di biglietterie
Utilizzo del modello: scenari alternativi e dati di output.

Considerazioni preliminari. Prima di iniziare a lavorare con il modello appena creato, si ritiene opportuno fare alcune considerazioni. Si sottolinea in primo luogo il carattere puramente ideale e teorico del modello, in quanto il layout oggetto di studio non rappresenta una stazione della metropolitana realmente esistente. Tuttavia si ritiene utile operare un tentativo di contestualizzazione del modello, non tanto per unelaborazione dettagliata di dati reali (che non sarebbe ora n possibile n sensata ovviamente), quanto per avere unidea dellordine di grandezza del problema e per comprendere meglio il funzionamento della modellazione. Si osserva quindi la planimetria del caso studio: questultimo si configura come una stazione della metropolitana di dimensioni medio-piccole, con due biglietterie e quattro tornelli di controllo biglietti/accesso ai binari. In secondo luogo, ci si chiede di quale entit possa essere il flusso di passeggeri che transiti in un terminale di questo tipo in una situazione reale: per rispondere a questa domanda si fa riferimento ai dati riportati sul sito http://mic-ro.com/metro/table.html. Nel caso specifico, sono stati considerati i dati relativi alla metropolitana di Roma: Citt n. linee n. stazioni totali n. passeggeri/giorno totali Roma 2 52 907000
Tenendo presente che non si ha alcuna pretesa di precisione, ma si vuole solamente verificare a grandi linee la coerenza dei dati di input suggeriti con una situazione reale, si procede a un calcolo grossolano del numero di passeggeri/ora in transito in una stazione:
Si sceglie quindi di mantenere il dato di input di 1000 passeggeri/ora suggerito dal tutorial. Per quanto riguarda il numero di passeggeri in ingresso al minuto, si considera un intervallo i cui estremi sono 0 (valore minimo) e 120 (valore massimo). [Il valore massimo stato scelto ipotizzando larrivo contemporaneo di due autobus urbani, di capienza pari a 80
5
posti, completamente pieni, ipotizzando che il 75% dei passeggeri presenti nei due autobus sia diretto verso la metropolitana.] Per ogni scenario di quelli proposti in seguito, si esegue la simulazione nel seguente modo: - prima fase: ingresso di circa 60 passeggeri/min per i primi dieci minuti della durata della simulazione; - seconda fase: si ipotizza un incremento di passeggeri in ingresso, che raggiungono il valore massimo di 120 passeggeri/min. Scenari alternativi proposti. Allo scopo di sperimentare in diverse condizioni il funzionamento del modello appena creato, vengono introdotti alcuni ipotetici scenari alternativi: Modello con file disordinate Modello con introduzione di sistema separa code alle biglietterie tradizionali Modello con introduzione di due nuove biglietterie automatiche Modello con introduzione di un cartellone di informazioni (ad esempio mappa delle linee della metropolitana).
Modello con file disordinate Il primo scenario proposto prevede una situazione del tutto simile a quella proposta dal tutorial: stato riprodotto landamento casuale delle file relative alle biglietterie e ai gate di accesso ai binari. Lambiente assume laspetto seguente ( in seguito lambiente viene riproposto graficamente solo nellimmagine del modello in esecuzione).
Lo schema operativo assume la configurazione seguente:
I parametri assunti per gli oggetti pedSelectOutput e windows sono evidenziati dalle immagini riportate in seguito.
In windows viene specificata la distribuzione del tempo di ritardo in coda alle biglietterie tradizionali, che viene assunta triangolare, con valore minimo 30 s, massimo 60 s, medio 45 s.
In pedSelectOutput vengono specificate le percentuali di utenti dirette verso i gates (chance 1) e verso le biglietterie tradizionali (chance 2).
Situazione nei primi 10 minuti con flusso pari a 60 pedoni/min:
Situazione nei successivi 5 minuti, con flusso pari a 120 pedoni/min:
Come si pu vedere, la saturazione viene raggiunta nella fase di carico massimo, dopo solo due minuti. Si osserva che il problema legato a una congestione delle file delle biglietterie, non tanto delle file dei gates di accesso ai binari. Si evidenzia quindi la possibilit di introdurre alcune modifiche alla modellazione delle biglietterie. Modello con introduzione di sistema separa code alle biglietterie tradizionali Si introduce nel secondo scenario, un sistema separa code alle biglietterie tradizionali, al fine di rendere pi ordinata la disposizione dei pedoni in fila, ottimizzando quindi lo spazio disponibile per i pedoni in attesa del biglietto. Lo schema operativo rimane invariato rispetto allo scenario precedente, in quanto stata modificata solo la configurazione geometrica delle code delle biglietterie. Situazione nei primi 10 minuti con flusso pari a 60 pedoni/min:
Si osserva che anche in questo scenario viene raggiunta la saturazione del sistema dopo circa due minuti dallintroduzione del carico massimo di pedoni in ingresso. Il problema riscontrato relativo, anche in questo caso, alle file delle biglietterie: ladozione del sistema separa code non ha apportato significativi vantaggi. Risulta perci evidente la necessit di apportare modifiche non tanto alla configurazione geometrica delle code, quanto alle modalit di acquisto dei titoli di viaggio. La soluzione pi immediata consisterebbe nelladozione di biglietterie automatiche, caratterizzate da unutenza che gi conosce le caratteristiche della rete di trasporto, e quindi da tempi di attesa contenuti. La biglietteria tradizionale, invece, impone tempi di attesa piuttosto elevati: ad essa dovrebbero rivolgersi solamente coloro che hanno necessit di informazioni o consigli riguardo la citt e i trasporti (solitamente i turisti). Modello con introduzione di due nuove biglietterie automatiche Nel terzo scenario si ipotizza la presenza di due biglietterie automatiche, a supporto del servizio delle due gi presenti biglietterie tradizionali. Per differenziare le biglietterie automatiche da quelle tradizionali, necessario creare un nuovo oggetto pedServices, che viene rinominato windows1, che
10
rappresenta le biglietterie automatiche. Lo schema operativo funzionale assume il seguente aspetto:
I parametri assunti per gli oggetti pedSelectOutput, windows e windows1 sono riportati in seguito.
In pedSelectOutput vengono specificate le percentuali di utenti dirette verso i gates (chance 1), le biglietterie tradizionali (chance 2), le biglietterie automatiche (chance 3).
In windows viene specificata la distribuzione del tempo di ritardo in coda alle biglietterie tradizionali, che viene assunta triangolare, con valore minimo 30 s, massimo 60 s, medio 45 s.
In windows1 viene specificata la distribuzione del tempo di ritardo in coda alle biglietterie automatiche, che viene assunta triangolare, con valore minimo 20 s, massimo 40 s, medio 30 s.
11
Si cerca di disporre le due nuove biglietterie in una posizione che interferisca il meno possibile con il flusso dei pedoni diretto ai treni e alle biglietterie tradizionali. Si ipotizza di mantenere il sistema separa code alle biglietterie tradizionali. Situazione nei primi 10 minuti con flusso pari a 60 pedoni/min:
Come si pu vedere, la situazione si presenta critica gi nella prima fase di esecuzione del modello. I problemi sembrano direttamente connessi alla scelta del posizionamento delle biglietterie automatiche: infatti, la coda creatasi alle biglietterie automatiche risulta di intralcio ai pedoni diretti ai gates. Le criticit tuttavia sono legate ad unulteriore serie di fattori: - la corretta valutazione dei tempi di attesa in coda - la corretta valutazione delle percentuali di utenti dirette alle varie destinazioni - la modellazione della coda che sia il pi possibile aderente al comportamento reale degli utenti. Un tentativo di soluzione dei problemi precedentemente esposti potrebbe prevedere leliminazione di una biglietteria tradizionale a favore di una biglietteria automatica; si propone inoltre di modificare il posizionamento delle biglietterie automatiche preesistenti.
12
13
La situazione migliora sensibilmente rispetto al caso precedente, tanto che la saturazione viene raggiunta, sotto carico massimo, dopo circa 6 minuti. La situazione pi critica viene riscontrata anche in questo caso in prossimit delle biglietterie. Risulta quindi evidente la necessit di abbattere i tempi di attesa alle biglietterie automatiche e di ridurre sempre pi la percentuale di utenti che si servono della biglietteria tradizionale. Modello con introduzione di un cartellone di informazioni (ad esempio mappa delle linee della metropolitana). Si intende ora simulare la presenza di un elemento di attrazione per i pedoni in transito nel terminale, quale pu essere ad esempio un cartellone con informazioni sulla rete di trasporto pubblico. Per far ci necessario lutilizzo di due funzionalit non illustrate nel tutorial: pedAttractor e pedWait. PedAttractor un oggetto facente parte della Pedestrian Library che consente di simulare la posizione in cui si dispongono i pedoni in attesa nelle vicinanze di un elemento di attrazione; per un utilizzo corretto di pedAttractor necessario creare unarea attorno allattrazione allinterno della quale si posizioneranno i pedoni in attesa mediante il comando pedArea. Nello schema funzionale viene quindi inserito loggetto pedWait, mediante il quale i pedoni si dirigono nellarea predefinita e l attendono per un determinato periodo di tempo. Lo schema funzionale si configura nel modo seguente:
14
15
Anche in questo caso si osserva che la saturazione del sistema si raggiunge dopo circa 6 minuti dallintroduzione del carico massimo di passeggeri in ingresso. Essa risulta tuttavia legata allinterazione tra una coda al gate e la coda alla biglietteria tradizionale. Lintroduzione dellelemento di attrazione sembra avere quindi rilevanza assai minore rispetto alle code alle biglietterie nellaccumulo di ritardo del sistema. Un miglioramento al sistema pu essere apportato introducendo metodi di controllo ticket di nuova generazione e eliminando progressivamente le biglietterie.
Osservazioni e conclusioni.
A fronte delle analisi condotte, possibile fare alcune considerazioni conclusive. Per quanto riguarda il programma AnyLogic, esso risulta per simulazioni relativamente semplici come questa di utilizzo non troppo complesso, una volta compresi i passaggi fondamentali alla base dellintroduzione di nuovi oggetti nellambiente di lavoro e della modifica degli oggetti inseriti in precedenza. Il software presenta inoltre uninterfaccia grafica il cui funzionamento diventa in breve tempo intuitivo. Particolare importanza nella creazione del modello riveste la definizione grafica di elementi quali code e aree di sosta. In particolare per quanto riguarda le code, la definizione della spezzata che le rappresenta di fondamentale importanza: variandone la forma possibile variare la localizzazione dei punti pi congestionati dellarea in esame. Ci pu costituire un limite della modellazione, infatti non si sa con certezza quale sia il comportamento reale degli utenti. Dal punto di vista invece della mobilit pedonale allinterno del terminale, le criticit riscontrate come daltronde ci si aspettava - riguardano soprattutto le biglietterie. Infatti anche i tempi di attesa alle biglietterie automatiche, che sono in genere sensibilmente inferiori rispetto ai tempi di attesa propri delle biglietterie tradizionali, risultano essere troppo elevati per un funzionamento corretto del terminale con un carico di utenti in ingresso pari a quello ipotizzato per lora di punta (120 pedoni/minuto). Per un ottimale deflusso pedonale, in cui quindi il numero di utenti in coda alle biglietterie risulti drasticamente ridotto, dunque necessaria la diffusione di sistemi di controllo biglietti di ultima generazione: ne un esempio la tecnologia NFC (Near Field Communications). Si tratta di una tecnologia wireless a corto raggio (o proximity-based) che consente lo scambio bidirezionale di dati, caratterizzata da un raggio dazione massimo di circa 10 cm. In questo modo, al prezzo di una ridottissima distanza operativa (che in pratica richiede lo sfioramento delle entit comunicanti), possibile concludere operazioni di pagamento e bigliettazione, ossia effettuare pagamenti e controllare titoli di viaggio con dispositivi di lettura di ridotta potenza e dimensioni, quali ad esempio telefoni cellulari.
16

Simulazione Pedonale Anylogic Bozza

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Simulazione Pedonale Anylogic Bozza

Încărcat de

Drepturi de autor:

Formate disponibile

Universit degli Studi di Trieste Facolt di Ingegneria Corso di Laurea Magistrale in Ingegneria Civile Corso di Impianti e Terminali di Trasporto

Esercitazione sullanalisi di simulazione della mobilit pedonale con il software AnyLogic

Prof. ing. Giuliano Stabon Ing. Giorgio Medeossi

Studentessa: Francesca Iurasek - matr. IN1100042

Anno Accademico 2011-2012

Il software utilizzato e la costruzione del modello.

Utilizzo del modello: scenari alternativi e dati di output.

Lo schema operativo assume la configurazione seguente:

Situazione nei primi 10 minuti con flusso pari a 60 pedoni/min:

Situazione nei successivi 5 minuti, con flusso pari a 120 pedoni/min:

Situazione nei successivi 5 minuti, con flusso pari a 120 pedoni/min:

rappresenta le biglietterie automatiche. Lo schema operativo funzionale assume il seguente aspetto:

Situazione nei primi 10 minuti con flusso pari a 60 pedoni/min:

Situazione nei successivi 5 minuti, con flusso pari a 120 pedoni/min:

Situazione nei primi 10 minuti con flusso pari a 60 pedoni/min:

Situazione nei successivi 5 minuti, con flusso pari a 120 pedoni/min:

S-ar putea să vă placă și