I moduli fondamentali della libreria “Enterprise”

Nelle simulazioni ad eventi discreti di tipo “processo-centriche”, la rappresentazione del sistema avviene attraverso una sequenza di operazioni eseguite su determinate entità, siano esse utenti di un certo servizio, parti, documenti, dati, telefonate, veicoli. Come accennato in precedenza le entità sono passive, non operano in modo diretto sui processi del sistema, ma possono possedere attributi in grado di mutare le modalità di processamento. Da un punto di vista informatico in Anylogic© ciò avviene rappresentando le entità come “classi” e gli attributi come metodi, strutture fondamentali del linguaggio Java. Avremo modo di chiarire in 3.3.6 quali siano gli attributi con i quali si è scelto di caratterizzare le entità di cui si è popolato il modello elaborato.

Per la costruzione dei processi la libreria Enterprise mette a disposizione una serie di elementi di processo predefiniti, ciascuno caratterizzato da funzioni e proprietà specifiche. L’assemblaggio di tali “blocchi” funzionali in catene, consente la corretta rappresentazione funzionale dei processi che si desidera considerare. Le entità, una volta generate, attraverseranno tali elementi subendo di volta in volta operazioni consone ai propri attributi interni. Per ogni blocco è inoltre possibile definire, attraverso opportuni comandi, operazioni da eseguirsi in corrispondenza dell’ingresso e dell’uscita dell’entità. Prima di esporre l’architettura del modello sviluppato, si propone una breve presentazione dei principali tra tali blocchi funzionali, in modo da rendere immediata la comprensione del loro ruolo all’interno del simulatore.

Il blocco source immette le entità nel sistema, consentendo di impostare una distribuzione probabilistica per il tasso di arrivo o di legare la generazione a specifici eventi attivando l’inserimento di una nuova entità nel sistema in modo dinamico. I parametri necessari alla definizione della distribuzione di probabilità che regola la generazione delle entità possono essere variati in qualsiasi istante temporale della simulazione attraverso opportuni comandi. Al momento dell’introduzione dell’entità nel sistema questa viene caratterizzata attraverso la classe di appartenenza e gli eventuali attributi della classe. Il blocco sink costituisce il terminale delle catene di processi presenti nel modello. Le entità che entrano in un blocco sink abbandonano il sistema.

L’elemento queue rappresenta una coda di entità in attesa di essere processate da un blocco successivo. La logica di default che regola il deflusso delle entità dalla coda è di tipo FIFO, sebbene sia possibile definire regole di priorità a piacere. È possibile limitare la capacità della coda ad un intero positivo o permettere piuttosto alla coda di ospitare un numero infinito di entità.

Figura 3.2 – Elementi funzionali queue e delay

Il blocco funzionale delay rappresenta un ritardo e trattiene l’unità al suo interno per una certa quantità di tempo senza operare su di essa nessuna ulteriore operazione. All’interno di delay è possibile definire una qualsiasi distribuzione per il tempo di ritardo; la distribuzione di default del ritardo è di tipo triangolare e richiede che sia fornito un valore temporale di attesa minimo, massimo e medio. Anche per delay è possibile definire un valore di capacità massima. Se il numero di entità che stazionano all’interno di delay è inferiore alla capacità massima, le entità vengono ritardate in modo contemporaneo, secondo una logica in parallelo. In caso contrario le entità in attesa di impegnare il blocco dovranno attendere che almeno una delle entità ospitate al suo interno venga rilasciata.

Service è un elemento operatore che rappresenta l’accesso di un’entità ad un generico servizio. Per ogni blocco service è necessario definire un relativo blocco resource pool che rappresenta il bacino di risorse necessarie all’erogazione del servizio ad una singola entità. Ogni qual volta che un’entità entra in un blocco service, una risorsa viene prelevata dall’opportuno blocco resource pool e rimane indisponibile per un tempo la cui distribuzione di probabilità è possibile impostare a piacimento. La distribuzione di default per il tempo di servizio è anche in questo caso triangolare. Se il numero di risorse è insufficiente a servire tutte le unità che impegnano in uno stesso momento il blocco, le unità in attesa vengono poste in coda. All’interno di resource pool è possibile definire il numero di risorse necessarie alla fornitura del servizio per ogni singola entità che impegna il corrispondente blocco service.

Figura 3.3 – Elementi funzionali service e resource pool

Il blocco hold consente di interrompere il flusso delle entità. Il blocco è generalmente attivato in modo dinamico al verificarsi di determinate condizioni nel corso della simulazione. Tra le proprietà di hold vi è quella di poter essere impostato in modo da impedire alle entità il transito sin dall’inizio della simulazione o di farlo solo a seguito della ricezione di opportuni comandi dall’esterno. Il blocco select output consente di smistare le unità su diverse catene di processo. Lo smistamento può avvenire secondo due modalità: la definizione di una distribuzione di probabilità o il verificarsi di una o più condizioni. La libreria Enterprise mette anche a disposizione un blocco select output caratterizzato da 5 possibili uscite diverse, con dinamiche di funzionamento analoghe a quanto appena descritto

Figura 3.4 – Elementi funzionali hold e select output

L’elemento pick-up consente di rappresentare un qualsiasi mezzo di trasporto. Il blocco possiede una porta di ingresso e di uscita per l’entità mezzo di trasporto, ed un canale di ingresso, associato ad una coda, per le entità passeggeri. All’ingresso di una entità mezzo di trasporto nel blocco le entità passeggeri in coda vengono prelevate secondo una logica che può essere impostata a piacimento. È possibile selezionare il prelievo di tutte le entità disponibili oppure fare in modo che venga prelevato esclusivamente un numero prefissato di entità, se disponibili. Si sottolinea come al momento del prelievo non si crei alcuna identità fra l’entità mezzo di trasporto e le entità passeggeri. Una volta che il mezzo di trasporto ha ultimato il percorso previsto, è possibile separare mezzi e passeggeri attraverso un blocco drop-off.

Figura 3.5 – Elementi funzionali pick-up e drop-off

Da ultimo si introducono gli elementi split e combine. Split consente di generare, contestualmente all’ingresso nell’elemento di una entità, un qualsiasi numero di entità della stessa classe o di classi differenti. Al momento della generazione è inoltre possibile impostare il valore che ciascun attributo delle entità duplicate dovrà assumere. Il blocco combine consente invece di combinare due (e solo due) entità, appartenenti a classi qualsiasi, in una nuova entità unica, i cui attributi possono essere impostati a piacimento.

Figura 3.6 – Elementi funzionali split e combine

Con la presentazione di questi elementi di processo si è completata la presentazione degli strumenti fondamentali che Anylogic© mette a disposizione per lo sviluppo di simulazioni orientate ai processi. Come però già accennato il software consente di “sovrapporre” a questa tipologia di modelli, elementi propri di simulazioni orientate agli eventi. L’elemento “event” della libreria “Main” è uno di questi e consente la rappresentazione di eventi permettendo di specificare l’istante o gli istanti in cui esso deve avvenire implementando le azioni desiderate. È inoltre possibile condizionare il verificarsi di un evento a particolari stati del sistema, attivando l’elemento event in modo dinamico. Esposta la funzione dei principali elementi operazionali e funzionali messi a disposizione dalla libreria Enterprise ed utilizzati per lo sviluppo del modello oggetto della presente tesi, si procede con la descrizione di dettaglio della modellistica elaborata, dichiarando la metodologia di sviluppo, le ipotesi fondative, l’architettura e le principali proprietà del modello, le modalità di estrapolazione dei dati ed il processo di validazione adottato.

3.3 Descrizione del modello realizzato

Come esposto nell’Introduzione al lavoro di tesi, la fase di sviluppo del modello è stata condotta durante la permanenza presso la Keio University di Tokyo, sotto la supervisione del prof. Nobuaki Minato. La metodologia attraverso la quale si è condotto il lavoro è stata quella di sviluppare ciascun macro-componente del modello in modo separato sulla base delle informazioni fornite dai docenti e studenti giapponesi partecipanti al progetto di ricerca. Ogni cluster del modello realizzato è stato discusso e verificato in modo collegiale attraverso meeting a cadenza settimanale, con diversi docenti e studenti della System Design Faculty presso la Keio University, anche estranei al progetto CMAC. I principali documenti dai quali si sono tratte informazioni per lo sviluppo del modello sono stati il documento redatto dal governo prefetturale di Yamagata riguardo al disastro del Marzo 2011(YPG [72]), un documento analogo redatto a livello nazionale dal Ministero delle infrastrutture e dei Trasporti Giapponese (MLIT, [73]), i dati messi a disposizione dallo stesso MLIT sul proprio sito web( [75]) ed infine il materiale raccolto a proposito dell’aeroporto di Yamagata dal prof. Minato, nell’ambito degli studi preliminari per la stesura del documento di analisi dei processi collaborativi messi in atto dagli operatori del trasporto aereo durante l'evento catastrofico del Marzo 2011 [70].

La fase di impostazione dello sviluppo ha previsto inoltre la raccolta di alcune fondamentali informazioni sul campo attraverso l’incontro con Masahiko Kurono, presidente dell’Institution for Transport Policy Studies ed ex amministratore delegato della Narita International Airport Corporation, in data 5 Marzo 2012, presso Japan International Transport Institute (JITI), Tokyo, l’incontro con personale del Tokyo Air Traffic Control Center presso Keio University in data 18 Aprile 2012, l’incontro con personale del Tokyo Regional Civil Aviation Bureau, Sendai Office, presso l’aeroporto di Sendai in data 15 Maggio 2012 e l’incontro con personale del Fukushima Airport Office e del Fukushima Prefectural Government, presso aeroporto di Fukushima in data 16 e 17 Maggio. Presso l’aeroporto di Fukushima e l’aeroporto di Tokyo, Haneda sono inoltre stati raccolti dati riguardanti la durata di alcune operazioni di gestione dei passeggeri all’interno del terminal e la durata delle operazioni di scalo effettuate sui velivoli, come specificheremo in 3.3.1.

La correttezza formale del programma che costituisce l’ossatura del modello è stata testata in modo estensivo, sottoponendo il programma a ripetute sessioni di debug, la cui conduzione è stata fortemente agevolata dai tool di debug messi a disposizione dal software, dal supporto tecnico fornito online da parte della casa produttrice e dall’interfaccia grafica di simulazione presente all’interno del software.

Di ciascun macro-componente del modello, progettato in modo tale da costituire un modulo capace di interfaccia sia orizzontale (con gli altri moduli del

modello), che verticale (con eventuali moduli da svilupparsi in futuro),si è prima testato il funzionamento in modo indipendente, procedendo progressivamente al suo assemblaggio nel modello complessivo e al collaudo di quest’ultimo ed alla sua validazione.