integración de dispositivos en una plataforma de vida
TRANSCRIPT
Integración de dispositivos en una
plataforma de vida cotidiana asistida por
computadora.
Trabajo Final - Ingeniería de Sistemas
Facultad de Ciencias Exactas
Universidad Nacional del Centro de la Provincia de
Buenos Aires
Alumna: Keimel Marina Gisele Director: Cristian García Bauza
Co-Directora: Carolina Valdez Gándara Junio de 2016
Tabla de contenido Resumen .................................................................................................................................. 6
CAPÍTULO 1: Introducción ........................................................................................................ 7
1.1 MOTIVACIÓN .................................................................................................................. 9
1.2. Objetivo....................................................................................................................... 10
1.3 Organización del documento ........................................................................................ 11
CAPÍTULO 2: Marco Teórico.................................................................................................... 12
2.1 Introducción ................................................................................................................. 12
2.2 Discapacidad y Tecnología ............................................................................................ 12
2.3 Inteligencia Ambiental (AmI)......................................................................................... 13
2.4 Ambient Assisted Living (AAL) ....................................................................................... 13
2.5 Reconocimiento de gestos ............................................................................................ 15
2.6. Reconocimiento de comandos de voz .......................................................................... 17
2.7 Sensor Myo .................................................................................................................. 18
2.8 Amazon Echo ................................................................................................................ 20
2.9 Intellihome ................................................................................................................... 21
2.9.1 Administración de datos y sensores: capa de abstracción y extensión para nuevos
sensores ..................................................................................................................... 22
CAPÍTULO 3: Diseño e implementación................................................................................... 25
3.1 Introducción ................................................................................................................. 25
3.2 Integración del dispositivo Amazon Echo ...................................................................... 25
3.2.1 Cómo interactúan los usuarios con Alexa. .............................................................. 26
3.2.2 Diseño de la interfaz de voz. .................................................................................. 29
El esquema de Intents ................................................................................................ 29
Frases de entrada ....................................................................................................... 31
Variables predefinidas ................................................................................................ 32
Peticiones enviadas por Alexa .................................................................................... 33
LaunchRequest ........................................................................................................... 33
IntentRequest ............................................................................................................ 34
SessionEndedRequest................................................................................................. 37
Devolución de una respuesta ..................................................................................... 38
Proceso de pruebas .................................................................................................... 39
3.2.3 Capa intermedia de servicios web. ......................................................................... 40
Componente de interacción con Intellihome .............................................................. 42
Estructura de datos de Intellihome ............................................................................. 42
3.2.4 Extensión de Intellihome ....................................................................................... 43
Componente Iniciar reconocimiento de dispositivos Remotos .................................... 45
Iniciar reconocedor de dispositivos remotos............................................................... 47
3.2.5 Conclusiones generales de la integración de Amazon Echo .................................... 48
3.2.6 Solución de infraestructura para la solución........................................................... 49
3.3 Integración del dispositivo MYO. .................................................................................. 51
3.3.1 Desarrollo de Scripts para Myo .............................................................................. 51
3.3.2 Conclusiones de la integración de Myo con scripts................................................. 53
3.3.3 Integración de Myo utilizando MyoSharp............................................................... 53
3.3.3 Conclusiones de la integración con MyoSharp. ...................................................... 57
CAPITULO 4: Análisis y pruebas .............................................................................................. 58
4.1. Assurance cases ........................................................................................................... 58
4.2. Atributos de calidad de un sistema de AAL .................................................................. 61
4.3. Evaluación de vulnerabilidades .................................................................................... 65
4.3.1 Disponibilidad y Confiabilidad ................................................................................ 65
Requerimientos mínimos de la PC a utilizar: ............................................................... 65
Limitaciones de Hardware .............................................................................................. 66
Distancia entre los usuarios y el sensor Amazon Echo:................................................ 66
Fallas de software .......................................................................................................... 66
Vulnerabilidades encontradas: ................................................................................... 67
4.3.2 Seguridad e Integridad ........................................................................................... 69
Vulnerabilidades encontradas: ................................................................................... 71
4.3.3 Confidencialidad .................................................................................................... 73
4.3.4 Mantenibilidad ...................................................................................................... 73
4.4 Pruebas de usuario ....................................................................................................... 76
4.4.1 Descripción de los sujetos de estudio. .................................................................... 76
4.4.2 Descripción de las tareas. ...................................................................................... 77
4.4.3 Resultados y conclusiones...................................................................................... 77
CAPITULO 5: Conclusiones y trabajos futuros ......................................................................... 84
5.1. Conclusiones................................................................................................................ 84
5.2. Trabajos futuros .......................................................................................................... 85
Referencias bibliográficas ....................................................................................................... 87
Agradecimientos .................................................................................................................... 90
Resumen
En esta tesis se describe la extensión una plataforma que facilita el desarrollo de aplicaciones
de Ambient Assisted Living (AAL, vida cotidiana asistida por computadora en castellano) que
permitan transformar un ambiente convencional en un ambiente inteligente utilizando
tecnología de bajo costo. El objetivo principal de este trabajo incorporar nuevos sensores a la
plataforma que permitan asistir a personas con discapacidad en sus residencias o ambientes
laborales promoviendo la inclusión social, incrementando su calidad de vida a través de la
autonomía y el confort, reduciendo la dependencia de terceros.
El sistema les permite a los usuarios ser su propio control remoto para controlar diversos
dispositivos de una vivienda u oficina, interactuando de manera natural utilizando gestos
corporales simples y comandos de voz.
La funcionalidad de la plataforma ha sido validada a través de la implementación de una
aplicación de prueba a la que llamamos "IntelliHome". Esta aplicación no solamente reconoce
gestos y comandos de voz de sus usuarios, sino que también cuenta con un prototipo
compuesto por una interfaz eléctrica que permite de la interacción entre el software y los
dispositivos eléctricos domésticos del ambiente, la cual fue utilizada para las pruebas y
validación con los usuarios.
CAPÍTULO 1: Introducción
En los últimos años se han desarrollado nuevas formas de interactuar con sistemas de
computadoras. El estudio multidisciplinario de la interacción humano-computadora (HCI, por
sus siglas en inglés) estudia la comunicación entre el ser humano y las máquinas. Esto implica
que HCI involucre conocimientos acerca de técnicas computacionales, psicología cognitiva y
función del ser humano
Hoy en día son muchos los dispositivos que ayudan a las personas a interactuar con sistemas de
computadora. Los sistemas de interfaz natural permiten a los usuarios interactuar con las
aplicaciones sin utilizar los dispositivos de entrada estándar y utilizar en su lugar pantallas
táctiles, reconocedores de gestos y voz, lectores de huellas digitales o retinas oculares para
iniciar sesión en sistemas de seguridad, entre otros. Todos estos dispositivos fueron
desarrollados por separado y se han unido dentro del estudio de Ambient Assisted Living (AAL,
vida cotidiana asistida por computadora). AAL es un dominio de aplicación en crecimiento que
pertenece al campo de Ambient Intelligence (AmI, Inteligencia Ambiental) y se caracteriza por
ser un conjunto de tecnologías innovadoras que pueden ser integradas dentro de un entorno
residencial familiar siendo, generalmente, transparente al usuario.
En general, las viviendas y edificios están construidos para satisfacer las necesidades de forma
masiva sin tener en cuenta a habitantes con dificultades. Por esta razón, una casa convencional
puede pasar a ser un lugar poco habitable para una persona con discapacidad (V. Gándara,
2015). Esto, combinado con situaciones cotidianas puede ocasionar que un usuario con
movilidad reducida tenga una vivienda poco habitable. Un ejemplo de esta problemática es
controlar un televisor utilizando un control remoto. En la mayoría de los casos, el usuario busca
el control remoto, para esto se debe dirigir hasta su ubicación, esquivando ciertos obstáculos
como objetos y muebles situados en el camino. Para una persona con discapacidad, este
desplazamiento puede significar un gran desafío y en ocasiones algo imposible de realizar,
tendiendo a recurrir a un tercero que los asista en estas sencillas tareas. Esta dependencia se
puede reducir con un ambiente inteligente que permita responder a las solicitudes de sus
usuarios en tiempo real.
El objetivo principal de AAL es aplicar el concepto de inteligencia ambiental (AmI) (Kleinberger,
2007) para ofrecer a las personas ancianas o con discapacidad una mayor autonomía y confort
en sus hogares.
AmI propone construir ambientes inteligentes, mientras que AAL tiene como objetivo asistir a
las personas ancianas o con discapacidad en su propio hogar o entornos laborales para mejorar
su calidad de vida y la inclusión social, utilizando las nuevas Tecnologías de la Información y la
Comunicación.
Por otra parte, el habla es una forma natural de comunicación que se adapta perfectamente a
aquellos usuarios con limitaciones motoras severas. En estos casos, las tecnologías de
reconocimiento de voz pueden ayudar a muchas personas con discapacidad, brindando mejoras
en la igualdad, inclusión social y en su vida cotidiana (Delić, V., 2013). Esta tecnología es utilizada
en sillas de ruedas inteligentes (Anastasiou, 2012) o en el campo de la educación y aprendizaje
basado en computadoras (Shrawankar, 2010). En los últimos años se ha visto una creciente
mejora en estos sistemas y con ellos la Inteligencia Artificial aplicada al procesamiento de
comandos asociados al mismo (Dale, 2015).
En la actualidad, existen varias plataformas de bajo costo de reconocimiento de gestos y
lenguaje natural, siendo Amazon Alexa Service una de las más populares gracias a la
comercialización del dispositivo Amazon Echo (Ecko, 2015).
En 2014, la compañía Thalmic Labs lanzó al mercado el dispositivo MYO, un brazalete de
sensores que capturan la actividad eléctrica de los músculos del brazo que permite controlar de
manera inalámbrica distintos dispositivos y aplicaciones de computadora o celular
(Attenberger, 2014).
1.1 MOTIVACIÓN
Según la Organización Mundial de la Salud (OMS) un 15% de la población mundial, padece
alguna forma de discapacidad (OMS, 2011). Las discapacidades pueden traer múltiples
limitaciones y restricciones en la participación en la sociedad para quienes las padecen. Por
ejemplo, los niños con discapacidad tienen menos probabilidades de ingresar en la escuela,
permanecer en ella y superar los cursos sucesivos. El fracaso escolar se observa en todos los
grupos de edad y tanto en los países de ingresos altos como bajos, pero con más frecuencia en
los países más pobres. Actualmente, el área de software aplicado para reducir la influencia de
las barreras para la participación de las personas con algún tipo de discapacidad, está en
crecimiento. Existen aplicaciones desarrolladas con fines pedagógicos y terapéuticos para niños
y adultos. Por estas razones, se propone extender las capacidades del Intellihome, integrando
nuevos dispositivos comerciales para mejorar la captura de datos de los usuarios, con el
objetivo de ampliar el alcance del sistema, permitiendo incorporar nuevos gestos para controlar
dispositivos y mejorar el reconocimiento de comandos de voz utilizando una tecnología más
precisa.
El sistema a extender esta basado en los principios de la tecnología asistiva, centrado en la
persona y no centrado en la tecnología. (Cook, 2015) Esto quiere decir que no hay una única
solución posible para asistir a una persona con discapacidad, sino que hay una solución para
cada individuo, según sus habilidades, necesidades y contexto (Cook, 2011). El mismo provee
reconocimiento de voz basado en palabras clave, aunque, este procesamiento ha evolucionado
en sistemas que tienen mejor precisión e interpretan lenguaje natural. Las nuevas tecnologías
como las mencionadas en la introducción, permiten desarrollar y experimentar con nuevos
métodos de interacción para proporcionar una comunicación humano-computadora intuitiva.
La motivación de este trabajo radica en aplicar conocimientos de ingeniería de software para
extender una plataforma de vida cotidiana asistida por computadora que pueda ayudar a más
personas con discapacidad, brindándoles mayor libertad dentro de sus viviendas y mejorando
su calidad de vida.
1.2. Objetivo
La meta de este trabajo es mejorar una plataforma de AAL para brindar una mejor experiencia
de usuario, y aumentar la precisión de la detección de comandos de voz y de gestos, evitando
la ejecución de acciones no deseadas en la vivienda provocada por falsos positivos. El sistema
permitirá reconocer distintos movimientos de manos a través del dispositivo MYO y comandos
de voz que serán procesados utilizando el servicio Amazon Alexa con el objetivo de ejecutar
acciones en los distintos dispositivos a controlar.
En particular interesa mejorar una plataforma que permite a desarrolladores y programadores
crear fácilmente aplicaciones de AAL, particularmente aquellas que operen a través de gestos y
sonidos, aparatos electrónicos. Para ello, las extensiones realizadas permiten a través de un
conjunto de módulos, recibir peticiones externas invocando a servicios web, reconocer los
impulsos mioeléctricos producidos por distintos movimientos del brazo, comandos de voz, que
son procesados por el servicio Amazon Alexa y recibidos por Intellihome quien utiliza
dispositivos actuadores para comunicarse por cableado o señales infrarrojas con los dispositivos
de la sala.
La comunicación se realiza mediante un formato de mensajes estándar y toda la plataforma se
encuentra bajo un diseño extensible, permitiendo en el futuro, utilizar otros dispositivos para
reconocer gestos y controlar dispositivos, e incluir nuevas plataformas que invoquen los
servicios web provistos por Intellihome. Más allá de brindar independencia y confort a los
usuarios del sistema en sus residencias, se busca promover el alcance masivo y la inclusión
social; a través de un software que propicia la creación fácil de aplicaciones y un primer
acercamiento a la domótica y la automatización de aparatos electrónicos, principalmente
concentrándose en los gestos, la voz y otros métodos de entrada no estándares.
1.3 Organización del documento
El capítulo 2 de este trabajo introduce todos los conceptos teóricos aplicados en el presente
trabajo, para ello se presentan las tecnologías utilizadas y los beneficios de los sistemas de
asistencia para personas con discapacidad.
En el capítulo 3, se detalla el diseño y la implementación de la plataforma junto con todas las
decisiones de diseño que se tomaron para su desarrollo.
En el capítulo 4, se presenta y detalla una guía para la implementación de aplicaciones utilizando
las características de la plataforma desarrollada.
En el capítulo 5 se encuentran las conclusiones y se mencionan los trabajos futuros que se
desprenden de este trabajo. También se incluye un Apéndice que contiene un estudio de
vulnerabilidades de la arquitectura de la plataforma implementada.
Por último, se listan las referencias bibliográficas consultadas durante la implementación del
presente trabajo.
CAPÍTULO 2: Marco Teórico
2.1 Introducción
El presente capítulo presenta los conceptos de discapacidad y de Ambient Intelligence (AmI) y
Ambient Assisted Living (AAL) relacionados a la plataforma extendida como trabajo final de
tesis. Adicionalmente, se describen los sensores incluidos junto con una breve descripción de
su funcionamiento y capacidades de reconocimiento de gestos y voz.
2.2 Discapacidad y Tecnología
"Discapacidad" es un término genérico que abarca disparidades, limitaciones de actividad y
restricción en la participación. La discapacidad no es sólo un problema de salud, es un fenómeno
complejo que refleja la interacción entre las características del cuerpo de una persona y las de
la sociedad en la que se desempeña (WHO, 2011). La superación de las dificultades a las que se
enfrentan las personas con discapacidad requiere de intervención para remover las barreras
ambientales y sociales. Una de las formas de reducir la influencia de estas barreras es el uso de
tecnologías asistivas. Estas abarcan productos y equipamientos personalizados para que las
personas con discapacidad puedan realizar tareas de manera fácil y segura. Las tecnologías de
información y comunicación incluyendo computadoras, celulares estándar o Smartphone y
tablets, son herramientas que afectan la manera en la que las personas aprenden, trabajan y
juegan (Wright, 2004). Su rápido desarrollo y aplicación en varias áreas muestra su potencial
para mejorar el acceso a la información, el conocimiento y las nuevas oportunidades de
aprendizaje, facilitando la obtención de empleo y la independencia (UNESCO, 2009). Por esta
razón, estas tecnologías son adaptadas para satisfacer las necesidades de personas con
discapacidad y utilizadas como tecnologías asistivas (Cook et al., 2015) en ámbitos cotidianos,
terapéuticos y educacionales.
2.3 Inteligencia Ambiental (AmI)
La inteligencia ambiental, o Ambient Intelligence (AmI) es una disciplina en pleno crecimiento
desarrollada a fines de los años 90. AmI describe un entorno en el que las personas están
rodeadas y asistidas por interfaces inteligentes e intuitivas, embebidas en objetos cotidianos
que se comunican entre sí. Estos conforman un medioambiente electrónico que reconoce y
responde a la presencia de los individuos inmersos en él. Los avances tecnológicos, como el
desarrollo de sensores, redes de sensores, inteligencia artificial y computación ubicua (Kidd et
al., 1999) fortalecen la investigación en esta disciplina. Estas tecnologías prometen revolucionar
la vida cotidiana creando entornos flexibles y adaptables para las personas (Cook et al., 2009).
Una de las áreas de aplicación más relevantes es colaborar con la vida independiente de las
personas ancianas o discapacitadas (Fariba, 2011) principalmente, con aquellas que padecen
impedimentos físicos o cognitivos que vivan en sus casas, aunque, deban ser monitoreadas por
el bien de su seguridad y bienestar. Vida cotidiana asistida por computadora o, en inglés
Ambient Assisted Living (AAL) es un concepto derivado de AmI que no trata de automatizar
tareas, sino que busca asistir a los usuarios en tiempo real dentro de sus viviendas. Este
concepto se describe a continuación y es un nuevo campo de investigación de gran interés a
nivel mundial.
2.4 Ambient Assisted Living (AAL)
Ambient Assisted Living (AAL) es un área de investigación y desarrollo en la cual la accesibilidad,
usabilidad y el aprendizaje juegan un papel de gran relevancia. El objetivo principal de AAL es
aplicar tecnología de inteligencia ambiental para permitir a las personas con discapacidad o
ancianas vivir con una mayor independencia y confort en sus hogares. (Kleinberger et al., 2007).
Algunas de las características más importantes de un sistema de AAL son:
● Ahorro de energía
● Comunicación inalámbrica para evitar cableados adicionales en las viviendas ya
construidas.
● Capacidad para percibir la información del ambiente
● Adaptabilidad en el contexto.
● Proveer interfaces fáciles de utilizar por personas ancianas o discapacitadas.
● Interfaces de interacción con el sistema no tradicionales.
Los sistemas de AAL permiten a los usuarios interactuar con dispositivos electrónicos, tales
como electrodomésticos y equipos de entretenimiento, luces y sistemas de alarmas, entre
otros. Algunos sistemas brindan asistencia en salud y otros son capaces de adelantarse a
siniestros al encontrar patrones en la conducta y movimientos del usuario que indiquen riesgo
para su vida. Como se muestra en la siguiente figura, las aplicaciones de los sistemas de AAL
pueden estar dirigidas a la asistencia a usuarios ante casos de emergencia, vida diaria o confort
y combinaciones de las mismas:
Figura 2.1 - Dominio de un sistema de AAL. (Kleinberger et. al, 2007).
Una de las formas más importantes de interacción en ambientes asistidos se realiza a través de
comandos de voz. Tal y como ocurre en la comunicación verbal, las personas tienden a realizar
gestos al reproducir unidades lingüísticas que contienen información espacial y, generalmente,
tienden a intercambiar palabras por gestos. Esto se ha considerado un factor fundamental para
interpretar los requerimientos de los usuarios ya que, de esta forma, pueden comunicarse con
el sistema de forma más natural.
Uno de los desarrollos más importantes en AAL se encuentra en Bremen, Alemania. El
laboratorio de vida cotidiana asistida por computadora cuenta con un departamento de
pruebas, que recrea una casa habitable con capacidad para dos personas. El lugar posee
electrodomésticos inteligentes adaptables y muebles para compensar las limitaciones
especiales que se acercan al usuario cuando este los necesita a su alcance. Adicionalmente, el
laboratorio cuenta con una silla de ruedas inteligente que es capaz de transportar a los usuarios
desde un ambiente a otro de forma autónoma. (Anastasiou D. et al., 2012). Esta réplica de una
casa a escala real, indica el compromiso con la usabilidad y accesibilidad de este tipo de
estudios. En los sistemas de AAL, los usuarios son observados por medio de cámaras o sensores.
Cada luz, alarma o electrodoméstico es controlado por medio de dispositivos actuadores que,
generalmente, implican el uso de un circuito electrónico. Para ello, primeramente, se procesa
en tiempo real la interacción entre el usuario y los dispositivos a través de gestos y comandos
de voz, permitiendo al usuario ser su propio control remoto. Este conjunto de componentes se
describe brevemente a continuación.
2.5 Reconocimiento de gestos
En los últimos años han surgido diferentes enfoques que utilizan sensores y dispositivos para
capturar los movimientos de los usuarios. Los dispositivos portátiles de mano, como guantes
sensores (Weissman et al., 1999) han sido utilizados, aunque suelen ser caros e intrusivos para
los usuarios. Otros dispositivos inalámbricos no intrusivos, como el controlador de la consola
Nintendo Wii (Schömer et al., 2008) han aparecido para superar estos inconvenientes.
Adicionalmente, otros sensores libres de contacto (es decir que no es necesario que el usuario
los toque o los tenga en su mano) han aparecido para detectar movimientos, como el sensor
Leap Motion, mostrado en la figura X.X que detecta movimientos de dedos (Weichert et al.,
2013) o sensores para detectar gestos como el sensor Kinect. En la actualidad los gestos son
utilizados en diversas aplicaciones tales como control y navegación en CAVEs (Cave Automatic
Figura 2.2 - Detección de Gestos con Leap Motion
Virtual Environments) (Cruz-Neira, 1993) y otros ambientes virtuales como habitaciones
inteligentes, ambientes virtuales de trabajo y espacios de interpretación y actuación utilizados
para efectos especiales en cine o brindar más realidad a los personajes de videojuegos.
2.6. Reconocimiento de comandos de voz
El reconocimiento de comandos de voz comenzó a finales de los años 70 con el proyecto "put
that there" (Bolt, 1980). En este proyecto los comandos se utilizan para interactuar con una
computadora. El sistema permitía pintar figuras en una interfaz gráfica utilizando frases de
lenguaje natural. Este proyecto revolucionó la manera en la que las personas interactúan con
las computadoras y, desde entonces, han surgido diversos proyectos que han ganado
importancia en el área de HCI.
Un sistema de reconocimiento de voz es una herramienta computacional capaz de procesar la
señal de voz emitida por el usuario y reconocer la información contenida en ella, traduciéndose
luego a texto o comandos que ejecuten una acción sobre un proceso. En su desarrollo
intervienen diversas disciplinas, tales como: la fisiología, la acústica, el procesamiento de
señales, la inteligencia artificial y la ciencia de la computación. En la actualidad, los sistemas
operativos Windows, desde su versión XP, y MAC OS X Lion permite a los usuarios reconocer
comandos de voz y dictar texto a una aplicación (Sharma et al. 2012). Sin embargo, pocas
personas utilizan estas funciones en su computadora. No ocurre lo mismo en los celulares, en
los cuales, la interacción a través de comandos de voz se ha implementado previo a los celulares
inteligentes. Estos últimos incluso le permiten al usuario mantener una conversación, solicitar
información y ejecutar comandos a través de lenguaje natural. Un ejemplo de estos sistemas es
Siri, el asistente personal de iPhone. (Geller, 2012). Los celulares Android también poseen
reconocimiento de dictado y de asistencia en búsquedas en Google; aunque no puede
interactuar de forma natural y esperar una respuesta tal y como lo hace Siri. Hoy en día, con la
popularidad de estos dispositivos, la tecnología de reconocimiento de voz se ha establecido y
es de uso habitual. Incluso la consola de videojuegos Xbox 360 de Microsoft permite a los
jugadores mantener conversaciones entre ellos, encender, apagar e interactuar con la consola
a través del reconocimiento de comandos de voz del sensor Kinect.
El reconocimiento de gestos y de comandos de voz son elementos fundamentales en los
ambientes asistidos por computadora. En la actualidad, existen muchos dispositivos de bajo
costo que pueden utilizarse para brindar esta funcionalidad en un ambiente.
Dos sensores que han ganado mucha popularidad en los últimos años son el ya mencionado
sensor Myo de Thalmic Labs y el dispositivo Amazon Echo, de la empresa que lleva su mismo
nombre. A continuación, se presenta cada uno de ellos junto con una breve descripción de sus
reconocedores.
2.7 Sensor Myo
El sensor Myo, desarrollado por Thalmic Labs en 2014, fue el primer sensor de impulsos
mioeléctricos en salir al mercado. Este brazalete mide aproximadamente entre 19 y 30 cm y su
diseño se muestra en la siguiente figura:
Si bien existen muchos dispositivos de interacción natural actualmente, los más populares son
los controlados mediante la voz, con los cuales se torna incómodo interactuar en lugares
públicos, solo para activar un comando, y el reconocimiento de gestos basado en cámaras, el
cual funciona bien, pero condicionando a tener que estar en el lugar donde las cámaras están
Figura 2.3 - Sensor Myo exteriormente
dispuestas. Myo surgió como una forma de proveer al usuario un dispositivo de detección de
gestos, que le permita seguir realizando las actividades cotidianas, y a la vez interactuar con la
tecnología. El sensor tiene ocho electrodos bipolares secos numerados secuencialmente, con
una frecuencia de muestreo de 200 Hz cada uno. (Montoya V., 2015)
Thalmic Labs se enfocó principalmente en la interacción Humano - computadora, por esto Myo
permite la detección de 5 poses por defecto, que se pueden observar en la figura siguiente, y
también permite la obtención de la información obtenida por el EMG provisto en el dispositivo,
junto con el acelerómetro, el giroscopio y la orientación.
Figura 2.4- Poses detectadas por Myo.
2.8 Amazon Echo
Amazon Echo es un dispositivo de reconocimiento de voz de Amazon.com, que se caracteriza
por responder preguntas, reproducir música, y controlar dispositivos inteligentes. El mismo,
incluye un parlante cilíndrico largo de 23 cm, con un micrófono de 7 piezas. Echo responde al
nombre “Alexa”, aunque la palabra de activación puede ser modificada por el usuario.
Amazon estuvo desarrollando Echo en sus oficinas de Silicon Valley y de Cambridge por al
menos 4 años.
Amazon Echo esta prendido todo el tiempo y escuchando, al reconocer la palabra de activación,
comienza a operar, el dispositivo es capaz de reconocer comandos a la distancia.
Figura 2.5- Amazon Echo
2.9 Intellihome
Como se mencionó en el capítulo I, IntelliHome se basa en los principios de la tecnología asistiva,
por esta razón, permite combinar diferentes sensores para interactuar con los usuarios. La
solución general utiliza una combinación de Kinect, Leap Motion, y una aplicación para
dispositivos Windows 8 para ejecutar diferentes tareas en distintos dispositivos y luces. Esta
variedad de sensores ofrece a los usuarios distintas formas de interacción, debido a que su uso
puede ser muy simple para algunos usuarios o representar un desafío para otros.
Adicionalmente, nos permite centralizar sus estándares de comunicación para combinar
sensores de distintas marcas. Durante la ejecución, los sensores capturan los datos del
ambiente y generan mensajes que luego son enviados a una capa de abstracción del sistema,
donde son estandarizados utilizando el formato establecido por el Protocolo OSC (Wright,
2006), un estándar utilizado para transmitir datos MIDI en una red. Este protocolo ha sido
elegido durante nuestro trabajo en el reconocimiento de voz por su sencillez y claridad en la
definición de la información. Cada mensaje comienza con un caracter '/' y contiene la siguiente
información: ID único de la tarea a ejecutar en el ambiente, Tipo de interacción utilizado para
ejecutarla (gesto, voz, tablet) Acierto (utilizado únicamente en los comandos de voz) Nombre
de la tarea a ejecutar en el ambiente. Como se muestra en la Figura X, el sistema es una red de
sensores y actuadores bajo una arquitectura cliente - servidor que permite capturar y ejecutar
las acciones solicitadas por el usuario en un cierto dispositivo.
Figura 2.6 - Vista de la arquitectura de IntelliHome
Como se ve en la Figura 2.6, el sistema se divide en dos grandes componentes: Administración
de datos y sensores y Administración de actuadores. La especificación de los mismos se
presenta en las siguientes subsecciones.
2.9.1 Administración de datos y sensores: capa de abstracción y extensión para
nuevos sensores
IntelliHome encapsula el comportamiento de los sensores a través de una capa de abstracción
que le permite a los programadores utilizar los datos que estos obtienen sin necesidad de tener
conocimientos técnicos en ellos. Como se muestra en la Figura 2.7, cada sensor conectado al
servidor de IntelliHome pertenece a una jerarquía de clases de sensores. Cada una de estas
clases se encarga de establecer la conexión con los dispositivos para obtener los datos del
ambiente. Esto se logra por medio de los SDK o bibliotecas desarrolladas para lenguaje C#
pertenecientes a cada sensor.
Figura 2.7 - Diagrama de clases de la jerarquía de sensores.
Adicionalmente, cada sensor tiene uno o más reconocedores asociados, por ejemplo, el sensor
Kinect reconoce gestos, así como también comandos de voz. Estos reconocedores interpretan
el habla y los movimientos de los usuarios y evalúan si estos son frases o gestos válidos en el
sistema. Cuando se detecta una coincidencia entre el movimiento o frase emitida por el usuario
y un gesto predefinido en la plataforma o una frase definida en el diccionario de palabras
esperadas, cada reconocedor crea el mensaje OSC mencionado previamente y lo envía al
componente "Administrador de actuadores". Este comportamiento
permite la generación de la jerarquía de clases de la Figura 2.8, la cual se encarga de comenzar
y detener la captura de datos del ambiente y de enviar a los actuadores las acciones a ejecutar
en él.
Este diseño permite agregar y remover sensores y reconocedores fácilmente. Para integrar un
nuevo sensor en el sistema, se debe crear su clase en la jerarquía de sensores y definir sus
métodos para establecer la conexión con el hardware. Luego, se debe implementar en la
jerarquía de reconocedores una clase por cada reconocedor del nuevo sensor. Esta clase debe
contener las estructuras de datos para almacenar la información proveniente de los sensores y
tres métodos heredados para iniciar y detener la captura y generar los mensajes OSC al
reconocer un comando de voz o gesto y enviar los datos al componente Cliente del
sistema. Estos métodos se llaman StartReconocimiento, StopReconocimiento y EnviarMsgOSC.
Para comenzar la ejecución del sistema, es necesario definir una colección de sensores y otra
de reconocedores. De esta manera, al recorrer ambas colecciones se inicializa el hardware y las
capturas de datos del ambiente. En las siguientes secciones se brindan los detalles de
implementación de los reconocedores de gestos y de voz, utilizando los distintos sensores y se
detalla cómo se realiza la comunicación con los actuadores. (V. Gándara, 2014)
Figura 2.8 - Diagrama de clases de la jerarquía de reconocedores.
CAPÍTULO 3: Diseño e implementación
3.1 Introducción
En este capítulo se presenta la implementación de las nuevas extensiones de IntelliHome
incluyendo las modificaciones realizadas al servidor y la implementación de una capa de
servicios web. Además, se detallan las decisiones de diseño que llevaron a las mismas.
En la sección 3.2 se detallan las modificaciones realizadas en la plataforma para adaptarla y dar
soporte a los servicios web, y los cambios de infraestructura necesarios para la integración con
Amazon Alexa Service.
Por otro lado, en la sección 3.3 de este capítulo, se describe cómo se adaptó el dispositivo de
reconocimiento MYO, detallando los elementos y atributos que los conforman.
3.2 Integración del dispositivo Amazon Echo
Alexa, es el servicio de voz que maneja el Amazon Echo, provee skills que permiten que el
usuario interactúe con dispositivos de una manera más intuitiva utilizando la voz. Las
habilidades incluidas oficialmente son la reproducción de música, respuesta de preguntas
generales, seteado de alarmas y temporizadores entre otros.
Alexa Skills Kit es una colección de APIs (Interfaces de programación de aplicaciones),
herramientas, documentación, y ejemplos, que facilitan la creación de nuevas habilidades a
Alexa. Todas las habilidades de Alexa, corren en la nube. Esto permite que cualquier usuario
tenga acceso a estas nuevas capacidades, solo interactuando con Alexa, haciéndole preguntas,
o realizando pedidos.
Cuando un usuario le realiza una pregunta, o le indica a Alexa que haga algo, ese pedido es
enviado a un servicio en la nube. Este determina que está queriendo hacer el usuario, y vincula
el pedido con el servicio correspondiente que provee la lógica, y espera la respuesta.
Al diseñar una nueva habilidad, como lo es el reconocimiento para Intellihome, se deben definir
intents, que el usuario va a invocar con su voz, y crear un servicio basado en la nube que acepte
esas interacciones del usuario que serán de una forma estructurada y pre-establecida, que
permita actuar en base a ellas. No se requiere realizar análisis sintáctico ni manejo del lenguaje
natural, ya que el servicio Alexa se encarga de esto. Para que Alexa pueda interactuar con las
habilidades creadas, las mismas deben estar desplegadas como un servicio web.
3.2.1 Cómo interactúan los usuarios con Alexa.
Dado que actualmente el servicio provisto por Alexa soporta solo el lenguaje inglés, se
introducirán los ejemplos de una manera simple en este idioma.
Los usuarios interactúan con las habilidades desarrolladas para comunicar Alexa con
Intellihome realizando una pregunta o indicando un comando en lenguaje natural. El usuario
indica la frase soportada por ejemplo “Ask”, el nombre de invocación definido para nuestra
habilidad, y el pedido o pregunta a realizar.
Usuario: “Alexa, ask Intellihome to turn on the kitchen light.”
El ejemplo que refleja lo desarrollado, se descompone de la siguiente forma
● “Alexa” es la palabra que inicia el reconocimiento en el dispositivo Amazon Echo, la cual
permite iniciar una conversación con el servicio.
● “Ask…to” es una de las frases aceptadas para solicitar la realización de una habilidad en
particular.
● “Intellihome” es el nombre que identifica la habilidad que el usuario quiere invocar. El
nombre es utilizado por Alexa para definir a qué servicio se debe derivar la petición
realizada por el usuario
● “turn on the kitchen light” es el pedido específico, la pregunta o el comando que se
asocia a un intent particular para este servicio
● En este contexto un intent representan una acción de alto nivel que cumple con el
pedido del usuario, Estos pueden tener argumentos como en este caso lo son “Kitchen
y “Light”
● Definir las frases que el usuario utilizara para interactuar y asociarlos a los intent es
parte de la interfaz de voz de una habilidad de Alexa.
El diagrama 3.1 demuestra a grandes rasgos cómo es la interacción con el servicio Alexa.
Este modelo de conversación se repite hasta que el usuario obtiene lo que desea,
independientemente de cómo se comienza la interacción con el servicio, la conversación
continúa hasta concretar un objetivo. Cada vez que se envía una respuesta, se puede incluir
FIGURA 3.1 - Interacción de Amazon Echo con el servicio Alexa.
el estado de la conversación, o si debe terminar o no la misma. Si el servicio de Intellihome
necesita más información del usuario para ejecutar una acción, establece que debe continuar.
Si el usuario no responde, o responde con una sentencia que no está asociada a un intent
definido en la interfaz de voz, Alexa pide nuevamente el comando.
Para que Alexa pueda proveer todas las interacciones mencionadas, las mismas fueron
definidas en el servicio desarrollado.
Siguiendo con el ejemplo inicial, una conversación corta seria:
Usuario: “Alexa, ask Intellihome to turn on the kitchen light.”
Alexa: “The kitchen light has been turned on.”
<fin>
Una conversación más larga sería:
Usuario: “Alexa, ask Intellihome”
Alexa: “Which rooms do you want me to help you with?”
Usuario: “kitchen”
Alexa: “What do you want to do in the kitchen”
Usuario: “turn the lights on”
Alexa: “The kitchen light has been turned on.”
<fin>
Como se puede observar al diseñar la interacción con el usuario, se pueden establecer
diferentes conversaciones que lleven a un mismo resultado, y así poder detectar mayor
cantidad de expresiones del mismo.
3.2.2 Diseño de la interfaz de voz.
Para definir una interfaz de voz, se debe especificar una asociación entre los comandos del
usuario y los intents que el servicio va a manejar. Para definir esa asociación, se deben incluir
dos recursos principales:
1. Un esquema de Intents: Es una estructura JSON que declara el set de intents que el
servicio va a aceptar y procesar.
2. Las frases de entrada:
○ Enunciados: Un archivo de texto estructurado que conecta los intents con las
frases que utilizara el usuario, conteniendo la mayor cantidad de frases
representativas posibles.
○ Valores personalizados: Una lista representativa de valores para ítems
específicos usados por la habilidad, y referenciados por los intents.
A continuación se explica cómo se utilizan estos recursos.
El esquema de Intents
En el contexto de Alexa, un intent representa una acción que es realizada ante un pedido del
usuario, los intents pueden tener opcionalmente argumentos, en el caso de Intellihome, se
definieron 3 tipos de argumentos que permiten determinar que va a realizar el servicio;
Ambiente, Ítem, y Acción. Para el ejemplo mencionado anteriormente cuando el usuario indica
“Alexa, ask Intellihome to turn on the kitchen light”, on ira en la variable de Acción, kitchen en
Ambiente, y light en Item.
Se debe definir un conjunto de intents válidos en JSON, como lo demuestra la figura 3.2
Figura 3.2 - Esquema de intents.
Cada intent tiene dos propiedades:
● El intent por sí mismo, que define el nombre.
● Las variables asociadas al intent, las cuales hacen referencia a listas ya definidas de
ítems.
En el ejemplo de la figura 3.2 OneShotIntellihomeIntent define 3 variables, Room, Item y Action.
Cada variable es definida con un tipo diferente. por ejemplo, Room es de tipo LIST_OF_ROOMS,
la cual se popula en un archivo separado, con los posibles valores que puede tomar esa variable
Cada una de las variables puede tomar un tipo predefinido de Amazon, o tener su tipo definido,
como en este caso.
Figura 3.3 - Definición de recursos.
La lista de posibles valores puede contener cualquier valor soportado por la aplicación, siempre
que pueda ser hablado por el usuario, aunque actualmente el soporte de Alexa se limita al
inglés, por lo que palabras en otro idioma pueden no ser reconocidas. Alexa devuelve al servicio,
las palabras dichas por el usuario de forma textual para poder ser procesadas.
Frases de entrada
Cada frase de entrada posible es asignada a un intent definido, por ejemplo, en la figura 3.4, se
muestran 2 frases de entrada que se asocian a OneShotIntellihomeIntent, cada línea del archivo
de frases de entrada consiste en 2 campos separados por tabulado o espacio:
● El nombre del intent a la izquierda.
● La frase que el usuario puede decir para activar el intent a la derecha.
Como se observa, al tener variables en un intent, se puede definir el lugar en el cual el usuario
las nombrara.
Figura 3.4 - Frases de entrada OneShotIntellihomeIntent
Cada frase de entrada no tiene la necesidad de tener alguna variable. El esquema permite dar
la flexibilidad, para adaptarse al lenguaje del usuario, y así proveer la mayor cantidad de frases
posibles, para disminuir el trabajo del usuario.
La usabilidad del servicio depende directamente en la customización de las variables y en las
frases de entrada, y cuán bien representan al lenguaje utilizado por el usuario. Crear un
conjunto representativo de variables y frases es un proceso importante, que requiere pruebas
con los posibles usuarios, y mejoras en base a su uso.
Variables predefinidas
Al usar variables predefinidas, se debe tener en cuenta que con las mismas se intenta cubrir la
mayor cantidad de posibilidades esperadas como entrada del usuario. Aunque en algunos casos
esto puede deducirse directamente. En servicios como el de Intellihome, esto es variable, y
depende de la ubicación donde vaya a estar instalado posteriormente el sistema, y los
dispositivos que vaya a controlar.
Con el fin de la realización de pruebas, como se observa en la figura 3.5 se han definido para
IntelliHome 4 posibles ambientes. De esta misma forma se han definido tanto los ítems como
las acciones a realizar, las cuales al momento incluyen solo encendido y apagado de artefactos.
Figura 3.5 - Lista de posibles cuartos.
Peticiones enviadas por Alexa
El servicio puede estar implementado en cualquier lenguaje, en este caso se eligió Java, dado
que Alexa Skills Kit incluye opcionalmente una librería para este lenguaje, que provee clases y
métodos de soporte que se pueden utilizar para crearlo.
El servicio implementado debe aceptar y responder a tres diferentes tipos de peticiones:
● LaunchRequest, es la petición que da inicio a la comunicación.
● IntentRequest, genera el diálogo entre el usuario y el servicio.
● SessionEndedRequest, termina la comunicación.
Al usar la librería Java, las clases SpeechServlet o SpeechletRequestStreamHandler determinan
el tipo de petición enviada por Alexa, e invocan al método correspondiente en el SpeechServlet:
● onLaunch()
● onIntent()
● onSessionEnded()
La llamada al método correspondiente incluye como argumento un objeto representativo del
tipo de petición, y un objeto que representa a la sesión que está manejando el dispositivo.
LaunchRequest
El servicio implementado para Intellihome recibe una petición de inicio LaunchRequest cuando
el usuario invoca la habilidad por su nombre, pero no provee ningún comando que pueda ser
asociado a un intent. Por ejemplo:
Usuario: “Alexa, talk to Intellihome”.
Hay ciertas habilidades que solo realizan una tarea, y no necesitan más información, pero este
no es el caso de IntelliHome, ya que, para poder ejecutar alguna acción, el usuario debe dar más
precisión de lo que necesita. Es por esto, que el servicio responde al usuario para comenzar con
la conversación.
Figura 3.6 - Petición onLaunch.
IntentRequest
El servicio recibe un IntentRequest cuando el usuario indica un comando asociado con n intent,
el objeto de la petición enviado al servicio de Intellihome contiene el intent con el cual fue
asociado, y las variables que contenga el mismo.
En este punto un IntentRequest puede tanto comenzar una nueva sesión, como continuar una
ya activa, dependiendo de cómo el usuario comience su interacción con Intellihome.
A continuación, se pueden observar las distintas interacciones posibles con Intellihome.
1. El usuario realiza una pregunta a Alexa o indica un comando en una sola frase, provoca
el envío de un intentRequest, y el comienzo de una nueva sesión.
Usuario: “Alexa, Ask Intellihome to turn the kitchen light on.”
En este caso, no se envía una petición de inicio, sino que directamente se empieza una
sesión.
2. Una vez que una sesión ya está iniciada, el usuario indica un comando que está asociado
con alguno de los intents definidos en la interfaz de voz. Esto envía un intentRequest
dentro de la sesión existente.
Usuario: “Alexa, talk to Intellihome”. (LaunchRequest, inicia la sesión)
Alexa: “Which appliance would you want me to activate for you?” (respuesta emitida
en el LaunchRequest).
Usuario: “turn the kitchen light on.” (Este comando envía al servicio un IntentRequest
en la sesión actual).
Para realizar el manejo de esto, como se observa en la figura 3.7, Intellihome obtiene el nombre
del intent y selecciona cómo actuar en base al mismo.
Figura 3.7 - Petición onIntent.
Como se puede observar, Alexa Skills Kit provee una colección de intents incluidos, asociados a
acciones comunes, como lo son detener, cancelar o solicitar ayuda.
Se pueden definir tantos intents diferentes como sean necesarios, en este caso, para
Intellihome, se definieron 3 diferentes tipos de intents:
● OneShotIntellihomeIntent, el cual hace referencia a la petición del usuario de realizar
una acción, proveyendo todos los datos necesarios para la ejecución de la misma, siendo
estos, la acción a realizar, y el ítem y habitación correspondientes.
Figura 3.8 - OneShotIntellihomeIntent
● DialogRoomIntent, esta petición está asociada a un pedido incompleto, siempre que se
deba pedir más información al usuario, será la opción elegida.
Figura 3.9 - DialogRoomIntent
● SupportedRoomsIntent, permite consultar los cuartos con los cuales puede interactuar.
Se diseñó esta petición para facilitar un modo de interacción con el sistema, y obtener
las variables soportadas por el mismo.
Figura 3.10 - SupportedRoomsIntent
SessionEndedRequest
El servicio recibe una petición SessionEndedRequest cuando una sesión es cerrada por alguna
de las siguientes razones:
1. El usuario dice “exit”.
2. El usuario no responde o indica algún comando no soportado por el servicio, o no
definido por la interfaz de voz
3. Ocurre un error
Además, se puede setear la variable shouldEndSession en verdadero en la respuesta del servicio,
para terminar la sesión.
Devolución de una respuesta
El servicio debe emitir una respuesta para las peticiones LaunchRequest y IntentRequest. Cada
respuesta debe respetar el formato predefinido por la interfaz de Alexa Skills Kit.
Al usar la librería Java en Intellihome, la misma provee una clase que representa una respuesta
válida, SpeechletResponse.
La respuesta puede incluir:
● Texto que será convertido en diálogo que Alexa dirá al usuario. El texto puede ser plano,
o marcado con SSML, Speech Synthesis Markup Language.
● Una tarjeta que será visualizada en la aplicación Amazon Alexa, la cual puede incluir un
título, texto descriptivo, y opcionalmente una imagen
● Texto que será convertido en diálogo si es que una repetición es necesaria. Esta es
necesaria solo si el servicio mantiene la sesión luego de la respuesta.
● Una variable que indica cómo se mencionó anteriormente, si la sesión debe cerrarse.
Adicionalmente, una respuesta puede incluir atributos que se deseen guardar en la sesión.
La librería java como se mencionó provee una interfaz denominada Speechlet con métodos a
implementar para cada tipo de petición que el servicio reciba. La clase que maneja la aceptación
de peticiones provenientes de Alexa y las redirecciona al Speechlet implementado, depende de
cómo se hostee el servicio en la nube.
Figura 3.11 - Diagrama de secuencia Usuario -Alexa.
Para deployar el servicio de Alexa asociado a Intellihome, se decidió la utilización de funciones
Lambda, provistas por Amazon, para esto, se configura la función que maneja las peticiones, en
este caso como se observa en la Figura 3.11 IntelliHomeSpeechletRequestStreamHandler es
quien define qué hacer con cada una de las peticiones.
Proceso de pruebas
Durante el proceso de desarrollo, se realizaron múltiples pruebas con el fin de validar la nueva
habilidad. Como se observa en la figura 3.12 Alexa provee un simulador de servicios, que
permite probar cada uno de los diferentes intents definidos, para poder mejorarlos en base a la
experiencia.
Figura 3.12 - Simulador del servicio
Utilizando este simulador, se perfeccionó el flujo del diálogo que el usuario tendrá con el
servicio de Intellihome, mejorando así la usabilidad del sistema.
3.2.3 Capa intermedia de servicios web.
Al decidir la integración del dispositivo Amazon Echo como sensor de captura de datos para
Intellihome, se presentó la necesidad de comunicar el sistema con servicios que se encuentran
en la nube.
Al tener que proveer funcionalidad a través de servicios, surgió la necesidad de separar la misma
en una capa de servicios. Dentro de esta, se definió e implementó una interfaz que permita a
agentes externos interactuar con Intellihome.
Hay varios factores que se tuvieron que considerar al diseñar esta capa. Muchos de estos tienen
que ver con la arquitectura que tomó Intellihome, al incluir servicios se tomaron en cuenta los
factores relacionados con la interacción basada en mensajes, que comúnmente se realiza sobre
una red, que puede ralentizar la interacción con el sistema. Además, la comunicación entre el
usuario y el sistema es asincrónica, y puede sufrir pérdidas de información en el camino, lo cual
genera una necesidad de manejar este comportamiento para evitar posibles errores.
Para el diseño de la capa de servicios se tomaron en cuenta los siguientes puntos:
● Diseño de los servicios basados en la funcionalidad de la aplicación: Las operaciones
accedidas mediante un servicio deben ser las funcionalidades básicas de la aplicación,
sin ser demasiado específicas, para asegurar un funcionamiento performante, y
posibilidades de escalar los mismos.
● Diseño de los servicios pensando en la escalabilidad de los mismos,
independientemente del usuario. Se propuso la generalización de los servicios,
intentando independizar los mismos de los datos del usuario particular.
Para la implementación de esta capa intermedia se decidió utilizar servicios REST,
Representational State Transfer, los mismos utilizan HTTP lo cual hace más sencilla su
utilización, y presentan la característica de proveer mayor escalabilidad y rendimiento, lo cual
es un atributo considerado importante para el futuro del sistema.
La capa de servicios interactúa directamente con IntelliHome, esta capa representa un set de
funcionalidades publicadas que ofrecen la posibilidad de ejecutar acciones sobre el sistema de
manera externa, abstrayéndose de Intellihome. Esta capa permite el diseño de múltiples
aplicaciones que interactúen con el usuario, tanto aplicaciones web, Mobile, como Alexa, sin
depender directamente de la implementación de Intellihome
Componente de interacción con Intellihome
La capa de servicios es la que provee el acceso externo, y establece una conexión TCP/IP
asincrónica utilizando sockets con Intellihome. Los servicios fueron implementados en Java, y
deployados en un servidor Tomcat en el mismo lugar donde funciona Intellihome, desde donde
los utiliza externamente el servicio Alexa.
Para esto se utilizó una clase TCPClient, que tiene la tarea de pasarle el mensaje a nuestro
sistema. Para poder realizar esto, nuestro cliente realiza los siguientes pasos
1. Crea un socket en el servidor especificado, actualmente seteado en el mismo ambiente
por lo que es localhost, a escuchar en un puerto determinado 1001 para Intellihome.
2. Obtiene un BufferedOutputStream, el cual permite a través de un OutputStreamWriter
escribir el mensaje que será enviado al servidor.
Figura 3.13 - Cliente TCP/IP
Estructura de datos de Intellihome
Para poder abstraerse del usuario para el cual el sistema está implementado, es necesario
distinguir inequívocamente cada uno de los artefactos a controlar. Para esto se decidió la
utilización de una base de datos, la cual asocia como se muestra en la figura 3.14 el usuario, el
cuarto, el ítem, y la acción a realizar.
Figura 3.14 - Esquema de la Base de Datos Intellihome
De esta forma al servicio web solo le llegará el id, sea de encendido o apagado del dispositivo,
y se abstrae totalmente de conocer la implementación del sistema en un lugar en particular.
Esta implementación facilitó la creación de los servicios web, ya que estos se limitan al
momento solo de comunicar el id de acción requerida a Intellihome.
Como se muestra en la figura anterior, para invocar al servicio de cambio de estado, solo se le
debe proveer el identificador anteriormente mencionado.
Figura 3.15 - Servicio de cambio de estado.
3.2.4 Extensión de Intellihome
El módulo de interacción usuario - sistema se encarga de capturar los gestos, comandos de voz
y conexiones remotas ejecutados por el usuario, procesarlos y coordinar la función a ejecutar
estableciendo la comunicación con el módulo Interacción sistema-dispositivos. En la figura 3.16
se detallan sus componentes y, a medida que se avance en este capítulo, se explicará la
interacción de los mismos.
Figura 3.16 - Vista de los componentes del módulo Interacción usuario - sistema
Cuando comienza la ejecución el componente Iniciar Sensores inicializa los sensores disponibles
en el sistema, entre los cuales se encuentra el Reconocedor de dispositivos Remoto. Luego, los
componentes Iniciar Reconocimiento de gestos e Iniciar Reconocimiento De Comandos de voz
envían mensajes al componente Cliente, Interacción sistema – dispositivos, cada vez que
reconocen un gesto o un comando de voz.
Esta comunicación la realiza el componente Controlador de dispositivos a través de protocolo
TCP/IP. La interacción entre los componentes mencionados se muestra en la siguiente figura:
Figura 3.17 - Diagrama de componentes y conectores del módulo Servidor, Interacción usuario
- dispositivos.
Para poder agregar el Reconocedor de Dispositivos remotos, se tuvo que realizar una extensión
de la clase abstracta Reconocedor, lo cual implica la implementación de los métodos
StartRecognition y Stop.
Componente Iniciar reconocimiento de dispositivos Remotos
Este componente evalúa la información capturada por los sensores. La figura 3.18 muestra el
diagrama de clases correspondiente a los reconocedores implementados. Cada sensor está
asociado a uno o más reconocedores, de acuerdo a sus prestaciones, y cada reconocedor está
asociado a sólo un sensor.
Figura 3.18 - Jerarquía de clases de reconocedores de los componentes Iniciar reconocimiento
de gestos e iniciar reconocimiento de voz.
Las clases hijas de esta jerarquía evalúan los datos obtenidos por los sensores. Cuando se
reconoce un gesto o comando de voz, envían la información al componente Controlador de
dispositivos. Este le envía al módulo Cliente la función a ejecutar. Adicionalmente, cada clase
puede comunicar a la vista de la aplicación los cambios a realizar en la interfaz, por ejemplo, un
plano de situación de la casa (ver figura 3.19).
Figura 3.19 - Plano de ejemplo de la Interfaz de usuario de la vivienda asistida por
computadora.
Iniciar reconocedor de dispositivos remotos
Los dispositivos remotos se conectan a Intellihome, como se dijo anteriormente mediante el
protocolo de TCP/IP, al iniciar el reconocimiento se establece una conexión TCP/IP asincrónica
utilizando sockets para poder obtener las peticiones para realizar las acciones correspondientes
asociadas a cada comando. Estas acciones son: mostrar en la interfaz de usuario los cambios
realizados en el ambiente y enviar un mensaje al cliente cada vez que un mensaje es recibido.
A continuación, se puede observar la creación del servidor TCP/IP que recibe esta comunicación,
la cual se ubica en el método StartRecognition:
Figura 3.20 - StartRecognition, reconocedor de dispositivos remotos.
Como se puede observar, una vez que la comunicación es aceptada por un cliente, se procede
a invocar a OnAccept, quien se encarga de comenzar a escuchar los paquetes de la conexión
establecida, y derivarlos a quien los procesará que es el método OnReceive.
Basado en el comando recibido desde el dispositivo remoto, se decidirá qué acción proceder a
ejecutar, enviando el correspondiente mensaje al módulo de interacción sistema - dispositivos.
3.2.5 Conclusiones generales de la integración de Amazon Echo
Como se han detallado, para la integración del dispositivo Amazon Echo, se implementaron 3
componentes nuevos, el Servicio de interacción de Alexa con su respectiva interfaz de voz, la
capa de abstracción de servicios web, y la extensión de reconocimiento de dispositivos remotos.
El reconocimiento de comandos se realiza de manera continúa invocando al servicio
“Intellihome” a través del dispositivo Amazon Echo, el cual, dependiendo del comando
indicado, invocará al servicio web desarrollado en la capa de abstracción de Intellihome, quien
mediante el protocolo TCP/IP invocará al servidor de Intellihome, para procesar el comando.
Este comando será enviado al cliente de Intellihome, quien accionará debidamente el módulo
Arduino.
La funcionalidad que permite el reconocimiento de los comandos de voz a través de Amazon
Echo, ha sido plasmada en el siguiente diagrama de casos de uso, en el cual se muestra el envío
de mensajes entre cada componente.
3.2.6 Solución de infraestructura para la solución.
El servicio desarrollado para interactuar con Amazon Echo, por las características del
dispositivo, tiene la necesidad de estar deployado en la nube, en particular Amazon, provee
facilidades para poder tener el servicio dentro de sus servidores. Esto implicó tener la necesidad
de comunicar el servicio en la nube, con los servicios web desarrollados como capa intermedia.
Desde un punto de vista teórico, este hecho resulta sencillo de realizar, dado que implica la
configuración de un dispositivo de ruteo en la red donde se encuentren los servicios web, que
permitan re direccionar los puertos para que el servicio de Alexa invoque los servicios desde
afuera. Tomando como consideración que Tanto el cliente como el servidor de Intellihome, que
están deployados como aplicaciones independientes, y el Tomcat donde se encuentran los
servicios web se encuentran en la misma máquina, se debe asegurar el acceso externo a solo
un dispositivo.
Al contar con una conexión de internet residencial con limitaciones, garantizar ese acceso se
tornó casi imposible. El proveedor de internet no permite el cambio de la configuración del
router, ni habilita puertos para poder realizar este tipo de tareas.
Este hecho llevó a tener que buscar alternativas al formato de despliegue que tenía actualmente
Intellihome, por lo que se decidió la creación de una máquina virtual en la nube, que permitiera
correr el servidor de Intellihome en la misma. Utilizando Azure, el proveedor de servicios en la
nube de Microsoft, se creó una máquina virtual, en la misma se procedió a ejecutar el servidor
de Intellihome, y los servicios web en un Tomcat.
Teniendo en cuenta este nuevo esquema, para el ejecutable que se encuentra en la máquina
virtual, se decidió dejar únicamente el reconocedor de dispositivos remotos. Ya que ningún otro
dispositivo podría ser conectado a Intellihome bajo este esquema, e incluso los adaptadores de
algunos de los dispositivos, como por ejemplo de MYO, necesitaban algunos requisitos del
sistema que la máquina virtual no los provee, como por ejemplo la librería OpenGL.
Este entorno permite desde los servicios desarrollados para Alexa, invocar a los servicios web
que se conectan con Intellihome. Para observar esto, a continuación, se observa en la figura
3.21 el diagrama de Despliegue.
Figura 3.21 - Diagrama de Despliegue correspondiente a los módulos involucrados en la
interacción Alexa - Dispositivos.
3.3 Integración del dispositivo MYO.
El dispositivo presenta diferentes formas de integración con sistemas externos, oficialmente
Thalmic Labs provee el SDK para lenguajes C y C++. Debido a que Intellihome se encuentra
implementada en C#, se descartó su uso en un principio. Adicionalmente, algunas tareas
pueden ser desarrolladas fácilmente a través de scripting utilizando Myo Connect, aplicación
que permite a MYO interactuar con la computadora, es capaz de ejecutar conectores que
interactúen con el dispositivo a través de eventos, utilizando los mismos para iniciar la ejecución
que permite controlar aplicaciones. Los scripts desarrollados para MYO son conectores escritos
en Lua, un lenguaje de scripting que permite actuar frente a determinadas acciones del usuario.
3.3.1 Desarrollo de Scripts para Myo
Myo Connect interactúa con los scripts mediante 2 mecanismos, funciones de retorno
(Callback) y funciones de la API. Las funciones de retorno son implementadas por scripts para
manejar eventos específicos o solicitar información. Cuando un evento sucede (tal como un
cambio de aplicación, de pose, etc), Myo Connect invoca al script asociado, en algunos casos
proveyendo información adicional.
Las funciones de la API, proveen scripts con funcionalidad adicional para acceder a las
propiedades brazalete, y a información del sistema. Esto incluye a los valores angulares de la
orientación del mismo, acceso a la vibración del dispositivo, el horario actual, y la salida de la
pantalla de debug. Además, permite manipular el sistema emitiendo eventos del teclado, los
cuales pueden ser usados para controlar aplicaciones.
Al crear un script para controlar aplicaciones, se debe indicar que es lo que queremos controlar,
en este caso, a Intellihome, es por eso, como se muestra en la figura siguiente, se declara esto,
en la función onForegroundWindowChange().
Figura 3.22 - onForegroundWindowChange
Cuando el dispositivo detecta algún cambio, el mismo es comunicado al script llamando la
función onPoseEdge, observada en el siguiente código, incluyendo en la misma la pose realizada
y el estado de la misma.
Figura 3.23 - onPoseEdge, determina qué acción tomar ante un evento.
El primer comando que se ejecuta para definir que pose se está realizando, es una función que
determina la pose, teniendo en cuenta el brazo en el que el usuario utiliza el dispositivo, dado
que Myo permite ser utilizado en cualquiera de los 2 brazos, las poses “Wave In” y “Wave Out”
difieren, dado que el dispositivo solo reconoce si el movimiento fue de izquierda a derecha o
viceversa. Por lo tanto, se maneja esto consultando al dispositivo en que brazo está colocado
con la función myo.getArm.
Teniendo en cuenta la pose realizada por el usuario, currentBindings retorna si es que la hay la
función asociada a esa pose. Para simplificar la interacción con Intellihome, como se explica en
el siguiente apartado, Myo actúa como si fuera un teclado. Si el usuario realizará el gesto del
puño, la función asociada seria:
fist_on = function() keyPress('n', 'press') end,
Esta función ejecutaría sobre Intellihome, la acción de presionar la tecla “n”.
Dentro de Intellihome, esto se interpreta gracias a la función Window_KeyDown, la cual
interpreta comandos del teclado, y dependiendo de los mismos ejecuta acciones. El siguiente
código demuestra cómo funciona definiendo 2 posibles comandos de teclado.
Figura 3.24 - Reconocedor de pulsaciones del teclado.
3.3.2 Conclusiones de la integración de Myo con scripts
En el apartado anterior se describió el proceso de integración de Myo utilizando scripts, y el
código requerido para adaptar la plataforma.
Al momento de desarrollo de esta funcionalidad, la misma solo provee soporte para obtener
una cantidad limitada de gestos genéricos, por lo cual no se podían crear nuevos gestos que
satisfagan las necesidades de los distintos usuarios. Por esto se decidió utilizar la librería
MyoSharp, que adapta el SDK provisto por Thalmic Labs, al lenguaje C#, que como se nombró
en la sección 2.9 es el lenguaje en el cual está desarrollado Intellihome.
En la sección 3.3.3, se detalla la implementación y decisiones de diseño para la integración de
Myo en este trabajo de tesis.
3.3.3 Integración de Myo utilizando MyoSharp.
Los componentes subyacentes de Myo, están escritos en C++, y solo hay un conjunto de
funciones que se pueden acceder utilizando la biblioteca. Para poder realizar eso, MyoSharp
utiliza las invocaciones de C#, PInvokes, para acceder a esta funcionalidad. A continuación, se
detalla en qué consiste MyoSharp
1. Inicialmente se abre un canal de comunicación con el módulo Bluetooth. La
implementación de esto está íntegramente en C++ y provisto por Thalmic Labs en su
SDK. Desde MyoSharp solo se invoca a la función provista, la cual permite acceder al
stream de eventos que provienen del módulo Bluetooth.
2. Una vez que se es capaz de interceptar eventos, se debe identificar el dispositivo Myo.
Existe un evento pair que proviene del módulo Bluetooth que notifica cuando un
dispositivo se ha conectado, y nos provee el control del dispositivo, este es utilizado
para identificar eventos y enviar mensajes.
3. Una vez que se identifica el dispositivo, se procede a interceptar los eventos, y
transformarlos en datos conocidos, sea cambios de orientación, de aceleración, etc.
4. Por último, al desconectar el dispositivo, se envía el evento correspondiente.
Figura 3.25- StartRecognition Myo.
Para la implementación dentro de IntelliHome, se creó una instancia del hub, esta maneja la
colección de Myos que se conecten y desconecten del sistema. Internamente el hub crea una
instancia del canal y se la pasa a la instancia del listener.
Como se mencionó en la sección 3.2.4, para poder agregar un nuevo Reconocedor, se tiene que
realizar una extensión de la clase abstracta Reconocedor, lo cual implica la implementación de
los métodos StartRecognition y Stop.
En la figura anterior se puede observar el método StartRecognition, el cual crea el Hub
proporcionado por MyoSharp, para poder interactuar con Myo, y espera a la conexión de un
dispositivo, notificando al usuario la conexión, con una vibración corta,
e.Myo.Vibrate(VibrationType.Short).
Figura 3.26 - Código de acción al reconocer una pose.
En el código de la figura anterior, se han integrado distintos controladores de eventos, tanto
para la conexión y desconexión del dispositivo, como para la detección de cambios de poses.
Esto nos permite comunicar al cliente de Intellihome las diferentes acciones a realizar sobre el
Arduino, dependiendo de la acción realizada por el usuario.
Cuando el dispositivo se desconecta el hub mantiene la instancia del objeto Myo, esto permite
que independientemente de las conexiones y desconexiones del dispositivo, el controlador de
eventos de cambios en las poses permanezca activo.
El dispositivo permite reconocer los eventos del acelerómetro, el giroscopio, y los cambios en
la orientación. Si bien se permite ante cada pose realizar un evento, la biblioteca permite a su
vez declarar secuencias de poses que activen una acción específica al finalizar la misma.
Cada pose permite tanto encender como apagar un dispositivo, es por esto que, al reconocer
una pose establecida, se debe determinar el estado del dispositivo a accionar, para poder
determinar la acción inversa a realizar.
3.3.3 Conclusiones de la integración con MyoSharp.
Como se indicó en el capítulo 2, los sistemas orientados a usuarios con discapacidad, deben ser
altamente personalizables, dado que cada discapacidad tiene consigo limitaciones físicas que la
acompañan, es por esto que Myo representa una buena opción dado que permite adaptar los
movimientos ante los cuales IntelliHome actúa dependiendo de las capacidades del usuario en
particular.
CAPITULO 4: Análisis y pruebas
Esta sección es el resultado de un estudio de usabilidad y vulnerabilidades de la plataforma de
AAL extendida. El objetivo es poder encontrar las posibles fallas que desencadenen en errores
del sistema que atenten contra su funcionalidad para evitar generar frustración en los usuarios
finales, y establecer los puntos a mejorar en cuanto a reconocimiento de gestos. En este estudio
se analizaron los potenciales errores, a través del análisis de su arquitectura y se generó la
documentación necesaria para efectuar las modificaciones que harán que el sistema se
comporte de forma estable. En la primera parte de esta sección se introducen los conceptos
correspondientes al marco teórico de una evaluación de assurance cases y a los atributos de
calidad de los sistemas de AAL. Luego, se presenta el estudio de las vulnerabilidades
encontradas, junto con los pasos a seguir para realizar las modificaciones pertinentes. Además,
se utilizaron 2 usuarios de prueba, los cuales realizaron pruebas sobre la usabilidad del sistema.
Por último, se encuentra el resumen de bibliografía consultado.
4.1. Assurance cases
Se conoce como Assurance Cases a la evidencia documentada que provee argumentos válidos
y convincentes de que un sistema es adecuadamente seguro para una aplicación dada en un
ambiente dado (Bishop et. al, 1998). Hay diferentes formas de construir esta justificación. Los
tres enfoques principales pueden ser distinguidos como un triángulo de:
● Una serie de afirmaciones sobre el comportamiento de seguridad del sistema.
● El uso de estándares y modelos aceptados.
● Una investigación de las potenciales vulnerabilidades del sistema conocidas.
Figura 4.1 - Estudio de seguridad de un sistema.
En el primer enfoque se especifican los objetivos de seguridad respaldados por argumentos y
evidencias en niveles progresivamente más detallados. El segundo enfoque se basa en
demostrar el cumplimiento de un estándar de seguridad conocido. El último enfoque es un
argumento basado en vulnerabilidades en el cual se demuestran las potenciales
vulnerabilidades del sistema que no constituyen un problema. Los atributos de seguridad en un
sistema considerados para asegurar completitud son:
● Correctitud
● Seguridad ante fallas
● Usabilidad
● Líneas de tiempo
● Precisión
● Seguridad
● Confiabilidad
● Mantenibilidad
● Disponibilidad
● Modificabilidad
● Robustez
Las propiedades son únicamente relevantes para la seguridad en un contexto de aplicación
dado. Por ejemplo, líneas de tiempo pueden no ser relevantes para la seguridad en un sistema
de asesoramiento, pero precisión puede serlo. Al enfocarse en el comportamiento deseado, los
argumentos y evidencias están primeramente relacionados a los productos en vez de a los
procesos. Generalmente la evidencia para el producto proviene de varias fuentes tales como:
● Análisis estático o revisión del sistema, hardware y software.
● Testing convencional de componentes o del sistema en general para controlar
propiedades tales como precisión y línea de tiempo.
● Test de confianza
● Experiencia de campo
Es evidente que no es posible decir si un componente es seguro o no en forma aislada, la
seguridad depende de contexto en el que el componente opera. Así que no podemos afirmar
que un componente es "seguro" en un sentido directo, pero debemos ser capaces de justificar
que el componente "hace lo que dice". Este es un concepto común para los sistemas basados
en hardware, que se someten a la "homologación", y una vez aprobados, se considera que
proporcionan un cierto nivel de servicio garantizado. Se ha investigado este enfoque para la
justificación de sensores inteligentes, en donde las demandas son relacionadas a las
propiedades de seguridad de los productos fuera de la plataforma en vez de la seguridad del
sistema como un todo, por ejemplo:
● Correctitud en relación a su especificación publicada.
● Precisión
● Línea de tiempo
● Confiabilidad
● Modos de falla
También es necesario tener en cuenta su uso con el sistema como un todo para poder
demostrar
● La ausencia de interferencia con otros componentes del sistema.
● La adaptabilidad del componente para la aplicación requerida
Normalmente cualquier componente fuera de la plataforma ejecutando en la misma región de
fallos puede interferir con otras funciones de otro componente. Incluso si la función actual del
componente no tiene un impacto directo en operaciones seguras del sistema, hay potencial
para interferencias con otras funciones relacionadas a la seguridad.
Las deferencias de diseño pueden formar parte de las justificaciones del sistema como parte de
evidencias en la justificación de integridad del mismo (Bishop et. al, 2004).
La siguiente sección de este Capítulo, detalla los atributos de calidad de Intellihome, que se ven
afectados por la extensión realizada mientras que en la sección 3 se documenta la investigación
de las potenciales vulnerabilidades de la misma. Esta sección forma parte de la evidencia de
argumentos válidos y convincentes acerca de la seguridad para asistir a personas dentro de una
vivienda residencial.
4.2. Atributos de calidad de un sistema de AAL
Los sistemas del dominio de AAL tienen requerimientos críticos. Si hay una falla estos dejarán
de funcionar y el usuario, al que se le está brindando independencia y confort, se vuelve
nuevamente dependiente. Intellihome no posee requerimientos de vida o muerte, sin embargo,
al fallar puede crear frustración y cambio en los estados de ánimo del usuario, lo que impacta
en su tratamiento y en su salud.
Los sistemas de AAL aplican dependabilidad (Avizienis et. al, 2004), un concepto integrador que
abarca los siguientes atributos:
● disponibilidad: servicio continuo a disposición del usuario.
● confiabilidad: continuidad del servicio correcto.
● seguridad: ausencia de consecuencias catastróficas en los usuarios y en el ambiente.
● integridad: ausencia de alteraciones impropias del sistema.
● mantenibilidad: capacidad de sufrir modificaciones y reparaciones.
No solo dependabilidad es importante, sino también seguridad. Para satisfacer los
requerimientos no funcionales presentes en el sistema se deben conocer los tipos de errores y
fallas que pueden encontrarse el mismo. En la siguiente clasificación se muestran las fallas que
pueden causar un cambio de estado en el sistema provocando el funcionamiento erróneo:
Clasificación de fallas (Bass et. al, 2003):
● Fallas de desarrollo
○ Todos los tipos de fallas ocurren durante el desarrollo.
● Fallas físicas
○ Todos los tipos de fallas que afectan el hardware.
○ Fallas de interacción
○ Todas las fallas externas.
● Fallas naturales
○ Causadas por fenómenos naturales que no involucran personas.
○ defectos de producción originados en el desarrollo.
○ Internas/externas.
● Fallas ocasionadas por personas
○ resultado de acciones humanas.
○ Omisión de errores.
○ fallas maliciosas/no maliciosas.
○ Virus/desperfectos.
Luego, se deben conocer las estrategias para lograr dependabilidad y seguridad, estas se
clasifican de la siguiente manera:
● Prevención de fallas: prevenir la ocurrencia o la introducción de fallas.
● Tolerancia a fallas: evitar fallas en el servicio en la presencia de fallos.
● Eliminación de fallas: reducir el número y la severidad de fallos.
● Anticipación de fallas: estimar el número de fallas presentes, la futura incidencia, y las
posibles consecuencias de fallas del sistema.
Figura 4.2 - Taxonomía de fallas.
Prevención y tolerancia a fallas proveen la capacidad de brindar un servicio que puede ser
confiable, mientras que eliminación y anticipación de fallas tratan de alcanzar confidencialidad
justificando que el funcionamiento y las especificaciones de dependabilidad y seguridad son
adecuadas y que el sistema probablemente las cumpla.
Teniendo en cuenta los atributos y las estrategias mencionadas se evaluará, a nivel software,
las extensiones de la plataforma Intellihome para localizar las posibles fallas que puedan existir
y plantear las estrategias para disminuir sus puntos vulnerables.
La evaluación se realizará por atributo de calidad y se tendrá en cuenta el diseño de la
implementación mencionado en la primera parte de esta sección para detallar los problemas
encontrados
Figura 4.3 - Árbol de dependabilidad y seguridad.
4.3. Evaluación de vulnerabilidades
4.3.1 Disponibilidad y Confiabilidad
El sistema debe funcionar cuando el usuario lo requiera. Dentro de la plataforma implementada
existen puntos de conflicto que pueden obligar la detención del reconocimiento de gestos o de
voz. Esto puede suceder por las distintas fallas de hardware o de software que se presentan a
continuación.
Requerimientos mínimos de la PC a utilizar:
La disponibilidad de la plataforma estará dada, en parte, por el hardware de la PC en la que se
conectan los sensores. El sensor MYO no tiene grandes requerimientos, el conector MYO puede
ser ejecutado sobre Windows 7, 8 y 10, y es necesario contar con un puerto USB, y el sistema
debe tener OpenGL 2.1 o superior.
Se analizó la performance del dispositivo en dos configuraciones diferentes:
Configuración 1:
Sistema operativo Windows 10 x64
Procesador i7 4510u 2.6Ghz
8Gb de Memoria
Configuración 2:
Sistema operativo Windows 7 x64
Procesador i3 2.3Ghz
4 Gb de Memoria.
Se pudo comprobar que la ejecución del sistema en cualquiera de las dos funciona de manera
performante.
En cuanto al Dispositivo Amazon Echo, al ser un dispositivo independiente, no depende de
donde esté siendo ejecutado Intellihome.
Limitaciones de Hardware
Distancia entre los usuarios y el sensor Amazon Echo:
Para el reconocimiento de voz el usuario debe estar dentro de un espacio a la redonda del
dispositivo, de aproximadamente entre 6 y 8 metros, lo cual es una distancia considerable para
ser utilizado en un ambiente cerrado. Si esta restricción no se cumple no se reconocerán los
comandos ejecutados por el usuario. El sistema actual no reconoce si el usuario está muy lejos
del sensor. Aunque esto tiene su restricción en el dispositivo en sí, el usuario da cuenta de su
lejanía observando si el sensor enciende su luz, o contesta en algún momento. Esto puede crear
la sensación de que el sistema no está funcionando cuando en realidad el usuario no está
respetando las restricciones especificadas en la documentación del sensor.
La estrategia a aplicar es prevención de fallas, notificando al usuario las medidas necesarias
para saber cuándo el sensor está activo, o colocando repetidores del sensor, que permitan
abarcar todo el espacio.
Fallas de software
Para solucionar los problemas encontrados se utilizan como herramienta principal las tácticas
de disponibilidad propuestas por el SEI (Avizienis et. al, 2004).
Figura 4.4 - Tácticas de Disponibilidad.
Vulnerabilidades encontradas:
Problema de conectividad entre Alexa WS e Intellihome WS: como se indicó en la sección 3.2.6,
para poder configurar que el servicio que procesa los comandos de voz de Alexa envíe
peticiones al servicio web provisto por Intellihome, se debe tener acceso al dispositivo de
routeo del ambiente en el cual se encuentra Intellihome, y especialmente se debe poder
cambiar la configuración de los puertos, lo cual, en algunos proveedores de internet, esto no es
posible
Para prevenir este problema se debe tener en cuenta con que configuración de red, y proveedor
de internet se cuenta en el ambiente a realizar la implantación del sistema.
Desconexión de red:
Al desconectarse el módulo Intellihome WS, que cumple la función de capa de servicios web
conectada con el sistema mediante TCP/IP, se enviará una notificación al módulo Alexa WS que
es quien recibe los comandos del usuario, notificando este problema. Este continuará su
funcionamiento normal. Sin embargo, no se procesarán comandos de voz, y se pondrá al cliente
en conocimiento de que la conexión se ha interrumpido. Para poder restablecer el servidor se
pueden utilizar las siguientes tácticas de recuperación de fallas (Bass et. al, 2003):
● Redundancia activa: Todos los componentes redundantes responden a los eventos en
paralelo. En consecuencia, todos se encuentran en el mismo estado. Se utiliza la
respuesta del primer componente y las demás son descartadas. Esta táctica es utilizada
en sistemas que necesitan respuestas rápidas aun cuando hay fallas, es ideal para
configuraciones cliente/servidor.
Figura 4.5 - Redundancia activa a implementar entre el Intellihome (Servidor) y nodos de
redundancia activa.
● Redundancia pasiva: Un componente, el primero, responde a los eventos e informa a
los otros componentes (en stand by) el estado de las actualizaciones que deben
procesar. Cuando ocurre una falla, el sistema primero debe asegurar que el estado de
respaldo sea lo suficientemente actualizado antes de reanudar los servicios.
Figura 4.6 - Redundancia pasiva a implementar entre el módulo Intellihome y nodos de
redundancia pasiva.
En este sistema en específico es necesario actualizar los servidores de respaldo, ya que el
servidor activo se comunica con los sensores y no se almacena un historial de las funciones
ejecutadas previamente. En esta configuración pueden perderse unos segundos desde que el
servidor principal deja de funcionar hasta que uno de respaldo toma su lugar.
Esto puede provocar la pérdida de uno o dos eventos, es decir, el usuario se verá obligado a
repetir el comando de voz para que el sistema ejecute la función solicitada. La pérdida de
interacción es mínima.
4.3.2 Seguridad e Integridad
Dentro de un sistema de software, seguridad representa la ausencia de consecuencias
catastróficas en los usuarios y en el ambiente. Este atributo de calidad se caracteriza por las
siguientes cualidades:
● No repudio: una transacción no puede ser negada por ninguna de sus partes.
● Confidencialidad: los datos o servicios están protegidos del acceso no autorizado.
● Integridad: los datos o servicios son entregados sin cambios.
● Seguridad: las partes en una transacción son quienes dicen ser.
● Disponibilidad: el sistema estará disponible para el uso legítimo. Los ataques no
perjudicarán la interacción con los usuarios.
● Auditoria: el sistema lleva un seguimiento de las actividades ejecutadas en un nivel
suficiente como para reconstruirlas (Bass et. al, 2003).
Mientras que la integridad representa la ausencia de alteraciones impropias del sistema. En la
plataforma implementada se llama usuario a toda aquella persona que utilice el sistema a través
de los sensores. No existe autentificación ni registro de quienes usan el sistema. Esto hace que
un ataque malicioso únicamente pueda provenir desde otro sistema por medio de una conexión
a Internet con el fin de modificar el comportamiento de los servicios del sistema.
Las soluciones a los problemas encontrados se basan en las tácticas de seguridad propuestas
por el SEI.
Figura 4.7 - Tácticas de Seguridad.
Vulnerabilidades encontradas:
Ataques a la conexión red: Actualmente no existen en el sistema métodos de control de
intrusos en la red. Se deben implementar mecanismos para evitar que entidades externas
provoquen desconexiones en la red teniendo en cuenta las siguientes tácticas:
Detección de ataques: se debe considerar la implementación de un sistema de detección de
intrusos. Estos sistemas funcionan comparando patrones del tráfico de la red con los de una
base de datos. Esto puede llevar a elevar los costos de instalación y de hardware de la
plataforma. La implementación de esta detección debiera estar en ambos componentes
principales del sistema, interacción usuario - sistema e interacción sistema - dispositivos.
Teniendo esta mejora, no sería necesario realizar cambios en la interfaz de servicios web, dado
que los mismos nunca llegarían a comunicarse con Intellihome, llegado el caso de un ataque
externo
Figura 4.8 - Extensión de la funcionalidad de los módulos Cliente y Servidor para brindar el
servicio de detección de ataques.
Recuperación de ataques: Esta táctica es similar a la explicada anteriormente en las figuras 4.5
y 4.6 de la sección de disponibilidad. Si alguno de los componentes se desconecta de la red esta
puede seguir funcionando a través de los nodos de respaldo
Ataques a los paquetes transportados por la red:
Actualmente no existen en el sistema métodos de protección de los paquetes enviados por la
red. Si los mensajes enviados son modificados, pueden descartarse, lo que atenta contra la
disponibilidad y la confiabilidad del servicio brindado. Para resolver este problema existen dos
soluciones pertenecientes a la táctica de resistencia ante ataques.
Mantener los datos confidenciales: Se deben proteger los datos enviados por la red a través de
encriptación. Para brindar mayor seguridad es conveniente el uso de encriptación asimétrica en
los módulos principales de la plataforma, como también en la capa de servicios de Intellihome,
y el servicio de Amazon Alexa.
Acceso limitado: Pueden utilizarse firewalls para restringir el acceso de mensajes de puertos
desconocidos.
Figura 4.9 - Diagrama de despliegue de la plataforma implementada con resistencia de
ataques con acceso limitado.
Realizar estos esfuerzos y elevar los costos de hardware del sistema, deben ser considerados
solo si se va a utilizar el dispositivo Amazon Echo, dado que el resto no utilizan datos de Internet,
la solución más sencilla y económica es mantener las computadoras involucradas sin conexión
a Internet para evitar ataques maliciosos y potenciales descargas de virus.
4.3.3 Confidencialidad
Para este sistema en particular, el atributo de calidad Confidencialidad no es aplicable ya que
no se mantiene información del usuario almacenada en el sistema.
4.3.4 Mantenibilidad
Dentro de un sistema de software se conoce como mantenibilidad a la facilidad con la que un
sistema o componente software puede ser modificado para corregir fallos, mejorar su
funcionamiento u otros atributos o adaptarse a cambios en el entorno (IEEE).
Un software bien desarrollado debe tener la flexibilidad necesaria para adaptarse al futuro y
que el mantenimiento deba hacerse de manera rápida y efectiva, afectando lo menos posible
las labores de la entidad que lo utilice. Por lo tanto, se deben corregir errores de manera rápida
y efectiva. Puede agregarse nueva funcionalidad, mejorar el uso del software a través del
tiempo, incrementar el rendimiento, resolver problemas actuales de vulnerabilidades o que
puedan surgir en el futuro y poder hacer cambios para que sea compatible con los nuevos
sistemas operativos que varían a través del tiempo.
Normalmente un sistema sufre modificaciones luego de que ha sido finalizado y presentado a
los usuarios como producto final. Esto se debe a que durante su uso pueden encontrarse fallas,
surgir nuevos requerimientos, realizar ajustes en alguna funcionalidad o mantener el sistema
actualizado para poder utilizarlo con las nuevas tecnologías de software y hardware existentes
en el mercado.
Mantenibilidad está relacionado con el atributo de calidad modificabilidad. Este último plantea
reducir el número de módulos que pueden estar directamente afectados por cambios. En la
plataforma extendida, el foco está dado por el comportamiento de los sensores y del actuador
en relación con los dispositivos. Actualmente se encuentran en el mercado nuevos sensores de
gestos que pueden ser más precisos que los que se usan actualmente en la plataforma.
Asimismo, existen nuevas tecnologías para el reconocimiento de voz, que ha crecido junto con
los avances de la telefonía celular y la inteligencia artificial. Los dispositivos Android y iOS
poseen reconocimiento de voz y son capaces de mantener una conversación con los usuarios.
Estos dispositivos pueden incorporarse a la plataforma de AAL implementada, pudiendo enviar
los comandos reconocidos a la PC por medio de conexiones wifi o bluetooth, o a través de
mensajes directamente a la capa de servicios web. Generalmente es difícil anticipar
modificaciones en un sistema. En este caso en particular, la plataforma busca brindar asistencia
a los usuarios a través de una interfaz interactiva. La funcionalidad de la plataforma
implementada puede ser fácilmente extendida para añadir más sensores, actuadores,
dispositivos y nuevas conexiones entre estos, así como también ampliar la cantidad de gestos y
comandos de voz reconocidos.
El poder ubicar los módulos a modificar es una táctica preventiva llamada anticipación de
cambios esperados. Esta se ha tenido en cuenta en el momento de la extensión. El análisis de
esta sección está centrado en las modificaciones a futuro de la plataforma implementada.
Añadir un nuevo sensor con la característica que procese externamente a Intellihome la entrada
del usuario: Al incorporar nuevos sensores se debe analizar si los mismos deben asociarse
internamente a Intellihome, o si pueden invocar a los servicios provistos.
Para añadir un nuevo reconocedor de comandos de voz para dispositivos móviles, por ejemplo,
éste podrá obtener los comandos del usuario en la aplicación nativa, tal y como se ha
implementado para el reconocimiento de voz con el sensor Kinect. y luego de procesar el
comando, ejecutar la correspondiente llamada al servicio provisto por la interfaz de servicios
web, detallada en la sección 3.2.3.
Las nuevas tecnologías pueden incorporarse teniendo mejores resultados, aunque, agregar
nuevos sensores puede no ser favorable. Estos necesitan un período de tiempo de prueba y
pueden no ajustarse al funcionamiento esperado dentro de la plataforma, lo que puede generar
conflicto entre otros sensores y bajar la performance, disponibilidad y confiabilidad del sistema.
Un inconveniente a tener en cuenta es que, aunque se realice un estudio de compatibilidad y
desempeño de los nuevos sensores, se deberá realizar la inversión para poder probar su
funcionamiento en el ambiente asistido por computadora, pudiendo esta ser o no beneficiosa.
Eliminar un sensor o reconocedor: Estos cambios debieran ser simples y no alterar el
funcionamiento de la plataforma. Se debe eliminar de las jerarquías de sensores/reconocedores
la clase que no vaya a ser utilizada nuevamente. Actualmente el sistema requiere una
modularización y abstracción que permita desactivar módulos a gusto, para evitar ejecutar
innecesariamente funcionalidades. Se debe entonces remover la clase gramática, el
reconocedor de gestos integrado y los reconocedores de voz y de gestos.
Estos cambios corresponden al módulo servidor de Intellihome, y deberían acarrear una
configuración de inicialización de los sensores más dinámica.
Control de versiones: El desarrollo de la plataforma implementada ha sido de forma iterativa e
incremental, aunque, recientemente se ha optado por subir la implementación a un repositorio
git. En ocasiones ha habido correcciones en archivos antiguos por no tomar este recaudo
previamente. Para evitar confusiones que lleven a modificar archivos equivocados y a una
pérdida considerable de tiempo y esfuerzo, en el futuro se debe utilizar constantemente el
sistema de control de versiones, para ayudar a quien modifique la funcionalidad de la
plataforma a mantener el código, tests y documentación actualizados y sincronizados.
4.4 Pruebas de usuario
Si bien este trabajo de tesis no realiza un análisis de usabilidad, resulto conveniente poder
evaluar el uso de los dispositivos de manera general, y poder obtener feedback para evaluar
mejoras y trabajos a futuro.
4.4.1 Descripción de los sujetos de estudio.
Para evaluar el funcionamiento de los dispositivos incluidos en la plataforma, se procedió a
analizar 3 usuarios de diferentes características, solicitando tareas concretas a realizar.
Usuario Nro. 1
Sexo: Masculino
Edad: 55
Educación: Universitario
Nivel de Inglés: Medio
Nivel de relación con la tecnología: Medio
Usuario Nro. 2
Sexo: Femenino
Edad: 56
Educación: Secundario
Nivel de Inglés: Bajo
Nivel de relación con la tecnología: Bajo
Usuario Nro. 3
Sexo: Femenino
Edad: 10
Educación: Primaria
Nivel de Inglés: Medio
Nivel de relación con la tecnología: Alto
4.4.2 Descripción de las tareas.
MYO
1. Desbloquear el dispositivo 10 veces.
2. Encender la luz 10 veces.
3. Encender y apagar la luz 10 veces.
4. Desbloquear el dispositivo 10 veces.
Amazon ECHO
1. Solicitar los cuartos disponibles 10 veces
2. Pedir que se encienda la luz en 1 solo comando 10 veces
3. Entablar una conversación que lleve a prender la luz 10 veces.
4.4.3 Resultados y conclusiones.
1 Desbloquear MYO 10 veces.
El dispositivo lleva un periodo de adaptación por parte del usuario, razón por la cual, en un
principio, los fallos en el uso, son mucho mayores que los aciertos. Los usuarios no contaban
con experiencia alguna en el uso del dispositivo, ni tampoco de tecnologías similares.
Cabe destacar que las pruebas con este dispositivo solo pudieron ser realizadas por los usuarios
1 y 2, dado que por la contextura física del usuario 1, dada la corta edad el dispositivo no pudo
ser utilizado.
Como paso previo a la tarea se explicó a los usuarios el gesto de la figura 4.10 que desactiva el
dispositivo, mostrando el video tutorial provisto por Thalmic Labs, y permitiendo que calibren
el dispositivo.
Figura 4.10 - Gesto de desbloqueo de MYO.
A continuación, se observa un gráfico que denota la cantidad de aciertos contra los fallos al
intentar desbloquear el dispositivo.
Figura 4.11 - Aciertos vs Fallos en desbloqueo de MYO.
2 Encender la luz 10 veces utilizando MYO.
Para poder realizar cualquier gesto utilizando el dispositivo MYO, antes se debe desbloquear,
por lo tanto, para poder encender la luz se debe, primero desbloquear el dispositivo, y dentro
de los siguientes 2 segundos se debe realizar el gesto de la figura 4.12 para encender la luz.
Figura 4.12 - Gesto de puño en MYO.
Esta secuencia de acciones llevo a dificultar aún más la prueba, los usuarios aun no llegaron a
dominar el desbloqueo por sí solo, y ahora debían incluir un gesto adicional, dentro de los 2
segundos siguientes al desbloqueo, dado que, sino el dispositivo se bloquea nuevamente, lo
cual fue la razón principal, por la que los usuarios necesitaron realizar tantas repeticiones para
lograr el objetivo.
Figura 4.13 - Aciertos vs Fallos en Encendido de luz con MYO.
3 Encendido y apagado de luz utilizando MYO
Esta secuencia de acciones implica la duplicidad de la acción anterior, ya que el encendido y el
apagado de un dispositivo, se realizan con el mismo gesto, por lo cual la secuencia se convierte
en, desbloquear, puño, desbloquear, puño.
Esta actividad fue solicitada casi una semana después que la anterior, lo cual pareciera beneficio
a los usuarios, dado que la cantidad de repeticiones para llegar al éxito fue en comparación
menor que en el ejercicio anterior.
Figura 4.14 - Aciertos vs Fallos en Encendido y apagado de luz con MYO.
4 Desbloqueo de MYO
Luego de alrededor de 150 desbloqueos realizados por cada usuario, se decidió tomar como
último punto de comparación, la mejora en cuanto al gesto de desbloqueo del dispositivo, con
respecto a las primeras pruebas, teniendo en cuenta que el dispositivo tiene una curva de
aprendizaje lenta en un principio, se pueden apreciar las diferencias generadas a partir del uso
del mismo.
Como se observa en la figura 4.15 se nota una gran mejoría dado que las fallas disminuyeron a
la mitad del inicio.
Figura 4.15 - Aciertos vs Fallos en desbloqueo de MYO.
5 Solicitar los cuartos disponibles 10 veces
Antes de comenzar con la ejecución de la serie de pruebas con Amazon ECHO, se explicó el
funcionamiento del mismo, cuales son las frases aceptadas, y la pronunciación esperada. Dado
que este dispositivo actualmente solo acepta el idioma inglés, las pruebas realizadas fueron en
ese idioma, con usuarios que no hablan fluidamente. El realizar las pruebas en otro idioma,
genera que la adaptación y mejoras del sistema tengan más dificultad. Ya que en un sistema de
interacción debería incluir frases de uso frecuente para el usuario, y dadas las circunstancias,
Figura 4.16 - Acierto vs fallos en solicitud de cuartos disponibles al Echo.
esto resulta casi imposible.
6 Pedir que se encienda la luz en 1 solo comando 10 veces
Como se explicó en la sección 3.2.2 existen diferentes formas de interactuar con el dispositivo
Amazon Echo, la más directa es indicándole 1 comando con toda la información necesaria. Es
por esto que para prender la luz se debe indicar la acción, el cuarto, y el objeto a accionar.
La frase que acciona en un solo comando el encendido de la luz es:
“Alexa, Ask Intellihome to turn the kitchen light on.”
Figura 4.17 - Acierto vs fallos encendido de luz con 1 comando con Echo.
7 Entablar una conversación que lleve a prender la luz 10 veces.
Antes de realizar esta prueba se explicó a los usuarios que es lo que espera identificar en la
conversación el servicio de Alexa. El propósito es indicar los 3 datos necesarios al dispositivo,
en forma de oraciones, se debe incluir el cuarto, el dispositivo, y la acción. Esta explicación
facilito las pruebas y redujo las fallas de las mismas.
Figura 4.18 - Aciertos vs Fallos al entablar una conversación con Echo.
Cabe destacar que gran cantidad de los fallos provocados por el usuario se deben a problemas
en la pronunciación de alguna palabra del comando. Y en este último caso, ante la interacción
con el dispositivo, el usuario 3 cometió errores provocados por la ansiedad de la situación de
interactuar con Echo.
CAPITULO 5: Conclusiones y trabajos
futuros
En los capítulos anteriores se presentó el concepto de vida cotidiana asistida por computadora
(AAL), su objetivo y alcance tecnológico. La plataforma extendida Intellihome, cumple
satisfactoriamente el objetivo de interactuar con dispositivos eléctricos de un ambiente a través
de gestos y comandos de voz, utilizando tecnología de bajo presupuesto y evitando el tendido
de cableados. Las extensiones realizadas sobre la misma, permiten alcanzar a un grupo mayor
de usuarios, dadas las nuevas capacidades integradas. Asimismo, permite al desarrollador
abstraerse de las características específicas de cada uno de los dispositivos y su manera de
comunicarse, utilizando un único punto de entrada.
5.1. Conclusiones
En el presente trabajo se extendió una plataforma de vida cotidiana asistida por computadora,
pensada principalmente para crear aplicaciones que sirvan para asistir a personas ancianas o
con algún tipo de discapacidad brindándoles más independencia y confort en las tareas de sus
hogares, pensando en la automatización de dispositivos a través de gestos y comandos de voz.
Para poder ampliar las capacidades del sistema, se agregaron 2 dispositivos que proveen nuevas
formas de interacción con el mismo.
Los dispositivos utilizados se han desarrollado en los últimos 5 años y la plataforma tiene un
gran potencial, aunque, a pesar de los esfuerzos en satisfacer las necesidades de los usuarios,
el verdadero desafío es lograr que las personas se sientan atraídas por el uso de la tecnología.
Hoy en día son muchas las áreas en las que pueden desarrollarse aplicaciones de asistencia y de
desarrollo cognitivo orientadas a personas con discapacidad. La necesidad de estos desarrollos
es muy grande. Sin embargo, es difícil encontrar sistemas que permitan asistir a personas
discapacitadas permitiendo la inclusión social y su desarrollo personal.
Desde el lado de la ingeniería, pueden construirse soluciones de software con muy poco
esfuerzo y con gran impacto en la sociedad, lo que nos brinda la oportunidad de reducir las
diferencias y transformar el mundo en el que vivimos en un mundo accesible para todos.
5.2. Trabajos futuros
Entre los trabajos y extensiones futuras se pueden mencionar:
● Incorporar una agenda virtual, recordatorios y alarmas.
● Incorporar la tecnología RFID utilizada en Internet de las cosas para encontrar objetos
de relevancia como llaves y documentos.
● Interactuar con módulos Arduino wifi, para evitar cableados en los dispositivos a
controlar.
● Implementar el ambiente asistido por computadora en edificios y oficinas.
● Integrar la base de datos en todo el sistema, en pos de abstraerse de la instalación.
● Incorporar el reconocimiento de comandos especiales emparejados con una base de
datos de canales de tv para solicitar el cambio de canal a raíz del comando que incluya
el nombre del programa deseado.
● Agregar nuevos dispositivos de entrada.
● Mejorar el reconocimiento de voz para lograr una comunicación más fluida con el
sistema.
● Integrar preferencias de usuario activadas a través de tecnología biométrica.
● Realizar pruebas de desempeño, de los dispositivos y de la plataforma.
● Integrar tecnología móvil a la plataforma.
● Permitir al sistema realizar llamadas de emergencia.
● Controlar dispositivos a través de aplicaciones para celulares inteligentes de forma local
y remota.
● Controlar dispositivos mediante wereables, tal como relojes inteligentes.
● Modularizar la aplicación para permitir la desactivación de sensores fácilmente.
● Permitir controlar dispositivos desde una interfaz web.
● Además del desarrollo técnico del sistema, se prevé el desarrollo de IntelliHome como
producto para llevarlo al mercado.
Referencias bibliográficas
Anastasiou D., Jian C., Zhekova D. "Speech and Gesture Interaction in an Ambient Assisted Living
Lab". Proceedings of the 1st Workshop on Speech and Multimodal Interaction in Assistive
Environments. (2012).
Avizienis A., Laprie J., Randell B., Landwehr C. "Basic Concepts and Taxonomy of Dependable
and Secure Computing". Dependable and Secure Computing, IEEE Transactions,
Volume:1(2004).
Bass L., Clements P., Kazman R. "Software Architecture in Practice, 2nd edition". Addison
Wesley. (2003).
Bishop P., Bloomfield R. "A methodology for safety case development". Industrial perspectives
of safety-critical systems: proceedings of the sisth-critical systems symposium, UK. (1998).
Bishop P., Bloomfield R., Guerra S. "The future of goal-based assurance cases" Northampton
Square London. (2004).
Bolt R. "Put-That-There: Voice and Gesture at the Graphics Interface". Proceedings of the 7th
annual conference on Computer graphics and interactive techniques. (1980).
Cook D., Augusto J., Jakkula V. "Ambient intelligence: Technologies, applications, and
opportunities". Pervasive and Mobile Computing 5 (2009).
Cook A., Miller Polgar J. 2011. Essentials of Assistive Technologies. Elsevier Mosby. St. Louis,
USA.
Cook, A. M., Polgar, J. M., 2015, Assistive Technologies: Principles & Practices, 4th edition, ISBN
978-0323096317
Cruz-Neira C., Sandin D., DeFanti T. "Surround-Screen Projection-Based Virtual Reality: The
Design and Implementation of the CAVE". Proceedings of the 20th annual conference on
Computer graphics and interactive techniques. (1993).
Delić, V., Sečujski, M., Bojanić, M., Knežević, D., Vujnović Sedlar, N., Mak, R. 2013. Aids for the
Disabled Based on Speech Technologies -Case Study for the Serbian Language. 11th
International Conference ETAI, Ohrid, Macedonia, pp. E2-1.1-4.
Fariba, S. "Ambient Intelligence: A Survey". ACM Computing Surveys, Vol. 43. (2011).
Geller T. "Talking to Machines". Communications of the acm. (2012).
IEEE Standard Glossary of Software Engineering Terminology
Kidd C., Orr R., Abowd G., Atkeson C., Essa I., MacIntyre B., Mynnat E., Starnet T, Newsletter W.
“The Aware Home: A Living Laboratory for Ubiquitous Computing Research". Lecture Notes in
Computer Science. (1999).
Kleinberger T., Becker M., Ras E., Holzinger A., Müller P. "Ambient Intelligence in Assisted Living:
Enable Elderly People to Handle Future Interfaces". (2007).
Organización mundial de la salud (OMS). "Reporte mundial de discapacidad". Informe de la
OMS. (2011).
María Montoya V. John Muñoz C. Oscar Henao G, 2015, “Surface EMG based muscle fatigue
detection using a low-cost wearable sensor and amplitude - frequency analysis”
Schömer T., Poppinga B., Henze N., Boll S. “Gesture Recognition with a Wii Controller”.
Proceedings of the 2nd International Conference on Tangible and Embedded Interaction. (2008).
Sharma K., Sryakanthi T., Prasad T. “Exploration of Speech Enabled Systems for English”.
International Conference on System Modeling & Advancement in Research Trends. (2012).
Shrawankar U., Thakare V. 2010. Speech User Interface for Computer Based Education System
Proceedings of the 2010 International Conference on Signal and Image Processing, Quebec,
Canadá, pp. 148 -152.
UNESCO, 2009, Empowering Persons with Disabilities through ICTs, ITU Telecom World,
Geneva, Switzerland
Valdez Gandara C, Sistema de control remoto para dispositivos domésticos a través una interfaz
basada en gestos y sonido, (2014).
Valdez Gándara C, “Una plataforma para el desarrollo de ambientes inteligentes utilizando
sistemas de interfaz natural y hardware de bajo costo”, CIAWI (2015).
Weichert F., Bachmann D., Rudak B., Fisseler D. “Analysis of the accuracy and robustness of the
Leap Motion controller”. (2013).
Weissmann J., Salomon R. “Gesture recognition for virtua reality applications using data gloves
and neural networks”. Proceedings of the International Joint Conference on Neural Networks
(IJCNN). (1999).
Wright, R. A., 2004, Short History of Progress, Anansy Pub, Toronto, ON, Canada.
Agradecimientos
Gracias a quienes me incentivaron, me ayudaron y siempre confiaron en mi. Sin ellos hoy no
estaría aquí, no sería quien soy y no podría llegar a cumplir mis aspiraciones.
En esta sección quiero agradecer a todas aquellas personas que me han acompañado durante
mi carrera, cada una de ellas ha aportado su granito de arena para que yo este acá.
Gracias a lo mejor que tengo en la vida, mi hija quien me toco tener a mi lado durante toda la
carrera.
Gracias a mis padres que me acompañaron en cada paso, con su total apoyo siempre.
A mi hermano, incondicional en cada paso. Mis abuelos y tíos que siempre me incentivaron a
ser más.
A Oscar Romera por su apoyo incondicional, y su aguante en las noches de desvelo.
A Carolina, mi co-directora y amiga, quien me incentivo y ayudo en todo el proceso, quien
considero una hermana de la vida.
A Alejandro Perez, gran compañero de proyecto, sin el IntelliHome no sería lo que es hoy.
A mi director Cristian García Bauza por todos los consejos y las oportunidades brindadas.
A mis amigos: Tamara Ferenc, Natalia Stele, Christian Villavicencio, Melisa Millan, Cesar Perez,
Martin Ditz, Santiago Carlinsky, Maximiliano Cassola, Juan Rodriguez, Ariel Borthiri, Facundo
Martin, Florencia Andres, Roberta Galeota, Lucia de Lorenzo, Mercedes Alvarez Estrada, Paula
Kolbl.
A mis compañeros de carrera.
A todos los que han aportado a IntelliHome en este último año para que sea más que un
proyecto de tesis.