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
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.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.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.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
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.
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.
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 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.
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.
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.
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 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)
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:
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
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
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.
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:
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.
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.
2.9 Intellihome
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
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.
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)
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.
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.
● “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
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>
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.
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.
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.
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.
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”.
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)
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.
● 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
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:
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.
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
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.
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.
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
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
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.
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
Figura 3.18 - Jerarquía de clases de reconocedores de los componentes Iniciar reconocimiento de gestos e iniciar reconocimiento de voz.
Figura 3.19 - Plano de ejemplo de la Interfaz de usuario de la vivienda asistida por
computadora.
Iniciar reconocedor de dispositivos remotos
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
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.
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.
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.
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,
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.
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.
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.
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.
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.
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.
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
● 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
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.
● 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.
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.
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
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.
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
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:
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.
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.
● 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.
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
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.
