ANALISI ED ESTENSIONE DI UNO STRUMENTO PER LA …rimlab.ce.unipr.it/documents/TesiCigolini.pdf ·...

UNIVERSITÀ DEGLI STUDI DI PARMAFACOLTÀ DI INGEGNERIA

Corso di Laurea in Ingegneria Informatica

———————–

ANALISI ED ESTENSIONE DI UNOSTRUMENTO PER LA PROGETTAZIONE DI

AMBIENTI ASSISTIVI IN REALTÀ VIRTUALE

ANALYSIS AND EXTENSION OF A TOOL FOR THE DESIGN OF ASSISTIVE ENVIRONMENTS IN VIRTUAL REALITY

Relatore: Chiar.mo Prof. STEFANO CASELLI

Correlatori:Dott. Ing. JACOPO ALEOTTI

Dott. VINCENZO MICELLI

Tesi di Laurea di:MARCO CIGOLINI

Anno Accademico 2009/2010

Indice

Capitolo 1 - Introduzione 71.1 - Origini e motivazioni.........................................................................................................91.2 - Obiettivi...........................................................................................................................10

1.2.1 - Impatto potenziale....................................................................................................101.3 - Contenuti della tesi..........................................................................................................11

Capitolo 2 - Il sistema VAALID 132.1 - Il progetto.........................................................................................................................14

2.1.1 - Definizione...............................................................................................................142.1.2 - Che cosa non è.........................................................................................................152.1.3 - Il consorzio...............................................................................................................15

2.2 - Realizzare l'Ambient Assisted Living..............................................................................162.3 - Contributo allo User-Centered Design.............................................................................17

2.3.1 - Le fasi del processo..................................................................................................182.3.2 - I vantaggi..................................................................................................................20

2.4 - La metodologia di progetto..............................................................................................202.4.1 - L'approccio alla soluzione........................................................................................212.4.2 - Potenziali utenti della piattaforma...........................................................................23

2.5 - Architettura di VAALID..................................................................................................242.5.1 - Strumento di caratterizzazione del modello utente..................................................252.5.2 - Il costruttore del modello ambiente.........................................................................262.5.3 - Il compositore del servizio AAL..............................................................................262.5.4 - Il pannello di controllo della simulazione................................................................272.5.5 - Il browser della simulazione 3D..............................................................................272.5.6 - Il verificatore Living Lab.........................................................................................27

2.6 - Tecnologie utilizzate per gli Scenari................................................................................282.6.1 - Il VRML...................................................................................................................292.6.2 - Le Ontologie............................................................................................................302.6.3 - I Workflow...............................................................................................................322.6.4 - InstantReality...........................................................................................................33

III

Capitolo 3 - Strumento di Authoring 373.1 - Creare o aprire un Progetto..............................................................................................38

3.1.1 - Integrazione dell'ambiente.......................................................................................393.1.2 - Aggiunta degli Spazi................................................................................................403.1.3 - Project Browser........................................................................................................41

3.2 - Dispositivi: modello ed inserimento................................................................................423.2.1 - Aggiungere un Dispositivo.......................................................................................42

3.3 - Dispositivi: comportamento ed interazione.....................................................................453.3.1 - Creare un nuovo Workflow......................................................................................45

3.4 - Servizio AAL ed Utente Virtuale.....................................................................................463.4.1 - Creare un Servizio AAL...........................................................................................463.4.2 - Creare un Utente Virtuale.........................................................................................47

3.5 - Scenario I: allarme intrusioni...........................................................................................493.5.1 - Realizzazione di un Dispositivo: Cassa Altoparlante..............................................503.5.2 - Realizzazione di un Dispositivo: Luce d'Allarme....................................................533.5.3 - Workflow di un Servizio: Allarme sonoro e visivo..................................................55

3.6 - Scenario II: illuminazione automatica.............................................................................573.6.1 - Realizzazione di un Dispositivo: Lampadario.........................................................583.6.2 - Realizzazione di un Dispositivo: Telecamera di Prossimità....................................623.6.3 - Workflow di un Dispositivo: Lampadario................................................................63

3.7 - Note sul prototipo dello strumento..................................................................................64

Capitolo 4 - Ambiente di Simulazione 654.1 - Architettura funzionale....................................................................................................654.2 - Componenti funzionali....................................................................................................66

4.2.1 - Instant Player............................................................................................................674.2.2 - Simulation Control Panel.........................................................................................684.2.3 - Logger......................................................................................................................724.2.4 - Workflow Engine.....................................................................................................73

4.3 - Flusso d'informazione tra AE ed SE................................................................................734.4 - Sito per la sperimentazione..............................................................................................74

Conclusioni 77

Bibliografia 79

IV

Alla mia famiglia

Capitolo 1

Introduzione

L'Europa sta affrontando un drastico cambiamento demografico. La concomitanza di un basso tasso di riproduzione e di una maggiore longevità, cioè una più elevata aspettativa di vita, sta causando un graduale spostamento nella distribuzione per età della popolazione europea, verso un incremento del numero di persone anziane. Questa progressiva crescita dell'età media solleverà inevitabilmente, nei prossimi decenni, nuove problematiche nei settori dell'assistenza personale e medica. Inoltre sono in aumento coloro, per esempio soggetti a disabilità, che decidono di ricorrere alle tecnologie assitive per migliorare la propria qualità della vita.

In questo contesto è nato il programma Ambient Assisted Living (AAL): l'Unione Europea si è pro-posta di finanziare lo sviluppo di sistemi e soluzioni tecnologiche volte a sostenere gli anziani e le persone con disabilità nella loro quotidianità, cercando di aiutarli a vivere in modo autosufficiente nelle loro abitazioni e di ricevere assistenza da operatori sociali o sanitari solo quando necessario.

L'AAL sottende tutte le sfide che in futuro riguarderanno il contesto dell'Intelligenza Ambientale. Lo scopo è poter restituire ad anziani e disabili un congruo livello d'indipendenza, promuoverne le rela-zioni sociali, fornire un supporto mediante l'interazione degli ambienti “intelligenti”, rinfrancarne sia lo stato psicologico che quello fisico. In termini pratici, l'AAL si riferisce a quegli ambienti tec-nologici che sono sensibili e reattivi alla presenza delle persone, offrendo loro l'assistenza necessa-ria al mantenimento di uno stile di vita il più possibile autonomo.

Numerose sono le iniziative che si stanno muovendo in quest'ottica. Fra esse vi è anche il progetto europeo VAALID (Accessibility and Usability Validation Framework for AAL Interaction Design Process), progetto STREP FP7 [1] finalizzato allo sviluppo di nuovi strumenti e tecnologie assistive per il processo d'interazione AAL, con la partecipazione dell'Università degli Studi di Parma.

L'obiettivo di VAALID è assistere i professionisti delle tecnologie ICT (Information and Communi-cation Technology) nel realizzare servizi AAL accessibili e semplici per l'utente, tecnicamente ed economicamente sostenibili per i produttori, efficienti e convenienti per il sistema di Welfare.

A tale scopo VAALID ha sviluppato una piattaforma di simulazione 3D immersiva. Essa intende contribuire a migliorare ed ottimizzare le caratteristiche di usabilità e di accessibilità dei servizi AAL, per una maggiore inclusione sociale e una vita indipendente dei beneficiari.

7

8 Capitolo 1 Introduzione

L'Ambiente di Simulazione, struttura sia hardware che software, si propone di consentire al proget-tista ICT la creazione di un contesto AAL in Realtà Virtuale o Aumentata e di coinvolgere gli utenti finali nel processo di progettazione, nel corso della successiva verifica dei servizi AAL in uno scena-rio virtuale.

Questa tesi si focalizza sull'Authoring Environment (AE), vale a dire sull'analisi e sull'estensione dello strumento previsto in VAALID per la progettazione e il supporto alla creazione di scenari AAL. Quindi il lavoro può essere suddiviso in due fasi distinte.

Nella prima fase è stato studiato l'Ambiente di Authoring, per comprenderne i requisiti di sistema e le principali funzionalità. In particolare sono necessari l'API Java3D e, per la simulazione di un am-biente virtuale, l'impiego del player fornito dal framework InstantReality, il cui utilizzo è previsto dallo stesso progetto VAALID.

Dopo aver compreso la struttura generale, la ricerca è proseguita con la disamina del corretto proce-dimento per la realizzazione di ambienti assistivi in realtà virtuale, in tutte le loro componenti: la scena 3D di contesto, i dispositivi coinvolti, il profilo dell'utente partecipante, le interazioni tra i di-versi elementi e i servizi AAL veri e propri.

Al termine di questa prima fase è stata redatta una sorta di guida all'uso, inclusa nei capitoli interni, in quanto potrebbe rivelarsi utile a condividere le conoscenze apprese ed agevolare la comprensione delle potenzialità dello strumento. Essa considera anche l'esecuzione dell'Ambiente di Simulazione integrato nel VAALID AE, visualizzato sullo schermo del computer, con la navigazione ed interazio-ne gestite mediante la tastiera e il mouse. Le considerazioni possono comunque essere estese anche ad altri casi applicativi, nei laboratori che offrono coinvolgimento e realismo.

Durante la seconda fase, invece, sono stati sviluppati due scenari AAL specifici, due esempi pratici al fine di completare e chiarire gli aspetti che necessariamente potevano soltanto essere accennati in un manuale generico. Sono state scelte due situazioni abbastanza tipiche per le “case intelligenti” e la domotica: un allarme, nel caso di tentata effrazione di una finestra, e l'illuminazione automatica degli interni di un'abitazione, la cui attivazione è in funzione della stanza in cui si trova l'anziano o il disabile.

I modelli grafici, sia dell'ambiente domestico che degli altri elementi coinvolti, erano stati costruiti tramite l'editor 3D Studio Max. Dunque sono stati esportati nel formato VRML, per essere compati-bili con lo strumento di VAALID utilizzato. In tale linguaggio è poi stata implementata, configurata e personalizzata la maggior parte dei dispositivi richiesti per gli scenari selezionati, non essendo già presenti nelle librerie fornite con il sistema. Combinando le proprietà del VRML con il meccanismo dei workflow disponibile nell'Authoring Environment, è stato definito il comportamento dei diversi elementi, gestendo sia le interazioni che il servizio AAL.

Lo strumento esaminato si trova allo stato di prototipo. Si è comunque contribuito ad estendere le sue librerie, grazie ai nuovi dispositivi sviluppati per gli scenari di questa tesi.

I paragrafi seguenti proseguono con un resoconto sulla nascita del progetto, sulle sue principali mo-tivazioni (1.1) e sugli obiettivi identificati nelle prime fasi di sviluppo della piattaforma (1.2). Infine è descritta l'organizzazione delle sezioni successive della tesi (1.3).

Capitolo 1 Introduzione 9

1.1 Origini e motivazioni

L'ambiente intelligente è considerato come uno dei possibili modi con cui le ICT contribuiranno allo sviluppo di società dell'informazione, specialmente l'AAL per quanto riguarda l'alleviare il problema dell'invecchiamento della popolazione.

La proposta di VAALID è nata allo scopo di realizzare strumenti d'ingegneria informatica che potes-sero aiutare gli sviluppatori, facilitando e ottimizzando i processi d'ideazione, progettazione e messa in campo di soluzioni tecnologiche nell'ambito dell'AAL.

Tra i diversi aspetti che tipicamente caratterizzano le soluzioni AAL, per esempio problemi di natura tecnica, medica, psicologica o semplicemente estetica, un'attenzione particolare è stata dedicata alla interazione con l'uomo, anzitutto all'accessibilità (la misura in cui le funzionalità del sistema sono fruibili dal maggior numero possibile di persone) ed usabilità (l'efficacia con cui un utente può rea-lizzare un compito specifico).

In questo contesto appare importante poter predisporre rapidamente soluzioni preliminari di valuta-zione, secondo un processo di User Centered Design (UCD) [2], che impone uno stretto legame con i futuri destinatari e una continua revisione o adeguamento delle tipologie di sistema proposte.

I temi dell'accessibilità ed usabilità, da parte degli utenti con diverse caratteristiche e requisiti, non possono essere affrontati dopo che i componenti principali del nuovo ambiente sono già in atto; quindi sono necessari strumenti specifici, che supportino un approccio maggiormente proattivo e che affrontino questi aspetti fin dalle prime fasi di progetto. I nuovi strumenti VAALID aspirano inoltre a favorire le industrie e le imprese ICT specializzate nelle progettazioni con aspetti rilevanti di Human Factors e User Interaction [3], la Ricerca e il mondo accademico.

D'altra parte, risulta ormai da tempo assodata a livello politico, sociale ed industriale, in una certa misura, l'impossibilità di poter accettare prodotti e servizi che escludano una consistente porzione di popolazione, come i disabili e gli anziani. Quindi progettare fin dal principio i prodotti e i servizi ICT rispettando i metodi dello User Centered Design, in modo tale che possano essere utilizzati dal numero più ampio possibile di popolazione, è essenziale per la creazione di una sostenibile società dell'informazione.

Al momento, la valutazione dell'accessibilità ed usabilità avviene in alcuni settori più di altri: per esempio, quella del web è molto diffusa ed ha un buon numero di risorse e strumenti implementati.

Come risultato del lavoro svolto in [4], furono identificate diverse cause per l'attuale situazione. Tra le più rilevanti si possono evidenziare le seguenti:

• Inconsapevolezza e assenza di competenze per quanto riguarda i principi di "accessibilità per tutti" all'interno delle imprese;

• Difficoltà nell'individuare le reali esigenze degli utenti, per la mancata conoscenza, nell'in-dustria tradizionale, delle necessità degli anziani e delle persone con disabilità;

• Assenza di strumenti di sviluppo a sostegno dell'applicazione della "progettazione per tutti";• Insufficiente grado d'informazione relativamente all'Intelligenza Ambientale e l'AAL.

10 Capitolo 1 Introduzione

1.2 Obiettivi

Il fine ultimo del progetto VAALID è quello di sviluppare una piattaforma di simulazione 3D immer-siva, un ambiente di sviluppo integrato (VAALID IDE) per la progettazione assistita e la validazione dei sottosistemi d'interazione con l'utente, che migliori ed ottimizzi le caratteristiche di accessibilità dei servizi AAL, per l'inclusione sociale e la vita autonoma delle persone anziane o disabili.

Lo scopo principale può essere ripartito in diversi obiettivi specifici:

1. Sviluppo della piattaforma di simulazione 3D immersiva (Piattaforma VAALID).La piattaforma VAALID è volta a fornire ai progettisti ICT uno strumento fondato sull'uso del computer, che permetta loro di affrontare con minori difficoltà le sfide incontrate durante i processi iterativi della progettazione di nuovi sistemi AAL, in tutte le sue fasi d'interazione con l'utente finale. Lo scopo principale è la realizzazione della piattaforma tecnologica, che include i framework di creazione e simulazione, così come tutti i necessari strumenti tecnici, modelli e metodologie di progetto.

2. Valutazione della piattaforma di simulazione 3D immersiva.Il secondo obiettivo principale è quello di valutare la piattaforma di simulazione 3D sulla base di due criteri tra loro distinti: la dimensione tecnica e la dimensione funzionale. Sono compresi, tra tutti gli utenti destinatari, solo i rappresentanti scelti nel ciclo di valutazione.

3. Definizione di un piano di sfruttamento commerciale e di una strategia IPR (Intellec-tual Property Rights) al termine del progetto.Il terzo proposito è quello di creare le condizioni iniziali ed un framework per un efficace sfruttamento dei risultati, che contribuisca realmente alla creazione di nuove opportunità per l'industria europea e promuova la leadership nel campo delle tecnologie ICT inclusive.

1.2.1 Impatto potenziale

Il progetto VAALID intende contribuire a nuove opportunità nel settore delle ICT inclusive, focaliz-zandosi sull'osservanza dell'obiettivo ICT-2007.7.2 [5]. Infatti, il risultato dovrà essere lo sviluppo di uno strumento tecnologico a supporto dell'implementazione di soluzioni AmI (Ambient Intelli-gence) basate sulle ICT per una vita indipendente e l'inclusione.

L'usabilità è il punto di partenza nell'integrazione e sostanziale miglioramento dell'accessibilità dei futuri prodotti e servizi ICT (per esempio, ambienti virtuali/immersivi o elettrodomestici), da parte delle persone con disabilità e limitazioni funzionali. Per usabilità s'intende la capacità di un gruppo definito di persone nell'impiegare un prodotto o un servizio. L'accessibilità può essere considerata come una misura dell'estensione di quei gruppi di persone, diverse dagli utenti originariamente pre-visti, cui può essere offerta l'esperienza di utilizzo del bene stesso.

Con il progetto VAALID si vorrebbe dare un contributo a tale obiettivo, per consentire al designer di affrontare il proprio lavoro avendo già in mente una gamma più ampia delle esigenze, condizioni, situazioni e preferenze dell'utente. Questo approccio, infatti, consentirebbe un'analisi sull'accessibi-lità ed usabilità fin dalle prime fasi di progettazione.

Capitolo 1 Introduzione 11

I componenti ICT essenziali in un ambiente AAL sono quelli che partecipano alla vita quotidiana delle persone, ad esempio la TV, gli elettrodomestici e i sistemi di illuminazione, con funzionalità d'interazione integrate per accedere ai servizi e strutture di calcolo più nascoste. Quindi è plausibile che VAALID, come altri progetti simili, possa aiutare anche i produttori tecnologici ICT del mercato di massa, che sarebbero in grado di simulare numerosi scenari d'uso dei loro prodotti, se dotati di caratteristiche personalizzate d'accessibilità ed appropriati per l'inserimento in edifici AAL.

L'ottimizzazione della metodologia di progetto user-centered, con un ruolo attivo degli utenti finali, potrebbe tradursi in prodotti migliori da immettere sul mercato europeo. Inoltre, sia la produzione che lo sviluppo di beni e servizi ICT accessibili sarebbero favoriti, grazie alla disponibilità di nuovi strumenti e metodi, che consentirebbero a progettisti e ingegneri di verificare ed ottimizzare l'acces-sibilità in tutte le fasi di progettazione.

1.3 Contenuti della tesi

La tesi è così strutturata:

• Nel Capitolo 2 è analizzato il sistema VAALID nel suo complesso. Ad una trattazione più teorica sulla definizione del progetto e sui contributi che esso intende apportare all'AAL e allo UCD, segue una parte più tecnica dedicata alla descrizione dell'architettura della piatta-forma, nelle sue componenti principali di authoring e simulazione. Infine sono citate le prin-cipali tecnologie e i linguaggi utili per la creazione di scenari AAL con VAALID.

• Nel Capitolo 3 è presentata la guida all'uso dello Strumento di Authoring, per la creazione di un progetto AAL in tutti i suoi aspetti, cioè definendo l'ambiente, i dispositivi, l'utente e le in-terazioni tra loro. Quindi sono esposti entrambi gli scenari realizzati, l'uno sull'allarme e l'al-tro sull'illuminazione automatica, con le descrizioni in dettaglio dei nuovi dispositivi svilup-pati. In chiusura sono riportate alcune considerazioni sulla versione del prototipo analizzato.

• Nel Capitolo 4 è infine considerato l'Ambiente di Simulazione, descrivendo la sua struttura generale, le componenti che lo costituiscono e come esso si relaziona al VAALID AE, in par-ticolare l'esecuzione di uno scenario realizzato con il supporto di tale strumento. Al termine è rappresentata una configurazione dell'Ambiente di Simulazione nella versione per la speri-mentazione in Italia.

Capitolo 2

Il sistema VAALID

Il progetto VAALID ha l'obiettivo di produrre uno strumento di sviluppo, che consenta di accelerare le iterazioni attraverso il ciclo di UCD. L'idea centrale è, in concreto, quella di realizzare una prima soluzione AAL virtuale, che possa in seguito essere perfezionata con gli altri soggetti interessati, senza la necessità di ricostruire dei prototipi fisici per ogni modifica apportata.

Il processo di creazione del prototipo virtuale per la soluzione AAL presuppone più compiti, suddi-visi in analisi e progetto, assegnati a un insieme integrato di strumenti, al fine di semplificarne e ve-locizzarne l'esecuzione.

Gli sviluppatori potranno, grazie a uno Strumento di Authoring, creare o modificare le diverse parti della soluzione AAL, adattandola ad una vasta gamma di utenti. Avranno così a disposizione tutti i mezzi necessari per ottenere prototipi virtuali realistici che siano anche immediatamente accessibili per il collaudo ed ulteriori miglioramenti. Queste personalizzazioni sono tipiche di una soluzione che dovrà attraversare più iterazioni del processo di UCD e che dovrà quindi essere continuamente analizzata e ri-progettata per poter soddisfare le specifiche degli utenti finali.

Infine, un sistema di realtà virtuale sarà utilizzato da VAALID per la simulazione delle parti visive. Allo scopo di poter interagire con esso, nuovi dispositivi sono in fase di sviluppo, con una specifica attenzione rivolta alle esigenze degli anziani e delle persone con disabilità. Questi, infatti, saranno gli utenti beneficiari che dovranno partecipare alla fase di valutazione del progetto, che è uno dei re-quisiti necessari per la validazione e il test di un processo UCD. La simulazione del servizio e del-l'intelligenza di sistema utilizza i workflow AAL e le ontologie.

Il Capitolo può essere suddiviso in due sezioni principali: nella prima, più descrittiva, è introdotto il progetto VAALID, cominciando dalla sua definizione e dal consorzio fondativo (2.1), proseguendo nella discussione dei diversi contributi potenziali negli ambiti dell'Ambient Assisted Living (2.2) e dello User-Centered Design (2.3), per concludere poi con la presentazione del metodo di risoluzio-ne proposto da VAALID e degli utenti cui esso si rivolge (2.4). La seconda sezione, più tecnica, ana-lizza l'architettura del sistema (2.5) e l'insieme degli strumenti software o dei linguaggi (2.6) signifi-cativi per lo sviluppo di scenari AAL e per la comprensione di quanto sarà esposto nei Capitoli 3 e 4.

13

14 Capitolo 2 Il sistema VAALID

2.1 Il progetto

VAALID promuoverà l'utilizzo di prototipi virtuali durante lo stadio di “valutazione” nel ciclo UCD, fin dalle prime fasi di progettazione delle soluzioni. Fornirà inoltre uno strumento per la comunica-zione tra gli sviluppatori, consentendo loro di creare velocemente un modello funzionante e di tra-smetterlo ai co-sviluppatori, mostrando direttamente la soluzione anziché semplicemente descriven-dola. VAALID potrà anche essere impiegato come mezzo di promozione commerciale, illustrando i risultati attesi per il sistema AAL di una simulazione in realtà virtuale, prima dell'avvio del progetto.

2.1.1 Definizione

VAALID è uno Specific Targeted Research Project [6] sostenuto dall'Unione Europea con l'obiettivo di creare un ambiente di sviluppo integrato e di simulazione di soluzioni AAL, mediante:

• Uno Strumento di Authoring, che consente la creazione di un ambiente AAL virtuale.Tale rappresentazione, corredata dei nuovi servizi AAL, è costituita da una scena in realtà virtuale, supportata da dispositivi e sensori anch'essi virtuali, che possa simulare la struttura dell'ambiente. I servizi saranno ottenuti grazie ad uno strumento grafico di programmazione, che consentirà una buona panoramica delle funzionalità offerte, oltre a un editing veloce per l'adattamento agli eventuali cambiamenti apportati durante le diverse iterazioni del processo di UCD.

• Un framework di Modellazione, per descrivere le parti attive disponibili all'interno del-la soluzione simulata, basandosi sulle ontologie e workflow AAL.Il framework supporta i modelli degli utenti, degli ambienti, delle interazioni e dei servizi. Tali modelli sono costruiti utilizzando lo Strumento di Authoring, forniscono la base funzio-nale per la simulazione dell'ambiente. I modelli degli utenti vengono usati per favorire i rea-lizzatori nel verificare il progetto già durante il suo sviluppo, basandosi su una definizione di limitazioni delle capacità dell'utente e constatando se potrà utilizzare tutti i servizi immagi-nati dal progettista, così da poter adattare la soluzione di conseguenza. La modellazione del-l'ambiente e dell'interazione rende l'attività dell'utente semanticamente significativa per la determinazione di servizi AAL. Questi sono generati mediante un'interfaccia grafica, per un più rapido e semplice set-up, e rappresentano il fondamento di nuove soluzioni alle sfide AAL.

• Un Ambiente di Simulazione in Realtà Virtuale, nel quale gli utenti possono navigare e interagire con la scena simulata per testare i servizi sviluppati nel suo contesto virtuale.In questa fase può essere configurata ed utilizzata una grande varietà di dispositivi differenti. A questo punto, lo sviluppatore può già inserire nel processo gli utenti destinatari, consen-tendo loro di sperimentare la soluzione nel corso della simulazione, traendone un feedback prezioso per eventuali miglioramenti. Oltre alla riproduzione virtuale, l'Ambiente di Simula-zione è anche in grado di integrare dispositivi reali, il che migliora la gamma dei servizi che possono essere testati e fornisce allo sviluppatore la possibilità di un graduale passaggio dal-l'implementazione virtuale della sua soluzione a quella reale, conducendo il test con gli utenti durante tutti gli stadi del trasferimento.

Capitolo 2 Il sistema VAALID 15

• Laboratori in cui il sistema verrà valutato da progettisti ed esperti di usabilità.Le valutazioni avranno luogo in tre diversi paesi europei, Germania, Italia e Spagna, dove le persone sottoposte al test verranno individuate a livello locale. In questo modo sarà possibile ricevere un feedback per il sistema VAALID da parte di utenti provenienti da diverse realtà dell'Unione Europea. Queste verifiche metteranno alla prova sia l'Ambiente di Authoring che quello di Simulazione, fornendo così un feedback specifico su entrambe le parti del si-stema VAALID con cui l'utente entrerà in contatto.

2.1.2 Che cosa non è

Sebbene offra potenti strumenti per l'analisi, la progettazione, l'esperienza ed il test dei servizi di Ambient Assisted Living, VAALID non è un simulatore dell'esperienza degli anziani o dei disabili. VAALID dà semplicemente al progettista la possibilità di controllare la sua soluzione dal punto di vista dell'idoneità ad una certa tipologia di utente, già durante lo sviluppo, verificandola mediante un modello predefinito. Questo può essere utilizzato per rilevare se un certo tipo di utente potrà uti-lizzare i servizi proposti. Dovranno quindi essere accertate le sue capacità nell'eseguire una serie di obiettivi all'interno della scena simulata, sulla base del modello virtuale e dei workflow.

VAALID simula ambienti AAL, compresi i prototipi semplificati della tecnologia utilizzata, oppure può includere dei veri dispositivi o sensori, al fine di sperimentare lo scenario AAL progettato. Dun-que VAALID non potrà mai essere uno strumento di simulazione completo, prevedendo tutte le di-verse tipologie di apparecchiature fisiche che si potrebbero immaginare, nella loro complessità, per una soluzione AAL. Piuttosto la piattaforma VAALID si specializza in un'offerta attentamente sele-zionata di quei servizi e quei dispositivi che, più di frequente, si rivelano necessari per l'Ambient Assisted Living, nel tentativo di favorire la progettazione e lo sviluppo accelerato di tali soluzioni.

2.1.3 Il consorzio

Il consorzio era articolato in otto partner complementari, di quattro Paesi europei (Figura 2.1).Era il risultato di una convergenza tra alcuni settori industriali (comprese piccole e medie imprese) specializzati nell'interaction design, tra gli istituti di ricerca e le università.

L'associazione VAALID fu organizzata e strutturata cercando di unire il maggior numero possibile di competenze, necessarie per conseguirne gli ambiziosi propositi, ma senza che ciò comportasse un eccessivo investimento di risorse su un insieme troppo grande di enti partecipanti.

VAALID è stato strutturato scegliendo un insieme di partner con ruoli importanti nei domini in cui sarebbero stati coinvolti all'interno del progetto, che avessero dunque interesse ed esperienza per partecipare ai diversi pacchetti di lavoro.Siemens aderì e coordinò le prime fasi di definizione dei requisiti. Lasciò il progetto dopo circa un anno dall'inizio dei lavori.

Il principale contributo del Dipartimento di Ingegneria dell'Informazione [7] dell'Università degli Studi di Parma è stato quello allo sviluppo di un ambiente di simulazione con proiettore 3D, con la possibilità d'integrazione di diversi dispositivi d'interazione. La descrizione in dettaglio sarà fornita nel paragrafo 4.4.


2.2 Realizzare l'Ambient Assisted Living

Il principale target del sistema VAALID è costituito dagli sviluppatori di soluzioni AAL. Essi utiliz-zeranno la piattaforma per creare e simulare i loro progetti, ricavando un più veloce feedback per aggiornarli con le eventuali modifiche necessarie. Gli strumenti per la realizzazione di siffatte solu-zioni virtuali consentono una rapida ed efficiente produzione e modifica dei modelli, anch'essi vir-tuali, così come una verifica preventiva in base ad alcune restrizioni specifiche, quali gli handicap di un certo insieme di utenti finali, per assicurarsi che i criteri di sviluppo più importanti siano stati raggiunti prima di testare un qualsiasi prototipo reale.

Figura 2.2 - Ambient Assisted Living

Figura 2.1 ‒ Consorzio VAALID


L'Ambiente di Simulazione è adattato per soddisfare le esigenze dei soggetti di prova più probabili, vale a dire le persone anziane e i portatori di handicap, per i quali si stanno sviluppando [8] le solu-zioni AAL (Figura 2.2). Essi si troveranno in un ambiente immersivo dotato di intuitivi dispositivi d'interazione e potranno quindi fornire un prezioso feedback per i nuovi sistemi.

La costruzione di un Ambiente Virtuale Ambient Assisted inizia con un modello in realtà virtuale dell'ambiente fisico che dovrà essere simulato. Esso è dotato delle rappresentazioni dei sensori e deidispositivi, similmente a come dovrebbe essere configurato un ambiente reale per il test del sistema AAL. Il test su ambiente reale tuttavia è un processo che costa tempo e denaro, il che limiterà inevi-tabilmente l'esercizio della creatività del designer e quindi la qualità della soluzione finale.

La simulazione dei servizi intelligenti è fatta utilizzando i workflow AAL e le ontologie, che possono essere modellati graficamente e consentono in tal modo sia un veloce set-up che la modifica delle soluzioni.

La piattaforma VAALID supporta la necessaria transizione da una rappresentazione virtuale ad un ambiente reale. Connesso a questo sistema visivo sono i dispositivi d'interazione, realizzati in modo specifico per l'utilizzo anche da parte delle persone anziane e dei disabili, consentendo indi un'im-mersione ancora più intensa nella simulazione e rendendo accessibile la simulazione 3D ad una va-sta gamma di test. Ciò è necessario affinché la soluzione venga correttamente valutata.

Le persone anziane ed i portatori di handicap possono sentirsi parte dell'ambiente virtuale e sono in grado di provare vere soluzioni AAL senza alcun bisogno d'essere sostituiti da una forma di avatar. VAALID ambisce a portare gli ambienti virtuali ad una nuova forma di esperienza, mettendo l'utente reale al centro delle simulazioni AAL. Mentre le rappresentazioni come gli avatar ostacolerebbero il processo fondamentale di immersione, rendendo indiretta l'interazione con la simulazione, VAALID sceglie la strada opposta di creare un'esperienza totalmente immersiva per l'utente, in un ambiente che gli consenta di percepire le nuove soluzioni il più direttamente possibile.

Così VAALID intende contribuire allo sviluppo di soluzioni AAL significative, che siano disponibili per un'ampia varietà di soggetti, rendendo il processo di progettazione più veloce ed efficiente.

2.3 Contributo allo User-Centered Design

Per una più efficace ed efficiente produzione di nuovi sistemi interattivi, quali le soluzioni AAL, che abbiano un'elevata usabilità e siano accettabili per gli anziani e i disabili, è necessario coinvolgere gli utenti finali durante tutto il processo di sviluppo. Ciò risulta essere particolarmente importante per tutti quei prodotti che saranno introdotti nel prossimo futuro.

Uno dei possibili metodi per conseguire quest'obiettivo è la procedura iterativa, lo Human Centered Design (HCD) Process, descritta nella norma ISO/DIS 9241-210 [9]. Questo approccio supporta l'intero processo di elaborazione dei sistemi interattivi basati sul computer, mediante alcune attività user-centered. Lo scopo primario è che i sistemi risultanti siano semplici da utilizzare ed abbiano un reale valore aggiunto per i destinatari e beneficiari previsti.


2.3.1 Le fasi del processo

Lo User-Centered Design (UCD) [10] è un metodo di progettazione che considera in primo luogo i bisogni, i desideri e le condizioni degli utenti finali di un certo prodotto, cercando di ottimizzarlo in base a come loro potrebbero o vorrebbero utilizzarlo, senza gravare su di essi l'onere di adattare i propri comportamenti per poterlo accettare.

Nonostante gli evidenti benefici, l'utilizzo dello UCD nel settore dell'industria ICT è ancora limita-to, a causa dei costi. Infatti, per sistemi più complessi, lo UCD si rivela essere non solo inefficiente, ma anche inefficace nel migliorare l'accessibilità, poiché non esistono gli strumenti adeguati.

Il progetto VAALID intende superare questi limiti sfruttando una metodologia AAL User-Centered e lo sviluppo di strumenti di supporto ed assistenza al computer, che potranno essere utilizzati dagli Interaction Designers ed Usability Engineers. Una sintesi del processo risultante è illustrata in Figura 2.3, nella quale si possono riconoscere quattro stadi distinti.

Figura 2.3 - Fasi dello UCD con la piattaforma VAALID


1. Ideazione:Lo scopo principale di questa fase è quello di elaborare i requisiti, sia quelli funzionali che quelli non funzionali. I primi specificano le funzioni inserite nella soluzione AAL proposta e come essa reagisce e si comporta; i secondi sono i vincoli da considerare nel sistema.

• Lo Usability Engineer utilizza l'Ambiente di Simulazione VAALID per presentare agli utenti finali un'ampia gamma di situazioni reali e suscitarne le reazioni, per rile-vare così le loro esigenze ed obiettivi.

• L'Interaction Designer ricorre all'Ambiente di Authoring VAALID per modellare i profili degli utenti (virtuali), le modalità e i dispositivi d'interazione, in modo tale da visualizzare le soluzioni concettuali. Usufruisce inoltre dell'Ambiente di Simulazione VAALID per esplorarle insieme ai destinatari reali.

2. Progettazione:L'obiettivo è definire le specifiche della soluzione AAL che saranno poi utilizzate dal team di sviluppo nella fase successiva. Il progetto teorico, che affronta e considera tutti gli aspetti, è creato e riflesso in prototipi a bassa fedeltà, che vengono valutati dai cittadini anziani o dai disabili. Le iterazioni sono guidate da eventuali feedback da parte dei beneficiari, fino al completo soddisfacimento dei requisiti.

• L'Interaction Designer si serve dell'Ambiente di Authoring VAALID per progettare la soluzione AAL e per la creazione dei prototipi virtuali dei servizi coinvolti, compresi gli scenari virtuali abilitati per l'AAL.

• Lo Usability Engineer adopera l'Ambiente di Simulazione VAALID per immergere gli utenti nella soluzione AAL per mezzo del prototipo virtuale, onde avere l'esperien-za con i nuovi dispositivi e modalità d'interazione, ricavare le reazioni degli utenti ed identificare subito i problemi di gradimento ed accessibilità.

3. Realizzazione:L'intento è quello di costruire i prototipi della soluzione AAL. L'attività chiave è il tradurre un progetto concettuale in un modello concreto e dettagliato, che comprenda dei prototipi ad alta fedeltà, realmente codificati e pienamente funzionali.

• Lo Usability Engineer, mediante l'Ambiente di Simulazione VAALID, intende valida-re i componenti sviluppati, basandosi sulle caratteristiche d'accessibilità e avvalendo-si della libreria di utenti virtuali, al fine di suggerire alcuni miglioramenti o altre azioni correttive all'Interaction Designer.

• L'Interaction Designer utilizza l'Ambiente di Authoring VAALID per migliorare la soluzione progettuale sulla base dei consigli ricevuti dallo Usability Engineer.

4. Collaudo e verifica:L'obiettivo principale di questa ultima fase è quello di validare l'implementazione finale dei prototipi della soluzione AAL, per accertare che risultino convenienti, soddisfino i criteri di mercato e le esigenze dei beneficiari.

• Lo Usability Engineer utilizza l'Ambiente di Simulazione VAALID per verificare la correttezza dell'implementazione definitiva, prima rilevando i problemi di usabilità con lo strumento automatico di VAALID e successivamente con gli utenti reali.


2.3.2 I vantaggi

Quando si è nella necessità di una rapida successione tra informazione/feedback/diagnosi, l'ISO/TR 16982:2002(E) [11] raccomanda diversi metodi, tra i quali le interviste, i questionari e lo studio del comportamento degli utenti. Ma progettare e validare soluzioni AAL tramite un approccio manuale è un impegno che dilata inesorabilmente i tempi, imponendo un elevato carico di lavoro, che sovente termina con l'adozione di soluzioni premature, vale a dire sub-ottimali.

L'IDE (Integrated Development Environment) VAALID intende superare queste limitazioni del pro-cesso HCD, essendo uno strumento per una celere realizzazione di prototipi, ed incentivare i proget-tisti nel trovare soluzioni velocemente, garantendo un ciclo iterativo di produzione più semplice. Inoltre, essendo integrato, potrà originare una conseguente e significativa riduzione dei costi globali di design e sviluppo. Dovendo fornire un supporto nell'applicare i metodi associati al processo HCD, le esigenze e problemi degli utenti finali dovranno essere al centro dell'attenzione in ogni fase della progettazione.

Grazie agli strumenti informatici di supporto, potrà essere creata una prima soluzione di massima, ricavata con un carico di lavoro relativamente leggero. Questa dovrà quindi essere valutata in una fase molto precoce di sviluppo ed essere perfezionata passo passo mediante l'IDE VAALID. Iterati-vamente, un'ulteriore validazione od altre preziose attività potranno essere svolte, ad esempio, pri-ma del test in un laboratorio fisico, solitamente denominato Living Lab nel contesto AAL.

2.4 La metodologia di progetto

VAALID affronta il problema della progettazione di interfacce utente e di modalità d'interazione che siano accessibili ed usabili da parte delle persone anziane o disabili che vivono in ambienti AAL.

Tre saranno le tipologie di elemento con le quali il designer si troverà a dover lavorare: gli utenti, gli ambienti e le loro interazioni. L'utente si riferisce alla persona destinataria, oppure al gruppo di persone contraddistinte da capacità simili, che sarà immerso nello spazio AAL. L'ambiente specifica lo scenario fisico e i dispositivi che saranno utilizzati dall'utente. L'interazione identifica i diversi compiti e le attività che la soluzione AAL consentirà di eseguire, grazie alle funzionalità fornite da quegli stessi dispositivi.

Il metodo scelto per VAALID non è finalizzato alla ricerca di un unico sistema valido per tutti, ma s'affiderà a quello in grado di affrontare la gamma più ampia possibile tra le capacità, competenze, esigenze e preferenze umane. Il risultato di tale processo non sarà un progetto, ma sarà un insieme di progetti, con quelle appropriate alternative che abbiano un fondamento logico a supportarle.

Considerate le quattro fasi dello UCD esposte al paragrafo 2.3.1, il framework prevede due Ambien-ti di lavoro, uno di Authoring e l'altro di Simulazione, che offrono all'Interaction Designer un com-plesso di strumenti, onde poter comprendere appieno le molteplici varianti d'usabilità e d'accessibi-lità della soluzione AAL proposta.


2.4.1 L'approccio alla soluzione

La grande novità di VAALID consiste nella peculiare combinazione ed integrazione dello Strumento di Authoring e dell'Ambiente di Simulazione, che rende possibile il progresso attraverso un ciclo virtuoso di progetto-sviluppo-test, fornendo un notevole supporto nella concezione, messa a punto e realizzazione delle soluzioni AAL.

Infatti, il sistema consente la modifica dinamica e la regolazione dei modelli tramite lo Strumento di Authoring e un loro immediato sviluppo e test nell'Ambiente di Simulazione, fornendo un concreto paradigma di sviluppo rapido per applicazioni AAL.

In questo modo VAALID aiuta a colmare il divario tra la fase di pianificazione delle soluzioni AAL e la loro sperimentazione e valutazione nella realtà fisica (es. in un laboratorio vivente), introducendo alcuni importanti vantaggi:

• possibilità di diagnosi anticipata, in silico, dei difetti potenzialmente dispendiosi, prima che le risorse siano effettivamente impiegate per l'implementazione e la produzione;

• processo decisionale più rapido, grazie alla riduzione del tempo necessario durante il ciclo di progettazione-sviluppo-test;

• migliore ricerca di soluzioni innovative, tramite la conduzione di analisi what-if efficienti;• potenzialità per affrontare le esigenze di un vasto numero di categorie di cittadini anziani o

disabili, orientandosi velocemente tra i loro diversi profili;• gestione di nuove tipologie d'informazione, non raggiungibili con mezzi tradizionali, come

ad esempio le indicazioni sul comportamento degli anziani.

Queste caratteristiche aspirano a favorire un significativo avanzamento nella progettazione AAL, con un conseguente miglioramento della qualità e dell'innovazione del prodotto, riducendo il time-to-market ed i costi d'implementazione in un settore relativamente giovane, il cui sviluppo dipende-rà soprattutto dall'ottimizzazione del rapporto tra costi e benefici.

Nella Figura 2.4 i componenti VAALID e le loro reciproche interconnessioni sono rappresentati in forma grafica. Sono mostrate anche le varietà delle parti interessate più importanti e le modalità con cui esse si relazionano al sistema.

I primary users della Piattaforma VAALID sono i professionisti che si occupano della concezione, progettazione, collaudo e validazione degli aspetti umani delle soluzioni AAL.

Essi possono essere classificati in due categorie principali:

• Interaction Engineers, che progettano la struttura globale mediante i profili dei beneficiari, i dispositivi e le modalità d'interazione, sviluppando ed esplorando le diverse soluzioni;

• Usability Engineers, i quali analizzano l'interfaccia tra i servizi AAL e i destinatari, suscitano le loro reazioni e individuano le loro esigenze ed obiettivi.

Questi specialisti, che in generale lavorano per società impegnate nel progetto, produzione o valuta-zione delle soluzioni AAL, dovrebbero essere i principali fruitori della Piattaforma VAALID e ricor-rere ampiamente ad essa nel corso della loro quotidiana attività professionale.


Una seconda tipologia essenziale è rappresentata dai beneficiaries, ossia gli anziani e i disabili, che saranno gli utenti finali dei servizi AAL, realizzati con il supporto di VAALID. Infatti, essi saranno interfacciati proprio alla Piattaforma VAALID, direttamente oppure grazie a dei loro rappresentanti, potendo così partecipare alle sessioni di test e validazione all'interno dell'Ambiente di Simulazione, dove saranno sperimentate le relative modalità d'interazione e saranno analizzate le loro necessità, mentre si condurranno i necessari studi sui loro profili.

Oltre alle esigenze degli utenti primari e alle necessità espresse dai beneficiari, il sistema dovrà af-frontare anche i requisiti dei vari secondary users che, pur non essendo direttamente coinvolti nel-l'utilizzo di VAALID, potrebbero ancora beneficiare di esso in modo indiretto. Essi sono:

• System designers di aziende che realizzano i componenti delle soluzioni AAL, come sensori, attuatori, software di controllo, ecc. Possono quindi convalidare gli aspetti dell'accessibilità ed usabilità dei propri prodotti, sempre nell'ambito di scenari AAL creati con la Piattaforma VAALID, lavorando in collaborazione con gli Usability ed Interaction Engineers;

• System designers in aziende che comprano ed implementano soluzioni AAL - come le società di costruzione, i centri di cura, le pubbliche amministrazioni, gli studi di interior design, ecc. Questi possono utilizzare le funzioni di simulazione in silico di VAALID al fine di:✔ migliorare la visualizzazione e discussione delle esigenze di un'applicazione AAL con gli

Usability ed Interaction Engineers responsabili della progettazione ed implementazione;✔ visualizzare, comprendere e discutere le soluzioni specifiche proposte dagli Usability ed

Interaction Engineers, i loro pro e contro, i compromessi necessari, ecc.

Figura 2.4 - Componenti VAALID


Per rispondere alle richieste degli utenti secondari, VAALID deve fornire interfacce adeguate con gli strumenti esterni da loro utilizzati, così da agevolare l'importazione e l'esportazione di nuove infor-mazioni sui progetti esistenti.

2.4.2 Potenziali utenti della piattaforma

La piattaforma VAALID ha l'obiettivo di supportare i programmatori ICT nel sviluppare le soluzioni AAL per gli anziani e i disabili. Tuttavia saranno anche altri i protagonisti coinvolti da tale sistema e dovranno quindi essere a loro volta considerati come utenti VAALID (Figura 2.5).

Per chiarire il loro ruolo all'interno del progetto, sono stati definiti tre livelli di partecipazione:

• Gli utenti finali sono quelli con il più alto livello di coinvolgimento, dato che lavoreranno direttamente sui risultati, sulle metodologie e sugli strumenti d'elaborazione. In altri termini, essi saranno proprio quegli Usability Engineers (UE) ed Interaction Designers (IxD) che contribuiranno a VAALID individuando esigenze e valutazioni dei fruitori che subentreranno durante le diverse fasi del progetto.

• I beneficiari della piattaforma VAALID sono innanzitutto gli anziani e i disabili, in quanto destinatari delle soluzioni AAL sviluppate utilizzando i risultati del progetto. In un secondo tempo, seguendo questo stesso approccio, il prodotto potrà essere facilmente esteso anche ad altre categorie di persone, sia giovani che adulti, con problemi di natura diversa e d'intensità moderata o rilevante: infatti, una delle caratteristiche della piattaforma VAALID sarà la sua adattabilità a qualunque tipo di validazione dell'accessibilità.

• Le terze parti, o beneficiari indiretti, sono tutti coloro i quali potrebbero essere interessati all'utilizzo della piattaforma VAALID come un servizio di consulenza: per esempio, un im-prenditore che volesse valutare l'accessibilità e la fruibilità di uno dei suoi prodotti nel con-testo AAL, o un architetto che desiderasse verificare l'idoneità di un progetto per gli anziani e i disabili, ecc. Il loro ruolo nel progetto VAALID sarà limitato alle attività connesse alla valu-tazione ed accertamento delle sue possibilità d'impiego.

Figura 2.5 - Potenziali utenti della piattaforma VAALID


2.5 Architettura di VAALID

Il sistema VAALID potrà essere utilizzato in tutte le fasi del ciclo di progettazione di soluzioni AAL. Sulla base di una metodologia che pone al centro l'utente, il progetto è articolato in due ambienti di lavoro (Figura 2.6): l'Ambiente di Authoring e l'Ambiente di Simulazione.

Il cuore dell'Ambiente di Authoring è lo strumento di authoring, che consente ai progettisti di creare e sviluppare i singoli elementi sui quali è strutturata l'interazione di una simulazione AAL. Questa componente basata sul 3D offrirà la realizzazione di tre diversi modelli:

• Modello degli utenti (descrizione fisica e sensoriale, ad es. mobilità ridotta o non vedente);• Modello dell'ambiente (casa intelligente, aeroporto, stazione, posto di lavoro, …);• Modello d'interazione del servizio AAL (attuale o futuro).

Essi potranno essere raccolti in una libreria, condivisa ed arricchita dagli Interaction Engineers. La libreria include: i sensori, le interfacce e gli attuatori che possono essere integrati nello spazio AAL; i modelli formali per rappresentare i diversi profili degli anziani e dei disabili (chiamati “beneficiari virtuali” nel contesto VAALID); le molteplici modalità per interagire con l'ambiente circostante.

Poiché tali modelli dovranno essere eseguiti durante la simulazione del servizio AAL, è importante che siano definiti secondo due prospettive, la prima con l'esposizione della struttura e delle relazioni interne a ciascheduno, la seconda per descrivere la loro interazione con l'esterno.

Le Ontologie forniscono le specifiche dei concetti coinvolti nella simulazione, mentre i Workflow sono utilizzati per le dinamiche dei processi d'interazione, vale a dire per specificare il modo in cui l'utente, l'ambiente e la soluzione AAL interagiscono tra loro.

Figura 2.6 - L'architettura di VAALID


I tre modelli concepiti grazie all'Ambiente di Authoring sono usati dall'Ambiente di Simulazione al fine di produrre un progetto dettagliato, sostenerne la costruzione e validarlo. Essi (servizio, utente ed ambiente) sono eseguiti insieme dal simulatore del servizio AAL, durante lo sviluppo, generando un feedback prezioso per i progettisti riguardo all'accessibilità, all'usabilità e al consenso da parte dell'utente.

I test, le simulazioni e convalide sono condotti sia tramite utenti finali reali in ambiente immersivo (realtà virtuale 3D oppure aumentata) che mediante utenti virtuali (caratterizzati dai loro modelli di comportamento). Gli anziani e i disabili potranno così sperimentare alcuni scenari AAL, creati con il supporto dell'Ambiente di Authoring, che offriranno dati cruciali circa le reazioni, le preferenze ed i requisiti di accessibilità ed usabilità.

La Figura 2.7 mostra le tre componenti, per ognuno dei due ambienti di lavoro in cui è strutturata la piattaforma VAALID, che saranno descritte brevemente nel prosieguo del paragrafo.

2.5.1 Strumento di caratterizzazione del modello utente

Lo strumento di caratterizzazione del modello utente ha lo scopo di definire le capacità e le eventua-li limitazioni del futuro beneficiario della soluzione AAL. Ad esempio, se viene progettato un servi-zio per un utente anziano con ridotte capacità visive, è bene che si tenga conto di tali caratteristiche.Il progettista potrà ricorrere a diversi profili, memorizzandoli nella libreria dei modelli.

Nell'ambito del processo di UCD, è necessario stabilire chi saranno gli utenti destinatari di un pro-dotto, quale la loro diffusione e quali le loro differenze individuali. Il progettista dovrebbe mirare a garantire che tutti i requisiti utente siano affrontati e che vi sia effettivamente un contributo verso l'integrazione delle necessità delle persone anziane e disabili.

Il modello selezionato per l'implementazione in VAALID mediante le ontologie si basa sull'Interna-tional Classification of Functioning, Disability and Health (ICF) [12] dell'Organizzazione Mondia-le della Sanità, in cui si chiede un equilibrio tra un approccio puramente medico ed uno puramente sociale nel descrivere le condizioni delle persone. Questa compensazione permette di valutare quel-le limitazioni che non sono dovute solo a menomazioni fisiche, ma che producono un risultato equi-valente per il sistema proposto.

Figura 2.7 - Piattaforma VAALID


Per quanto riguarda le capacità selezionate per essere incluse nel modello dell'utente, sono state ri-spettate le raccomandazioni dell'ETSI (European Telecommunications Standards Institute) sugli at-tributi che dovrebbero essere considerati per avere un impatto diretto sulla corretta applicazione di un prodotto e dei servizi ICT [13]:

• abilità sensoriali come la vista, l'udito, il tatto, il gusto, l'olfatto e l'equilibrio;• abilità fisiche come la parola, la destrezza, la mobilità, la forza e la resistenza;• abilità cognitive come l'intelletto, la memoria, il linguaggio e l'alfabetizzazione.

2.5.2 Il costruttore del modello ambiente.

Il costruttore del modello dell'ambiente è uno strumento di editing che importa la scena 3D da qual-siasi interfaccia grafica utente (i cosiddetti strumenti di progettazione 3D, come 3D Studio Max) ed assegna le proprietà ed il comportamento desiderato agli elementi che sono rilevanti per l'interazio-ne con il servizio AAL.

Di solito gli ambienti che sono più frequentemente oggetto dei servizi AAL sono i luoghi “chiusi”, come un residence, un ospedale, una casa, ecc. Nella maggior parte dei casi, questi servizi vengono impiegati nell'abitazione dell'utente. Ci sono invece altri servizi AAL che sono pensati per spazi più “aperti”, come una stazione ferroviaria, della metropolitana, ecc.Ciascuna varietà di ambiente ha i propri oggetti; alcuni sono proattivi, altri producono una certa rea-zione quando giunge uno stimolo: determinano, cioè, una risposta per l'ambiente.

Le applicazioni VAALID proposte e testate nel progetto sono limitate all'ambiente domestico. Tutta-via, l'ontologia sviluppata potrà comunque essere estesa o adattata anche ad altri spazi.

2.5.3 Il compositore del servizio AAL

Il compositore del servizio AAL è lo strumento di progettazione volto alla creazione del workflow relativo a tale servizio. Esso riceve i modelli dell'ambiente e dell'utente, in base ai quali stabilisce le connessioni e l'accessibilità tra i diversi elementi della scena. L'obiettivo è quello di costruire le fun-zionalità e il comportamento del servizio reale desiderato.

Come conseguenza della complessità di un Ambiente Intelligente, dove la persona è immersa in un spazio che corrisponde alle sue esigenze e preferenze, sono stati sviluppati nuovi modelli d'intera-zione tra l'uomo ed il computer, come quello che verrà utilizzato per la descrizione dei Servizi AAL nella piattaforma VAALID, lo Human Computer Interaction [14].

Per quanto concerne le funzionalità di accessibilità degli elementi di interazione, VAALID rispetta le specifiche ISO/IEC 24756:2009 [15] per un framework che definisca un profilo di accesso comune (PAC) delle esigenze e capacità degli utenti, dei sistemi informatici e dei loro ambienti, compreso il supporto dovuto alle tecnologie d'assistenza. Esso fornisce una base per individuare ed affrontare i problemi d'accessibilità in modo standardizzato su piattaforme multiple e verrà usato nell'Ambiente di Simulazione al fine di validare la soluzione AAL progettata per determinati utenti.


2.5.4 Il pannello di controllo della simulazione

Il pannello di controllo della simulazione è l'interfaccia utente nella sessione di simulazione, il suo strumento di configurazione. Ne consente la selezione dei parametri, il controllo dell'esecuzione, l'attivazione degli eventi, l'analisi dei risultati e, cosa più importante, la progettazione definitiva. VAALID prevede diversi livelli di simulazione a seconda della fase del processo di UCD in cui il progettista utilizza il pannello:

• Verifica dei vincoli di accessibilità : durante la fase di progettazione e implementazione, sarà possibile rilevare automaticamente l'accessibilità dai profili corrispondenti agli elementi in-clusi nella simulazione. Può essere visto come l'equivalente per le soluzioni AAL di uno stru-mento per la valutazione automatica dell'accessibilità del web;

• Verifica dei workflow : usato durante la fase di progettazione, non richiede la visualizzazione della scena 3D, poiché il suo obiettivo è quello di verificare che i workflow coinvolti nella simulazione siano ben definiti e di verificarne le prestazioni. Esso fornirà al progettista un elenco degli errori, per esempio i nodi mai raggiunti;

• Anteprima della simulazione del Servizio AAL : utilizzato durante la fase di concezione e di progettazione, userà il browser di simulazione 3D per presentare al progettista la scena 3D ed i suoi oggetti, permettendo di navigare ed interagire con i suoi elementi e convalidare la qualità dello scenario in cui gli anziani o i disabili saranno immersi;

• Simulazione del Servizio AAL : utilizzato durante la fase di progettazione e test, metterà a di-sposizione una simulazione immersiva, per provare con gli utenti reali l'usabilità della solu-zione AAL. Essa permetterà al progettista di catalogare tutte le interazioni tra gli utenti reali e la soluzione AAL simulata. I risultati saranno posti in un registro di tutte le azioni eseguite dai partecipanti alla simulazione, insieme al feedback diretto da parte degli utenti circa la loro esperienza.

2.5.5 Il browser della simulazione 3D

Il browser della simulazione 3D è il motore di rendering per le scene. L'utente è immerso in esso e gli è consentito d'interagire con la rappresentazione del servizio AAL che viene eseguito su di esso. Si basa sullo sviluppo del Fraunhofer Institute for Computer Graphics Research IGD denominato InstantReality e può presentarsi sia come semplice schermo che come realtà virtuale Cave.L'interazione tra il player InstantReality e l'utente avviene per mezzo di dispositivi d'interazione 3D. I dispositivi di interazione 3D sono le interfacce fisiche che l'utente utilizza per “toccare” gli oggetti dell'InstantReality: alcuni esempi di dispositivi in uso sono guanti, puntatori, Wiimote (Figura 2.8).

2.5.6 Il verificatore Living Lab

Invece di utilizzare il browser 3D, l'utente è invitato a verificare il servizio AAL in ambiente reale, tramite veri dispositivi d'interazione. Tale modalità di sperimentazione è detta “Living Lab”. Il labo-ratorio deve essere integrato con il modello del servizio, al fine di valutare gli aspetti di usabilità della soluzione.Generalmente il Living Lab viene utilizzato nell'ultima fase del processo di simulazione, ma la stes-sa infrastruttura può essere adoperata per convalidare i singoli dispositivi d'interazione. I dispositivi reali possono così essere adattati all'ambiente 3D, al modello del servizio oppure ad altri elementi.


2.6 Tecnologie utilizzate per gli Scenari

In questo paragrafo sono illustrati i principali strumenti software o linguaggi menzionati nella tesi ed utili per la realizzazione in VAALID di uno Scenario AAL:

• VRML;• Ontologie;• Workflow;• InstantReality;

VRML è il linguaggio impiegato per la costruzione della scena 3D, che si articola in un ambiente e in un certo numero di dispositivi coinvolti. Ha il vantaggio di essere un linguaggio ad alto livello, a differenza di OpenGL, per esempio. È possibile creare i modelli utilizzando le primitive delle forme geometriche oppure un editor di grafica 3D (3D Studio Max, Blender, ecc.). Nel caso specifico, gli Scenari del Capitolo 3 sono stati esportati nel formato wrl grazie a 3D Studio Max.

La maggior parte delle ontologie di VAALID è utile a descrivere l'ambiente, i dispositivi inseriti e gli utenti virtuali che dovranno confrontarsi con il sistema. Offrire una tassonomia degli oggetti che si trovano in un certo ambiente, le specifiche e funzionalità dei possibili dispositivi, le caratteristiche principali dei modelli per una fedele riproduzione dei beneficiari reali, sono tutti contributi fondativi per determinare l'evoluzione di una soluzione AAL.

D'altra parte, questa necessità di definire un meccanismo efficace che descriva il comportamento che gli elementi avranno durante la simulazione è stata affrontata mediante l'uso di workflow. Quin-di in tali termini dovranno essere espresse le loro interazioni.Questa dinamica è semplificata da una ricerca condotta proprio per selezionare le proprietà e azioni strettamente connesse ai servizi AAL, specificando una versione essenziale del linguaggio.

Figura 2.8: Nintendo Nunchuk (sx) e Wiimote (dx)


Il framework InstantReality offre un insieme completo di funzionalità per supportare sia la classica Realtà Virtuale (VR) che l'avanzata Realtà Aumentata (AR). Ad un'interfaccia semplice si associano gli ultimi risultati della ricerca nell'ambito del rendering ad alto realismo, dell'interazione 3D con l'utente e nella tecnologia per la visualizzazione totale-immersiva. È inoltre previsto l'uso di diversi standard industriali, come VRML e X3D.

2.6.1 Il VRML

La norma ISO/IEC 14772 [16] definisce un formato, il Virtual Reality Modeling Language (VRML), per i file che integrano grafica 3D e multimedialità. Concettualmente, ogni file VRML è uno mondo 3D interattivo, virtuale ma con una dimensione temporale, che contiene oggetti grafici e acustici che possono essere modificati dinamicamente.

La semantica del VRML descrive un comportamento funzionale astratto e non specifica i dispositivi fisici o qualsiasi altro concetto dipendente dall'implementazione (come la risoluzione dello schermo e le periferiche di input/output). Essendo in pratica multi-piattaforma, consente un'ampia libertà nel-l'interpretare e realizzare fisicamente le diverse funzionalità.

Il VRML può anche essere utilizzato su Internet, intranet e sistemi client locali, essendo un formato di scambio universale. Esiste una grande varietà di aree d'applicazione quali l'ingegneria, le mostre multimediali, l'intrattenimento, le pagine web e i mondi virtuali condivisi.

Il VRML è stato progettato per soddisfare i seguenti requisiti:

• Authorability - consentire lo sviluppo di programmi informatici per creare, modificare e cu-stodire i file VRML, così come programmi di traduzione automatica per la conversione in VRML dei più comuni formati di file per la grafica 3D;

• Componibilità - poter utilizzare e combinare gli oggetti 3D dinamici all'interno di un mondo VRML, supportando la riusabilità dei precedenti;

• Estensibilità - aggiungere nuove tipologie di oggetto, non esplicitamente definite in VRML;• Essere in grado d'implementare - implementazione su una vasta gamma di sistemi;• Performance - migliorare le prestazioni, che devono risultare scalabili ed interattive su una

vasta gamma di piattaforme informatiche;• Scalabilità - abilitare mondi dinamici 3D arbitrariamente grandi.

VRML è in grado di rappresentare oggetti 3D dinamici e multimediali, statici ed animati, mediante dei collegamenti ipertestuali ad altri mezzi quali testo, suoni, filmati e immagini. I browser VRML, come pure gli strumenti di authoring per la creazione di file VRML, sono ampiamente disponibili.

Qualunque file VRML:

(a) stabilisce implicitamente uno spazio di coordinate-mondo per tutti gli oggetti definiti, valido anche per tutti quelli semplicemente inclusi dal file;

(b) definisce in modo esplicito e combina un insieme di oggetti 3D e multimediali;(c) può specificare collegamenti ipertestuali ad altri file e applicazioni;(d) può definire i comportamenti degli oggetti.


Una qualità importante del VRML è la possibilità di comporre insieme più file, grazie al processo d'inclusione, e di relazionarli attraverso i collegamenti ipertestuali. Ad esempio, considerare il file earth.wrl, che specifica un mondo contenente una sfera, rappresentazione della Terra: esso potrà contenere i riferimenti a una serie di altri file VRML che rappresentino le città (come paris.wrl). Il file principale, earth.wrl, definirebbe il sistema di coordinate globali, cui sono soggette tutte le città. Il file di ciascuna di esse, invece, avrebbe un suo sistema di coordinate locali.

L'inclusione gerarchica dei file consente la creazione di mondi arbitrariamente grandi e dinamici. Pertanto, VRML garantisce che ognuno sia completamente descritto dagli oggetti in esso contenuti.

Un'altra caratteristica essenziale del VRML è l'essere orientato all'uso in ambiente distribuito, come il World Wide Web. Infatti, diversi campi e funzionalità integrate nel linguaggio supportano i file più diffusi, tra cui:

(e) l'inclusione di altri file VRML;(f) i collegamenti ipertestuali ad altri file;(g) l'utilizzo degli standard Internet ed ISO per altri formati di file;(h) la definizione di una sintassi compatta.

2.6.2 Le Ontologie

Le ontologie definiscono il linguaggio e le espressioni utilizzate per descrivere e rappresentare un certo dominio di conoscenza. Sono usate nell'ambito della scienza del computer per la condivisione semantica. In tale campo, Gruber propose in [17] di definire l'ontologia come un tipo di conoscenza condivisa, che stabilisce il vocabolario valido per essere utilizzato nel contesto previsto, così come i suoi oggetti e le relazioni tra loro, mediante una rappresentazione formale.

La gestione di grandi quantità di dati necessita di una soluzione robusta ed efficiente. Le ontologie possono soddisfare questo bisogno, perché nate con l'obiettivo di specificare e conservare i concetti, insieme alle eventuali relazioni tra loro, in modo gerarchico, al fine di condividere e riutilizzare le conoscenze acquisite su un certo dominio.

Per VAALID le ontologie modellano il contesto in cui è coinvolto il beneficiario, ovvero l'ambiente, gli utenti virtuali, i dispositivi, l'esposizione dei servizi forniti e delle interazioni. I risultati di questa ricerca nell'ambito dell'AAL sono i seguenti:

• Utente : l'insieme dei concetti che costituiscono il suo profilo (antropologici e anagrafici), le sue condizioni fisiche, capacità e preferenze.

• Ambiente : le principali informazioni circa gli elementi presenti, i dispositivi, le dimensioni e le condizioni ambientali (illuminazione, umidità, rumore, temperatura, ecc.).

• Servizio AAL : raccoglie i dettagli relativi alle sue funzionalità, al flusso e successione delle azioni, ai suoi parametri, al tipo di chiamata, ecc.

• Interazione : descrive le competenze di ciascun elemento presente nello scenario e gli aspetti d'accessibilità nelle loro interazioni.

La Figura 2.9 presenta le relazioni tra i quattro modelli precedentemente elencati.


Per quanto concerne il modello dell'ambiente, VAALID definisce i piani, entità che possono essere poste a diversi livelli da terra; ciascun piano può essere articolato in più spazi, ognuno dei quali po-trà essere classificato come stanza, scala o rampa. Gli spazi hanno certe dimensioni, condizioni am-bientali (temperatura, umidità, ...) e possono contenere diversi oggetti o dispositivi. Gli elementi sono controllabili o incontrollabili: soltanto i primi avranno degli stati, dei servizi (funzionalità) ed eventi per comunicare. In VAALID sono classificati come elementi controllabili gli elettrodomestici, i dispositivi (sensori e attuatori), e l'illuminazione. Elementi incontrollabili sono invece le giunzioni (porte e finestre) e i mobili (letti, tavoli, armadi, ...).

Essendo la maggior parte degli attuali servizi e soluzioni AAL rivolti agli anziani e alle persone con particolari esigenze, disabilità o handicap, VAALID specifica inoltre le caratteristiche e funzionalità dell'utente che deve essere modellato. In questo modo, oltre ai dati anagrafici (nome, indirizzo, ecc) e antropologici (età, sesso, altezza, peso, ecc), l'utente virtuale è descritto anche mediante le sue abi-tudini e capacità.

Tra le diversi tipologie di abitudini individuate, soltanto quelle più significative per il contesto AAL sono state conservate ed aggiunte al modello ontologico dell'utente, per esempio quelle relative al-l'assunzione di farmaci, al riposo e ai lavori domestici. Tutte queste informazioni potranno essere utilizzate in un servizio AAL per determinare se l'utente sta agendo in modo diverso rispetto al suo quotidiano, se sta dimenticando qualcosa oppure semplicemente per fornire un supporto.

In relazione alla definizione delle capacità dell'utente e delle interazioni, VAALID ha scelto la classi-ficazione ICF, già discussa nel paragrafo 2.5.1.I concetti individuati riguardano le abilità sensoriali, fisiche e cognitive: le prime si riferiscono alla vista (campo visivo, acuità e qualità visiva), all'udito (distinzione di suoni e parole), all'equilibrio e alla sensibilità (temperatura, vibrazione e pressione); le seconde alla resistenza ed alla manualità (sollevare, trasportare o riporre oggetti), alla parola (emissione di suoni e vocaboli), alla forza e alla destrezza (tirare, afferrare, spingere, …), alla mobilità (movimenti volontari e involontari); le ultime all'intelletto, all'attenzione, all'orientamento (tempo, spazio e persone), al linguaggio (comprensione ed espressione) e alla memoria (breve e lungo termine).

Tutti i modelli forniti all'interno di VAALID consentono al progettista di descrivere alcuni elementi che potranno partecipare a una soluzione concreta AAL, sono integrati nell'Ambiente di Authoring e saranno utilizzati in diversi momenti durante il processo di sviluppo.

Figura 2.9 - Relazioni tra i modelli d'ontologia VAALID


2.6.3 I Workflow

Nella letteratura si trovano numerose soluzioni diverse al problema del modellare il comportamento di una certa entità, qualunque essa sia. Esistono per esempio quelle basate su regole che tentano di utilizzare istruzioni scomposte in due parti: la condizione "IF" + l'azione "THEN". Una di queste è il metodo denominato Evento-Condizione-Azione.

Questi criteri furono pensati per agire in risposta ad un evento lanciato dal sistema, ma non erano sufficienti a coprire tutti i possibili casi, necessari invece per modellare un intero comportamento. A poco a poco la struttura del flusso dovette quindi essere modificata, per rispecchiare la condotta del soggetto reale da modellare.

In questo contesto sorse una nuova tipologia di soluzioni, basata sull'utilizzo dei workflow, i quali potevano essere definiti mediante certe regole, oppure anche senza di esse.

Attualmente un workflow è descritto come la specifica formale di un processo. Infatti, ne definisce le azioni, eseguite da esseri umani o da sistemi computerizzati, e l'insieme di transizioni consentite, che realizzano i possibili percorsi che potranno essere seguiti durante l'evoluzione. In maniera più precisa, la Workflow Management Coalition [18] afferma che un workflow è come l'automazione di un processo di business, in tutto o in parte, durante il quale i documenti, le informazioni e i compiti vengono trasferiti da un partecipante ad un altro tramite delle azioni, nel rispetto di un determinato complesso di regole procedurali.

Tradizionalmente i workflow sono stati utilizzati per modellare i processi di business (BPM) e il loro coordinamento (BPC), ma sempre più settori stanno approfittando di queste tecnologie. Proprio per questo motivo nascono nuovi linguaggi e paradigmi che descrivono i workflow, per il successo commerciale ottenuto dalle loro applicazioni. Tra i problemi che la specificazione di un workflow cerca di risolvere vi sono quelli relativi alla leggibilità e all'espressività delle soluzioni proposte (i diversi linguaggi, rappresentazioni, ecc.). Al fine di ottenere la massima efficacia per lo standard dei processi, quest'ultime dovrebbero essere:

• Formali: essere determinate con un linguaggio appropriato.• Eseguibili: consentire di essere lette, elaborate e calcolate dai computer.• Espressive: essere in grado di coprire tutte le situazioni dell'area d'applicazione. È misurata

come la capacità di una lingua specifica di rappresentare situazioni diverse.

• Leggibili: permettere che gli esperti dell'organizzazione comprendano la definizione dei pro-cessi. La leggibilità può essere intesa come la semplicità con cui una persona è in grado di capire il flusso rappresentato da un workflow.

• Tracciabili: rendere tracciabile e controllabile l'esecuzione dei processi.

Una delle questioni più importanti quando si cerca di progettare ed eseguire un workflow è il modo in cui esso è rappresentato. Il linguaggio di specifica deve avere sufficiente espressività ed essere semplice da rappresentare. Il fine è quello di consentire agli esperti, provenienti da diversi settori, di modellare i processi senza conoscere la tecnologia sottostante che stanno utilizzando. Molti sistemi commerciali di gestione dei workflow sono, per questo motivo, sovente accompagnati da utilità gra-fiche, che agevolano la progettazione.


Per VAALID è stato selezionato il Java Business Process Management [19]. jBPM è un sistema di gestione dei workflow che supporta BPEL, Seam pageflow e un proprio linguaggio jPDL (jBPM Process Definition Language), il quale prevede un'interfaccia grafica (Figura 2.10), in modo che il diagramma del processo eseguibile possa essere compreso anche da parte dell'analista di business.

jPDL è fortemente accoppiato con il classico ciclo di sviluppo del codice ed, essendo incorporato in un ambiente Java, al verificarsi di un evento le azioni jPDL chiameranno metodi e funzioni Java, il che permetterà allo sviluppatore del codice di aggiungere la logica necessaria senza aggiornare il grafico disegnato.

Uno dei pregi di jPDL è il fatto di poter estendere il linguaggio con l'aggiunta di nuovi tipi di nodi. Altra caratteristica è che il linguaggio (il codice) è abbastanza leggibile, inducendo gli sviluppatori a modificarlo direttamente a mano. L'applicazione fornisce anche i form per riempire i campi delle proprietà associate alle attività, così come le chiamate e le mappature al codice Java.

2.6.4 InstantReality

InstantReality è un sistema di Mixed Reality (MR) ad elevate prestazioni, che unisce più componenti distinte al fine di presentare un'interfaccia unica e consistente agli sviluppatori, inclusi i più recenti risultati della ricerca nell'ambito del rendering realistico, delle tecnologie dell'interazione 3D con l'utente e degli ambienti immersivi [20].

Il framework offre un insieme di funzionalità per supportare sia la Virtual Reality (VR) che l'Aug-mented Reality (AR) (Figura 2.11).

Figura 2.10 - Eclipse graphic designer per jPDL


Il framework fornisce un grafo di tipo data-flow, che è un'estensione del modello X3D della scena e della sua esecuzione. Pertanto, esso consente allo sviluppatore di creare applicazioni modellando ol-tre che programmando. Ciascuna applicazione consta di un certo numero di grafi, definiti tramite i componenti e le relazioni tra di essi. Ogni componente include dei parametri di stato ed un'unità di elaborazione, che ne controlla il comportamento. La complessità di un componente può variare da semplici operazioni booleane ad applicazioni più complesse, articolate in sottoparti per la geometria e la simulazione. L'unità di elaborazione di ciascun componente può essere dichiarata mediante un grafo nascosto, uno script o un insieme di classi native precompilate.

L'architettura risultante è altamente flessibile e permette la realizzazione di applicazioni complesse usando una semplice interfaccia drag&drop. Il grafo-applicazione finale può essere adottato in ogni ambiente runtime supportato, da un semplice PDA (Personal Digital Assistant) a un'unità cluster multi-screen o multinodo.

L'approccio alla modellazione basata sui comportamenti consente nuove applicazioni e prototipi, in efficienza e senza ricorrere alla programmazione. L'ambiente runtime analizza ed esegue i grafi dei componenti usando un ampio numero di metodi d'ottimizzazione automatici (sia online che offline), grazie ai quali il sistema gestisce grafi talvolta complessi e di dimensioni considerevoli e visualizza efficientemente un vasto insieme di poligoni, punti, NURBS e volumi. InstantReality usa inoltre le ultime funzionalità hardware GPU per eseguire le tecniche avanzate di real-time shading.

InstantReality include diversi metodi d'ottimizzazione per l'esplorazione di tutte le risorse hardware disponibili, al fine di raggiungere gli obiettivi specifici delle applicazioni runtime:

• Auto-Parallelismo/Multithread : Il sistema analizza in tempo reale la struttura del grafo e usa un metodo brevettato per individuare i sottografi indipendenti, eseguibili in parallelo.

• Cluster : Diversi algoritmi di ordinamento crescente/decrescente bilanciano il caricamento del rendering per ciascun nodo cluster in tempo reale. Il metodo è lineare e non prevede li-miti sul numero di CPU. Questo permette di migliorare le prestazioni generali dei cluster ag-giungendo più nodi di rendering.

• Dataset multi-risoluzione : Il framework può creare e gestire dataset multi-risoluzione per punti, mesh e volumi. Ciò rende il sistema in grado di controllare le prestazioni generali di rendering, per raggiungere gli obiettivi globali dell'applicazione, come la massimizzazione del frame rate.

Figura 2.11 - Augmented Reality


Le componenti del middleware di InstantReality forniscono specifiche interfacce di rete sincrone ed asincrone ad elevate prestazioni, per incorporare i dati dell'applicazione a tempo di esecuzione, ad esempio per i pacchetti del simulatore. Inoltre le interfacce SOAP e HTTP offrono dei mezzi aperti e flessibili per il controllo e la manipolazione delle applicazioni in esecuzione, per esempio tramite la creazione di interfacce utente avanzate.

Una piramide di dichiarazione dei dispositivi di I/O basata sul flusso dei dati fornisce vari livelli di astrazione, onde controllare l'applicazione e gli aspetti relativi all'input/output. Il sistema la offre per accedere direttamente sia ai flussi di dati a basso livello che ai componenti ad alto livello, che sono indipendenti dalla classe di dispositivo, e per definire su una parte del grafo dell'applicazione alcuni modelli astratti d'interazione.

Il framework offre un insieme completo di tool e plugin a supporto dello sviluppo e distribuzione delle applicazioni:

• Integrazione : i plugin per i più comuni strumenti DCC (Digital Content Creation), come Maya e 3DMax, consentono allo sviluppatore dell'applicazione di integrare con efficienza i dati 3D. Il framework può leggere ed elaborare direttamente, con opportune importazioni dei dati, i più comuni formati CAD (JTOpen, Catia5 e 4, Step, STL, ecc.);

• Composizione : particolari ambienti runtime permettono allo sviluppatore di integrare e com-porre i dati provenienti dalle diverse sorgenti. Il Sistema include vari plugin per creare ogni tipologia di logica e comportamento di un'applicazione, attraverso la definizione dei compo-nenti, delle loro relazioni e delle loro unità di elaborazione. Un debugger di eventi e script facilita questo processo di sviluppo;

• Distribuzione : numerosi server e sistemi middleware possono essere utilizzati per sviluppare le applicazioni finali su un ampio numero di piattaforme hardware. Il server ed i servizi co-municano tramite lo ZeroConf, al fine di semplificare il processo di installazione.

InstantReality include diversi standard industriali (es. OpenGL 2.0, X3D, JAVA) ed è indipendente dalla piattaforma, essendo i suoi componenti disponibili per un ampio numero di sistemi hardware e software, sia Windows che Linux.

Capitolo 3

Strumento di Authoring

Il VAALID Authoring Environment (AE) è lo strumento che consente di progettare e implementare i singoli elementi che compongono il contesto di una simulazione AAL. Esso consiste in un insieme coordinato di Editors, che permettono la creazione, la modifica, l'archiviazione, il recupero e la ge-stione dei diversi componenti della soluzione AAL, per la quale si desidera realizzare un prototipo.

Quando il VAALID AE è lanciato, viene aperto un workspace o “Spazio di Lavoro” (Figura 3.1).

37

Figura 3.1 - Workspace VAALID AE

38 Capitolo 3 Strumento di Authoring

Da esso sono accessibili i seguenti Editor, resi disponibili dallo strumento:

• Project Editor : Per impostare, visualizzare e modificare le proprietà di un Progetto VAALID e per navigare velocemente fra i suoi componenti.

• User Model Editor : Per impostare, visualizzare e modificare il profilo degli utenti previsti per la soluzione AAL, progettato includendo le loro capacità, che si basano sullo standard di Classificazione Internazionale del Funzionamento, della Disabilità e della Salute [21].

• Environment Model Editor : Per impostare, visualizzare e modificare le proprietà dell'am-biente in cui sono progettati i Servizi AAL, inclusa la rappresentazione grafica 3D (come un file VRML).

• Space Model Editor : Per impostare, visualizzare e modificare le proprietà e le condizioni ambientali degli Spazi associati all'ambiente modellato.

• Device Model Editor : Per impostare, visualizzare e modificare le proprietà dei Dispositivi che possono essere collocati negli Spazi dell'ambiente (ad esempio elettrodomestici, stru-menti, mobili, ecc.).

• Service Model Editor : Per impostare, visualizzare e modificare le proprietà dei Servizi AAL in fase di progettazione.

• Workflow Editor : Per creare, modificare e salvare i workflow relativi ai comportamenti dei Modelli di Dispositivi e Servizi.

Nei prossimi paragrafi (dal 3.1 al 3.4) saranno fornite le principali informazioni ed istruzioni utili per la creazione di un Progetto generico. In 3.5 e 3.6 verranno esplicati due Scenari AAL specifici, sviluppati quali esempi chiarificatori. Concludono alcune valutazioni sul prototipo analizzato (3.7).

3.1 Creare o aprire un Progetto

Il VAALID AE prevede la creazione di un nuovo Progetto, oppure l'apertura di uno già esistente.

Per iniziare un nuovo Progetto:• Cliccare su File New• Immettere un nome e premere OK.

Per aprire un Progetto esistente:• Cliccare su File Open• Trovare il file del Progetto ProjectX.jar• Selezionarlo e premere Open.

Capitolo 3 Strumento di Authoring 39

3.1.1 Integrazione dell'ambiente

L'ambiente virtuale è definito da un file VRML, da importare tramite il VAALID AE.Di seguito sono riportate le operazioni necessarie per inserire un nuovo ambiente all'interno di un Progetto (Figura 3.2):

Cliccare sull'icona “Open Environment”, immettere un nome e premere OK.

Premere il bottone Change VRML per aggiungere il file con un modello 3D dell'ambiente.

Il modello è caricato nella finestra 3D View. Cliccandola con il mouse se ne può abilitare l'e-splorazione, che consiste nello spostarsi mediante i tasti freccia.

Gli Spazi possono essere definiti premendo il bottone Add e aprendo lo Space Model Editor.

Non bisogna mai dimenticare di salvare il proprio ambiente, anche dopo aver terminato la creazione degli Spazi.

Figura 3.2 - Inserimento di un ambiente

1

2

3

4

5


3.1.2 Aggiunta degli Spazi

L'ambiente scelto per la simulazione può essere caratterizzato in più Spazi distinti tra loro. Di segui-to i passi per definire gli Spazi presenti in un ambiente (Figura 3.3):

Si possono definire la tipologia di Spazio ed altre proprietà.

Per consentire l'analisi dei vincoli d'accessibilità, possono essere personalizzate alcune con-dizioni ambientali.

Ricordarsi sempre di salvare, per confermare le modifiche.

L'Editor può essere chiuso o tenuto aperto per un uso successivo.

È possibile tornare al proprio ambiente cliccando la tab, oppure mediante un doppio clic sul nome corrispondente nel Project Browser.

Figura 3.3 - Aggiungere uno Spazio

1

2

3

4

5

5


3.1.3 Project Browser

Il Project Browser (Figura 3.4) consente un rapido accesso ai diversi componenti del Progetto at-tualmente aperto. Infatti, è sufficiente cliccare due volte su ciascuno di essi per visualizzarne il ri-spettivo Editor.

Da qui è inoltre possibile trasferire i componenti del progetto nella Library, al fine di conservarli per un futuro riutilizzo. Per fare ciò, occorre selezionarne uno, cliccare con il tasto destro del mouse su di esso e scegliere l'opzione Copy to Library nel menu delle azioni. Il componente sarà copiato nella Library e diverrà visibile, sotto la relativa categoria, nel Libraries Browser.

Figura 3.4 - Project Browser

La Library view contiene tutti quei componenti forniti da terze parti e quelli personali salvati in pre-cedenza. Per caricare un Dispositivo dalla Libreria (Figura 3.5):

• Nella 3D view, navigare e posizionarsi di fronte al luogo desiderato per il Dispositivo.• Cliccare sulla tab Library.• Selezionare il Dispositivo che si desidera importare.• Cliccarlo con il tasto destro del mouse e scegliere l'opzione Copy to project nel menu.

Figura 3.5 - Dispositivo caricato dalla Libreria

Infine, digitare il nome del nuovo Dispositivo, il cui modello 3D apparirà nell'ambiente virtuale.


3.2 Dispositivi: modello ed inserimento

I Dispositivi devono essere modellati considerando sempre le tre diverse prospettive: Semantica, Visiva e Comportamentale (Figura 3.6).

• Quella Semantica comprende le proprietà caratterizzanti il Dispositivo (come la tipologia, l'ubicazione, il riferimento alla rappresentazione visiva e del comportamento, le funzioni...).

• Visiva è invece la rappresentazione 3D del Dispositivo. Nel VRML sono inoltre definite le interazioni che possono essere gestite durante la simulazione in Realtà Virtuale.

• Comportamentale è, da ultimo, il workflow associato al Dispositivo. Esso rappresenta la di-namica offerta agli utenti finali dalla soluzione AAL.

Figura 3.6 - Prospettive per il modello

3.2.1 Aggiungere un Dispositivo

Completata la costruzione dell'ambiente, bisogna definire almeno un Dispositivo che dovrà interagi-re con l'anziano in un contesto AAL. Per aggiungere un dispositivo (Figure 3.7, 3.8, 3.9):

Cliccare sull'icona “New Element”, inserire un nome e premere OK.

Selezionarne quindi la Tipologia, navigando attraverso l'albero dedicato, che sarà aperto in una finestra a parte.

Cliccare all'interno della vista 3D e posizionarsi di fronte al luogo scelto per il Dispositivo.

Premere il pulsante Change VRML per aggiungere il file con il modello 3D del Dispositivo.


Il modello è caricato nella finestra 3D View. Cliccando all'interno dell'ambiente, è possibile ruotare/traslare (tasti freccia, oppure Page Up / Page Down con o senza Alt) l'assetto del Di-spositivo, altrimenti ricavabile (get) e regolabile (set) mediante le sue coordinate nelle tre di-mensioni. Premere Done per confermare, anche se non si è alterata la posizione di default.

Selezionare lo Spazio in cui è inserito il Dispositivo.

Figura 3.7 - Aggiungere un Dispositivo

Per specificare il comportamento del Dispositivo, è necessario iniziare con la definizione delle funzioni che, a partire dal file VRML, saranno rese disponibili nell'editor dei workflow.

Definire gli stati che il Dispositivo potrà avere.

1

2

3

4

55

610


Figura 3.8 - Funzioni e Stati del Dispositivo

Definire gli Eventi che questo Dispositivo potrà comunicare agli altri elementi. I nomi e le tipologie di questi parametri, come per le Funzioni (#7), sono rintracciabili nel file VRML.

Ora si è pronti per creare il workflow associato a questo Dispositivo. Cliccare su New Work-flow per aprire un workflow vuoto nell'editor specifico.

Figura 3.9 - Eventi del Dispositivo

7

8

9


3.3 Dispositivi: comportamento ed interazione

Per definire correttamente il comportamento di un Dispositivo, occorre preservare il nome del mo-dello VRML associato, che coincide con quello del dispositivo VR, e quelli che individuano le sue funzioni, i suoi stati ed eventi, scritti all'interno del medesimo file; ad essi si dovrà ricorrere per spe-cificare l'insieme delle possibili risposte del Dispositivo ai segnali ricevuti. È necessario pertanto usare quei nomi, che sono nel file VRML, sia per l'editor dell'elemento (3.2.1) che per il workflow.

3.3.1 Creare un nuovo Workflow

I workflow sono gestiti integralmente dal VAALID AE. Questi sono i passi per la loro creazione (Fi-gure 3.10, 3.11):

Per aggiungere nodi (Task) al workflow, selezionare l'icona relativa nella palette e cliccare sull'area di lavoro (canvas).Collegare i nodi con i flussi (Flow), selezionando l'icona nella palette e cliccando prima sul nodo d'origine e poi sul nodo destinazione.Cliccare due volte su un nodo per impostarne il nome.

Figura 3.10 - Creare un nuovo Workflow

2

3

4

55

6101

1

2

2

3

3

5

5

6


Per definire la funzione di un nodo, cliccare su di esso con il tasto destro del mouse e sele-zionare l'opzione Add Action nel menu contestuale. Seguire quindi il wizard per la creazione.Cliccare due volte su un flusso di transizione (freccia) per associargli un Evento, seleziona-bile dalla lista di quelli disponibili, relativi ai Dispositivi.Per salvare il workflow, premere la relativa icona per la memorizzazione.

Figura 3.11 - Wizard per una nuova Azione

I workflow possono essere associati ai Dispositivi, e in tal caso è consigliabile preservare lo stesso nome, oppure possono anche definire la struttura dell'evoluzione del Servizio AAL scelto per il Pro-getto, che descriverà l'interazione nello Scenario dei diversi Dispositivi, tra loro e con l'utente.

3.4 Servizio AAL ed Utente Virtuale

Il Servizio AAL specifica quelle che dovranno essere le modalità delle interazioni tra i Dispositivi presenti nel contesto virtuale e gli utenti che usufruiranno delle loro funzionalità. Tipicamente esso riproduce i benefici e il comportamento dell'ambiente assistivo.L'Utente Virtuale è sostanzialmente un modello dell'attore reale, il soggetto che dovrà interfacciarsi con il sistema realizzato dal VAALID AE, caratterizzato da un certo grado di anzianità o disabilità. Le sue caratteristiche fisiche sono simulate, nel modo più fedele possibile, tramite alcuni parametri di questa riproduzione virtuale.

3.4.1 Creare un Servizio AAL

Il VAALID AE prevede l'esposizione del contesto, mentre le azioni effettive sono in un workflow.

4


Ecco i passi per realizzare un Servizio (Figura 3.12):

Cliccare sull'icona “New Service”, immettere un nome e premere OK.

Riempire le proprietà e gli attori coinvolti, per descrivere il Servizio AAL. Sarà utile per fu-ture consultazioni (orientato ad una maggior comprensione da parte dell'essere umano).Descrivere le interazioni AAL utilizzando un workflow. Seguire i passi visti in 3.3.1.

Figura 3.12 - Creazione Servizio AAL

3.4.2 Creare un Utente Virtuale

L'ultima funzionalità fornita dal VAALID AE è quella di realizzare un profilo virtuale che descriva fedelmente, per quanto possibile, l'utente fisico (Figura 3.13):

Cliccare l'icona “New User”, immettere un nome e premere OK.

Riempire le proprietà personali dell'Utente.

Descrivere le disabilità del proprio Utente aggiungendo le Characteristics. Navigare attra-verso l'albero per selezionare le disabilità associate all'Utente.

1

2

2

3


Configurare le disabilità impostandone la posizione e la gravità.

Inoltre è possibile aggiungere Habits (Abitudini) e Preferences (Preferenze) al proprio Uten-te, in modo analogo alle disabilità.

Salvare infine il Progetto. Per avviare l'Ambiente di Simulazione (SE), consultare il paragrafo 4.2.2.

I successivi paragrafi (3.5 e 3.6) saranno dedicati a due Scenari AAL, realizzati al fine di rendere di-sponibile un esempio pratico esplicativo di quanto è stato finora soltanto accennato.

Figura 3.13 - Creazione Utente Virtuale

1

2

3

3

4

5


3.5 Scenario I: allarme intrusioni

Questa simulazione si riferisce ad una possibile situazione notturna: l'anziano si trova in casa e la fi-nestra della cucina subisce un tentativo di effrazione dall'esterno. Ciò provoca l'attivazione dell'al-larme, nelle sue componenti sonora e visiva: effettuati i dovuti controlli, l'antifurto potrà essere spento mediante un apposito touchscreen, posto nella camera da letto.

Ambiente:• casa o appartamento (environment.wrl).

Spazi coinvolti:• cucina;• salotto;• camera da letto.

Dispositivi installati:• finestra (Device_Window.wrl);• luce d'allarme (Device_WarningLight.wrl);• cassa altoparlante (Device_Speaker.wrl);• touchscreen (Device_TouchDisplay.wrl).

Servizio:• allarme antifurto.

Per sviluppare lo Scenario sono stati realizzati due workflow, il primo per definire il comportamento della finestra (apertura e chiusura), mentre il secondo è associato al Servizio (alarm), che coordina l'interazione tra tutti i Dispositivi presi in esame e ne controlla l'evoluzione.

Nello Scenario sono coinvolti quattro Dispositivi. Il Listato 3.1 ne rappresenta la struttura generica.

DEF TopDevice_NomeDispositivo Transform {# Eventuali trasformazioni (scala, trasla, ruota) children [

DEF Device_NomeDispositivo_Virtual Switch{ whichChoice 0 choice [

Group{ children [

# Modello 3D del Dispositivo (in VRML)# più eventuali nodi associati ai suoi Eventi, es:# DEF Device_NomeDispositivo_TS1 TouchSensor {}# DEF Device_NomeDispositivo_PS1 ProximitySensor {}

] } ]

}


]}

DEF Service_NomeDispositivo_NomeFunzione Script{

# Codice nodo Script per definire il comportamento del# Dispositivo, utilizzando il linguaggio JavaScript

}

ROUTE Node.eventOut TO Node.eventIn # eventi tra i nodiListato 3.1 - Struttura standard Dispositivo VAALID

Importante è notare che il primo nodo di tipo Transform, con la sua organizzazione interna scritta in nero nel Listato 3.1, costituisce la parte invariabile di un qualunque modello s'intenda importare tramite il VAALID AE.NomeDispositivo e NomeFunzione possono essere scelti a piacere, con il solo vincolo che non contengano spazi e con la consapevolezza che:

• Device_NomeDispositivo potrà essere il nome dell'elemento e dell'eventuale workflow as-sociato (scelta consigliata ma non necessaria), durante la creazione dello Scenario (vedere i punti 1 e 10 del precedente 3.2.1);

• NomeFunzione dovrà essere riutilizzato nell'editor, alla definizione delle funzioni (vedere il punto 7 del precedente 3.2.1), con un parametro del tipo corretto;

• Gli eventi associati al TouchSensor e ProximitySensor dovranno invece avere per nome i soli TS1 e PS1, rispettivamente (punto 9 del precedente 3.2.1);

L'esempio della cassa altoparlante (3.5.1) chiarirà il significato di questa sintassi del codice.

3.5.1 Realizzazione di un Dispositivo: Cassa Altoparlante.

Il modello del Dispositivo è stato ottenuto convertendo il file originario .3ds (3D Studio Max) nel formato .wrl (VRML), grazie allo strumento di esportazione incluso nello stesso programma 3D Studio Max. Poiché ciò si rivela essere indipendente da VAALID e, di conseguenza, esula dallo sco-po di questa tesi, le righe di codice relative ad esso saranno omesse e non verranno approfondite nella seguente analisi.Nel Listato 3.2 è presentato il codice del dispositivo.

DEF TopDevice_Speaker Transform { scale 0.3 0.3 0.3 translation 0.0 0.0 0.0 rotation 0 0 0 0.0 children [

DEF Device_Speaker_Virtual Switch{ whichChoice 0 choice [

Group{ children [


# [...]# Modello 3D del Dispositivo (in VRML)# [...]

DEF Device_Speaker_TS1 TouchSensor {}

DEF alarm Sound { minFront 200 maxFront 1000 minBack 200 maxBack 1000 direction 0 0 1 location 0 0 0 spatialize TRUE source DEF SoundOut AudioClip {

enabled FALSEloop TRUE url "maps\alarm.wav"

}}

]

} ] }

]}

DEF Service_Speaker_PlayAudio Script{ eventIn SFBool RunScript eventIn SFBool Param_PlayAudio exposedField SFString ServiceDescription "This Service plays the Audio-File"

exposedField SFBool paudio FALSE eventOut SFBool audioplay url " javascript:

function Param_PlayAudio(value){

paudio = value;}

function RunScript(value){

audioplay = paudio;}

"}ROUTE Service_Speaker_PlayAudio.audioplay TO SoundOut.enabled

Listato 3.2 – Device_Speaker.wrl

Già al primo esame dovrebbe essere evidente il rispetto della struttura generale di un Dispositivo per il VAALID AE. Infatti, è sufficiente considerare il NomeDispositivo pari a Speaker e il Nome-Funzione pari a PlayAudio, per rendere manifesta la conformità con quanto scritto in precedenza per il Listato 3.1.


Ora ci si soffermerà sui nodi VRML più significativi.

DEF Device_Speaker_TS1 TouchSensor {}Listato 3.3 - Nodo TouchSensor

Un nodo di tipo TouchSensor (Listato 3.3) consente di determinare quando la cassa altoparlante è cliccata con il mouse, durante l'esecuzione della simulazione.

DEF alarm Sound { minFront 200 maxFront 1000 minBack 200 maxBack 1000 direction 0 0 1 location 0 0 0 spatialize TRUE source DEF SoundOut AudioClip {

enabled FALSEloop TRUE url "maps\alarm.wav"

}}

Listato 3.4 - Nodo Sound

Un nodo Sound (Listato 3.4) è costituito da un insieme di campi, che definiscono le proprietà della sorgente sonora (posizione, direzione...), identificata da un nodo di tipo AudioClip.Il significato di ciascuna impostazione dovrebbe essere abbastanza intuitivo, ma merita una più im-portante osservazione il fatto che il file audio (alarm.wav nel caso specifico) debba trovarsi in una cartella denominata maps e situata nella stessa directory del file VRML del Dispositivo.

Questo discorso vale, in generale, per una qualunque inclusione esterna (immagini, video, audio...), poiché il VAALID AE importerà nel Progetto soltanto il modello VRML e tutti i file posti nella rela-tiva cartella maps (con un nome o un url diverso, resterebbero esclusi da tale processo).

Il nodo è, di default, disattivo. Dovrà dunque essere attivato dal workflow del Servizio, al momento più opportuno. Ciò è implementato dallo Script finale (Listato 3.5).

DEF Service_Speaker_PlayAudio Script{ eventIn SFBool RunScript eventIn SFBool Param_PlayAudio exposedField SFString ServiceDescription "This Service plays the Audio-File"

exposedField SFBool paudio FALSE eventOut SFBool audioplay url " javascript:

function Param_PlayAudio(value){

paudio = value;}


function RunScript(value){

audioplay = paudio;}

"}ROUTE Service_Speaker_PlayAudio.audioplay TO SoundOut.enabled

Listato 3.5 - Script in Device_Speaker.wrl

Pertanto il nodo Script evidenzia quattro campi booleani:

• RunScript, la funzione che aggiorna quello che dovrà essere lo stato voluto per il Dispositi-vo (audio attivo vero/falso).

• Param_PlayAudio, la funzione che gestisce l'evento in ingresso, causato dal workflow (la funzione in esso definita dovrà avere un parametro della stessa tipologia qui dichiarata, boo-leana in questo caso specifico), che ha l'obiettivo di modificare il valore dello stato.

• paudio, il campo accessibile all'aggiornamento forzato da parte dell'evento ricevuto; è ini-zializzato a FALSE, dato che lo Speaker è spento, cioè il nodo AudioClip è disattivo.

• audioplay, l'evento in uscita, per notificare ad altri nodi lo stato attuale.

Il ROUTE dell'ultima riga di codice (Listato 3.5) effettua proprio l'invio, al nodo identificato da SoundOut, del nuovo valore booleano con cui aggiornare il campo enabled di attivazione dell'ese-cuzione del file audio.

3.5.2 Realizzazione di un Dispositivo: Luce d'Allarme.

Questo Dispositivo è stato importato dalla Libreria fornita dal VAALID AE. Tuttavia, poiché lo stato “acceso” prevedeva semplicemente un diverso aspetto del modello, si è pensato fosse preferibile rendere visibile almeno quella intermittenza che un utente si aspetterebbe da un allarme reale, modi-ficando il colore delle lampadine.

Pertanto il Listato 3.6 si focalizzerà soltanto sulle integrazioni apportate al codice originario.

DEF TopDevice_WarningLight Transform { # [...] scale, translation, rotation children [ DEF Device_WarningLight_Virtual Switch { whichChoice 0 choice [ Group { children [ DEF WarningLightOnOff Switch { whichChoice 1 choice [


Group{ # [...] Modello 3D Dispositivo "ON" (in VRML) }

Group { # [...] Modello 3D Dispositivo "OFF" (in VRML) } ] }

DEF Clock TimeSensor { enabled FALSE cycleInterval 2.0 loop TRUE } DEF LampColor ColorInterpolator { key [ 0.0, 0.2, 0.8, 1.0 ] keyValue [ 1.0 0.0 0.0, 1.0 0.0 0.0, 0.103873 0.386620 0.538200, 0.103873 0.386620 0.538200 ] } DEF Device_WarningLight_TS1 TouchSensor {} ] } ] } ]}

# [...]# Service_WarningLight_warnLampOn Script# [...]

# ROUTE [...]ROUTE Service_WarningLight_warnLampOn.WarningLightOn TO Clock.enabledROUTE Clock.fraction_changed TO LampColor.set_fractionROUTE LampColor.value_changed TO lamp_1.set_diffuseColor

Listato 3.6 – Device_WarningLight.wrl

L'alternarsi dei colori è stato reso possibile combinando un TimeSensor e un ColorInterpolator, nodi già previsti in VRML (Figura 3.14). Infatti, uno degli eventi generati dal nodo TimeSensor (in questo caso impostato per ripetere un ciclo di durata pari a due secondi) è il fraction_changed, che può essere collegato al set_fraction dell'interpolatore, sempre tramite il comando ROUTE.

Il valore trasmesso sarà compreso tra 0 e 1.

Il ColorInterpolator (Listato 3.7), di conseguenza, origina un value_changed, che potrà essere utilizzato per aggiornare il valore del campo più opportuno in un altro nodo. È stata scelta la com-ponente diffusiva, espressa nel nodo lamp_1, di tipo Material, che definisce le proprietà del colore, di riflessione e di trasparenza, valide per tutte le luci della Device_WarningLight.


Figura 3.14 - Scambio degli eventi tra i nodi

Il risultato è che il colore della lampadine, quando l'allarme è attivo, varia con continuità nel tempo (sull'intervallo di 2 s), rispettando l'andamento determinato dal nodo ColorInterpolator: proprio il suo campo key, infatti, serve a dichiarare tutti i punti chiave dell'evoluzione.Ovviamente, essi dovranno essere almeno due, corrispondenti agli stati iniziale (0) e finale (1), più altri eventuali intervalli intermedi, non necessariamente equispaziati.

ColorInterpolator { key [ ] keyValue[ ]}

Listato 3.7 - Sintassi ColorInterpolator

Il campo keyValue, invece, associa un valore a ciascun punto chiave. L'interpolatore si occuperà di mediare i diversi valori di colore, così da ottenere un cambiamento graduale tra l'uno ed il seguente. Il risultato di tale operazione è il campo value_changed, trasmesso dall'evento come nuovo valore RGB al nodo interessato dall'aggiornamento.

La modifica alla Device_WarningLight coinvolge soltanto lo stato on, passando da una luce statica ad una più realistica transizione tra più colori nel tempo. Si è inoltre preferito lasciare attivo il nodo TimeSensor soltanto durante l'intervallo utile, disabilitandolo quando l'allarme viene fermato.

3.5.3 Workflow di un Servizio: Allarme sonoro e visivo.

Un workflow è definito da un file JPDL e da un documento XML. La loro creazione, modifica ed interpretazione è gestita direttamente dal VAALID AE, tramite interfaccia grafica (Figura 3.15).

Figura 3.15 - Service_Alarm workflow


Lo stato iniziale, all'avvio dell'esecuzione dello Scenario, resta in attesa dell'apertura della finestra (l'effrazione è simulata da un clic del mouse). L'evento comporta l'attivazione dello Speaker e l'ac-censione della WarningLight, che sono le due componenti dell'allarme, rispettivamente quella audio e quella visiva.Quindi i due Dispositivi restano attivi fino all'avvenuta pressione del touchscreen (sempre cliccando con il mouse), che li riporta allo stato OFF analogo a quello iniziale, poiché entrambi erano stati di-sattivati di default, nel loro codice VRML.

Agendo alternativamente sulla finestra e sul touchscreen, la medesima evoluzione potrà essere più volte ripetuta, senza alcun limite sul loro numero totale, almeno sino a quando non si deciderà di terminare la simulazione.

Le transizioni di stato (Flow) tra i nodi (Task) avvengono grazie al nodo TouchSensor presente nel codice VRML della Device_Window e del Device_TouchDisplay, così come descritto in dettaglio per il Device_Speaker. Naturalmente tale Evento è stato poi inserito al momento dell'integrazione dei due Dispositivi nello Scenario (vedere punto 9 del precedente 3.2.1 Aggiungere un Dispositivo).

L'azione di ciascun nodo è invece stata specificata grazie al wizard volto alla loro creazione (punto 4 del precedente 3.3.1). Il procedimento risulta abbastanza automatico, poiché si potranno scegliere, per ciascun Dispositivo già importato, soltanto le funzioni dichiarate per esso (riferirsi al punto 7 vi-sto in 3.2.1). Ognuna ha un opportuno parametro, il cui valore è ciò che differenzia uno stato da un altro nel grafo del workflow.

Per l'esempio in esame (Figura 3.16), dal task chiamato SpeakerON si evince la presenza della fun-zione PlayAudio, proveniente dal file VRML del Device_Speaker. Coerentemente con quanto già visto, il parametro associato è un booleano, il cui valore si alternerà tra true e false, passando ri-spettivamente da SpeakerON a SpeakerOFF e viceversa.

Il discorso è analogo anche per la Device_WarningLight, la cui funzione modifica l'aspetto del modello 3D in base al fatto che il Dispositivo debba essere acceso o spento.

Figura 3.16 - Task del Device_Speaker workflow

Infine, rimarrebbe da analizzare il workflow della Device_Window, riconoscibile in Figura 3.10 (nel paragrafo 3.3.1). Ma ciò sarà ridotto solo ad un breve accenno, poiché la comprensione dovrebbe essere alquanto semplificata, alla luce di quanto già esposto.


La finestra è inizialmente chiusa. Può essere aperta soltanto con un volontario clic del mouse su di essa (nodo TS1 di tipo TouchSensor), mentre la chiusura della stessa è stata gestita da un nodo PS1 di tipo ProximitySensor: in pratica, si è ipotizzato che l'utente, avvicinandosi ad essa, esprima contestualmente l'intenzione di chiuderla. Quindi si avranno due casi possibili: se la finestra era sta-ta cliccata mantenendosi ad una certa distanza, portandosi in sua prossimità si otterrà l'effetto di ri-chiuderla; se, invece, era stata aperta stando nelle sue immediate vicinanze, il medesimo risultato si avrà allontanandosi.

Nel contesto di questa simulazione di un allarme, l'apertura della finestra è stata ovviamente tradotta in un tentativo di intrusione, con la conseguente attivazione dei segnali di avviso (audio e visivo). Al contrario, la chiusura può essere interpretata come la conclusione dei dovuti controlli da parte del proprietario, oppure l'esito del necessario sopralluogo da parte delle autorità competenti.

3.6 Scenario II: illuminazione automatica

Questo paragrafo presenta un secondo Scenario d'esempio, per il quale non saranno ripetute tutte quelle informazioni già fornite, la cui conoscenza verrà data per assodata.Sarà comunque un'analisi importante ed utile per introdurre alcuni concetti qui trascurati.

Questa simulazione intende rispondere ad una tipica esigenza: risparmiare all'anziano, che si trova in casa, il dover cercare in ogni stanza gli interruttori della luce. Esse, infatti, saranno poste nella condizione di accendersi da sole, una volta rilevato l'approssimarsi dell'utente, oppure di spegnersi al momento opportuno, vale a dire all'allontanarsi del soggetto.

Ambiente:• casa o appartamento (environment.wrl).

Spazi coinvolti:• salotto;• camera da letto.

Dispositivi installati:• lampadario (Device_Chandelier.wrl);• telecamera infrarossi (Device_ProxCamera.wrl);

Per la realizzazione di questo Scenario nessun Dispositivo è stato importato dalla Libreria, dato che, tra quelli disponibili, nemmeno uno rispondeva alle esigenze del servizio AAL. Dunque è stato ne-cessario creare due nuovi file VRML, per un Device_Chandelier ed una Device_ProxCamera, poiché dei modelli simili non erano stati previsti.

Si è preferito, inoltre, realizzare un unico workflow, che fosse associato al lampadario e che ne de-scrivesse l'evoluzione (accensione/spegnimento delle luci) in funzione dell'ingresso o dell'uscita dell'utente dal raggio d'azione del sensore di prossimità, qui identificato da una telecamera ad infra-rossi monitorante una certa area, più o meno vasta, dimensionata conoscendo la stanza, oppure il luogo di installazione.


Questi due Dispositivi sono situati nel salotto.Poiché era necessario replicare la configurazione almeno in un'altra stanza, per poter correttamente simulare il comportamento di un ambiente domestico reale, in un secondo momento sono stati ag-giunti una Device_LampLight ed un Device_ProxSensor: la prima è stata ottenuta cambiando semplicemente il nome Chandelier (comprese tutte le occorrenze all'interno del file VRML, per quella stessa necessità di coerenza già illustrata nel paragrafo 3.3); analogamente è accaduto con la ProxCamera per il secondo, con l'ulteriore modifica della regione soggetta a controllo, dovendo es-sere adattata alle dimensioni della camera da letto.

Infine è stato creato un workflow anche per il secondo lampadario, perfettamente conforme al pri-mo, con l'unica differenza dei Dispositivi coinvolti.

Date queste simmetrie nel codice, nelle pagine seguenti saranno presi in esame solamente i due file VRML e il workflow relativi allo Scenario AAL parziale, cioè quello ricreato nel soggiorno.

3.6.1 Realizzazione di un Dispositivo: Lampadario.

Il modello del lampadario è stato ottenuto convertendo il file originario .3ds nel formato .wrl, grazie allo strumento di esportazione incluso nello stesso programma 3D Studio Max. Poiché ciò si rivela essere indipendente da VAALID e, di conseguenza, esula dallo scopo di questa tesi, le parti relative ad esso saranno omesse e non verranno approfondite nell'analisi seguente, esattamente come per lo Scenario precedente (3.5.1).Il Listato 3.8 ne mostra il codice sorgente.

DEF TopDevice_Chandelier Transform { scale 4 4 4 translation 0.0 0.0 0.0 rotation 0 0 0 0.0 children [ DEF Device_Chandelier_Virtual Switch { whichChoice 0 choice [ Transform { translation 0 -58.52 0 children [

# Modello 3D del Dispositivo (in VRML) # [...]

DEF Sphere00 Transform { translation -0.1023 57.37 0 scale 1.387 1.387 1.387 children [ DEF ChandelierOnOffSwitch Switch { whichChoice 0 choice [ Group { children [


Shape { appearance Appearance { material Material { diffuseColor 0.9451 0.9686 0.6667 ambientIntensity 1.0 specularColor 0.72 0.72 0.72 shininess 0.259 transparency 0.4 } } geometry Sphere { radius 0.7733 } } ] }

Group { children [ Shape { appearance Appearance { material Material { diffuseColor 0.9451 0.9686 0.6667 emissiveColor 1.0 1.0 1.0 ambientIntensity 1.0 specularColor 0.72 0.72 0.72 shininess 0.259 transparency 0.04 } } geometry Sphere { radius 0.7733 } }, DEF Lights SpotLight { on FALSE intensity 1.0 ambientIntensity 0.0 color 1.0 1.0 1.0 location 0.0 0.0 0.0 direction 0 -1 0 attenuation 0.0 0.00195 0.0 radius 250 beamWidth 1.570796 cutOffAngle 1.570796 } ] } ] } ] } # [...] # Fine Modello 3D del Dispositivo (in VRML)

DEF Device_Chandelier_TS1 TouchSensor {} ] } ] } ]}


DEF Service_Chandelier_TurnLights Script{ eventIn SFBool RunScript eventIn SFBool Param_On exposedField SFString ServiceDescription "Service changes chandelier's state"

exposedField SFBool Onfield FALSE eventOut SFInt32 OnOut url " javascript:

function Param_On(value){ Onfield=value; }

function RunScript(value){ if (Onfield) { OnOut = 1; } else OnOut = 0; }

"}ROUTE Service_Chandelier_TurnLights.OnOut TO ChandelierOnOffSwitch.whichChoiceROUTE Service_Chandelier_TurnLights.Onfield TO Lights.on

Listato 3.8 - Device_Chandelier.wrl

Anche in questo caso è evidente il rispetto della struttura compatibile con il VAALID AE.

Avendone già discusso nel paragrafo precedente (3.5) gli elementi di carattere generale, ora ci si concentrerà sui nodi più rilevanti di questo modello VRML.

DEF Sphere00 Transform { # [...] DEF ChandelierOnOffSwitch Switch { whichChoice 0 choice [ Group { # [...] }

Group { children [ # [...] DEF Lights SpotLight { on FALSE # [...]

Listato 3.9 - Luci in Device_Chandelier.wrl

Il nodo nel Listato 3.9 è interessante, perché è stato aggiunto al lampadario, in precedenza ottenuto convertendo un file di 3D Studio Max. In sostanza, esso crea le lampadine, che dovranno quindi po-tersi accendere e spegnere.


Questa funzionalità è stata realizzata sfruttando le proprietà del nodo Switch, un nodo VRML di raggruppamento: soltanto uno, tra tutti i suoi figli, sarà visualizzato. Il campo whichChoice serve proprio a questo scopo, cioè specificare l'indice dell'unico nodo figlio da visualizzare.

La sintassi generale è visibile nel Listato 3.10.

Switch{ whichChoice -1 choice [ ] }

Listato 3.10 - Nodo Switch

Nel nostro esempio particolare si hanno due nodi figli, che corrispondono ai due stati desiderati. Il primo nodo Group contiene il codice per una lampadina spenta e questa sarà la scelta di default (l'indice, infatti, è zero). Il secondo, di conseguenza, rappresenta una lampadina accesa, cui è stata aggiunta una SpotLight come fonte luminosa, inizializzata ad off.

Quindi i campi sui quali dovrà intervenire l'aggiornamento, per consentire l'alternarsi di accensione e spegnimento delle lampadine, sono whichChoice (modificare l'indice da 0 a 1 e viceversa) e on (FALSE o TRUE).

DEF Service_Chandelier_TurnLights Script{ eventIn SFBool RunScript eventIn SFBool Param_On exposedField SFString ServiceDescription "Service changes chandelier's state"

exposedField SFBool Onfield FALSE eventOut SFInt32 OnOut url " javascript:

function Param_On(value){ Onfield=value; }

function RunScript(value){ if (Onfield) { OnOut = 1; } else OnOut = 0;

}

"}

Listato 3.11 - Script in Device_Chandelier.wrl

Lo Script nel Listato 3.11 è simile a quello presentato per il Device_Speaker nel Listato 3.5, con l'unica differenza sostanziale nella variabile del campo eventOut, che in questo caso è di tipo intero invece di essere un booleano. Si è dunque attuata una semplice conversione, con la corrispondenza tra i valori 1/0 e TRUE/FALSE rispettivamente.


I cambiamenti, apportati dallo Script, devono quindi essere notificati ai relativi nodi (Listato 3.12).

ROUTE Service_Chandelier_TurnLights.OnOut TO ChandelierOnOffSwitch.whichChoiceROUTE Service_Chandelier_TurnLights.Onfield TO Lights.on

Listato 3.12 - Eventi in Device_Chandelier.wrl

Pertanto l'intero 1 per OnOut corrisponderà alla scelta del secondo figlio nel nodo Switch (acceso) e all'attivazione del nodo di tipo SpotLight, con il campo on posto a TRUE.Vale un discorso analogo anche per l'altro caso, con OnOut pari a 0.

3.6.2 Realizzazione di un Dispositivo: Telecamera di Prossimità.

Al fine di rendere più realistico lo Scenario, si è preferito separare il sensore, che rileva la presenza dell'utente nella stanza, dal lampadario vero e proprio. Il Dispositivo fisico scelto per questo scopo è una telecamera ad infrarossi. Come nei precedenti esempi, il modello è stato ottenuto convertendo un file originario .3ds nel formato .wrl, tramite l'opzione di esportazione che è inclusa tra gli stessi strumenti del programma 3D Studio Max.

Analogamente a quanto accaduto con gli altri Dispositivi, l'aspetto grafico in VRML risulta poco si-gnificativo nel perseguire un'analisi sull'utilizzo del VAALID AE e, di conseguenza, esula dallo sco-po di questa tesi. Il codice relativo ad esso verrà omesso e non sarà ulteriormente approfondito.La sola parte d'interesse è dunque riportata nel Listato 3.13.

DEF TopDevice_ProxCamera Transform { scale 0.3 0.3 0.3 translation 0.0 0.0 0.0 rotation 0 0 0 0.0 children [ DEF Device_ProxCamera_Virtual Switch { whichChoice 0 choice [ Transform { rotation 0 1 0 2.356194490192345 children [

# [...] # Modello 3D del Dispositivo (in VRML) # [...]

Transform { rotation 0 1 0 -2.356194490192345 children [ DEF Device_ProxCamera_PS1 ProximitySensor { enabled TRUE center 627.833 -566.667 949.833 size 2000 333 2667 }


] } DEF Device_ProxCamera_TS1 TouchSensor {} ] } ] } ]}

(Listato 3.13 - Device_ProxCamera.wrl)

Il cuore fondamentale del Device_ProxCamera è, praticamente, il solo ProximitySensor. A diffe-renza del TouchSensor, il sensore di prossimità ha esigenza che vengano definiti alcuni campi ed inizializzati a valori non casuali, al fine di delineare il raggio d'azione, cioè l'area da monitorare. Dunque acquisiscono un'importanza sostanziale la posizione ed orientazione dello stesso, così come tutte le operazioni di trasformazione, siano esse una traslazione oppure una rotazione.

Questa necessaria precisione, che ha tra i suoi requisiti la conoscenza completa della stanza in cui si desidera inserire il Dispositivo, ha un evidente richiamo alla realtà fisica: ciò corrisponde, infatti, ad un qualunque processo d'installazione di un simile strumento in ambiente domestico, che non può prescindere dalle condizioni del luogo e che dovrà quindi essere configurato ed impostato per con-formarsi ad esso.

3.6.3 Workflow di un Dispositivo: Lampadario.

Come già era stato anticipato (inizio 3.6), per questo secondo Scenario AAL si è scelto di associare il workflow di gestione delle luci proprio al relativo lampadario controllato, senza creare un Servizio generico. La Figura 3.17 presenta il risultato, visto dal VAALID AE, tramite interfaccia grafica.

Figura 3.17 - Device_Chandelier workflow

Nello stato iniziale, all'avvio dell'esecuzione dello Scenario, si rimane in attesa dell'approssimarsi dell'utente. Nell'istante in cui quest'ultimo, entrando in una stanza, supera il raggio d'azione della Device_ProxCamera, cioè si trova nella regione da essa monitorata, il Dispositivo invia l'Evento caratterizzato dal nodo PS1. Il ProximitySensor notificherà il valore TRUE, che sarà catturato dalla funzione TurnLights, la quale agirà secondo le modalità viste in 3.6.1.


Il Device_Chandelier sito in quello stesso Spazio (ed opportunamente associato alla telecamera) si troverà dunque nello stato attivo, con tutte le luci del lampadario accese. Il valore tornerà ad essere FALSE (tutte le lampadine spente) soltanto all'uscita dell'utente dall'area di prossimità.

Muovendosi all'interno dell'ambiente virtuale e spostandosi alternativamente entro oppure oltre i confini del raggio d'azione di ciascuna Device_ProxCamera, sarà possibile accendere e spegnere la luce proveniente dal relativo Device_Chandelier, vale a dire il lampadario di quella stessa stanza, attualmente il salotto.

Aggiungendo una Device_LampLight ed un Device_ProxSensor nella camera da letto, seguendo le istruzioni già esposte all'inizio del paragrafo 3.6 Scenario II: illuminazione automatica, risulta ancora più evidente l'effetto della non necessità, da parte dell'anziano, del ricercare gli interruttori della luce, ogniqualvolta intenda trasferirsi da un ambiente ad un altro nella propria abitazione.

3.7 Note sul prototipo dello strumento

Con questo paragrafo s'intende precisare che il VAALID Authoring Environment esaminato si trova ancora allo stato di prototipo e che potrebbe quindi differire in alcuni aspetti dal prodotto finale. In particolare, l'utente potrebbe non riscontrare più i seguenti problemi o difficoltà, poiché risolti in una fase successiva:

• I nomi delle funzioni e degli eventi di un Dispositivo devono essere cercati manualmente al-l'interno del corrispettivo file VRML, perché al momento non possono essere rilevati auto-maticamente dallo strumento (3.2.1 Aggiungere un Dispositivo).

• I parametri del Dispositivo, quali la dimensione o il file audio da eseguire, non possono es-sere modificati dall'interfaccia grafica ma soltanto accedendo direttamente al file VRML.

• Non è consentito replicare il medesimo Dispositivo e i nomi devono essere unici, per evitare problemi di conflittualità nel distinguere le funzioni o gli eventi coinvolti e nel riconoscere a quali Dispositivi essi sono associati e a quali invece bisogna inviare i segnali.

• Il posizionamento di un Dispositivo potrebbe presentare alcune complicazioni, soprattutto per quanto riguarda le traslazioni e le rotazioni in un ambiente le cui dimensioni sono ignote. Una possibile semplificazione potrebbe derivare da un'esplorazione preventiva della scena: dato che la finestra 3D View fornisce le coordinate dell'utente virtuale, è possibile dedurre da esse le proporzioni dell'ambiente e la posizione desiderata per il Dispositivo, con una buona approssimazione. Ricavate le cifre nelle tre dimensioni, è sufficiente digitarle nei campi de-dicati (punto 5 in 3.2.1 Aggiungere un Dispositivo) per impostarle, lasciando soltanto l'orien-tazione alla regolazione manuale.

Allo stato attuale l'Utente Virtuale e l'analisi dei vincoli d'accessibilità non comportano variazioni per l'ambiente virtuale o per la simulazione in generale. Tali opzioni saranno sicuramente attivate e funzionali a prodotto ultimato.

Capitolo 4

Ambiente di Simulazione

Lo scopo dell'Ambiente di Simulazione è quello di rendere disponibile la soluzione AAL, sviluppata tramite lo Strumento di Authoring, per l'esperienza dell'utente nel corso delle dimostrazioni e delle valutazioni. L'Ambiente di Simulazione dovrebbe consentire all'utente finale di sperimentare la so-luzione in modo realistico, oltre a fornire agli sviluppatori gli strumenti per visualizzare e nel caso adattare il comportamento del sistema, mentre la simulazione è in esecuzione.Le caratteristiche dell'Ambiente di Simulazione consentiranno di riscontrare dove i cambiamenti dovranno essere apportati e, se l'utente denunzierà dei problemi, si avrà un feedback diretto.

Nel capitolo saranno esaminate l'architettura dell'Ambiente di Simulazione (4.1), le componenti del sistema (4.2) e le modalità di scambio d'informazione con l'Ambiente di Authoring (4.3). Infine si presenterà il sito per la sperimentazione sviluppato presso l'Università di Parma (4.4).

4.1 Architettura funzionale

L'Ambiente di Simulazione (SE) integrato nel progetto VAALID fornisce all'utente un sistema di si-mulazione flessibile e adattabile. Si dovrebbe pertanto dare all'utente il massimo controllo e traspa-renza sul funzionamento interno della simulazione. In questo modo verrebbero massimizzati i van-taggi ottenibili dalle verifiche condotte durante i test del prototipo.

La visualizzazione dei modelli 3D è soltanto una parte dell'Ambiente di Simulazione. La Figura 4.1 mostra una panoramica delle diverse componenti e le loro connessioni. L'Ambiente di Simulazione, infatti, è articolato in cinque elementi principali:

• Instant Player che visualizza lo scenario 3D, in particolare i dispositivi e sensori simulati, e riceve gli input dell'utente finale per mezzo dei controlli della simulazione.

• Workflow Engine che simula i servizi AAL sviluppati e le funzionalità dei dispositivi e dei sensori tramite l'uso di workflow (simili alle macchine a stati, che si spostano da uno stato ad un altro attraverso una serie di transizioni predefinite disponibili).

• Process Choreographer che collega il Workflow Engine alla simulazione dell'ambiente 3D e alle attrezzature reali nel Living Lab Verifier.

65

66 Capitolo 4 Ambiente di Simulazione

• Logger che riceve i dati dal Process Choreographer, circa le azioni dei servizi e dispositivi simulati, e dall'Instant Player, relativamente agli input degli utenti finali (il movimento nella scena e l'interazione con i componenti attivi del contesto simulato) e può salvare tutti questi risultati in un file, per una successiva analisi.

• Simulation Control Panel che consente all'utente di impostare i parametri dell'ambiente di simulazione e visualizzare gli stati del workflow e l'uscita del Logger mentre la simulazione è in esecuzione. L'utente può anche modificare manualmente gli stati del workflow e quindi interagire con la simulazione in esecuzione. Il Simulation Control Panel permetterà inoltre un'analisi dell'accessibilità all'ambiente, in base al modello precedentemente definito dallo Strumento di Authoring, per migliorarlo secondo le specifiche AAL.

Le diverse componenti dell'Architettura funzionale utilizzano i file creati mediante lo Strumento di Authoring per eseguire e controllare la simulazione. Alcune di queste saranno descritte in dettaglio nel paragrafo seguente (4.2), mentre le connessioni tra loro, l'uso di file differenti e i workflow fun-zionali sono esposti nel paragrafo 4.3.

4.2 Componenti funzionali

Sulla base della struttura generale dell'Ambiente di Simulazione, descritta nel paragrafo 4.1, si darà una spiegazione maggiormente precisa delle diverse componenti del sistema completo. Tuttavia sarà escluso l'approfondimento del Process Choreographer e del relativo Living Lab Verifier, in quanto il sito sviluppato presso l'Università di Parma non prevede un ambiente di tipo Living Lab (4.4).

Figura 4.1 - Architettura funzionale dell'Ambiente di Simulazione

Capitolo 4 Ambiente di Simulazione 67

4.2.1 Instant Player

Instant Player è un framework di rendering 3D sviluppato da Fraunhofer IGD. È usato nel contesto del sistema VAALID come blocco centrale della componente di simulazione in Realtà Virtuale (VR).Instant Player è avviato e può anche essere gestito dal Simulation Control Panel (vedere 4.2.2). Esso carica la simulazione completa in realtà virtuale, compresi i modelli 3D, le applicazioni logi-che e la gestione dei dispositivi, da un file VRML/X3D creato dall'Ambiente di Authoring VAALID.

Instant Player è destinato soprattutto ad ambienti virtuali immersivi come CAVE oppure a pareti di proiezione ad alta risoluzione composte di più proiettori, come lo HEyeWall (Figura 4.2) presso la sede Fraunhofer IGD di Darmstadt, ma può essere utilizzato anche per la visualizzazione tradizio-nale in 2D e 3D su computer desktop.Lo HEyeWall è l'ambiente VR principale utilizzato per le prove degli utenti in VAALID. Si compone di 24 moduli di proiezione stereo in 6 colonne e 4 righe. Ogni modulo di proiezione ha due proietto-ri, uno per l'occhio sinistro e uno per il destro. Ogni proiettore è controllato da un computer. Questo cluster di 48 computer per il rendering è guidato da un server d'applicazione sul quale Instant Player è in esecuzione. Il player trasferisce il grafico della scena, nonché tutte le modifiche apportate ad esso, tramite la rete, al cluster di rendering.

Molteplici dispositivi hardware di input sono stati integrati in Instant Player e consentono di naviga-re e interagire con la scena, come gamepad e space-mouse. Oltre agli strumenti convenzionali, una sedia a rotelle è collegata al player e permette di navigare nella scena in un modo più intuitivo.

I file VRML/X3D non contengono solo le geometrie 3D, ma supportano anche le animazioni e la logica complessa di applicazioni scritte in Javascript o Java. Questo permette di eseguire la maggior parte delle simulazioni all'interno del player. Si possono aprire e chiudere porte, accendere le luci e spegnerle, oppure simulare anche dispositivi elettronici più complessi, come le radio e i televisori o altri elettrodomestici, ad esempio macchine da caffè e forni a microonde.

Esistono inoltre particolari sensori all'interno della scena 3D che permettono di tenere traccia di tut-te le azioni dei partecipanti al test nell'ambiente virtuale. Queste informazioni vengono inviate al modulo di log, che consente di registrarle e analizzarle.

Figura 4.2 - HEyeWall


4.2.2 Simulation Control Panel

L'ambiente di sviluppo e simulazione VAALID fornisce strumenti sia per la creazione di simulazioni virtuali che per la loro esecuzione e gestione. Lo strumento che realizza il legame tra queste due funzioni di base è il Simulation Control Panel (SCP).

Questo strumento viene utilizzato dopo il processo di modellazione nell'Ambiente di Authoring, una volta creato lo scenario da simulare, compresi i modelli degli utenti, dell'ambiente, dei dispositivi e sensori, oltre ai servizi AAL che dovrebbero essere testati e valutati utilizzando il sistema VAALID.

Il Simulation Control Panel è stato integrato nello Strumento di Authoring. Tale scelta è motivata dal fatto che risulta conveniente per il progettista il passare dalla fase di modellazione dell'ambiente alla verifica della simulazione, potendo anche tornare indietro in modo semplice per effettuare le eventuali modifiche. Questo processo viene eseguito più agevolmente con uno strumento integrato, che supporta entrambi gli aspetti all'interno di un'unica applicazione.

Il Simulation Control Panel si compone delle seguenti funzionalità:

• Configurazione della simulazione: può configurare le specifiche per l'esecuzione della si-mulazione. La Settings view permette di decidere quali dispositivi avranno parte nel Living Lab Verifier, necessitando di una dotazione hardware, o se invece potrà essere usato un mo-dello virtuale di tali componenti. Lo sviluppatore può modificare le condizioni ambientali, per esempio se la simulazione si svolgerà di notte o di giorno, e scegliere anche tra i disposi-tivi di controllo supportati quello che meglio si adatta al suo attuale scopo di valutazione, di solito basandosi sul gruppo di utenti che dovrà valutare la soluzione AAL.

• Verifica dei vincoli d'accessibilità: prima d'iniziare la simulazione, l'utente può eseguire il cosiddetto Accessibility Check sull'ambiente, che è una prova formale, un'analisi del punto in cui l'ambiente simulato potrebbe presentare problemi di accessibilità rispetto alle esigenze del modello dell'utente. Avvertenze e raccomandazioni vengono dunque fornite al progettista su come l'ambiente può essere migliorato per soddisfare i criteri più importanti. Ad esempio, può essere segnalata un'insufficiente intensità di un allarme sonoro, quando l'utente ha un certo grado di ipoacusia.

• Simulazione dei Workflow: dopo aver avviato la simulazione, si è in grado di controllare lo stato dei workflow che sono in esecuzione e attivare le transizioni predefinite per cambiarlo. Questa funzionalità permette di forzare gli eventi che non possono essere attivati altrimenti.

• Esecuzione della simulazione: una volta che la simulazione è in esecuzione, il Simulation Control Panel memorizza l'input dell'utente e le corrispondenti reazioni del sistema, per un'analisi successiva. Il log panel mostra tutti i messaggi che vengono scambiati tra i com-ponenti della simulazione, consentendo al progettista di seguire i risultati in tempo reale.

• Analisi dei risultati: i dati registrati sono analizzati dal Simulation Control Panel per mette-re in luce le caratteristiche chiave del sistema AAL. I dati di log analizzati forniscono all'u-tente una visione ad alto livello delle sue funzionalità e parametri oggettivi per le sue presta-zioni. Questo è particolarmente utile nelle fasi iniziali di sviluppo, quando i sistemi sono ve-rificati dagli sviluppatori stessi, per ottenere un'esperienza in prima persona della soluzione e le modifiche sono condotte rapidamente, con costi ridotti.

Da un punto di vista dell'usabilità, il Simulation Control Panel è composto da sei finestre, ciascuna delle quali ha una funzione diversa, specifica, per agevolare lo scopo di offrire all'utente il controllo su qualsiasi test o esecuzione dell'ambiente sviluppato (Figura 4.3).


La finestra Overview fornisce all'utente una panoramica delle funzionalità di tutto il SCP, compresi i collegamenti alle funzioni più utilizzate, come le impostazioni salvate, i workflow caricati e i profili di accessibilità degli elementi di simulazione.

Il pannello SCPLoggerView è sempre visibile quando si avvia la simulazione. Questa finestra elenca i messaggi che il logger riceve da Instant Player o dal Process Choreographer ed è costantemente aggiornato. Il logger salva anche i dati registrati in un file di log, analizzato dal SCP al termine della simulazione.

Il pannello Thumbnails è visibile anche quando la Overview è attiva. Questo strumento acquisisce un'immagine della scena simulata, in qualsiasi momento, che può essere poi salvata, esportata o eli-minata. Questa funzionalità è ancora in via di sviluppo, in quanto considerata non prioritaria.

La finestra Simulation Control Editor (Figura 4.4) stabilisce le impostazioni per la simulazione. Queste comprendono la decisione sul fatto che i dispositivi e sensori dell'ambiente siano reali oppu-re virtuali, nonché la selezione dell'orario (notte o giorno) e di altre condizioni ambientali. Con essa si scelgono qui anche i controlli da utilizzare. Le impostazioni possono essere memorizzate come impostazione predefinita, per una riconfigurazione rapida della simulazione.

Figura 4.3 - SCP Overview, Logger e Thumbnails

PLAYPLAY

STOPSTOP


L'Accessibility verifier (Figura 4.5) consente al progettista di definire il profilo di accessibilità delle diverse componenti della simulazione. Questo profilo rappresenta le caratteristiche e le limitazioni che i dispositivi, l'ambiente e gli utenti hanno riguardo alle loro modalità di interazione. Una volta che i profili sono definiti, può essere eseguito il controllo, per determinare se esiste un problema che debba essere tenuto in considerazione.

La WF Simulation (Figura 4.6) mostra i flussi di lavoro in azione durante la simulazione. L'utente può scegliere quale workflow deve essere visualizzato e seguirne i messaggi e cambiamenti di stato, sovente di quello che descrive il servizio AAL. Questo punto di vista consente inoltre di intervenire nel corso degli eventi, tramite l'invio di XML-message artificiali al Process Choreographer, i quali saranno interpretati dal Workflow Engine come gli altri messaggi.

Infine, la finestra Results (Figura 4.7) è la revisione del file di log di qualsiasi simulazione eseguita, supportando anche il filtraggio per tipologia di messaggio o elementi all'interno della simulazione. Metriche diverse sono state implementate per essere calcolate sulla base di tali contenuti, come il tempo trascorso tra gli eventi, il numero delle interazioni degli utenti, oppure il numero di errori; le metriche sono definite dal progettista, che può scegliere quali eventi costituiranno il punto di inizio e di fine di un certo compito, monitorandone il tasso di completamento. I risultati sono memorizzati in un formato di set di dati, che permette di includere più calcoli e di salvarli come file separato.

Figura 4.4 - Simulation Control Editor


Figura 4.5 - SCP Accessibility Verifier

Figura 4.6 - SCP WF Simulation


In concreto, per eseguire uno Scenario creato con il VAALID AE (Capitolo 3), bisogna prima acce-dere al Simulation Control Editor (Figura 4.4) ed eventualmente modificarne le preferenze. In ogni caso, premere poi il pulsante PLAY segnato in Figura 4.3 per avviarne la simulazione. Dopo aver at-teso il tempo necessario per il caricamento e l'apparizione dell'avviso “Simulation - Started” nella finestra SCPLoggerView, è possibile interagire con l'ambiente in Instant Reality. Da ultimo premere STOP per terminarla.

4.2.3 Logger

Il logger è un componente software totalmente integrato col pannello di controllo della simulazione (SCP). Il modulo di log è stato sviluppato allo scopo di fornire un sistema di gestione automatica e trasparente per la registrazione di tutti gli eventi che si verificano durante una simulazione, tramite un gestore per quelli provenienti dal Process Choreographer e un altro per quelli di Instant Player (Figura 4.8). Così il logger di VAALID conserva anche i dati delle interazioni tra utente e ambiente.

Tutti i dati raccolti vengono salvati in un file di log (formato testuale). Ciascuna voce considera sia l'istante in cui si è verificato un evento che i suoi dati effettivi. Oltre a salvare i dati registrati in un file di log, tutti gli eventi vengono visualizzati in una finestra nella parte inferiore del Simulation Control Panel (Figura 4.3).

Figura 4.7 - SCP Results


4.2.4 Workflow Engine

Questo modulo si occupa di visualizzare lo stato di un workflow ad ogni istante della simulazione e consente all'utente di forzare i segnali dal nodo attualmente attivo e in esecuzione, evidenziato come in Figura 4.6. Vi è quindi una continua interazione tra il simulatore e il Workflow Engine.

4.3 Flusso d'informazione tra AE ed SE

Le componenti dell'architettura di VAALID comunicano l'una con l'altra secondo diverse modalità. Mentre il Process Choreographer è collegato agli altri grazie all'invio e alla ricezione di messaggi XML, il flusso di informazioni a partire dalla creazione del modello dell'ambiente con lo Strumento di Authoring fino all'Ambiente di Simulazione avviene attraverso altri tipi di file, con scopi distinti. Questo paragrafo descrive il flusso di informazioni tra le diverse componenti, in ordine cronologico.

Il primo passo è la creazione di un nuovo Scenario usando lo Strumento di Authoring (Capitolo 3). In questo processo viene creato il modello 3D della scena, il profilo dell'utente di destinazione, il modello ontologico dei dispositivi presenti nell'ambiente simulato e un insieme di servizi AAL che li associano in modo significativo. Tali risultati sono salvati in file diversi, ciascuno dei quali serve ad uno scopo specifico nel suo utilizzo finale, come base per l'Ambiente di Simulazione.

Tre sono le tipologie di questi file: JPDL, OWL e VRML.

Figura 4.8 - Schema del Logger


Il JPDL identifica il formato dei workflow, che descrivono sia i servizi AAL che le funzionalità dei diversi tipi di dispositivi. Ad ogni servizio o dispositivo ne può essere associato al massimo uno. L'OWL definisce le ontologie, che contengono una descrizione semantica dell'ambiente e delle sue attrezzature e il modello dell'utente. Un file è dell'ambiente, mentre gli altri sono associati, uno per ciascuno, ad ogni attrezzatura e servizio AAL sviluppati. Il VRML rispecchia i file che contengono la rappresentazione 3D dell'ambiente, inclusi script e collegamenti di controllo della simulazione.

Prima che la simulazione possa essere avviata sulla base di questi input dell'Ambiente di Authoring, l'utente può configurare le impostazioni utilizzando il Simulation Control Panel (SCP). Quando si scelgono i controlli da utilizzare per interagire con la simulazione, il SCP modifica il file VRML di conseguenza, aggiungendo il codice necessario per il collegamento di questi dispositivi di input con i componenti del modello 3D. Per esempio, anche la variazione Giorno/Notte dovrà comportare un aggiornamento al file VRML. Nella versione finale dello strumento, che attualmente è allo stato di prototipo, l'utente potrà eseguire anche una verifica sull'accessibilità dell'ambiente AAL sviluppato. A tal fine, il SCP leggerà i file delle ontologie semantiche di ambiente, utente e dispositivi.

Quando l'utente inizia la simulazione, il Simulation Control Panel carica i file JPDL nel Workflow Engine, i file VRML in Instant Player ed avvia sia il Process Choreographer che il Logger: il primo scambia messaggi XML con il Workflow Engine ed Instant Player, agendo da mediatore tra i servizi AAL e i dispositivi simulati; il secondo, durante la simulazione, riceve dal Process Choreographer e da Instant Player i dati su tutti gli input dell'utente tramite i comandi di simulazione e sulle relative reazioni del sistema, ottenendo un registro completo di quanto avvenuto.

Durante la simulazione, l'utente può seguire l'evoluzione dei workflow che simulano le interazioni tra l'ambiente, i dispositivi ed i servizi AAL, osservando le reazioni del sistema agli input dell'utente mediante una visualizzazione grafica. Essa è realizzata dal SCP caricando le rappresentazioni dai file JPDL creati nell'Ambiente di Authoring e permette all'utente d'inviare messaggi all'interno della simulazione mentre essa è in esecuzione, che per il Process Choreographer è equivalente a riceverli dal Simulation Control Panel.Completata l'esecuzione, il SCP può leggere il file di log e analizzare i risultati della simulazione, con un feedback conciso per l'utente.

4.4 Sito per la sperimentazione

Il sito per la sperimentazione di VAALID in Italia prevede sia l'Ambiente di Authoring (Authoring Environment) che l'Ambiente di Simulazione (Simulation Environment), realizzato dal Dipartimen-to di Ingegneria dell'Informazione dell'Università degli Studi di Parma. Una singola stanza è adope-rata per la valutazione di entrambi. L'arredamento è costituito essenzialmente da un tavolo e da una sedia per l'utente. Gli esperimenti, infatti, saranno effettuati in un'area di lavoro desktop.

L'Ambiente di Simulazione italiano (Figura 4.9), diversamente da quelli realizzati in Spagna e in Germania da altri partner, non fornisce un Living Lab, cioè un reale appartamento attrezzato, ma comprende come dispositivo d'uscita un proiettore 3D per la visualizzazione di un ambiente virtuale su una parete della stanza. Esso è in grado di sovrapporre due immagini della stessa scena, una per ciascun occhio, e restituire l'effetto delle tre dimensioni spaziali, ma soltanto nel caso in cui la pro-iezione stessa venga guardata mediante gli appositi occhiali per la visione 3D.


Gli esperimenti riguardanti lo Strumento di Authoring sono eseguiti su un computer desktop, utiliz-zato anche per l'Ambiente di Simulazione. L'utente siederà sulla sedia e interagirà con l'interfaccia proposta per lo svolgimento delle valutazioni sulla navigazione in ambiente virtuale. A tale scopo sono previste quattro possibili configurazioni per i dispositivi d'interazione virtuale:

• VHT (Virtual Hand-Tracking);• Smartphone Android;• Wiimote;• Falcon + SpaceMouse o Wheelchair.

Il sistema di tracciamento manuale VHT [22] richiede una telecamera monoculare, un sostegno e un pannello nero. Sopra quest'ultimo è situata la telecamera, rivolta verso il basso, al fine di riconosce-re i movimenti della mano. Tramite la visione artificiale del computer, connesso ad un programma di servizio alla simulazione in realtà virtuale (sulla base del player InstantReality), ed opportune as-sociazioni con alcuni semplici gesti della mano, è possibile spostarsi nell'ambiente ed interagire con esso. Una procedura di calibrazione è dunque necessaria, per impostare i parametri interni dell'algo-ritmo di riconoscimento.

Lo Smartphone Android necessita di una Wireless LAN per la comunicazione con il PC desktop. I movimenti nella scena 3D sono controllati dagli accelerometri del dispositivo. Quindi gli sposta-menti avvengono inclinando il dispositivo nella direzione desiderata. L'interazione è invece gestita mediante i pulsanti oppure il touchscreen.

Una connessione Bluetooth è invece richiesta dal Wiimote. Il suo accelerometro interno percepisce l'inclinazione e la rotazione dell'oggetto per i movimenti nello spazio virtuale, mentre le interazioni sono attuate grazie al meccanismo di puntamento a infrarossi integrato con la Wii Sensor Bar [23].

Figura 4.9 - Ambiente di Simulazione sviluppato presso l'Università di Parma


L'ultima interfaccia separa fisicamente la navigazione nell'ambiente 3D proiettato e l'interazione con lo Scenario virtuale: la prima può basarsi sia su un semplice SpaceMouse che su una Wheel-chair, una sedia a rotelle appositamente costruita e configurata; la seconda avviene usando le fun-zionalità e il realismo offerti dal Falcon [24], in grado di simulare anche la dinamica e le forze.

La (Figura 4.10) mostra un riepilogo dei dispositivi coinvolti.

I progettisti di sistemi e servizi AAL avranno quindi a disposizione più interfacce, caratterizzate per un diverso grado d'usabilità, che potranno consentire una migliore adattabilità all'età e alla semplici-tà richiesta dai beneficiari, anziani o disabili, che valuteranno le soluzioni in ambiente virtuale.

Figura 4.10 - Wheelchair, Falcon, SpaceMouse, Wiimote, Smartphone, VHT

Conclusioni

Il lavoro compiuto durante questa tesi ha riguardato soprattutto l'analisi e l'estensione del VAALID Authoring Environment, lo strumento per la progettazione e per il supporto alla creazione, in realtà virtuale, di ambienti assistivi rivolti alle persone anziane o disabili.

Inizialmente è stato necessario condurre un esame almeno delle principali componenti dell'Ambien-te di Authoring, al fine di comprenderne il funzionamento. Ne è nata una guida all'uso, un manuale che illustra il procedimento per la realizzazione di un generico progetto di una soluzione AAL: am-biente, dispositivi, profilo dell'utente, interazioni e servizi. Quindi sono stati ideati due scenari spe-cifici, per completare la trattazione degli aspetti che non potevano essere approfonditi in una discus-sione generale.

Nuovi dispositivi sono stati sviluppati in VRML. I loro modelli grafici sono stati convertiti in que-sto formato grazie alla possibilità di esportazione fornita da 3D Studio Max, mentre le loro proprietà e il loro comportamento sono il risultato di una convergenza tra le potenzialità dei nodi e campi VRML e i workflow della piattaforma VAALID.

I file risultanti, relativi alla gestione dell'aspetto e dell'evoluzione dei nuovi dispositivi, in risposta agli eventi nell'ambiente circostante oppure agli stimoli dell'utente, sono stati utilizzati per estendere le librerie fornite con lo strumento, così da renderli disponibili anche per altre future applicazioni.

Il VAALID Authoring Environment si trova attualmente allo stato di prototipo. Quindi alcune funzio-nalità potrebbero essere aggiunte o migliorate, rispetto alla versione considerata, quando il prodotto sarà ultimato. In particolare, alcuni problemi riscontrati dovranno essere risolti, per esempio il fatto di non poter prescindere dalla conoscenza del codice VRML di un dispositivo che si desidera inte-grare in una soluzione AAL, al fine di ricavarne le funzioni ed eventi.

Sono inoltre da ottimizzare sia la definizione del profilo dell'utente virtuale che l'analisi dei vincoli d'accessibilità. Al momento, infatti, esse non comportano variazioni per l'ambiente o per la simula-zione in generale. A motivo di queste limitazioni, tali funzionalità sono state escluse da entrambi gli scenari proposti.

Per comprendere alcune delle problematiche dello strumento, sono utili ed interessanti i risultati dei test sperimentali condotti in collaborazione con il Centro di Cultura Scientifica “Alessandro Volta”, su un campione di otto utenti scelti tra gli esperti d'usabilità e gli Interaction Designer (Tabella 1). Sono state selezionate alcune delle fasi più significative, sulle quali era stato chiesto di esprimere un giudizio, una volta completate le azioni previste.

77

78 Conclusioni

Secondo i dati raccolti, l'esercizio sulla collocazione dei dispositivi all'interno dello spazio 3D (task 3a nella Tabella 1) ha rappresentato la difficoltà maggiore. Nessuno dei candidati è riuscito, infatti, a completare il processo senza un aiuto importante da parte dei moderatori. Molti hanno lamentato l'eccessiva complessità nell'orientarsi all'interno dell'ambiente virtuale e nella gestione del posizio-namento dei dispositivi. Alcune soluzioni, da loro proposte, prevedevano l'aggiunta di proiezioni 2D o visuali da altre angolazioni, unite ad un controllo bilanciato tra la tastiera e il mouse per ruotare e traslare gli oggetti.

Task 2: Modifica al Modello di

Edward

Task 3a: Aggiunta elemento dalla

Libreria

Task 4: Definire una Azione nel

Workflow

Task 5: Avviare la Simulazione

Task 6: Verificare evoluzione

correttaProfessione

Consultant 2 A 4 C 3 B 2 B 2 A

Interaction Designer 2 A 2 C 1 B 2 A 1 A


Interaction Designer 2 A 5 C 3 C 1 A 1 A


AALSystem Integrator 2 A 4 C 3 C 1 B 2 A

Researcher 2 A 3 C 1 C 1 A 1 A

SystemDesigner 1 A 3 C 2 B 1 A 1 A

Media 2 A 3 C 2 B 1 A 1 A

Giudizio: 1=facile, 5=difficile. Successo: A= da solo; B= qualche aiuto; C= insuccesso.

Tabella 1 – Risultati test del VAALID AE

Anche per quanto riguarda la modifica dei workflow è stata necessaria qualche indicazione. Tuttavia in questo caso hanno convenuto quasi tutti che sarebbe sufficiente l'inserimento di qualche spiega-zione sul significato dei diversi elementi e sul loro possibile utilizzo, poiché l'interfaccia grafica è invece semplice ed intuitiva.

Tutte le altre richieste sono invece state completate con successo, sia l'avvio della simulazione che la sua esecuzione, con la verifica che le interazioni avvenissero correttamente.

Nel complesso, queste prime verifiche con esperti e futuri utenti professionali del sistema VAALID hanno portato a risultati promettenti e fornito indicazioni concrete per il completamento dello stru-mento.

Bibliografia

[1] Home page - FP7 - Research - European Commission (novembre 2010) http://ec.europa.eu/research/fp7/

[2] Karol Vrendenburg, Scott Isensee, Carol Righi. User-Centered Design: An Integrated Ap-proach. Prentice Hall PTR, 2002.

[3] Nancy J. Cooke, Eduardo Salas. Best of Human Factors: Thirty Classic Contributions to Human Factors/Ergonomics Science and Engineering. Human Factors and Ergonomics So-ciety, 2008.

[4] Towards an Inclusive Future: Impact and Wider Potential of Information and Communica-tion Technologies. Edited by Patrick R.W. Roe. COST 219ter, Brussels, 2007. http://www.tiresias.org/cost219ter/inclusive_future/index.htm

[5] European Commission : CORDIS : FP7 : ICT : Programme : Independent living and inclu-sion (dicembre 2010) http://cordis.europa.eu/fp7/ict/programme/challenge7-budget_en.html

[6] CORDIS FP6: What is FP6: Intruments: Specific targeted research projects: (dicembre 2010) http://cordis.europa.eu/fp6/instr_strp.htm

[7] Dipartimento di Ingegneria dell'Informazione (dicembre 2010) http://www.dii.unipr.it/

[8] Ambient Assisted Living Joint Programme (AAL JP) (ottobre 2010) http://www.aal-europe.eu/

[9] ISO/FDIS 9241-210 Ergonomics of human-system interaction - Part 210: Human-centred design for interactive systems.

[10] Susan Gasson. Human-centered vs. user-centered approaches to information system design. Journal of Information Technology Theory and Application, 2003.

[11] ISO/TR 16982:2002(E) Ergonomics of human-system interaction - Usability methods sup-porting human-centred design.

[12] World Health Organization. Towards a Common Language for Functioning, Disability and Health: ICF. Geneva, Switzerland: World Health Organization, 2002.

[13] ETSI EG 202 116 v1.2.1 (2002-09): Human Factors (HF); Guidelines for ICT products and services; "Design for All".

[14] A. Schmidt. Interactive Context-Aware System Interacting with Ambient Intelligence. G. Riva, F. Vatalaro, F. Davide, M. Alcañiz (Eds.). IOS Press, pp. 159-178, 2005.

[15] ISO/IEC 24756:2009: Information technology - Framework for specifying a common access profile (CAP) of needs and capabilities of users, systems, and their environments.

79

80 Bibliografia

[16] ISO/IEC 14772: Information technology - Computer graphics and image processing - The Virtual Reality Modeling Language (VRML).

[17] T. R. Gruber. A Translation Approach to Portable Ontology Specifications. Knowledge Ac-quisition, 5(2):199-220, 1993.

[18] Workflow Management Coalition (novembre 2010) http://www.wfmc.org/

[19] jBPM - JBoss Community (dicembre 2010) http://www.jboss.org/jbpm

[20] Instant Reality (ottobre 2010) http://www.instantreality.org/

[21] International Classification of Functioning, Disability and Health: ICF. WHO Library Cata-loguing-in-Publication Data. World Health Organization, Geneva, 2001. http://www.handicapincifre.it/documenti/ICF_18.pdf

[22] Ying Wu, Huang T.S. Hand modeling, analysis and recognition. IEEE Signal Processing Magazine, vol. 18, n. 3, pp. 51-60, 2001.

[23] Official Wii website (dicembre 2010) http://wii.com/

[24] The Novint Falcon controller (dicembre 2010) http://home.novint.com/products/novint_falcon.php

ANALISI ED ESTENSIONE DI UNO STRUMENTO PER LA …rimlab.ce.unipr.it/documents/TesiCigolini.pdf ·...

Documents

Transcript of ANALISI ED ESTENSIONE DI UNO STRUMENTO PER LA …rimlab.ce.unipr.it/documents/TesiCigolini.pdf ·...