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 sull’analisi 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



Studentessa: Francesca Iurasek

2

Scopo dell’esercitazione.

Obiettivo della presente esercitazione è comprendere il funzionamento dell’analisi di simulazione

con riferimento alla mobilità pedonale all’interno di un terminale di trasporto con l’ausilio 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. L’esecuzione

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 all’analisi di

simulazione: gli approcci tradizionali, SD (System Dynamics) e DE (Discrete Event),

caratterizzati da un più alto livello di astrazione, e l’ultimo approccio sviluppato, AB (Agent

Based), caratterizzato da un processo “bottom-up” (“dal basso verso l’alto”) ossia

focalizzato sul comportamento del singolo oggetto facente parte del modello.




3

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 l’interazione tra struttura organizzativa del modello e ritardi

temporali. Un’altra caratteristica basilare dei modelli SD è l’utilizzo 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à).

L’approccio 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 all’interno 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 l’esatta geometria, l’accelerazione/decelerazione che

subisce, eccetera.

L’approccio 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 all’estremo opposto dell’approccio SD nella scala dell’astrazione. 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.

L’approccio AB è adatto alla risoluzione di problematiche a livello microscopico e

operativo.




4

Breve descrizione del software AnyLogic.

Il software AnyLogic può essere utilizzato secondo tutti i paradigmi di simulazione appena

descritti. In questa esercitazione si sperimenta l’utilizzo 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 nell’ambiente di lavoro del programma. Nel modello di simulazione costruito con

la Pedestrian Library, i pedoni si muovono in un’area definita dall’utente e interagiscono

con diversi tipi di ostacoli e con gli altri pedoni. In seguito all’esecuzione del modello si

ottengono svariate informazioni: ad esempio, é possibile stimare il tempo di attesa in

determinate aree, per evidenziare eventuali difetti geometrici dell’edificio o

dell’infrastruttura 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 dell’apposito tutorial “Pedestrian Library Tutorial – Subway Entrance

Model”. Con questo tutorial è possibile apprendere l’utilizzo delle funzionalità base della

Pedestrian Library. In seguito vengono riportate le fasi della procedura seguita.

1. Creazione del nuovo modello e visualizzazione dell’ambiente di lavoro di AnyLogic

2. Disegno degli elementi dell’animazione del modello

3. Creazione di un flusso pedonale

4. Regolazione delle impostazioni del modello




5

5. Prima esecuzione del modello

6. Aggiunta di tornelli di controllo ticket

7. Aggiunta di un sistema di modifica interattiva del numero di pedoni in ingresso

8. 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 un’elaborazione dettagliata di dati reali (che non sarebbe ora né

possibile né sensata ovviamente), quanto per avere un’idea dell’ordine di grandezza del

problema e per comprendere meglio il funzionamento della modellazione.

Si osserva quindi la planimetria del caso studio: quest’ultimo 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à Roma

n. linee 2

n. stazioni totali 52

n. passeggeri/giorno totali 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 l’arrivo contemporaneo di due autobus urbani, di capienza pari a 80

http://mic-ro.com/metro/table.html




6

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 l’andamento casuale delle file relative alle

biglietterie e ai gate di accesso ai binari. L’ambiente assume l’aspetto seguente ( in

seguito l’ambiente viene riproposto graficamente solo nell’immagine del modello in

esecuzione).




7

Lo schema operativo assume la configurazione seguente:

I parametri assunti per gli oggetti pedSelectOutput e windows sono evidenziati dalle

immagini riportate in seguito.

In pedSelectOutput vengono specificate

le percentuali di utenti dirette verso i

gates (chance 1) e verso le biglietterie

tradizionali (chance 2).

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.




8

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

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




9

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.





10


Si osserva che anche in questo scenario viene raggiunta la saturazione del sistema

dopo circa due minuti dall’introduzione del carico massimo di pedoni in ingresso. Il

problema riscontrato è relativo, anche in questo caso, alle file delle biglietterie:

l’adozione 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 nell’adozione di biglietterie

automatiche, caratterizzate da un’utenza 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




11

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


coda alle biglietterie tradizionali, che



In windows1 viene specificata la


coda alle biglietterie automatiche, che






12

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.


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 un’ulteriore 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 l’eliminazione di una biglietteria tradizionale a favore di una biglietteria

automatica; si propone inoltre di modificare il posizionamento delle biglietterie

automatiche preesistenti.




13






14

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 l’utilizzo 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

un’area attorno all’attrazione all’interno della quale si posizioneranno i pedoni in

attesa mediante il comando pedArea.

Nello schema funzionale viene quindi inserito l’oggetto pedWait, mediante il quale i

pedoni si dirigono nell’area predefinita e lì attendono per un determinato periodo

di tempo.

Lo schema funzionale si configura nel modo seguente:




15






16

Anche in questo caso si osserva che la saturazione del sistema si raggiunge dopo

circa 6 minuti dall’introduzione del carico massimo di passeggeri in ingresso. Essa

risulta tuttavia legata all’interazione tra una coda al gate e la coda alla biglietteria

tradizionale. L’introduzione dell’elemento di attrazione sembra avere quindi

rilevanza assai minore rispetto alle code alle biglietterie nell’accumulo 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 dell’introduzione di nuovi oggetti nell’ambiente di lavoro e della modifica degli oggetti

inseriti in precedenza. Il software presenta inoltre un’interfaccia 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 dell’area 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 all’interno del terminale, le criticità riscontrate –

come d’altronde 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 l’ora 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 d’azione 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.

Documents

Simulazione Pedonale Anylogic Bozza