PROGETTAZIONE E SVILUPPO DI SERVIZI DI GESTIONE PER UN LABORATORIO REMOTO DI ELETTRONICA

Transcript

1 Universitá degli Studi di Genova Facoltá di Ingegneria Dipartimento di Ingegneria Biofisica ed Elettronica Tesi di Laurea triennale in Ingegneria Elettronica PROGETTAZIONE E SVILUPPO DI SERVIZI DI GESTIONE PER UN LABORATORIO REMOTO DI ELETTRONICA Relatori: Correlatore: Allievo: Anna Marina Scapolla Giancarlo Parodi Paolo Buschiazzo Federico Picchi Genova, 30 Settembre 2011 Anno Accademico

2 2 Dichiarazione del Relatore Alla Commissione di Laurea e di Diploma Alla Commissione Tirocini e Tesi Sottopongo la tesi redatta dallo studente Federico Picchi dal titolo PRO- GETTAZIONE E SVILUPPO DI SERVIZI DI GESTIONE PER UN LA- BORATORIO REMOTO DI ELETTRONICA. Ho esaminato, nella forma e nel contenuto, la versione finale di questo elaborato scritto e propongo che la tesi sia valutata positivamente assegnando i corrispondenti crediti formativi. I Relatori Accademici Anna Marina Scapolla Giancarlo Parodi

3 3 Ringraziamenti Credo sia giusto precedere questa tesi con alcuni ringraziamenti alle persone che maggiormente hanno contribuito a questa mia laurea. Desidero ringraziare la Professoressa Anna Marina Scapolla, sempre disponibile e presente, soprattutto in quest ultimo periodo per aiutarmi a concludere al meglio il lavoro. Grazie a Paolo, per tutti i consigli e la collaborazione fondamentale che mi ha fornito durante il lavoro di laboratorio. Un enorme grazie va a tutta la mia famiglia, soprattutto ai miei genitori, che mi hanno seguito, incoraggiato e sopportato in questi anni di studi e che, a quanto pare, dovranno farlo ancora! Grazie infine a tutti i miei compagni di corso, per i momenti passati insieme a lezione, di svago, le partite di calcetto ecc. Un pensiero particolare lo dedico a Max e alla Vale che mi hanno aiutato ogni volta ne ho avuto bisogno e anche di piú. Federico

4 4 Sommario Lo sviluppo di nuove tecnologie nel settore dell informatica e delle telecomunicazioni ha prodotto notevoli cambiamenti nei metodi di insegnamento e messo a disposizione nuove risorse. Se fino a qualche anno fa, era difficile disporre di laboratori ben attrezzati e in numero sufficiente a coprire le esigenze della didattica e della ricerca, ora studenti e ricercatori possono accedere via Internet a laboratori remoti e utilizzare strumenti di simulazione e strumentazione reale a distanza. In questo modo, le universitá possono migliorare la qualitá della formazione, ridurre i costi per l acquisto della strumentazione e la gestione dei laboratori, offrire ai ricercatori un valido mezzo di collaborazione con colleghi di altri enti. Il Dipartimento di Ingegneria Biofisica ed Elettronica dell Universitá di Genova ha realizzato un proprio laboratorio remoto per la formazione di base nel campo dell elettronica analogica e digitale. Il laboratorio, denominato ISILab (Internet Shared Instrumentation Laboratory), é utilizzato dal Corso di Studi di Ingegneria Elettronica e collocato presso il laboratorio Electronic Systems and Networking Group (ESNG). Consente di effettuare esperimenti su circuiti analogici e digitali ed offre un ambiente per la scrittura e il test di programmi in codice C per schede DSP. Un laboratorio remoto é un sistema complesso che comporta un lavoro notevole di progettazione, allestimento e manutenzione. Questa tesi ha trat-

5 5 tato la preparazione di alcuni strumenti destinati ai gestori del laboratorio per il controllo e l aggiornamento delle risorse hardware e software che sono alla base degli esperimenti online. Gli obiettivi sono facilitare la manutenzione del sistema e fornire supporto all aggiornamento e allo sviluppo. La tesi è articolata come segue: il primo capitolo è un introduzione sui laboratori remoti; il secondo capitolo tratta ISILab e ne descrive lo stato attuale, architettura e funzionamento; segue la presentazione del lavoro svolto nella tesi, ovvero dei servizi di gestione che sono stati aggiunti e infine si accennano gli sviluppi futuri che potrebbero ancora migliorare il laboratorio.

6 6 Abstract Design and development of management services for a remote laboratory on electronic The development of new information and communication technology has produced significant changes in teaching methods and has made available new resources. Until just a few years ago, it was difficult to have well-equipped laboratories in number sufficient to cover the needs of teaching and research, now students and researchers can access via the Internet to remote laboratories and use simulation tools and real instruments remotely. In this way, universities can improve the quality of training, reduce costs for the purchase of equipment and the lab management, provide researchers with a valuable means of collaboration with colleagues from other institutions. The Department of Biophysical and Electronic Engineering of the University of Genoa has created its own remote laboratory for basic training in analog and digital electronics. The lab, which is named ISILab (Internet Shared Instrumentation Laboratory), is used by courses of the Electronic Engineering Curriculum and is placed in the Electronic Systems and Networking Group (ESNG) laboratory. It allows running experiments on analog and digital circuits and provides an environment for writing and testing C code programs for DSP boards. A remote laboratory is a complex system that involves a remarkable job of

7 7 design, construction and maintenance. This thesis deals with the development of tools to control and update the hardware and software resources that are the basis of lab experiments. The objectives are to facilitate the system maintenance and to support, updating and development. The thesis is structured as follows: the first chapter introduces the topic of remote laboratories, the second chapter describes the current architecture and functionality of ISILab, the presentation of the work done during the thesis follows and finally a mention to future developments, which may further improve the laboratory, is reported.

8 Indice 1 Introduzione ai laboratori remoti Introduzione Stato dell arte Laboratori remoti per Elettronica e Microelettronica Laboratori remoti per Elettronica di potenza e controllo Laboratori remoti per l Automazione Laboratori remoti integrati con mondi virtuali Funzionalitá e servizi ISILab Presentazione del laboratorio Architettura del laboratorio circuiti analogici e digitali Sviluppo tramite la tecnologia web-service Architettura laboratorio DSP Home Page ISIlab Gestione del laboratorio Home page

9 INDICE Archive of pre-loaded projects Experiment Type Lab Server Engine Actions Le actions e il Lab Server Engine Available Resources Serializzazione e deserializzazione XML Conclusioni 56 Bibliografia 57

10 Capitolo 1 Introduzione ai laboratori remoti In questo capitolo verranno descritte le principali caratteristiche dei laboratori remoti. In particolare si analizzeranno tipologie, obiettivi e funzionalitá a disposizione dei diversi utenti. 1.1 Introduzione Un laboratorio remoto puó essere definito come un sistema hardware/software che consente agli utenti di interagire con processi fisici dislocati in altri luoghi attraverso la rete Internet (od altri tipi di reti). Con l avvento dei primi laboratori remoti, si é iniziato ad accorciare il divario tra lo studio teorico dello studente in classe e la varietá di problemi reali che si incontreranno nel momento del confronto vero e proprio con le apparecchiature. In molte materie scientifiche la teoria imparata a lezione ha ben poco significato se 10

11 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 11 non supportata da un attivitá pratica; occorre confrontarsi con dati imprecisi, inefficienze degli strumenti e complessitá nel setup durante i primi utilizzi. I laboratori tradizionali spesso non sono in grado di soddisfare tutte le esigenze di didattica e ricerca perchè limitati nel numero, nelle attrezzature e nel personale di supporto. Ecco quindi che il laboratorio remoto coniuga la risoluzione di alcuni di questi problemi e la possibilitá di dare a studenti e docenti uno strumento molto potente e versatile. Le Universitá o le istituzioni che si sono dotate di laboratori remoti stanno ora operando per la creazione di reti di laboratori. Da un punto di vista economico possiamo immaginare due universitá che decidano di creare una rete comune dividendosi le spese di acquisto di materiali e attrezzature. In qualunque momento tramite il laboratorio remoto studenti, ricercatori, professori possono usufruire sia di strumentazione presente fisicamente nella loro struttura sia di uno strumento a chilometri di distanza senza doversi muovere. Ma non vi sono solo vantaggi economici; é possibile infatti che un esperimento o determinate prove siano pericolose per persone, cose o dati con i quali si tratta; evitando il contatto diretto con lo strumento si abbattono rischi di danneggiamenti e di incidenti che potrebbero comportare grossi problemi per l Universitá. Altro aspetto molto importante é quello delle persone con disabilitá; i laboratori remoti offrono la possibilitá di utilizzare in modo comodo strumenti magari difficilmente raggiungibili (lo strumento potrebbe dover essere posizionato in un punto di difficile accesso da una persona con disabilitá oppure in caso di utilizzo di piú attrezzature potrebbe essere necessario spostarsi frequentemente in luoghi diversi). Dal punto di vista didattico l esperimento effettuato da un docente tramite laboratorio remoto puó essere reso visibile a tutti gli studenti

12 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 12 sia presenti in quel momento che riprodotto a distanza tramite collegamento audiovisivo. 1.2 Stato dell arte Negli ultimi dieci anni il numero di istituzioni che hanno progettato laboratori remoti è aumentato velocemente, di pari passo con una maggiore diversificazione di approcci e ambiti di utilizzo. Un laboratorio di questo tipo é adatto ad essere utilizzato in tutte le aree scientifiche di ricerca. Sono stati realizzati laboratori per l elettronica, la fisica, l automatica e la robotica.[1] Possiamo generalizzare ancora di piú affermando che possono essere utilizzati in qualunque ambito sia previsto l utilizzo di strumentazione controllabile tramite computer. L ambito di utilizzo é solo uno dei metodi di classificazione dei laboratori remoti. Gli sviluppatori sceglieranno come strutturarlo oltre che in base a questo criterio anche al tipo di esperimenti offerti. La maggior parte dei laboratori remoti é basata su applicazioni client/server e sulle tecnologie web. La topologia puó essere classificata in due gruppi fondamentali: ˆ web-based applications; ˆ dedicated remote computer control applications; Queste ultime hanno il vantaggio di supportare interfacce potenti e di acquisire i vantaggi delle caratteristiche associate ai dispositivi utilizzati nel laboratorio. Per contro rispetto alle applicazioni web hanno una scarsa flessibilitá e portabilitá [2]. Un altro criterio che caratterizza i vari laboratori é

13 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 13 quello delle differenti tecnologie che possono essere utilizzate per la comunicazione fra livelli differenti (utente - server- risorse). Partendo dal livello piú basso, ovvero la comunicazione tra il server del laboratorio e la strumentazione, questa puó avvenire tramite le interfacce standard come la TCP-IP, RS- 232, IEEE-488 per esempio. Per quanto riguarda la connessione tra l interfaccia utente e il server individuiamo due tipi di soluzioni: basata su software installati sul computer utente tipo LabView, VEE o MATLAB/Simulink; oppure basata su linguaggi di programmazione general purpose come C, C++, basic o Python.[3] Laboratori remoti per Elettronica e Microelettronica Ll Universitá della Tecnologia di Darmstad ha recentemente sviluppato un laboratorio che offre la possibilità di eseguire simulazione su piattaforme FPGA (field-programmable gate-array) nei prototipi di cirguiti elettronici digitali. Questa realizzazione non consente solo di effettuare misure o esperimenti predefiniti ma consente allo studente di configurare completamente il sistema che ha progettato.[4] In Francia invece possiamo trovare il laboratorio del National Test Resource Center (CRTC) che consente il test di circuiti integrati utilizzando da remoto strumentazione per test industriali. In questo modo il Centro ha deciso, insieme al Commitee National pour la Formation en Microelectronique, di rispondere alla richiesta dell industria di formare laureati con maggiori competenze pratiche e ben integrati nelle problematiche reali.[5] Per quanto riguarda la Microelettronica un laboratorio remoto é stato svilup-

14 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 14 pato dall Universitá del Sud Australia. Esso consente agli studenti di testare i loro circuiti direttamente sugli strati di silicio tramite microscopi. Il vantaggio di questo approccio é che il sistema é completamente indipendente dal progetto del circuito e non richiede pre cablaggio.[6] Laboratori remoti per Elettronica di potenza e controllo I laboratori remoti relativi a questo ambito hanno recentemente subito un forte sviluppo con l aumento della richiesta delle energie alternative in particolare riguardo alla loro generazione e distribuzione. É il caso della Lunghwa University of Science and Technology che offre un ambiente di test configurabile dagli studenti tramite una interfaccia webbased. Il laboratorio, integrato con una piattaforma di e-learning, consente di progettare una grande varietá di convertitori e invertitori. [7] Il Center of Technologian Innovation in Static Converters aand Drives dell Univeristá della Catalogna ha invece sviluppato un laboratorio remoto incentrato sui PLC (programmable logic controller). Gli studenti necessitano solo della connessione ad internet per poter lavorare sia su esperimenti che su processi industriali reali.[8] Laboratori remoti per l Automazione In questo ambito abbiamo una realizzazione in Italia a cura del Politecnico di Milano che ha sviluppato il CrAutoLab. Questo laboratorio offre l accesso a due impianti principali, un impianto di controllo termico e un impianto di

15 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 15 controllo di velocitá. Utilizza la tecnologia web-server di LabVIEW tramite un browser e una comunicazione ad hoc che permette l accesso remoto in tempo reale al loop di controllo.[9] Sempre restando in Italia, l Automatic Control Telelab (ACT) dell Universitá di Siena consente agli studenti di progettare i loro controllori, scegliendoli da una lista precaricata e modificando remotamente i parametri tramite un ambiente MATLAB o Simulink. Tramite ACT gli utenti possono progettare controlli specifici e segnali di riferimento su un PC locale e, successivamente, caricarli sul server del laboratorio per testarli e verificarne le prestazioni. Consente inoltre l accesso a numerosi sistemi non lineari come il controllo di un motore in corrente alternata e un simulatore di elicottero Laboratori remoti integrati con mondi virtuali Questo percorso è stato sviluppato in particolar modo presso l Universitá di Deusto. L idea è quella di integrare il laboratorio remoto giá presente nell ateneo e il famoso mondo virtuale Second Life. Il laboratorio vero e proprio consente agli studenti di lavorare su esperimenti reali utilizzando schede FPGA, PIC e CPLD. L integrazione tra queste due realtá ha richiesto innanzitutto di acquistare uno spazio a pagamento all interno del mondo virtuale, dove poter effettuare le modifiche; successivamente il lavoro si é concentrato sulla parte grafica, ovvero la realizzazione di edifici, oggetti, parte testuale e comandi, sfruttando l editor 3D messo a disposizione da Second Life; infine i programmatori hanno dovuto adattare i codici al linguaggio degli script creato dal Linden Lab, per essere integrato in questo ambiente. Il risultato è SecondLab che sinteticamente funziona in questo modo: lo stu-

16 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 16 dente scrive il suo codice C relativo all esperimento che sta conducendo, lo compila e ne ottiene l equivalente esadecimale; a questo punto accede a Second Life utilizzando il suo avatar personale (comprensivo di nome, cognome e password) e si reca al SecondLab. Una volta entrato nel laboratorio, tramite alcuni comandi carica il file esadecimale di cui sopra e si posiziona davanti ad uno schermo che visualizza la sequenza di programmazione. Una volta finita questa procedura lascerá il laboratorio. Gli sviluppatori hanno finora individuato alcune difficoltá non facili da superare: tra queste la limitatezza del linguaggio di script, uno scarso numero di componenti disponibili per l interfaccia utente, restrizioni sulla memoria a disposizione e la mancanza di protocolli di comunicazione ad alto livello. [10] 1.3 Funzionalitá e servizi Un laboratorio remoto puó come abbiamo visto avere diverse finalitá, ambiti di utilizzo e utilizzatori. Nel nostro caso possiamo distinguere almeno tre categorie di utenti che avranno accesso al servizio. Il sistema riconoscerá, tramite il login, l identitá di chi richiede l accesso e gli consentirá di usufruire delle aree per cui ha i privilegi d accesso. In primo luogo l amministratore o gli amministratori del laboratorio. Stiamo quindi parlando dei tecnici e dei docenti che hanno la responsabilitá di sviluppare il laboratorio e le sue funzionalitá. Sono loro che decidono quali aree rendere visibili alle altre categorie di utenti, nascondendo le parti di amministrazione. Questa tipologia d utente ha accesso a tutti i contenuti

17 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 17 del laboratorio, puó creare, modificare, cancellare, contenuti del laboratorio (sempre inteso ad un livello alto e non di codice sorgente). Solitamente hanno la possibilitá di accedere ad una home page di amministrazione del sito oltre che a quella classica ad uso degli altri utenti con minor privilegi. Il lavoro degli amministratori é fondamentale per monitorare lo stato del laboratorio e per verificare che non vengano inavvertitamente causati danni o perdite di dati. Essi necessitano di strumenti per modificare i contenuti e monitorare lo stato delle apparecchiature collegate e dei processi in atto, delle potenzialitá a loro disposizione per sviluppi futuri del sistema. Per un tecnico sviluppatore per esempio é fondamentale verificare che il sistema riconosca e consenta l accesso a tutta la strumentazione; con semplici strumenti é possibile controllare il loro stato (collegato, non riconosciuto, disponibile, in uso da qualche utente) oltre a tutti i dati che riceve in quel momento in input ed in output. In questo modo é possibile risolvere tempestivamente eventuali problemi ma anche fornire piú indicazioni possibili in merito all utilizzo. Un interfaccia di amministrazione ben strutturata semplifica anche il passaggio di consegne per coloro che si avvicendano in questo ruolo. Piú persone nel tempo potranno entrare rapidamente nel sistema pur non avendolo progettato personalmente. Consideriamo ora le funzionalitá dedicate ai docenti; come possiamo immaginare queste saranno inferiori a quelle degli amministratori ma con possibilitá aggiuntive rispetto agli studenti. I professori potranno accedere ai contenuti del laboratorio, modificandoli o aggiungendone di nuovi, potranno ricevere materiale dagli studenti, verificando anche il loro operato, seguendo la traccia dei loro esperimenti. Il laboratorio infatti puó essere un valido sup-

18 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 18 porto nell apprendimento e nella pratica di ogni studente, che collegandosi ed eseguendo esperimenti puó svolgere un attivitá di approfondimento e di valutazione. Lavorando su simulazioni nella maggior parte dei casi, i docenti potranno chiedere agli allievi di esercitarsi preliminarmente, limitando i rischi che potrebbero derivare da un uso non corretto delle apparecchiature, nelle prime esperienze di laboratorio. Molto utile potrebbe anche essere nelle fasi iniziali, consentire agli studenti di imparare autonomamente le caratteristiche e le funzionalitá degli strumenti seguendo le descrizioni e le specifiche che gli amministratori o i docenti hanno inserito per ognuno di questi ed approfondendo autonomamente qualora il materiale non risulti sufficiente. Gli studenti a loro volta possono trarre numerosi benefici da questa nuova modalitá di apprendimento. Sono loro infatti che usufruiscono maggiormente della flessibilitá di questo strumento. In primo luogo la comoditá é nel poter accedere a questo metodo di apprendimento senza vincoli di orari e di luogo (si pensi per esempio agli studenti lavoratori). Non meno importante la possibilitá di fare pratica, aspetto fondamentale nell apprendimento delle materie ingegneristiche. Un esempio tipico puó essere il test di un circuito utilizzando un generatore di forme d onda ed un oscilloscopio. Tramite il laboratorio remoto è possibile impostare la strumentazione ed avere interfaccie virtuali dei dispositivi o, se il laboratorio ne é attrezzato, un flusso video tramite una webcam posta in direzione dei dispositivi utilizzati. Bisogna sottolineare che é comunque importante coniugare il lavoro tramite il laboratorio remoto con quello del laboratorio tradizionale. L apprezzamento per questo strumento da parte degli studenti é stato anche oggetto di studio di alcune Universitá

19 CAPITOLO 1. INTRODUZIONE AI LABORATORI REMOTI 19 in questi anni, con risultati sempre soddisfacenti e che hanno contribuito in molti casi a migliorare aspetti pratici che nei primi sviluppi non erano stati presi in considerazione. É il caso per esempio dell Universitá di Deusto [11] che ha monitorato sia il gradimento sia l incremento dell utilizzo di questo strumento da parte dei studenti. Grazie alle indicazioni via via raccolte negli anni questa e altre importanti Universitá hanno corretto alcune delle problematiche che erano sorte nelle prime realizzazioni.

20 Capitolo 2 ISILab Questo capitolo descrive il Laboratorio ISILab sviluppato dall Universitá di Genova. 2.1 Presentazione del laboratorio ISILab, é l acronimo di Internet Shared Instrumentation Lab; é un laboratorio remoto per la formazione nel settore dell elettronica. ISILab é il risultato di un progetto nato al DIBE (Dipartimento di Ingegneria Biofisica ed Elettronica) nel 1999, ed é disponibile all indirizzo [12] Pur essendo un progetto relativamente giovane, ISILab ha subito molte trasformazioni in questi anni. 20

21 CAPITOLO 2. ISILAB 21 Gi obbiettivi che hanno spinto docenti e ricercatori coinvolti nel progetto sono quelli giá presentati, ovvero eseguire esperimenti da remoto con strumentazione e circuiti reali, con diverse finalità in base alla tipologia di utente che ne usufruisce Architettura del laboratorio circuiti analogici e digitali Il laboratorio nelle sue prime realizzazioni comprendeva solamente dei circuiti analogici e digitali, ed é per questo che quando parliamo di strumentazione ci riferiamo a oscilloscopi ed a generatori di forme d onda (vedi fig. 2.1). I dispositivi in questione erano controllati da uno o piú server dedicati, detti RLS (Real Laboratory Server), sui quali era attiva un applicazione LabVIEW, (abbreviazione di Laboratory Virtual Instrumentation Engineering Workbench, l ambiente di sviluppo integrato per il linguaggio di programmazione visuale di National Instruments) e le richieste da parte dell utente sugli specifici esperimenti erano gestite da un web server centralizzato detto VLS (Virtual Laboratory Server), che connetteva gli esperimenti alle interfacce web dei client.[13] L interfaccia utente, nel primo prototipo del 2000, si basava su LabVIEW, come del resto il motore lato server; cosí facendo peró, si costringeva l utilizzatore ad installare sul proprio sistema il LabVIEW Run-Time Engine. Per migliorare questo aspetto e rendere piú accessibile il laboratorio si decise di passare ad una versione basata su Java. É molto piú frequente trovare una Java Virtual Machine installata sul computer dell utilizzatore rispetto al LabVIEW Run-Time. In questo modo le interfacce grafiche potevano

22 CAPITOLO 2. ISILAB 22 Figura 2.1: Architettura ISILab ora essere caricate piú facilmente. Inizialmente ogni esperimento necessitava di strumentazione propria, ma si progettó una soluzione che permettesse di utilizzare la stessa strumentazione per piú circuiti. Fu cosí che venne ideata ISIBoard (fig. 2.2), ovvero una scheda dedicata alla gestione di piccole schede-esperimento su cui erano installati i circuiti da utilizzare. Negli anni dal 2001 al 2007 continui aggiornamenti hanno portato ad una offerta di numerosi esperimenti di elettronica analogica e digitale. Il laboratorio gestisce la multiutenza e consente di utilizzare la stessa strumentazione per diversi esperimenti.

23 CAPITOLO 2. ISILAB 23 Figura 2.2: La scheda ISIBoard Sviluppo tramite la tecnologia web-service Recentemente l architettura del laboratorio é stata aggiornata sotto la spinta delle nuove tecnologie nel mondo delle applicazioni web. Dal 2009, si adotta un approccio completamente nuovo basato sull uso di web services[14]. Il W3C (World Wide Web Consortium), la principale organizzazione degli standard per il web, definisce un web service come un sistema software progettato per supportare l interazione tra macchine (computer) diverse tra di loro attraverso una rete. Un web service ha un interfaccia descritta in un formato comprensibile da ogni macchina, ovvero il WSDL (Web Services Description Language). Altri sistemi comunicano con il web service in modi conformi a questa sua descrizione usando messaggi SOAP, solitamente veicolati da pacchetti HTTP. Inoltre si utilizza la serializzazione XML dei dati unitamente

24 CAPITOLO 2. ISILAB 24 ad altri standard. Un web service consente quindi alle applicazioni che vi si collegano di usufruire delle funzioni che esso mette a disposizione. Una caratteristica importante é che ogni operazione ha una sua descrizione comprendente i parametri che si aspetta di ricevere, quelli che restituirá e il tipo di entrambi. L idea é quella di avere un interfaccia che contenga dei metodi per leggere, scrivere ed elencare tutte le risorse disponibili, che possono essere descritte tramite metadati strutturati[15]. Al momento il laboratorio offre agli studenti la possibilitá, tramite un software di sviluppo, web based, di creare applicazioni C che possono essere testate remotamente su una scheda DSP Analog Devices BF533 (e relativo kit di sviluppo) [16].Questa parte del laboratorio è sviluppata utilizzando la tecnologia AJAX (Asynchronous Javascript and XML) e un approccio service oriented. Per accedere a questo strumento gli utenti non hanno bisogno di applicazioni o plig-in installati a parte una connessione internet e un browser. La decisione di utilizzare la tecnologia AJAX è dovuta alla scelta di creare una applicazione web interattiva e che minimizzi le comunicazioni tra utente finale e i livelli più alti. Tramite AJAX, l interfaccia utente può richiedere dati al server del laboratorio in background senza interferire con la visualizzazione e il comportamento della pagina esistente. Ogni componente della pagina puó essere ricaricato asincronamente in modo da far percepire all utente una applicazione piú veloce e reattiva.[17] Architettura laboratorio DSP L architettura del laboratorio, come vediamo in figura 2.3, é organizzata in tre livelli distinti: le risorse, il Lab Server e l interfaccia utente.

25 CAPITOLO 2. ISILAB 25 Figura 2.3: Schema dell architettura di ISILab DSP Partendo dal livello piú basso troviamo appunto le risorse del laboratorio, costituite dalla strumentazione, dai dispositivi e dai pacchetti software usati negli esperimenti. In questo momento le risorse disponibili sono la scheda

26 CAPITOLO 2. ISILAB 26 di sviluppo ADSP BF533 Ez-Kit Lite e il suo software di sviluppo Visual DPS++ [18]. Ogni risorsa si interfaccia con il livello superiore (ovvero il lab server) tramite i plug-in, i controller e i web service. Proprio questi ultimi, come abbiamo già visto, consentono di incapsulare ogni risorsa creando dei metodi comuni che consentono di controllare una risorsa software al pari di una hardware, semplicemente conoscendo i parametri richiesti e gli output che ci si aspetta di ricevere. Il Lab server é a sua volta suddiviso in due parti: il Lab Server Engine e un web service destinato a collegarsi con l interfaccia utente. Come si può intuire il lavoro principale é svolto dal LSE che dovrá gestire l accesso dei vari utenti alle risorse. Questa procedura avverrá in seguito alla richiesta di una determinata azione generata dall interfaccia utent. Il LSE trasforma in sequenze di comandi a basso livello. Fra i compiti del LSE vi é anche quello di settare gli strumenti che si utilizzeranno secondo i parametri richiesti dall utente e una volta finito l esperimento di restituire i dati in output all utilizzatore. Uno dei punti di forza del LSE è quello di sfruttare la tecnologia dei web service: in questo modo é molto piú facile aggiungere o rimuovere i dispositivi adattandoli alla struttura generale ed è rapida anche l interazione con l interfaccia utente. L ultimo livello è costituito proprio dall interfaccia utente che non é altro che una applicazione in grado di stabilire un canale di comunicazione con il Lab Server Engine per ricevere e inviare dati utili all utente. É sviluppata interamente con tecnologia AJAX che consente di minimizzare le comunicazioni tra il browser e il Lab server, consentendo l aggiornamento in background della pagina web, senza interferenze riscontrabili dall utente.

27 CAPITOLO 2. ISILAB 27 La comunicazione tra le risorse e il Lab server avviene tramite una applicazione software detta controller; questa é facilmente utilizzabile su qualunque risorsa disponga di un sistema operativo; in via alternativa si possono collegare le risorse tramite USB, GPIB ecc. ad un personal computer che svolga un ruolo di mediatore. Grazie alla tecnologia Web Service ogni controller nasconde le caratteristiche proprie di ogni dispositivo e i protocolli di comunicazione rendendo cosi facilmente accessibile la risorsa utilizzando una interfaccia comune. La comunicazione tra il lab server e la user interface avviene nuovamente sfruttando al massimo la tecnologia dei web service. L utente senza conoscere i dettagli di come avverranno le sue richieste vedrá solamente il tipo di azione, i paramentri di ingresso e di uscita. A livello piú basso l applicazione Front-end Web service avvierá la richiesta al lab Server dell utente ricercandola tra quelle già implementate e si comporterá come un azione generica dando il via all esperimento. Quando l azione sarà completata restituirà all interfaccia utente gli output che si limiterá a visualizzarli. A questo punto é ancora più chiaro come il Lab Server Engine svolga i compiti fondamentali del laboratorio lasciando all interfaccia utente e a quella delle risorse compiti esclusivamente ad alto livello.

28 CAPITOLO 2. ISILAB Home Page ISIlab La pagina principale fornisce all utente tre link, come si puó vedere nella figura 2.4. Figura 2.4: Attuale home page di ISILab Il primo, Analog and Digital Elecronic Circuits, consente di accedere alla lista degli esperimenti pre caricati che gli studenti possono utilizzare. In questo momento sono caricati circa 20 esperimenti che riguardano tipici circuiti di elettronica analogica e digitale, ad esempio il circuito derivatore, quello integratore, filtri passa basso e passa alto, convertitori analogico-digitali ecc.

29 CAPITOLO 2. ISILAB 29 Una volta scelto il circuito l utente accede ad una pagina in cui puó vedere l immagine del circuito (generata utilizzando il programma P-Spice) e uno schema della realizzazione su basetta con componenti reali. In questo modo sono giá forniti due importanti supporti allo studente che puó partire da qui per ricreare o modificare quanto gli viene proposto in formato virtuale. Nella parte destra invece può verificare il funzionamento, utilizzando i parametri giá inseriti o inserendone lui di nuovi. Nella parte superiore avrà a disposizione un generatore di forme d onda a suo piacimento (tipo e parametri). Nella parte inferiore potrá visualizzare il tracciato come se avesse davanti un oscilloscopio con la possibilitá di agire sui principali comandi di questo dispositivo. Figura 2.5: Esempio di simulazione di circuito elettronico Il secondo link, Digital Signal Processing Board, consente all utente di ca-

30 CAPITOLO 2. ISILAB 30 ricare e testare sulla scheda ADSP - BF533 EZ-Kit Lite che monta un DSP della serie Blackfin, dei progetti C da lui creati, tramite il software Visual DSP++. Quando lo studente entra in questa sezione (fig. 2.6) si trova in un cosiddetto IDE (Integrated Development Environment)dove potrá scrivere, eseguire e monitorare le sue applicazioni C. Come vediamo dall esempio in figura l interfaccia presenta in alto una barra degli strumenti, sotto un pannello dove inserire il codice vero e proprio, un pannello per l output della compilazione e una finestra di pop-up per seguire l esecuzione. Il codice puó essere scritto dall utente o possono essere utilizzati progetti pre caricati. Figura 2.6: IDE Visual DSP++ Il link DIBE Portal to ilab Network ci porta alla pagina di Figura 2.7. In ordine di tempo questa é l estensione di ISILab piú recente. Si tratta dell integrazione con l ilab Share Architecture (ISA).[19] ilabs é un progetto

31 CAPITOLO 2. ISILAB 31 del MIT, il Massachussets Institute of Technology, che punta a creare e a promuovere una rete mondiale di laboratori remoti. L obbiettivo finale del progetto é quello di avere una vasta rete di laboratori remoti che condividono attraverso internet esperimenti, apparati e utenti appartenenti a istituzioni di tutto il mondo (con notevoli vantaggi in termini economici e di risorse a disposizione). Il progetto si propone anche di fornire un framework software per l integrazione dei diversi laboratori, comprendente dei meccanismi autonomi di scheduling e prenotazioni di slot temporali. Gli utenti devono prima essere autenticati dal sistema ISA e poi prenotare il proprio esperimento. Far parte della rete ilab ha apportato alcuni vantaggi al laboratorio ISILab: ˆ la possibilitá di condividere in sicurezza il laboratorio in un contesto interfacoltá; ˆ la disponibilitá di alcune funzionalitá pronte da utilizzare, come ad esempio le prenotazioni e la gestioni di utenti e gruppi; ˆ il vantaggio di essere ora parte di una comunitá internazionale.

32 CAPITOLO 2. ISILAB 32 Figura 2.7: ilab Service Broker, pagina del D.I.B.E

33 Capitolo 3 Gestione del laboratorio In questo capitolo sono presentati gli sviluppi apportati con questa tesi alla sezione di gestione della parte di ISILab dedicata allo sviluppo di progetti in Visual DSP++ per la scheda Blackfin. Si tratta di possibilità per tecnici e docenti di caricare progetti predefiniti in linguaggio C, di visualizzare le azioni a disposizione degli amministratori e uno strumento di monitoraggio delle risorse hardware e software disponibili. 3.1 Home page L accesso alle funzionalità di amministrazione avviene come di consueto tramite la pagina di login. L utente inserendo il suo ID e la sua password (figura 3.1) sarà identificato dal sistema che applicherà i privilegi relativi al suo status e nel caso di un amministratore gli consentirà la scelta di entrare nel laboratorio oppure di visualizzare l home page di amministrazione. 33

34 CAPITOLO 3. GESTIONE DEL LABORATORIO 34 Figura 3.1: Pagina di login Vediamo come avviene questo meccanismo; quando l utente inserisce i suoi dati tramite il login il sistema lo ricerca nel database e va a verificare qual è il suo ruolo. Tramite un semplice file XML sono state create 3 tipologie di ruoli, amministratore, utente, ospite. È infatti possibile accedere ad alcune aree del laboratorio senza essere autenticati. Come vediamo in figura 3.2 l Home Page dei servizi di gestione di ISILab presenta già un buon numero di funzionalità che consentono di controllare le caratteristiche principali del laboratorio remoto. L archivio dei progetti pre-caricati consente all amministratore di vedere quali progetti sono già inseriti nel database del laboratorio e gli consente di aggiungerne nuovi, modificare o rimuovere quelli presenti. Il link Experiment Type rimanda ad una pagina in cui sono presentati i

35 CAPITOLO 3. GESTIONE DEL LABORATORIO 35 Figura 3.2: Home page amministratore tipi di esperimento che è possibile caricare sul laboratorio. Per ora si tratta solo si applicazioni DSP, ma da questo pannello sarà possibile verificare e crearne nuove tipologie in base agli sviluppi futuri. Il link Lab Server Engine Status consente di visualizzare quali azioni siano in esecuzione in background da parte del LSE e quali di queste siano state schedulate. Queste operazioni avvengono di default in automatico ma è possibile avviarle e fermarle manualmente e visualizzarne lo stato. Il link Lab Server Engine Actions consente all amministratore di visualizzare quali azioni siano state implementate nel laboratorio e che ha a disposizione per lavorare con le risorse. Fornisce inoltre alcune caratteristiche fondamentali delle LSE Actions specificando per esempio i parametri d ingresso e di uscita e il loro tipo. Il link Logs & Errors consente di visualizzare i log e gli errori che si generano durante l esecuzione di esperimenti e test.

36 CAPITOLO 3. GESTIONE DEL LABORATORIO 36 Available Resources è l integrazione dell applicazione esterna Fox Controller, all interno delle pagine di Amministrazione. L obbiettivo è sviluppare un applicativo sempre più completo che consenta all utente di non dover installare o eseguire software aggiuntivi. Index of Available Experiments è un link che punta alla pagina degli esperimenti visibili agli utenti e che come vediamo per ora gestisce il materiale a disposizione per la scheda Blackfin (figura 3.3). Figura 3.3: Index Esperimenti Blackfin e DaVinci Tutte le pagine presentate sono create utilizzando la tecnologia ASP.net e il linguaggio C# come codice sorgente. Tramite Hyperlink ognuna di queste sezioni rimanda ad una successiva pagina aspx con a sua volta un proprio codice sorgente e cosi via.

37 CAPITOLO 3. GESTIONE DEL LABORATORIO Archive of pre-loaded projects Figura 3.4: Pagina gestione progetti pre-caricati In questa pagina troviamo il primo dei servizi aggiunti a disposizione degli amministratori. Nella pagina come possiamo vedere vengono visualizzati semplicemente una tabella con i progetti per la scheda Blackfin già caricati, specificandone il nome del codice sorgente che li genera e il titolo che gli è stato assegnato. La tabella presenta inoltre un pulsante che consente la rimozione del progetto. Sotto questi elementi troviamo un pulsante separato che aprirà una finestra pop up con gli strumenti per caricare invece un nuovo progetto. La maggior parte delle tabelle utilizzate in queste pagine sfruttano le potenzialità delle gridview. Queste consentono sia di visualizzare contenuti importati da database o altre tabelle in maniera molto veloce, sia di effettuare operazioni sui contenuti utilizzando o funzioni gia previste (come la rimozione) o altre specificate dall utente.

38 CAPITOLO 3. GESTIONE DEL LABORATORIO 38 <asp:gridview ID="grdProjects1" runat="server" AutoGenerateColumns="false" OnRowCommand="grdProjects_RowCommand" > <Columns> <asp:templatefield HeaderText="Code"> <ItemTemplate> <asp:label ID="Code" runat="server" Text= <%# Bind("Code")%> ></asp:label> <asp:hiddenfield ID="hddID" Value= <%# Bind("Id")%> runat="server" /> </ItemTemplate> </asp:templatefield> <asp:boundfield HeaderText="Description" DataField="Description" /> <asp:buttonfield buttontype="link" commandname="remove" text="remove"/> </Columns> </asp:gridview> Come vediamo dal codice, una volta creato il controllo gridview, abbiamo impostato la creazione di colonne manuale, in modo da poter scegliere quali campi visualizzare della struttura dati sorgente. Nel nostro caso abbiamo utilizzato un etichetta (label) per il codice, estraendo i dati tramite l istruzione bind e un semplice campo concatenato per visualizzare la descrizione. Il pulsante di rimozione, presente in ogni riga e quindi implicitamente riferito al progetto corrispondente, una volta premuto chiederá una ulteriore confer-

39 CAPITOLO 3. GESTIONE DEL LABORATORIO 39 ma all utente, dopodiché utilizzando le funzioni del DataBase Manager opera direttamente la rimozione dal database del laboratorio remoto. Figura 3.5: Pop-up caricamento nuovo progetto Scegliendo di aggiungere un progetto, tramite l apposito tasto passa in secondo piano la pagina di visualizzazione e si apre una finestra pop-up (figura 3.5) che consente di inserire quanto necessario. Per prima cosa occorre

40 CAPITOLO 3. GESTIONE DEL LABORATORIO 40 assegnare un codice al progetto e la descrizione, i due campi che identificheranno in modo univoco il nuovo inserimento e che andremo di volta in volta a visualizzare. Dal sottostante menú a dropdownlist si imposta il tipo di esperimento scelto fra quelli presenti nel database. In questo caso l utente non puó scegliere di inserire un nuovo tipo di esperimento ma dovrá necessariamente utilizzare uno di quelli giá presenti. Attualmente é disponibile un solo tipo di esperimenti (che come si vede viene impostato di default), relativo alla scheda BF533. Il passo successivo é quello di inserire il codice sorgente, che deve soddisfare determinate caratteristiche e puó essere caricato tramite la scelta della cartella in cui é depositato. Il sorgente deve essere un file compresso che il sistema importerà tramite un tool AJAX predefinito e gestito poi da un Database Manager proprio del laboratorio. protected void AddProj(object sender, EventArgs e) { if (this.isvalid) { bool uploadcompleted= Convert.ToBoolean(this.Session["_UPLOAD_COMPLETED_"]); if (uploadcompleted) { Project p = new Project(); p.code = txtcode.text; p.description = txtdescription.text;

41 CAPITOLO 3. GESTIONE DEL LABORATORIO 41 byte[] codice = asnproject.filebytes; p.source = codice; int ExpId = int.parse(drpexperimenttypeid.selecteditem.value); DatabaseManager.Instance.AddProject(p, ExpId); pnlone.visible = false; pnltwo.visible = true; } } } L inserimento di un nuovo progetto é comunque un operazione che sarà visibile immediatamente dagli utilizzatori del laboratorio ed é quindi importante verificare che non vi siano errori. I primi due campi code e description saranno validati da una funzione AJAX che controllerá che siano stati inseriti solo caratteri testuali e che non venga lasciato vuoto nessun campo (creerebbe problemi anche nell archiviazione nel database). Come vediamo anche nel codice ci si riferisce sempre ad istanze che sono giá proprie del laboratorio: il DatabaseManager opera con oggetti di tipo Project, che dovranno essere caratterizzati dai parametri inseriti dall utente. Il codice una volta caricato é convertito in un array binario e assegnato all istanza di progetto che viene poi gestita dal Database. Terminato correttamente l inserimento, viene data conferma all utente.

42 CAPITOLO 3. GESTIONE DEL LABORATORIO Experiment Type Questa funzione consente all amministratore del laboratorio di visualizzare i tipi di esperimento caricati nel database del laboratorio e le loro caratteristiche. Questo puó essere utile nel momento in cui sia necessario inserire un nuovo progetto e scegliere uno dei tipi presenti. Come si é visto nella sezione precedente, l amministratore non puó inserire direttamente un tipo di esperimento da assegnare al progetto che sta caricando ed è per questo importante che conosca bene le caratteristiche prima di asssegnarlo. Figura 3.6: Visualizzazione tipi di esperimento disponibili Come vediamo dalla figura 3.6 l utente sceglie dalla lista a scorrimento il tipo di esperimento di cui vuole le informazioni e a quel punto la pagina viene ricaricata aggiornando la tabella sottostante. Sempre tramite l utilizzo delle gridview i tre campi vengono riempiti estraendo dal database i dati specifici dell esperimento prescelto. I campi visualizzati sono il nome assegnato al

43 CAPITOLO 3. GESTIONE DEL LABORATORIO 43 tipo di esperimento, la pagina di riferimento dove trovare il codice relativo e la sua configurazione, ovvero uno schema xml che mostri come é stato creato il modello e alcuni parametri. 3.4 Lab Server Engine Actions Prima di presentare l utilizzo e le caratteristiche di questo servizio di gestione del laboratorio é utile spiegare cosa siano le azioni e la loro importanza Le actions e il Lab Server Engine Figura 3.7: Comunicazione LSE - interfaccia utente Come giá visto il LSE si occupa della comunicazione sia con le risorse sia con gli utenti. L interazione tra il LSE e l interfaccia utente é mediata da un semplice web service che avvia e monitora le azioni: il Front-end Web Service. L utente infatti ha a disposizione un set ben definito di azioni che

44 CAPITOLO 3. GESTIONE DEL LABORATORIO 44 manderá in esecuzione tramite il LSE. Un esempio di azione é lo start di un processo di acquisizione dati o la configurazione dei parametri di una delle risorse. L interfaccia utente non conosce i dettagli dell implementazione delle azioni, ma conosce solo i loro nomi e la lista di parametri di imput ed output. Le azioni sono definite dagli sviluppatori del laboratorio remoto e generalmente il loro numero aumenta quando vengono aggiunti nuovi esperimenti. La figura 3.7 specifica il design interno del LSE. In figura 3.8 vediamo come si presenta questo servizio. Abbiamo quindi una tabella (gridview) che visualizza tutte le azioni a disposizione attualmente. A fianco ad ogni azione troviamo due piccole frecce che consentono di aprire e chiudere un pannello con le specifiche di ognuna. Figura 3.8: Visualizzazione azioni a disposizione degli amministratori Tra le azioni in elenco, definite per il laboratorio DSP, le piú rappresentative sono: ˆ Execute: carica ed esegue il codice eseguibile sulla scheda Ez-KiT Lite L azione termina quando l applicazione finisce o quando viene inviato

45 CAPITOLO 3. GESTIONE DEL LABORATORIO 45 un comando di Halt dall utente; ˆ Halt: termina immediatamente (anche prima che sia completata) l esecuzione di una applicazione in funzione sulla scheda di sviluppo; ˆ Build: invia il codice sorgente al compilatore e restituisce gli output prodotti; Come vediamo dal codice seguente il lavoro effettuato sulle azioni é leggermente diverso da quello fatto per gli esperimenti. In questo caso infatti non si trattava di leggere semplicemente un database ma di andare a cercare dei metodi implementati dagli sviluppatori del sito. protected void loadactionstable() { var controller = LabServerController.Instance; ActionDescriptionList list = new ActionDescriptionList(); var result = list.fromxmlstring(controller.getactiondescription()); grdaction.datasource = result.actionsdescription; grdaction.databind(); grdaction.headerrow.cells[0].text = "ACTIONS"; } Per questo motivo é stato creato un oggetto ActionDescription che potesse modellare in modo sintetico e chiaro le nostre azioni. Bisogna sempre tenere

46 CAPITOLO 3. GESTIONE DEL LABORATORIO 46 presente che la maggior parte degli oggetti e delle istanze del laboratorio remoto sono serializzate in XML e per visualizzarle bisogna effettuare prima una conversione. Qui sotto possiamo vedere il codice utilizzato per effettuare quanto fin qui descritto. public class ActionDescription { [XmlElement(ElementName = "Name")] public string Name { get; set; } [XmlElement(ElementName = "Input")] public ParametersInputDescription[] Inputs { get; set; } [XmlElement(ElementName = "Output")] public ParametersOutputDescription[] Outputs { get; set; } [XmlElement(ElementName = "BackgroundExecution")] public bool BackgroundExecution { get; set; } } [XmlElement(ElementName = "TextDescription")] public string TextDescription { get; set; } public class ParametersInputDescription {

47 CAPITOLO 3. GESTIONE DEL LABORATORIO 47 [XmlElement(ElementName = "InputName")] public string InputName { get; set; } [XmlElement(ElementName = "Type")] public string Type { get; set; } } public class ParametersOutputDescription { [XmlElement(ElementName = "OutputName")] public string OutputName { get; set; } [XmlElement(ElementName = "Type")] public string Type { get; set; } } La descrizione é stata costruita tramite una struttura ramificata: ogni ActionDescription avrá un nome, una lista di parametri input e output, la possibilitá di esecuzione in background e una descrizione testuale. A loro volta ogni parametro in ingresso ed uscita della lista avrá un nome ed un tipo. Ognuno di questi é un elemento XML che deriva dalla radice che sará l azione vera e propria. La parte relativa all esecuzione in background indica se una certa azione debba essere eseguita immediatamente o possa essere

48 CAPITOLO 3. GESTIONE DEL LABORATORIO 48 schedulata in coda ad altre piú importanti. Nella figura 3.9 troviamo invece il dettaglio di una delle azioni visualizzate. Abbiamo espanso il pannello relativo all azione GetMemoryDump. Nel primo riquadro è visualizzata la descrizione dell azione. Sotto troviamo l informazione sull esecuzione in background giá descritta precedentemente. Infine la specifica più importante ovvero quali sono i parametri di input e output, i loro nomi per identificarli e il tipo che devono rispettare. Figura 3.9: Esempio di visualizzazione dell azione GetMemoryDump L utilizzo dei pannelli AJAX ha consentito di creare un numero minimo di pagine, rendendone attive solo alcune parti (per l appunto i vari pannelli) in base al servizio offerto e all interazione con l utente. In molti casi infatti é proprio la diversa richiesta dell utente che abilita/disabilita alcune parti anziché altre. 3.5 Available Resources Tramite questa pagina di visualizzazione l amministratore puó monitorare le risorse hardware e software collegate e in funzione nel sistema. In figura 3.10

49 CAPITOLO 3. GESTIONE DEL LABORATORIO 49 vediamo lo stato attuale del laboratorio, con due risorse collegate: la scheda di sviluppo e il compilatore VisualDSP++. Figura 3.10: Visualizzazione delle risorse disponibili e loro specifiche Anche in questo caso, tramite l uso dei pannelli, si parte da una semplice tabella, espandibile tramite i due pulsanti a fianco alla risorsa. Per ognuna si visualizza il nome, una breve descrizione di carattere tecnico, per consentire all amministratore di individuare con certezza quale stia analizzando ( molto utile in caso di più risorse simili); sono poi elencati i parametri, questa volta senza distinzione di input e output, visualizzandone il nome, la descrizione e la possibilità di essere scritti o letti; l ultima sezione mostra i comandi e la loro descrizione (la parte relativa all autorizzazione a lettura o scrittura é disabilitata). Per questo servizio é stato piú complesso andare a ricavare i dati da vi-