Analisi e sviluppo di strumenti performance-aware per la migrazione cloud enterprise

Questa tesi affronta il tema dell'analisi della migrazione verso un ambiente cloud enterprise, con considerazioni sui costi e le performance rispetto agli ambienti di origine

Tecniche di ottimizzazione del software per sistemi su singolo chip per applicazioni di Nomadic Computing

I moderni sistemi embedded sono equipaggiati con risorse hardware che consentono l’esecuzione di applicazioni molto complesse come il decoding audio e video. La progettazione di simili sistemi deve soddisfare due esigenze opposte. Da un lato è necessario fornire un elevato potenziale computazionale, dall’altro bisogna rispettare dei vincoli stringenti riguardo il consumo di energia. Uno dei trend più diffusi per rispondere a queste esigenze opposte è quello di integrare su uno stesso chip un numero elevato di processori caratterizzati da un design semplificato e da bassi consumi. Tuttavia, per sfruttare effettivamente il potenziale computazionale offerto da una batteria di processoriè necessario rivisitare pesantemente le metodologie di sviluppo delle applicazioni. Con l’avvento dei sistemi multi-processore su singolo chip (MPSoC) il parallel programming si è diffuso largamente anche in ambito embedded. Tuttavia, i progressi nel campo della programmazione parallela non hanno mantenuto il passo con la capacità di integrare hardware parallelo su un singolo chip. Oltre all’introduzione di multipli processori, la necessità di ridurre i consumi degli MPSoC comporta altre soluzioni architetturali che hanno l’effetto diretto di complicare lo sviluppo delle applicazioni. Il design del sottosistema di memoria, in particolare, è un problema critico. Integrare sul chip dei banchi di memoria consente dei tempi d’accesso molto brevi e dei consumi molto contenuti. Sfortunatamente, la quantità di memoria on-chip che può essere integrata in un MPSoC è molto limitata. Per questo motivo è necessario aggiungere dei banchi di memoria off-chip, che hanno una capacità molto maggiore, come maggiori sono i consumi e i tempi d’accesso. La maggior parte degli MPSoC attualmente in commercio destina una parte del budget di area all’implementazione di memorie cache e/o scratchpad. Le scratchpad (SPM) sono spesso preferite alle cache nei sistemi MPSoC embedded, per motivi di maggiore predicibilità, minore occupazione d’area e – soprattutto – minori consumi. Per contro, mentre l’uso delle cache è completamente trasparente al programmatore, le SPM devono essere esplicitamente gestite dall’applicazione. Esporre l’organizzazione della gerarchia di memoria ll’applicazione consente di sfruttarne in maniera efficiente i vantaggi (ridotti tempi d’accesso e consumi). Per contro, per ottenere questi benefici è necessario scrivere le applicazioni in maniera tale che i dati vengano partizionati e allocati sulle varie memorie in maniera opportuna. L’onere di questo compito complesso ricade ovviamente sul programmatore. Questo scenario descrive bene l’esigenza di modelli di programmazione e strumenti di supporto che semplifichino lo sviluppo di applicazioni parallele. In questa tesi viene presentato un framework per lo sviluppo di software per MPSoC embedded basato su OpenMP. OpenMP è uno standard di fatto per la programmazione di multiprocessori con memoria shared, caratterizzato da un semplice approccio alla parallelizzazione tramite annotazioni (direttive per il compilatore). La sua interfaccia di programmazione consente di esprimere in maniera naturale e molto efficiente il parallelismo a livello di loop, molto diffuso tra le applicazioni embedded di tipo signal processing e multimedia. OpenMP costituisce un ottimo punto di partenza per la definizione di un modello di programmazione per MPSoC, soprattutto per la sua semplicità d’uso. D’altra parte, per sfruttare in maniera efficiente il potenziale computazionale di un MPSoC è necessario rivisitare profondamente l’implementazione del supporto OpenMP sia nel compilatore che nell’ambiente di supporto a runtime. Tutti i costrutti per gestire il parallelismo, la suddivisione del lavoro e la sincronizzazione inter-processore comportano un costo in termini di overhead che deve essere minimizzato per non comprometterre i vantaggi della parallelizzazione. Questo può essere ottenuto soltanto tramite una accurata analisi delle caratteristiche hardware e l’individuazione dei potenziali colli di bottiglia nell’architettura. Una implementazione del task management, della sincronizzazione a barriera e della condivisione dei dati che sfrutti efficientemente le risorse hardware consente di ottenere elevate performance e scalabilità. La condivisione dei dati, nel modello OpenMP, merita particolare attenzione. In un modello a memoria condivisa le strutture dati (array, matrici) accedute dal programma sono fisicamente allocate su una unica risorsa di memoria raggiungibile da tutti i processori. Al crescere del numero di processori in un sistema, l’accesso concorrente ad una singola risorsa di memoria costituisce un evidente collo di bottiglia. Per alleviare la pressione sulle memorie e sul sistema di connessione vengono da noi studiate e proposte delle tecniche di partizionamento delle strutture dati. Queste tecniche richiedono che una singola entità di tipo array venga trattata nel programma come l’insieme di tanti sotto-array, ciascuno dei quali può essere fisicamente allocato su una risorsa di memoria differente. Dal punto di vista del programma, indirizzare un array partizionato richiede che ad ogni accesso vengano eseguite delle istruzioni per ri-calcolare l’indirizzo fisico di destinazione. Questo è chiaramente un compito lungo, complesso e soggetto ad errori. Per questo motivo, le nostre tecniche di partizionamento sono state integrate nella l’interfaccia di programmazione di OpenMP, che è stata significativamente estesa. Specificamente, delle nuove direttive e clausole consentono al programmatore di annotare i dati di tipo array che si vuole partizionare e allocare in maniera distribuita sulla gerarchia di memoria. Sono stati inoltre sviluppati degli strumenti di supporto che consentono di raccogliere informazioni di profiling sul pattern di accesso agli array. Queste informazioni vengono sfruttate dal nostro compilatore per allocare le partizioni sulle varie risorse di memoria rispettando una relazione di affinità tra il task e i dati. Più precisamente, i passi di allocazione nel nostro compilatore assegnano una determinata partizione alla memoria scratchpad locale al processore che ospita il task che effettua il numero maggiore di accessi alla stessa.

Utilizzo del Software OpenStack per la realizzazione di Piattaforme "Cloud"

Il Cloud computing è probabilmente l'argomento attualmente più dibattuto nel mondo dell'Information and Communication Technology (ICT). La diffusione di questo nuovo modo di concepire l'erogazione di servizi IT, è l'evoluzione di una serie di tecnologie che stanno rivoluzionando le modalit à in cui le organizzazioni costruiscono le proprie infrastrutture informatiche. I vantaggi che derivano dall'utilizzo di infrastrutture di Cloud Computing sono ad esempio un maggiore controllo sui servizi, sulla struttura dei costi e sugli asset impiegati. I costi sono proporzionati all'eettivo uso dei servizi (pay-per-use), evitando dunque gli sprechi e rendendo più efficiente il sistema di sourcing. Diverse aziende hanno già cominciato a provare alcuni servizi cloud e molte altre stanno valutando l'inizio di un simile percorso. La prima organizzazione a fornire una piattaforma di cloud computing fu Amazon, grazie al suo Elastic Computer Cloud (EC2). Nel luglio del 2010 nasce OpenStack, un progetto open-source creato dalla fusione dei codici realizzati dall'agenzia governativa della Nasa[10] e dell'azienda statunitense di hosting Rackspace. Il software realizzato svolge le stesse funzioni di quello di Amazon, a differenza di questo, però, è stato rilasciato con licenza Apache, quindi nessuna restrizione di utilizzo e di implementazione. Oggi il progetto Openstack vanta di numerose aziende partner come Dell, HP, IBM, Cisco, e Microsoft. L'obiettivo del presente elaborato è quello di comprendere ed analizzare il funzionamento del software OpenStack. Il fine principale è quello di familiarizzare con i diversi componenti di cui è costituito e di concepire come essi interagiscono fra loro, per poter costruire infrastrutture cloud del tipo Infrastructure as a service (IaaS). Il lettore si troverà di fronte all'esposizione degli argomenti organizzati nei seguenti capitoli. Nel primo capitolo si introduce la definizione di cloud computing, trattandone le principali caratteristiche, si descrivono poi, i diversi modelli di servizio e di distribuzione, delineando vantaggi e svantaggi che ne derivano. Nel secondo capitolo due si parla di una delle tecnologie impiegate per la realizzazione di infrastrutture di cloud computing, la virtualizzazione. Vengono trattate le varie forme e tipologie di virtualizzazione. Nel terzo capitolo si analizza e descrive in dettaglio il funzionamento del progetto OpenStack. Per ogni componente del software, viene illustrata l'architettura, corredata di schemi, ed il relativo meccanismo. Il quarto capitolo rappresenta la parte relativa all'installazione del software e alla configurazione dello stesso. Inoltre si espongono alcuni test effettuati sulla macchina in cui è stato installato il software. Infine nel quinto capitolo si trattano le conclusioni con le considerazioni sugli obiettivi raggiunti e sulle caratteristiche del software preso in esame.

Clinical Data Mining: Traumatic Brain Injury

Il trauma cranico é tra le piú importanti patologie traumatiche. Ogni anno 250 pazienti ogni 100.000 abitanti vengono ricoverati in Italia per un trauma cranico. La mortalitá é di circa 17 casi per 100.000 abitanti per anno. L’Italia si trova in piena “media” Europea considerando l’incidenza media in Europa di 232 casi per 100.000 abitanti ed una mortalitá di 15 casi per 100.000 abitanti. Degli studi hanno indicato come una terapia anticoagulante é uno dei principali fattori di rischio di evolutiviá di una lesione emorragica. Al contrario della terapia anticoagulante, il rischio emorragico correlato ad una terapia antiaggregante é a tutt’oggi ancora in fase di verifica. Il problema risulta rilevante in particolare nella popolazione occidentale in quanto l’impiego degli antiaggreganti é progressivamente sempre piú diffuso. Questo per la politica di prevenzione sostenuta dalle linee guida nazionali e internazionali in termini di prevenzione del rischio cardiovascolare, in particolare nelle fasce di popolazione di etá piú avanzata. Per la prima volta, é stato dimostrato all’ospedale di Forlí[1], su una casistica sufficientemente ampia, che la terapia cronica con antiaggreganti, per la preven- zione del rischio cardiovascolare, puó rivelarsi un significativo fattore di rischio di complicanze emorragiche in un soggetto con trauma cranico, anche di grado lieve. L’ospedale per approfondire e convalidare i risultati della ricerca ha condotto, nell’anno 2009, una nuova indagine. La nuova indagine ha coinvolto oltre l’ospedale di Forlí altri trentuno centri ospedalieri italiani. Questo lavoro di ricerca vuole, insieme ai ricercatori dell’ospedale di Forlí, verificare: “se una terapia con antiaggreganti influenzi l’evolutivitá, in senso peggiorativo, di una lesione emorragica conseguente a trauma cranico lieve - moderato - severo in un soggetto adulto”, grazie ai dati raccolti dai centri ospedalieri nel 2009. Il documento é strutturato in due parti. La prima parte piú teorica, vuole fissare i concetti chiave riguardanti il contesto della ricerca e la metodologia usata per analizzare i dati. Mentre, la seconda parte piú pratica, vuole illustrare il lavoro fatto per rispondere al quesito della ricerca. La prima parte é composta da due capitoli, che sono: • Il capitolo 1: dove sono descritti i seguenti concetti: cos’é un trauma cra- nico, cos’é un farmaco di tipo anticoagulante e cos’é un farmaco di tipo antiaggregante; • Il capitolo 2: dove é descritto cos’é il Data Mining e quali tecniche sono state usate per analizzare i dati. La seconda parte é composta da quattro capitoli, che sono: • Il capitolo 3: dove sono state descritte: la struttura dei dati raccolti dai trentadue centri ospedalieri, la fase di pre-processing e trasformazione dei dati. Inoltre in questo capitolo sono descritti anche gli strumenti utilizzati per analizzare i dati; • Il capitolo 4: dove é stato descritto come é stata eseguita l’analisi esplorativa dei dati. • Il capitolo 5: dove sono descritte le analisi svolte sui dati e soprattutto i risultati che le analisi, grazie alle tecniche di Data Mining, hanno prodotto per rispondere al quesito della ricerca; • Il capitolo 6: dove sono descritte le conclusioni della ricerca. Per una maggiore comprensione del lavoro sono state aggiunte due appendici. La prima tratta del software per data mining Weka, utilizzato per effettuare le analisi. Mentre, la seconda tratta dell’implementazione dei metodi per la creazione degli alberi decisionali.

Towards model driven software development for Arduino platforms: a DSL and automatic code generation

La tesi ha lo scopo di esplorare la produzione di sistemi software per Embedded Systems mediante l'utilizzo di tecniche relative al mondo del Model Driven Software Development. La fase più importante dello sviluppo sarà la definizione di un Meta-Modello che caratterizza i concetti fondamentali relativi agli embedded systems. Tale modello cercherà di astrarre dalla particolare piattaforma utilizzata ed individuare quali astrazioni caratterizzano il mondo degli embedded systems in generale. Tale meta-modello sarà quindi di tipo platform-independent. Per la generazione automatica di codice è stata adottata una piattaforma di riferimento, cioè Arduino. Arduino è un sistema embedded che si sta sempre più affermando perché coniuga un buon livello di performance ed un prezzo relativamente basso. Tale piattaforma permette lo sviluppo di sistemi special purpose che utilizzano sensori ed attuatori di vario genere, facilmente connessi ai pin messi a disposizione. Il meta-modello definito è un'istanza del meta-metamodello MOF, definito formalmente dall'organizzazione OMG. Questo permette allo sviluppatore di pensare ad un sistema sotto forma di modello, istanza del meta-modello definito. Un meta-modello può essere considerato anche come la sintassi astratta di un linguaggio, quindi può essere definito da un insieme di regole EBNF. La tecnologia utilizzata per la definizione del meta-modello è stata Xtext: un framework che permette la scrittura di regole EBNF e che genera automaticamente il modello Ecore associato al meta-modello definito. Ecore è l'implementazione di EMOF in ambiente Eclipse. Xtext genera inoltre dei plugin che permettono di avere un editor guidato dalla sintassi, definita nel meta-modello. La generazione automatica di codice è stata realizzata usando il linguaggio Xtend2. Tale linguaggio permette di esplorare l'Abstract Syntax Tree generato dalla traduzione del modello in Ecore e di generare tutti i file di codice necessari. Il codice generato fornisce praticamente tutta la schematic part dell'applicazione, mentre lascia all'application designer lo sviluppo della business logic. Dopo la definizione del meta-modello di un sistema embedded, il livello di astrazione è stato spostato più in alto, andando verso la definizione della parte di meta-modello relativa all'interazione di un sistema embedded con altri sistemi. Ci si è quindi spostati verso un ottica di Sistema, inteso come insieme di sistemi concentrati che interagiscono. Tale difinizione viene fatta dal punto di vista del sistema concentrato di cui si sta definendo il modello. Nella tesi viene inoltre introdotto un caso di studio che, anche se abbastanza semplice, fornisce un esempio ed un tutorial allo sviluppo di applicazioni mediante l'uso del meta-modello. Ci permette inoltre di notare come il compito dell'application designer diventi piuttosto semplice ed immediato, sempre se basato su una buona analisi del problema. I risultati ottenuti sono stati di buona qualità ed il meta-modello viene tradotto in codice che funziona correttamente.

Lifecycle analysis for surgery instruments at a hospital

Gli strumenti chirurgici sono importanti “devices” utilizzati come supporto indi-spensabile nella cura di pazienti negli ospedali. Essi sono caratterizzati da un intero ciclo di vita che inizia convenzionalmente nello “Store”, dove gli strumenti sterilizzati sono prelevati per essere utilizzati all’interno delle sale operatorie, e termina nuovamente nello “Store”, dove gli strumenti vengono immagazzinati per essere riutilizzati in un nuovo ciclo. Può accadere che le singole fasi del ciclo subiscano ritardi rispetto ai tempi previ-sti, non assicurando, pertanto, nelle sale operatorie, il corretto numero degli stru-menti secondo i tempi programmati. Il progetto che vado ad illustrare ha come obiettivo l’ottimizzazione del ciclo degli strumenti chirurgici all’interno di un nuovo ospedale, applicando i principi della Lean philosophy ed in particolare i metodi: “Poke Yoke, 5S e tracciabilità”. Per raggiungere tale scopo, il progetto è stato articolato come segue. In un primo momento si è osservato l’intero ciclo di vita degli strumenti nei due principali ospedali di Copenhagen (Hervel e Gentofte hospital). Ciò ha permesso di rilevare gli steps del ciclo, nonché di riscontrare sul campo i principali problemi relativi al ciclo stesso quali: bassa flessiblità, decentramento dei differenti reparti di cleaning e di store rispetto alle operation theatres ed un problema nel solleva-mento degli strumenti pesanti. Raccolte le dovute informazioni, si è passati alla fase sperimentale, in cui sono stati mappati due cicli di vita differenti, utilizzando tre strumenti di analisi: • Idef0 che consente di avere una visione gerarchica del ciclo; • Value stream Mapping che permette di evidenziare i principali sprechi del ciclo; • Simulator Tecnomatix che favorisce un punto di vista dinamico dell’analisi. Il primo ciclo mappato è stato creato con il solo scopo di mettere in risalto gli steps del ciclo e alcuni problemi rincontrati all’interno degli ospedali visitati. Il secondo ciclo, invece, è stato creato in ottica Lean al fine di risolvere alcuni tra i principali problemi riscontrati nei due ospedali e ottimizzare il primo ciclo. Si ricordi, infatti, che nel secondo ciclo le principali innovazioni introdotte sono state: l’utilizzo del Barcode e Rfid Tag per identificare e tracciare la posizione degli items, l’uso di un “Automatic and Retrievial Store” per minimizzare i tempi di inserimento e prelievo degli items e infine l’utilizzo di tre tipologie di carrello, per consentire un flessibile servizio di cura. Inoltre sono state proposte delle solu-zioni “Poke-Yoke” per risolvere alcuni problemi manuali degli ospedali. Per evidenziare il vantaggio del secondo ciclo di strumenti, è stato preso in consi-derazione il parametro “Lead time”e le due simulazioni, precedentemente create, sono state confrontate. Tale confronto ha evidenziato una radicale riduzione dei tempi (nonché dei costi associati) della nuova soluzione rispetto alla prima. Alla presente segue la trattazione in lingua inglese degli argomenti oggetto di ri-cerca. Buona lettura.