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.

Lo sviluppo cooperativo del software

Studio degli strumenti Open Source usati per lo sviluppo cooperativo del software, delle loro possibili interazioni e di come esse facilitino lo sviluppo cooperativo.

La certificazione del software dispositivo medico: aspetti salienti della nuova normativa di riferimento e processo dell'analisi del rischio

Il testo documenta due aspetti importanti della certficazione del software DM come la conoscenza della normativa 93/42 e il processo di gestione del rischio. Entrambi fondamentali per valutare la sicurezza di tali dispositivi.

Dispersione di sostanze odorigene nell'atmosfera e modellizzazione mediante software dedicato (un'applicazione del software LAPMOD)

Gli odori rappresentano uno degli elementi di disturbo che la popolazione avverte maggiormente e, anche nel caso in cui non siano associati a sostanze tossiche, sono causa di conflitti e di intolleranza, sia nei confronti delle aziende che li diffondono nel territorio, sia nella scelta del sito di localizzazione di nuovi impianti. La valutazione del disturbo olfattivo e la sua regolamentazione (esistono linee guida, ma non una legislazione di riferimento) rappresentano aspetti caratterizzati da elevata complessità, dal momento che l’inquinamento olfattivo è strettamente associato alla percezione umana. Nella tesi vengono valutate le emissioni odorigene e le relative immissioni, dovute ad un comparto per la gestione integrata dei rifiuti. Per caratterizzare le emissioni sono stati prelevati dei campioni di aria presso le principali sorgenti individuate e quantificate utilizzando la tecnica dell’olfattometria dinamica. Una volta caratterizzate le sorgenti, i dati di emissione ottenuti dalla campagna di misura e dall’analisi olfattometrica sono stati utilizzati come dati di input del modello LAPMOD (LAgrangian Particle MODel). LAPMOD è stato implementato con un modulo specifico per la determinazione delle concentrazioni massime orarie che utilizza un peak-to-mean variabile nel tempo, a differenza di altri modelli che usano un valore costante per la determinazione. Dall'elaborazione dei dati è emerso che, utilizzando il modulo specifico per gli odori, le concentrazioni come 98° percentile riferite al giorno tipico hanno un andamento opposto rispetto all’uso di un peak-to-mean costante. Dal confronto della simulazione in cui le emissioni sono indipendenti dalla variazione della portata di odore in funzione della velocità del vento, con quella che invece simula tale dipendenza (nelle sorgenti che presentano paratie laterali e tettoia) è emerso che la simulazione che mitiga completamente l’effetto del vento è più coerente con la realtà.

Creación del OPAC de la Biblioteca Conjunta de la FCAyF-FCV, UNLP : Implementación del software Koha-UNLP

En el presente trabajo se exponen las condiciones de la creación de la única unidad de información para dos Unidades Académicas dentro de la UNLP -la Biblioteca Conjunta de Facultad de Ciencias Agrarias y Forestales y de la Facultad de Ciencias Veterinarias- y cómo esta situación influyó directamente en la conformación del OPAC de la Biblioteca Conjunta en su reconversión al sistema de gestión de bibliotecas Koha-UNLP. Dado que Bienes Patrimoniales requiere que se mantenga el inventario de cadabiblioteca origen, se tuvo que implementar una codificación para asignar losinventarios. Ya que Koha-UNLP genera los inventarios en forma automática, en nuestrocaso decidimos completar manualmente el campo "código de barras", para así poder agregar al número de inventario y la codificación correspondiente a cada Facultad. Dicha codificación es la que dio el CAICYT, DAG (Agrarias/Forestales), DVE (Veterinaria). De esta manera se diferencian los fondos bibliográficos de las distintas facultades, y a su vez el fondo completo lleva la identificación dada por nosotros de Biblioteca Conjunta (DAV) para facilitar la circulación de los libros. Al quedar identificada la Biblioteca Conjunta con la sigla DAV, se pueden realizar movimientos en las colecciones (DAG, DVE) simultáneamente, sin importar a qué Unidad Académica pertenezcan los usuarios, y sin tener que entrar y salir del sistema KOHAUNLP para realizar las transacciones del Área de Circulación.

Creación del OPAC de la Biblioteca Conjunta de la FCAyF-FCV, UNLP : Implementación del software Koha-UNLP

En el presente trabajo se exponen las condiciones de la creación de la única unidad de información para dos Unidades Académicas dentro de la UNLP -la Biblioteca Conjunta de Facultad de Ciencias Agrarias y Forestales y de la Facultad de Ciencias Veterinarias- y cómo esta situación influyó directamente en la conformación del OPAC de la Biblioteca Conjunta en su reconversión al sistema de gestión de bibliotecas Koha-UNLP. Dado que Bienes Patrimoniales requiere que se mantenga el inventario de cadabiblioteca origen, se tuvo que implementar una codificación para asignar losinventarios. Ya que Koha-UNLP genera los inventarios en forma automática, en nuestrocaso decidimos completar manualmente el campo "código de barras", para así poder agregar al número de inventario y la codificación correspondiente a cada Facultad. Dicha codificación es la que dio el CAICYT, DAG (Agrarias/Forestales), DVE (Veterinaria). De esta manera se diferencian los fondos bibliográficos de las distintas facultades, y a su vez el fondo completo lleva la identificación dada por nosotros de Biblioteca Conjunta (DAV) para facilitar la circulación de los libros. Al quedar identificada la Biblioteca Conjunta con la sigla DAV, se pueden realizar movimientos en las colecciones (DAG, DVE) simultáneamente, sin importar a qué Unidad Académica pertenezcan los usuarios, y sin tener que entrar y salir del sistema KOHAUNLP para realizar las transacciones del Área de Circulación.

Creación del OPAC de la Biblioteca Conjunta de la FCAyF-FCV, UNLP : Implementación del software Koha-UNLP

En el presente trabajo se exponen las condiciones de la creación de la única unidad de información para dos Unidades Académicas dentro de la UNLP -la Biblioteca Conjunta de Facultad de Ciencias Agrarias y Forestales y de la Facultad de Ciencias Veterinarias- y cómo esta situación influyó directamente en la conformación del OPAC de la Biblioteca Conjunta en su reconversión al sistema de gestión de bibliotecas Koha-UNLP. Dado que Bienes Patrimoniales requiere que se mantenga el inventario de cadabiblioteca origen, se tuvo que implementar una codificación para asignar losinventarios. Ya que Koha-UNLP genera los inventarios en forma automática, en nuestrocaso decidimos completar manualmente el campo "código de barras", para así poder agregar al número de inventario y la codificación correspondiente a cada Facultad. Dicha codificación es la que dio el CAICYT, DAG (Agrarias/Forestales), DVE (Veterinaria). De esta manera se diferencian los fondos bibliográficos de las distintas facultades, y a su vez el fondo completo lleva la identificación dada por nosotros de Biblioteca Conjunta (DAV) para facilitar la circulación de los libros. Al quedar identificada la Biblioteca Conjunta con la sigla DAV, se pueden realizar movimientos en las colecciones (DAG, DVE) simultáneamente, sin importar a qué Unidad Académica pertenezcan los usuarios, y sin tener que entrar y salir del sistema KOHAUNLP para realizar las transacciones del Área de Circulación.