Requirements definition and testing of the new version of multi-mission generic monitoring system (GEMS) v 4.4 for operations at Eumetsat

EUMETSAT (www.eumetsat.int) e’ l’agenzia europea per operazioni su satelliti per monitorare clima, meteo e ambiente terrestre. Dal centro operativo situato a Darmstadt (Germania), si controllano satelliti meteorologici su orbite geostazionarie e polari che raccolgono dati per l’osservazione dell’atmosfera, degli oceani e della superficie terrestre per un servizio continuo di 24/7. Un sistema di monitoraggio centralizzato per programmi diversi all’interno dell’ambiente operazionale di EUMETSAT, e’ dato da GEMS (Generic Event Monitoring System). Il software garantisce il controllo di diverse piattaforme, cross-monitoring di diverse sezioni operative, ed ha le caratteristiche per potere essere esteso a future missioni. L’attuale versione della GEMS MMI (Multi Media Interface), v. 3.6, utilizza standard Java Server Pages (JSP) e fa uso pesante di codici Java; utilizza inoltre files ASCII per filtri e display dei dati. Conseguenza diretta e’ ad esempio, il fatto che le informazioni non sono automaticamente aggiornate, ma hanno bisogno di ricaricare la pagina. Ulteriori inputs per una nuova versione della GEMS MMI vengono da diversi comportamenti anomali riportati durante l’uso quotidiano del software. La tesi si concentra sulla definizione di nuovi requisiti per una nuova versione della GEMS MMI (v. 4.4) da parte della divisione ingegneristica e di manutenzione di operazioni di EUMETSAT. Per le attivita’ di supporto, i test sono stati condotti presso Solenix. Il nuovo software permettera’ una migliore applicazione web, con tempi di risposta piu’ rapidi, aggiornamento delle informazioni automatico, utilizzo totale del database di GEMS e le capacita’ di filtri, insieme ad applicazioni per telefoni cellulari per il supporto delle attivita’ di reperibilita’. La nuova versione di GEMS avra’ una nuova Graphical User Interface (GUI) che utilizza tecnologie moderne. Per un ambiente di operazioni come e’ quello di EUMETSAT, dove l’affidabilita’ delle tecnologie e la longevita’ dell’approccio scelto sono di vitale importanza, non tutti gli attuali strumenti a disposizione sono adatti e hanno bisogno di essere migliorati. Allo stesso tempo, un’ interfaccia moderna, in termini di visual design, interattivita’ e funzionalita’, e’ importante per la nuova GEMS MMI.

Il ruolo delle architetture di controllo nella progettazione e sviluppo di applicazioni web: Un confronto fra event-loop e control-loop utilizzando il linguaggio dart e linguaggi agent-oriented

Quando si parla di architetture di controllo in ambito Web, il Modello ad Eventi è indubbiamente quello più diffuso e adottato. L’asincronicità e l’elevata interazione con l’utente sono caratteristiche tipiche delle Web Applications, ed un architettura ad eventi, grazie all’adozione del suo tipico ciclo di controllo chiamato Event Loop, fornisce un'astrazione semplice ma sufficientemente espressiva per soddisfare tali requisiti. La crescita di Internet e delle tecnologie ad esso associate, assieme alle recenti conquiste in ambito di CPU multi-core, ha fornito terreno fertile per lo sviluppo di Web Applications sempre più complesse. Questo aumento di complessità ha portato però alla luce alcuni limiti del modello ad eventi, ancora oggi non del tutto risolti. Con questo lavoro si intende proporre un differente approccio a questa tipologia di problemi, che superi i limiti riscontrati nel modello ad eventi proponendo un architettura diversa, nata in ambito di IA ma che sta guadagno popolarità anche nel general-purpose: il Modello ad Agenti. Le architetture ad agenti adottano un ciclo di controllo simile all’Event Loop del modello ad eventi, ma con alcune profonde differenze: il Control Loop. Lo scopo di questa tesi sarà dunque approfondire le due tipologie di architetture evidenziandone le differenze, mostrando cosa significa affrontare un progetto e lo sviluppo di una Web Applications avendo tecnologie diverse con differenti cicli di controllo, mettendo in luce pregi e difetti dei due approcci.

Feasibility study and flow scheduling optimization of a multi-product pipeline system

The first goal of this study is to analyse a real-world multiproduct onshore pipeline system in order to verify its hydraulic configuration and operational feasibility by constructing a simulation model step by step from its elementary building blocks that permits to copy the operation of the real system as precisely as possible. The second goal is to develop this simulation model into a user-friendly tool that one could use to find an “optimal” or “best” product batch schedule for a one year time period. Such a batch schedule could change dynamically as perturbations occur during operation that influence the behaviour of the entire system. The result of the simulation, the ‘best’ batch schedule is the one that minimizes the operational costs in the system. The costs involved in the simulation are inventory costs, interface costs, pumping costs, and penalty costs assigned to any unforeseen situations. The key factor to determine the performance of the simulation model is the way time is represented. In our model an event based discrete time representation is selected as most appropriate for our purposes. This means that the time horizon is divided into intervals of unequal lengths based on events that change the state of the system. These events are the arrival/departure of the tanker ships, the openings and closures of loading/unloading valves of storage tanks at both terminals, and the arrivals/departures of trains/trucks at the Delivery Terminal. In the feasibility study we analyse the system’s operational performance with different Head Terminal storage capacity configurations. For these alternative configurations we evaluated the effect of different tanker ship delay magnitudes on the number of critical events and product interfaces generated, on the duration of pipeline stoppages, the satisfaction of the product demand and on the operative costs. Based on the results and the bottlenecks identified, we propose modifications in the original setup.