TARE (Trigger Action Rule Editor) [17] in cui il robot Pepper è stato integrato, è necessario un rapido escursus sul background tecnologico su cui questa soluzione pone le fondamenta.
La crescita del numero di dispositivi intelligenti che oggigiorno troviamo intorno a noi va di pari passo all’esigenza di un loro sempre più crescente controllo personalizzato.
Col tempo sono inoltre cambiate le modalità d’interazione con gli apparati, dalle pulsantiere siamo arrivati ai telecomandi programmabili, dai touch panel alle app su smartphones, fino ad arrivare al controllo vocale, al controllo tramite gesture e al riconoscimento delle espressioni del volto.
Luci, tende, dispositivi da cucina, sensori di luminosità, termostati e innumerevoli altri device di tipo “smart” da qualche anno stanno popolando le nostre abitazioni e anche per chi non è programmatore, nasce l’esigenza di capire ed essere in grado di gestire le loro funzionalità, sia in maniera isolata, ovvero il semplice controllo di un singolo dispositivo, sia in maniera sinergica, con dispositivi che “dialogano” fra loro al fine di ottenere logiche più complesse che abbracciano molteplici ambiti della vita comune. Esistono diverse tipologie di soluzioni professionali e non e tentativi di standard internazionali che si sono imposti nel corso degli anni.
Si parte dalla tecnologia EIB-KNX, per passare ad apparati Creston, AMX, Control-4 e arrivare a “soluzioni casalinghe” basate su Arduino [18].
Tutte queste soluzioni richiedono però a monte una preparazione specifica sulla particolare tecnologia, delle competenze di programmazione nonché spesso di elettronica e circuiti elettrici.
Inoltre col tempo cambiano le esigenze dell’impianto e con maggiore velocità quelle dell’utente e dunque, una configurazione valida oggi, potrebbe non essere più adeguata fra qualche mese o anno. Da qui riparte la ricerca dell’esperto della particolare tecnologia e del nuovo apparato, con una
ripercussione sui tempi e sui costi di gestione oltre alla compromissione della soddisfazione
dell’utilizzatore che spesso tende a rinunciare a certe tipologie di soluzioni e a vederle come “gadget tecnologici” senza apprezzarne a pieno le potenzialità.
La meta della piattaforma di personalizzazione TARE è quella di rendere capace l’utilizzatore finale, anche privo di skills di programmazione informatica, di essere in grado di personalizzare in maniera semplice e autonoma il comportamento della propria applicazione IoT in maniera da sentire costantemente esaudite le proprie aspettative.
Il software TARE fa parte a pieno titolo delle tecnologie End-User Development (EUD), tecnologie che si prefiggono la meta di consegnare la configurazione delle applicazioni nelle mani dell’utilizzatore finale, l’unico che ha piena coscienza delle dinamiche delle proprie esigenze personali (rappresenta cioè l’autentico domain expert).
46
Gli scenari d’impiego di questa branca di tecnologie sono molto numerosi e non si limitano di certo alla home-building automation bensì possono ricoprire aree diverse come:
Supermercati (smart retail), dove potrebbero essere creati dei percorsi personalizzati per l’acquirente, in possesso del proprio smartphone, combinando le informazioni presenti ad esempio nella sua lista dei preferiti o nei cookies del browser.
Musei, dove potrebbero essere configurate varie tipologie di percorsi e informazioni da presentare in funzione della particolare mostra o del periodo dell’anno oppure cambiare le informazioni presentate in funzione della distanza o del tempo che la persona dedica alla particolare opera (trigger correlato all’interesse dimostrato dall’utente).
Gestione di magazzini e approvvigionamenti in cui la gestione di eventi, liberamente configurabili dal magazziniere, possono aiutare e guidare l’iter di gestione dei prodotti.
Assistenza remota ad anziani o persone disabili in cui ad esempio reminder e alert di vario genere (vocali, testuali, sonori, vibrotattili) possono essere inviati allo scatenarsi di una certa condizione (orario, temperatura corporea, frequenza respiratoria).
L’attività centrale di questa tesi è stata quella di integrare il robot Pepper in questa infrastruttura tecnologica, dando la possibilità a un utente qualsiasi di gestire in piena autonomia le numerose funzionalità offerte dal robot.
Tale libertà permetterà di integrare il robot in uno qualsiasi degli scenari e ambienti prima descritti (o in qualunque altro contesto di utilizzo) garantendo massima flessibilità e customizzazione grazie al design infrastrutturale che verrà esposto nei paragrafi successivi.
6.1 I Requisiti
Dall’analisi descritta in [17], l’applicazione TARE è stata sviluppata nel rispetto di diversi requisiti fra i quali si riportano:
1) Necessità di un approccio meta-design che integri informazioni contestuali IoT, ovvero la focalizzazione su una collaborazione partecipata fra utilizzatori finali, domain experts e sviluppatori ai vari steps di design, sviluppo e controllo della soluzione, al fine del raggiungimento di mete concrete che soddisfano esigenze reali.
2) La possibilità di combinare una molteplicità di triggers e azioni secondo le più comuni logiche di tipo AND, OR, NOT al fine di adattarsi alla maggior parte delle condizioni e modalità di utilizzo. (caratteristica che contraddistingue TARE dalla più conosciuta piattaforma action-rule based IFTTT [19]).
3) Una comunione fra linguaggio visuale e linguaggio naturale al fine di una gestione multimodale dell’applicazione.
4) Usare un vocabolario (e dunque funzionalità) ad hoc per descrivere al meglio ogni genere di contesto di utilizzo della piattaforma.
47
5) Garantire un tool flessibile e al contempo semplice grazie ad un’accurata gestione delle tassonomie informative e dei flussi di composizione delle regole.
6.1.1 Classificazione dei trigger nel modello del contesto
Lo sviluppo di applicazioni dipendenti da contesto impone la definizione degli eventi e delle azioni rilevanti al contesto stesso.
Il modello di contesto è strutturato su 4 dimensioni: users, environment, technology e social relationships.
Sotto user vanno le informazioni personali del soggetto (come sesso, età, istruzione, abitudini, interessi preferenze), fisiche e mentali (es. disabilità, malattie congenite ma anche frequenza
respiratoria/cardiaca emozioni e stati d’animo) ma anche la sua posizione (assoluta/relativa) e prossimità a un determinato punto di interesse.
Environment raccoglie la gamma d’informazioni riguardanti il background in cui l’utente si trova. Fanno parte di questa categoria la posizione (es. dentro/fuori un edificio), la luminosità, il rumore, la
temperatura d’ambiente e condizioni meteo.
Con technology si tiene conto delle caratteristiche del dispositivo con cui si accede al servizio (es. risoluzione, tipo di connettività, livello di batteria) oppure le tipologie di smart things/appliances cui vogliamo associare una regola di gestione.
Infine social relationship racchiude l’appartenenza a gruppi virtuali o reali, la lista degli amici o followers, la tipologia di relazione, il grado di parentela, la partecipazione ad eventi e feste.
48
Un cambiamento di uno di questi aspetti (evento) o l’essere in una determinata condizione (stato) determinano dei triggers che innescano il processo di esecuzione della regola.
Il modello di contesto iniziale è indipendente dal dominio e viene di volta ridefinito in base allo specifico dominio applicativo considerato. Il Context Manager (descritto successivamente in 7.2 Authoring Tool,
Adaptation Engine, Context Manager) svolgerà questa funzione d’integrazione omogenea delle
informazioni provenienti dalle differenti sorgenti caratterizzanti il contesto.
Figura 28. Esempio di selezione di un trigger in un particolare contesto d’uso.
6.1.2 Classificazione delle azioni
Anche per le azioni vale la considerazione del fatto che possono essere definite quando viene determinato lo specifico dominio applicativo d’interesse, dato che sono loro che specificano come l’applicazione deve cambiare al fine di ottenere l’adattamento richiesto.
In [17] sono state definite le seguenti famiglie di azioni:
relative agli smart things/appliance come il cambiamento di uno stato di un attuatore (es. accensione di una luce);
modifiche nell’interfaccia utente come il cambio di presentazione, i contenuti o modalità di navigazione;
49
di distribuzione dell’interfaccia utente ovvero come gli elementi dell’interfaccia utente vengono distribuiti su dispositivi diversi;
funzionalità, quando un servizio esterno viene acceduto (ad esempio le previsioni del tempo);
allarmi, per indicare qualche situazione potenzialmente pericolosa;
reminders, per indicare qualcosa che deve essere fatto.
Anche per le azioni sarà la fase di customizzazione dell’applicazione a definire nel dettaglio la tipologia da utilizzare per il ottenere il miglior fitting con le esigenze del contesto d’uso target.
Figura 29. Esempio di selezione di un’azione in un particolare contesto d’uso.