Upload
others
View
3
Download
0
Embed Size (px)
Citation preview
UNIVERSIDAD DE MURCIA
INGENIERÍA EN INFORMÁTICAPROYECTO FIN DE CARRERA
Dispositivo inteligente de alerta domiciliaria. Tecnologías de la Web Semántica para aplicaciones
sensibles al contexto.
Autor: Ana Villa Caballero
Directores: José Tomás Palma MéndezJuan Botía Blaya
Facultad de Informática Febrero 2009
Índice General 1 Introducción......................................................................................................................................4
1.1 Marco del Proyecto....................................................................................................................4 1.2 Alcance y Objetivos..................................................................................................................5 1.3 Estructura del Trabajo...............................................................................................................6
2 Estado del Arte ................................................................................................................................7 3 Tecnologías utilizadas.....................................................................................................................11
3.1 JAVA........................................................................................................................................11 3.2 Ontologías...............................................................................................................................11
3.2.1 OWL................................................................................................................................12 3.2.2 SWRL..............................................................................................................................13 3.2.3 Protégé.............................................................................................................................15 3.2.4 JENA...............................................................................................................................15 3.2.5 ORE.................................................................................................................................16
3.3 MySQL....................................................................................................................................17 4 Análisis y casos de uso...................................................................................................................19
4.1 Plan de Trabajo........................................................................................................................19 4.2 Metodología............................................................................................................................20
4.2.1 Ingeniería del Software....................................................................................................20 4.2.1.1 Análisis de Requisitos..............................................................................................21 4.2.1.2 Casos de Uso............................................................................................................23
5 Diseño de la aplicación...................................................................................................................28 5.1 Arquitectura de tres capas.......................................................................................................28 5.2 Ontología: Nexo entre capas...................................................................................................31
5.2.1 Timers en la Ontología....................................................................................................36 5.2.2 Atendido: estado actual e intermedio..............................................................................38
5.3 Capa Inferior: OCP.................................................................................................................39 5.4 Capa intermedia: Razonamiento Autómata..........................................................................43
5.4.1 Estados.............................................................................................................................43 5.4.2 Reglas SWLR e Inferencia .............................................................................................50
5.5 Capa superior: MetaRazonador...............................................................................................51 5.5.1 Resolución de inconsistencias.........................................................................................51
5.5.1.1 Tipos de Inconsistencias...........................................................................................54 5.5.1.1.1 ActividadInactividad.......................................................................................54 5.5.1.1.2 ActividadActividad..........................................................................................54 5.5.1.1.3 InactividadDormido/Descansando..................................................................55 5.5.1.1.4 ActividadIntruso..............................................................................................55
5.5.2 Actuación .......................................................................................................................56 5.5.3 Razonamiento Complejo.................................................................................................56
5.6 Salida del Sistema...................................................................................................................57 5.6.1 Logs por Capas................................................................................................................57 5.6.2 Interfaz gráfica................................................................................................................59
6 A. Herramientas Auxiliares Desarrolladas.....................................................................................61 6.1 Instalación y Despliege: ProdiaConfigurator..........................................................................61 6.2 Simulación: ProdiaSimulator.................................................................................................62
6.2.1 Fichero de Simulación.....................................................................................................62
2/86
6.3 Data Mining y Validación: ProdiaMonitor.............................................................................65 6.3.1 Visualización de resultados mediante gráficas................................................................65
6.3.1.1 Búsqueda de estados................................................................................................66 6.3.2 Filtrado de Datos.............................................................................................................67 6.3.3 Estadísticas de Localización dependiendo del Momento del Día...................................67 6.3.4 Estudio de Timers para Adaptación................................................................................69 6.3.5 Datos .arff para Weka......................................................................................................70
7 Validación del Sistema....................................................................................................................72 7.1 Pruebas de Validación ............................................................................................................72
7.1.1 Infraestructura..................................................................................................................72 7.1.2 Preparación del Sistema...................................................................................................74 7.1.3 Casos de prueba...............................................................................................................74
7.1.3.1 Caso 1: Movimiento y Caída ...................................................................................75 7.1.3.2 Caso 2. Ausencia y estado de descanso....................................................................76 7.1.3.3 Caso 3. Presión en cama y caída..............................................................................78
8 Conclusiones y trabajos futuros......................................................................................................81 9 Bibliografía.....................................................................................................................................83
3/86
Índice de ilustracionesIlustración 1: Interfaz ORE.................................................................................................................18Ilustración 2: Diagrama de Gantt 1.....................................................................................................21Ilustración 3: Diagrama de Gantt 2.....................................................................................................21Ilustración 4: Casos de Uso................................................................................................................25Ilustración 5: Estructura de 3 capas....................................................................................................30Ilustración 6: Árbol de la ontología....................................................................................................35Ilustración 7: Diagrama simplificado de términos..............................................................................36Ilustración 8: Diagrama de ontología OCP.........................................................................................41Ilustración 9: Transformación de bytes percibidos a conocimiento....................................................41Ilustración 10: OCP y su Comunicación con el exterior....................................................................43Ilustración 11: Autómata Finito Determinista....................................................................................49Ilustración 12: Transición entre estados Active y Absentee...............................................................50Ilustración 13: Resolución de múltiples inconsistencias....................................................................54Ilustración 14: Salida del sistema por capas.......................................................................................58Ilustración 15: Interfaz gráfica de Prodia...........................................................................................60Ilustración 16: Interfaz ProdiaConfigurator........................................................................................61Ilustración 17: Ejemplo de fichero de simulación...............................................................................64Ilustración 18: Interfaz ProdiaMonitor...............................................................................................65Ilustración 19: Gráficos de las 3 capas...............................................................................................66Ilustración 20: Búsqueda de estados en Gráficos...............................................................................66Ilustración 21: Filtrado de Gráficos....................................................................................................67Ilustración 22: Estadísticas de localización........................................................................................68Ilustración 23: Estadísticas de localización por momento del día......................................................68Ilustración 24: Gráficas de timers ......................................................................................................70Ilustración 25: Estructura de comunicaciones para pruebas...............................................................72Ilustración 26: Pruebas realizadas en la primera casa........................................................................72
4/86
1 INTRODUCCIÓN
1.1 MARCO DEL PROYECTO
En la última década, debido al aumento de la esperanza de vida, ha habido un gran incremento del número de personas de avanzada edad que viven solas en casa. Estas desean conservar su total independencia y en la mayoría de casos creen que su estado de independencia no conlleva ningún riesgo, negando cualquier asistencia del exterior. Sin embargo, son tristemente frecuentes las noticias de ancianos que fallecen en soledad y que son encontrados en casa varios días después de su muerte. Personas de avanzada edad que viven en soledad y que en muchos casos sólo reciben visitas una o dos veces por semana.
Teniendo esta tendencia en mente se propone crear un sistema inteligente no intrusivo que sea capaz de detectar una situación de emergencia y dar la voz de alarma para que se asista al anciano si es necesario.
Para poder detectar una posible situación de emergencia será necesario tener algún conocimiento de lo que está sucediendo en la casa en cada momento. La percepción de la realidad de la casa no debe de interferir en ningún momento con la intimidad del atendido, por ello se elimina desde el principio la opción de utilizar videocámaras. Nos bastará con “sentir” la presencia del atendido en casa.
Un punto clave del proyecto es que debe ser no intrusivo, el atendido debe poder hacer su vida cotidiana sin sentirse obstaculizado por la presencia del sistema de asistencia en casa. Por ello el sistema huirá de los dispositivos “wearables” y se construirá a partir de una red de sensores inalámbricos desplegados en la casa.
Después de estudiar la gama de dispositivos sensores que existen en el mercado y pensando en la percepción de la realidad que nos podían aportar cada uno de ellos se decide incluir 3 tipos diferentes de sensores: movimiento, presión y apertura de puerta. Se decide estos tres ya que el de movimiento nos informará del grado de actividad que hay en la casa y se podrá inferir la localización del atendido, con la presión podremos detectar cuando se encuentra acostado o sentado en su sillón preferido y con la apertura de puerta podremos detectar cuando está fuera de casa y por tanto no es necesario que se activen alarmas.
Los dispositivos sensores elegidos y un pequeño PC que realizará el tratamiento inteligente de la información de estos dispositivos debe ser suficiente para mantener asistido al anciano en su casa.
El proyecto ha sido desarrollado en el marco de dos contratos de investigación entre la Universidad de Murcia y la empresa AMI2:
• SISTEMA INTELIGENTE PARA EL RAZONAMIENTO Y ACTUACIÓN SOBRE PATRONES DE COMPORTAMIENTO DETECTADOS A PARTIR DE SENSORES, cuyo Investigador principal es el profesor D. José Tomás Palma Méndez
• MUSU: SISTEMA DE REPROSITARIO DE PATRONES DE USO. Con investigador principal el profesor D. Juan Botía Blaya
5/86
1.2 ALCANCE Y OBJETIVOS
El objetivo principal del proyecto radica en el desarrollo de un sistema inteligente no intrusivo para la vigilancia en el hogar de personas mayores que viven solas. El sistema debe ser capaz de alertar de posibles situaciones de riesgo (caídas, desfallecimientos, ..) que supongan una situación potencial de riesgo. Este objetivo se puede descomponer en los siguiente subobjetivos:
1. Diseño de una arquitectura software modular y abierta que permita el desarrollo del sistema anteriormente diseñado, además de la integración entre Hardware y software.
2. Diseño e implementación de una capa sensible al contexto que permita la caracterización del mismo, así como el desarrollo de procesos de inferencia.
3. Diseño e implementación de herramientas de apoyo para (1) realizar procesos de verificación de la correcta ejecución del sistema y (2) analizar la actividad del atendido a largo plazo
4. Integrar los módulos desarrollados con el resto de los módulos relacionados con la red de sensores.
5. Definir y ejecutar un plan de validación que permita comprobar la funcionalidad del sistema desarrollado.
No es objetivo de este proyecto el desarrollo de la red de sensores, así como la capa software que recibe la información directamente de los sensores. Es decir, el presente proyecto parte de una representación de alto nivel de la lectura de los sensores, aunque gran parte de las decisiones de diseño que aquí se van a tomar van a afectar a los mecanismos que se diseñen para interaccionar con la red de sensores.
6/86
1.3 ESTRUCTURA DEL TRABAJO
Este documento está estructura de la siguiente manera: en la sección 2 podremos ver un resumen del estudio realizado sobre el estado del arte de la temática de este proyecto.
En la siguiente sección se dará un repaso a todas las tecnologías utilizadas para el desarrollo de este trabajo, se explicarán brevemente cada una de ellas. En la cuarta sección veremos el plan de trabajo que se ha llevado a cabo y la metodología que se ha seguido para guiar el desarrollo.
La sección 5 definirá en detalle la estructura software en que se apoya este proyecto, inicialmente se realizará un repaso general de toda la estructura y después se irá definiendo una a una cada una de las partes de la estructura.
En la sección 6 se incluye una descripción de las herramientas auxiliares que se han desarrollado como apoyo al software principal de este proyecto.
La sección 7 detalla el plan de pruebas y validación en casas reales que se ha llevado a cabo. Se define desde la infraestructura necesaria para la realización de esas prueba hasta las historias a reproducir en los entornos reales. Ademas se indica con detalle la reacción que el sistema debería proporcionarnos al realizar dichas prueba.
Por ultimo se incluye una sección de conclusiones y trabajos futuros en la que también se definen las contribuciones académicas que ha generado el desarrollo de este proyecto.
7/86
2 ESTADO DEL ARTE En el contexto de la asistencia de personas independientes en el entorno del hogar, hoy en día los trabajos están orientados a favorecer la independencia de dichas personas, reduciendo los costes asociados con la hospitalización y mantenimiento de centros de día [Krose et al. 2008]. A medida que la tecnología va evolucionando, este tipo de aplicaciones tiende a integrar tecnologías propias de la inteligencia ambiental [Ducatel et.al 2001; Aarts, Encarnasao, 2005; Witchert, 2008] que permitan integrar la información contextual, a partir de la información procedente de los sensores no intrusivos, con información procedente de sensores biomédicos, en entornos de computación ubicua.
Teniendo en cuenta uno de los objetivos de este proyecto, se pretende desarrollar una aplicación ubicua, que en función de la información procedente de un conjunto de sensores mínimamente intrusivos, pueda detectar de forma autónoma estados potencialmente peligrosos (caídas, desvanecimientos,...). Para el desarrollo de este tipo de aplicaciones, se requiere una adecuada percepción del entorno en que se desenvuelve el usuario, es decir, su localización espaciotemporal e información sobre el entorno físico [Khriyenko y Terziyan, 2005]. Por lo tanto, la detección y representación del contexto es clave para este tipo de aplicaciones, así como su evolución. Esto implica que el marco para la representación del contexto debe ser: abierto, es decir, independiente de la aplicación y la arquitectura, con lo cual se puede compartir entre aplicaciones [Coutaz et al, 2005]; y dinámica, en el sentido de que permita la incorporación de nuevos dispositivos y, por consiguiente, la representación de nueva información de contexto [Euzenat J. et al, 2008].
En la mayoría de los casos que podemos encontrar en la literatura de trabajos similares [Krose et al. 2008], no se trabaja con el concepto de contexto en genérico [Intille, Larson 2005, Mynatt et al. 2004]. Se asume que es necesario el reconocimiento de contexto y de ahí, se pasa directamente a caracterizar el tipo de actividad [Krose et al. 2008]. Sin embargo, el contexto es algo más complejo [Marscholleck, 2007] ya que puede incluir informaciones como la localización, características biométricas, características dinámicas del entorno, etc [Botazzi, 2006, Caceres, 2006,Euzenat J. et al, 2008], además de ser relativo a una situación particular [Dourish, 2001; Chalmers, 2004]. Es más, hay aplicaciones en las que el contexto es considerado como un conjunto de informaciones altamente estructurado, no teniendo sólo en cuenta al atendido, sino a otros roles dentro del sistema (e.g. asistentes, enfermeros, ..) [Botazzi,2006]. Sin embargo, la información contextual no se gestiona de tal forma que se le pueda sacar todo el partido, teniendo en cuenta todas las tecnologías de las que disponemos en la actualidad.
En otros tipos de sistemas de computación ubica sí se hace esto, incluso en entornos domóticos [Wang, 2004; Zhang et al. 2006]. Hay gran cantidad de trabajos que las ontologías constituyen una herramienta potente para la representación del contexto ya que su uso no requiere una correspondencia exacta entre la información disponible y la requerida [Chen el al., 2004a; 2004b; Flury et al., 2004; Gu et al., 2004; 2005; Coutaz et al., 2005; Nieto et al., 2006; Heckmann, 2007, Klein, 2007], además de posibilitar la utilización de las tecnologías desarrolladas para la web semántica. Aunque no existen estándares para el desarrollo de aplicaciones dependientes del contexto, si existen algunos esfuerzos en esta línea como CDF [Khriyenko and Terziyan, 2005] o COWL [Bouquet et al., 2003], además de propuestas de ontologías genéricas para este tipo de
8/86
aplicaciones [Flury et al., 2004; Gadon and Sadeh; 2004; Fu et al., 2005, Ngoc et al., 2005].
Todas estas consideraciones tecnológicas se están plasmando de alguno manera en los proyectos que están en desarrollo. Las diferencias entre los sistemas surgen en el modo de detección de alertas y el seguimiento más o menos profundo del atendido. A continuación comentaremos algunos de estos sistemas, así como sus características, además de las fortalezas o desventajas respecto a nuestro sistema .
La Universidad de Virginia está desarrollando el proyecto AlarmNet (AssistedLiving And Residential Monitoring Network) [A. Wood. Et al., 2006]. Este proyecto se apoya en una red de sensores wireless que combina sensores no intrusivos incluidos en el hogar, con sensores "wearables" que mantienen al atendido monitorizado en todo momento.
Estos últimos sensores son capaces de detectar cambios en la frecuencia cardíaca, niveles de oxigeno en sangre,... Los datos recogidos de la red inalámbrica de sensores se pueden almacenar e integrar en un amplio historial médico para cada paciente, permitiendo a los médicos tener mucha más información sobre la que fundamentar sus diagnósticos Finalmente, el análisis, diagnóstico y tratamiento también puede ser semiautomatizado, por lo que el médico puede ser asistido por un médico electrónico.
Uno de los aspectos más destacables de este proyecto radica en la utilización de los ciclos circadianos [G. Virone. Et al., 2002] para aprender patrones de comportamiento del atendido y poder inferir a partir de estos, cambios drásticos en sus hábitos que se puedan derivar en una posible emergencia.
En este sistema se apuesta por sensores wearables, que como hemos visto, son capaces de proporcionar información médica importante sobre paciente. Sin embargo, esto nos lleva a un control quizás demasiado exhaustivo y algo intrusivo, ya que estamos obligando al paciente a llevar los sensores en su propio cuerpo.
Nuestro proyecto huye, en principio, de ese tipo de sensores, ya que pretende ser transparente al usuario sin modificar lo más mínimo sus hábitos diarios.
En cuanto al uso de patrones de comportamiento, nuestro sistema también los utiliza de alguna manera.. Como se ha comentado, en la primera fase del desarrollo del sistema, se pretende inferir situaciones de alerta a partir de un patrón de comportamiento genérico, que puede utilizarse con cualquier individuo. En la próxima fase del proyecto, se diseñarán mecanismos que permitan al sistema aprender los patrones de comportamiento específicos de cada individuo..De esta forma se pretende reducir el número de falsos positivos.
La compañía Intel también está trabajando en este campo junto con los investigadores de la Oregon Health & Science University, la Universidad de Washington, y la Universidad de Michigan en la elaboración del sistema inteligente AgeinPlace Advanced SmartHome [Intel Research. AgeinPlace Advanced SmartHome]. Este sistema se ha diseñado para ser capaz de captar las actividades diarias y habituales que realiza un individuo. Este proyecto se basa en la incorporación de sensores RFID en objetos de uso cotidiano, cepillo de dientes, gafas, tarro de pastillas, microondas... De esta manera se lleva un seguimiento exhaustivo de las actividades que realiza el usuario, para que el sistema se a capaz de detectar desde olvidos en la toma de medicamentos, hasta los primeros
9/86
síntomas de la aparición de Alzheimer a partir de la comprobación de sus actividades cotidianas. Como se puede apreciar, este proyecto se centra en la enfermedad de Alzheimer ya que, además de su detección temprana, el sistema será capaz de recordar al usuario dónde se encuentran los objetos marcados con sensores RFID, a partir de un simple comando de voz.A diferencia de este último proyecto, nuestro sistema se basa en los patrones de comportamiento detectados a partir del movimiento y la localización del atendido en cada momento. De estos patrones, sin llegar a recoger de manera explícita las acciones del atendido, el sistema es capaz de inferir la realización o no de ciertas actividades cotidianas. Por ejemplo, la estancia en el baño a una hora temprana de la mañana y durante un periodo de tiempo determinado nos indica que el atendido se está aseando. El no pasar por la cocina en el periodo del día que comprende la hora de comer, nos indica que existe la posibilidad de que el atendido no haya comido y, por lo tanto, podría tratarse de una situación anormal.
Otro proyecto interesante es el titulado Assisted Living Proyect, en el que participan la Universidad de Illions, la Universidad de OHIO y la Universidad de NorthWestern [Jennifer Hou et al, 2007]. Este proyecto se basa en la creación de un entorno de vida asistida a partir de una red de dispositivos pequeños, de bajo coste y baja potencia. Entre los dispositivos utilizados encontramos lectores y etiquetas RFID y una gran variedad de sensores y actuadores. Todos estos dispositivos disponen de capacidad de comunicación inalámbrica. Este sistema se ha diseñado para que, en caso de que fuese necesario, avisará al atendido de que tiene que tomar un determinado medicamento. Este tipo de avisos se podrán realizar, por ejemplo, desde el televisor si el atendido lo está viendo en ese momento, realizando un cambio automático de canal y visualizando en este el aviso correspondiente. Además, el sistema está preparado para incorporar wearables que mantengan monitorizadas las constantes vitales del atendido. Por otro lado, también es capaz de detectar ciertas situaciones de emergencia basándose en la localización del usuario en todo momento, siendo esto posible gracias a la utilización de sensores no intrusivos.
Este proyecto intenta combinar las tecnologías vistas en los dos proyectos anteriores, para realizar desde un seguimiento de las constantes vitales mediante sensores werables, hasta la recolección de actividades diarias a partir de etiquetas RFID. Aún así, parece no centrarse en ninguna de sus tecnologías de detección y simplemente intentar abarcar todas ellas.
La inclusión de otros tipos de sensores, por ejemplo aquellos que nos dan información sobre las constantes vitales del paciente, sería algo trivial en nuestro sistema. El desarrollo y despliegue de nuestra red de sensores actual y su comunicación con la estación base, que recoge y analiza toda esta información, hace que el añadir sensores RFID o werables no tenga complicación alguna. De esta forma, nuestro sistema queda abierto a la incorporación de nuevos dispositivos de detección que permitan su adaptación a un determinado tipo de pacientes.
El proyecto Smart inhome Monitoring System at University of Virginia [University of Virginia, Smart inHome Monitoring System] se basa en la recolección de datos a partir de de sensores de bajo coste instalados en el hogar del atendido. El proyecto se centrar en la monitorización de actividades diarias para detectar patrones de comportamiento del paciente y tratar de descubrir cambios en sus actividades que indiquen algún tipo de anomalía. Es decir, el sistema no está concebido para detectar situaciones de emergencia que ocurran de forma inesperada en el hogar, si
10/86
no para un estudio a largo plazo que nos haga prever la aparición de posibles enfermedades.
Al igual que en nuestro proyecto, la la detección de situaciones de emergencia se apoya en la utilización de un sistema basado en reglas [Siddharth Dalal et al, 2005]. La diferencia clara con nuestro proyecto es que nosotros sí que nos centramos en la detección y rápida intervención ante cualquier signo de que algo va mal. Nos interesamos por las situaciones inesperadas de emergencia, dejaremos para próximas versiones del producto el tratamiento de los patrones de comportamiento de usuario a largo plazo que, como hemos comentando, nos servirán para la personalización del sistema y detección de anomalías en el comportamiento.
La universidad de Georgia Tech ha desarrollado el proyecto Aware Home [Kidd, Cory D., 1999]. Este proyecto se plasmó en un prototipo de entorno inteligente que es capaz de recopilar toda la información contextual asociada a las actividades diarias en el hogar, por medio de la computación ubicua en las. La idea básica del proyecto consiste en la creación de una casa prototipo hace posible que se vayan probando distintas formas de detección de las actividades diarias en un hogar. Para ello se utilizan técnicas que van desde la monitorización basada en mecanismos de visión o seguimiento acústico, hasta la utilización de baldosas especiales que nos indicarían la localización de una persona en la casa. Aunque se trata de un estudio piloto sobre distintas formas de recoger información contextual en el hogar, se hace cierto hincapié en personas mayores. Por ejemplo, se habla de la localización de objetos para las personas que sufran Alzheimer, funcionalidad que ya hemos visto en proyectos anteriores.
11/86
3 TECNOLOGÍAS UTILIZADAS
3.1 JAVAJava es un lenguaje de programación orientado a objetos desarrollado por Sun MicroSystems a principios de los años 90. El lenguaje en sí mismo toma mucha de su sintaxis de C y C++, pero tiene un modelo de objetos más simple y elimina herramientas de bajo nivel, que suelen inducir a muchos errores, como la manipulación directa de punteros o memoria.
La promesa inicial de JAVA era Write Once, Run Anywhere (Escríbelo una vez, ejecútalo en cualquier lugar), proporcionando un lenguaje independiente de la plataforma y un entorno de ejecución (la JVM) ligero y gratuito para las plataformas más populares de forma que los binarios (bytecode) de las aplicaciones Java pudiesen ejecutarse en cualquier plataforma.
El entorno de ejecución era relativamente seguro y los principales navegadores web pronto incorporaron la posibilidad de ejecutar applets Java incrustadas en las páginas web.
El lenguaje Java se creó con cinco objetivos principales:
1. Debería usar la metodología de la programación orientada a objetos. 2. Debería permitir la ejecución de un mismo programa en múltiples sistemas operativos. 3. Debería incluir por defecto soporte para trabajo en red. 4. Debería diseñarse para ejecutar código en sistemas remotos de forma segura. 5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos, como C+
+.
En este proyecto se ha optado por este tecnología porque dispone de APIs para el manejo de ontologías (como JENA que se verá más adelante), nos proporciona software multiplataforma y la robustez que se necesita en un proyecto como este.
3.2 ONTOLOGÍAS
Una ontología es una herramienta conceptual que define un vocabulario común para quien necesita compartir información dentro de un determinado dominio. Esto incluye definiciones de los conceptos básicos del dominio, así como sus relaciones, que tienen que ser interpretables por máquinas.
El término ontología, dentro del ámbito de la inteligencia artificial, ha recibido múltiples definiciones. Hoy en día, no hay una definición consensuada de este término. La definición proporcionada por Grubber en 1993 es una de las más extendidas: "Una ontología es una especificación explícita de una conceptualización. El término proviene de la filosofía, donde una ontología es un recuento sistemático de la existencia. En sistemas de Inteligencia Artificial, lo que existe es lo que puede ser representado."
En base a esta definición, una ontología se puede entender como una estructura de representación
12/86
formal de conocimiento que contiene los conceptos más relevantes dentro de un dominio determinado. Además, las ontologías definen el significado de las anotaciones, los términos nuevos pueden formarse a partir de otros anteriores, el significado se define formalmente y pueden especificarse relaciones entre términos de varias Ontologías .
3.2.1 OWL
OWL (Web Ontology Language) o Lenguaje de Ontologías para la Web, se convirtió en recomendación del W3C el 10 de febrero de 2004 [http://www.w3.org/TR/owlref/]. La web: OWL Web Ontology Language Overview [http://www.w3.org/TR/owlfeatures/] ofrece una explicación detallada de en qué consiste este lenguaje, para qué se usa y cuáles son los conceptos fundamentales empleados por dicho lenguaje.
OWL, como su nombre indica, es el lenguaje definitivo para la creación de ontologías e intercambio de contenidos semánticos a través de la web, y será utilizado con este fin a lo largo de nuestro proyecto. Está diseñado para usarse cuando la información contenida en los documentos necesita ser procesada por programas o aplicaciones, en oposición a situaciones donde el contenido solamente necesita ser presentado a los seres humanos.
OWL puede usarse para representar explícitamente el significado de términos en vocabularios y las relaciones entre aquellos términos. OWL constituye una ampliación del vocabulario de RDF con la diferencia de que su potencia expresiva es muy superior, lo que le hace totalmente apropiado para representar, con la complejidad necesaria, el conocimiento asociado a cualquier dominio.
Así pues, OWL nos permite estructurar los recursos en clases o conceptos y describir instancias o individuos de estas clases. También diferencia entre propiedades cuyo rango es un tipo de datos básico (DataTypeProperty) y propiedades cuyo rango es un objeto (ObjectProperty), siendo posible restringir la extensión de estos rangos. Incluso permite establecer la equivalencia o diferenciación entre clases, propiedades e individuos. Y, al extender a RDF Schema, puede utilizar también las construcciones de éste para definir relaciones jerárquicas entre clases y propiedades.
OWL constituye una ampliación del vocabulario de RDF, por lo que algunos de sus concepto principales derivan de éste. Así, podemos definir Class como una clase que define un grupo de individuos que permanecen juntos porque comparten las mismas propiedades. Por ejemplo, Juana y Pedro son ambos miembros de la clase Persona. Las clases pueden ser organizadas en una jerarquía especial, usando subClassOf. Hay una construcción de clase más general llamada Thing que es la clase de todos los individuos y una superclase de todas las clases OWL. Existe, también, una construcción más específica de clase llamada Nothing que es la clase que no tiene instancias y unasubclase de todas las clases OWL.
Las jerarquías de clase deben crearse para hacer una o más declaraciones de que una clase es una subclase de otra clase. Por ejemplo, la clase Persona podría ser establecida para ser una subclase de la clase Mamífero. Desde aquí un razonador puede deducir que si un individuo es una Persona, entonces es también un Mamífero. Para esto utilizamos la estructura rdfs:subClassOf.
Hay dos tipos de propiedades: las que pueden usarse para expresar relaciones entre individuos (relaciones) y las que pueden usarse para expresar relaciones desde individuos a valores de datos (atributos). Ejemplos de estos dos tipos de propiedades son hasChild y hasAge. La primera puede
13/86
usarse para relacionar una instancia de una clase Person a otra instancia de la clase Person (mediante una ObjectProperty). La segunda (hasAge) puede usarse para relacionar una instancia de la clase Persona a una instancia del tipo de datos Entero (mediante una DataTypeProperty). Tanto owl:ObjectProperty como owl:DatatypeProperty son subclases de la clase RDF rdf:Property.
Ambos tipos de propiedades definen un dominio y un rango. Un dominio de una propiedad limita los individuos a los que se aplica la propiedad. Si una propiedad relaciona un individuo a otro individuo y la propiedad tiene una clase como uno de sus dominios, entonces el individuo debe pertenecer a la clase. Por ejemplo, la propiedad hasChild debe ser establecida para tener el dominio de Mamífero. Desde aquí, un razonador puede deducir que si Pedro hasChild Ana, entonces Pedro debe ser un Mamífero.
Un dominio, rdfs:domain, se denomina una restricción global, ya que la restricción está establecida sobre la propiedad y no sobre la instancia en particular. El rango de una propiedad limita los individuos que la propiedad debe tener como su valor. Si una propiedad relaciona un individuo a otro individuo y la propiedad tiene una clase como su rango, entonces el otro individuo debe pertenecer a la clase del rango. Por ejemplo, la propiedad hasChild debe ser establecida para tener el rango de Mamífero. Desde aquí, un razonador puede deducir que si Luisa está relacionado con Juana por la propiedad hasChild, (por ejemplo, Juana es la hija de Luisa), entonces Juana es un Mamífero. El rango, rdfs:range, es también una restricción global como lo era el dominio.
Las ObjectProperties relacionan individuos entre sí. Un individuo, Individual, es la instancia de una clase. Siguiendo con el ejemplo anterior, Juana será una instancia de la clase Person.
3.2.2 SWRL
SWRL está basado en una combinación de OWL DL y OWL Lite (sublenguajes de OWL) y RuleML. SWRL define una sintaxis de nivel superior para incluir reglas en OWL.
Las reglas propuestas se definen como la relación entre un antecedente (body) y su consecuente (head). El significado de las mismas se puede leer como: cuando las condiciones del antecedente se cumplen a continuación se deben cumplir las condiciones del consecuente.
Tanto el antecedente con el consecuente consisten de cero o más atoms. Un antecedente vacío se trata como un antecedente que siempre se cumple, por lo que el consecuente se debe cumplir para todos los casos. Sin embargo un consecuente vacío se trata como que no es cumplido en ningún caso por lo que el antecedente no debe satisfacerse en ningún caso. Los atoms de las reglas pueden ser: C(x), P(x,y), sameAs(x,y) or differentFrom(x,y), donde C es una descripción OWL, P es una propiedad OWL y x e y son variables diferentes.
Las reglas estarán formadas a partir de una secuencia de hechos y axiomas.Un axioma de una regla consiste en un antecedente y un consecuente, cada uno de los cuales consta de un conjunto de atoms (con la posibilidad de que sea vacío). Podremos asignarle una URI para cada axioma que nos servirá para identificar las reglas.
14/86
La sintaxis abstracta tendría la siguiente forma:rule ::= 'Implies(' [ URIreference ] { annotation } antecedent consequent ')'antecedent ::= 'Antecedent(' { atom } ')'consequent ::= 'Consequent(' { atom } ')'
atom ::= description '(' iobject ')' | dataRange '(' dobject ')' | individualvaluedPropertyID '(' iobject iobject ')' | datavaluedPropertyID '(' iobject dobject ')' | sameAs '(' iobject iobject ')' | differentFrom '(' iobject iobject ')' | builtIn '(' builtinID { dobject } ')'
builtinID ::= URIreference
Un ejemplo de regla sería utilizar la combinación de las propiedades hasParent y hasBorther para definir hasUncle:
hasParent(?x1,?x2) ∧ hasBrother(?x2,?x3) ⇒ hasUncle(?x1,?x3)
En la sintaxis vista anteriormente tendríamos:Implies(Antecedent(hasParent(Ivariable(x1) Ivariable(x2))
hasBrother(Ivariable(x2) Ivariable(x3)))Consequent(hasUncle(Ivariable(x1) Ivariable(x3))))
A partir de la sintaxis abstracta vista se define la sintaxis concreta en XML, esto nos dará la posibilidad de mezclar ontologías y reglas y simplificar la interoperabilidad entre OWL y RuleMF.
El Schema XML para SWRL XML Concrete Syntax es swrlx.xsd. Este es una copia del Schema de OWL XML al que se le han añadido características para soportar RuleMF. Utiliza los siguientes namespaces:
http://www.w3.org/2003/11/swrlx , http://www.w3.org/2003/11/rulemlhttp://www.w3.org/2003/05/owlxml http://www.w3.org/2001/XMLSchema.
La sintaxis es la siguiente:
<swrlx:Ontology swrlx:name = xsd:anyURI > Content: (owlx:VersionInfo | owlx:PriorVersion | owlx:BackwardCompatibleWith | owlx:IncompatibleWith | owlx:Imports | owlx:Annotation | owlx:Class[axiom] | owlx:EnumeratedClass(D,F) | owlx:SubClassOf(D,F) | owlx:EquivalentClasses | owlx:DisjointClasses(D,F) | owlx:DatatypeProperty | owlx:ObjectProperty | owlx:SubPropertyOf | owlx:EquivalentProperties | owlx:Individual[axiom] | owlx:SameIndividual | owlx:DifferentIndividuals | ruleml:imp[axiom] | ruleml:var[axiom])* </swrlx:Ontology>
El ejemplo visto anteriormente traducido a la sintaxis concreta quedaría de la siguiente forma:
<ruleml:imp> <ruleml:_rlab ruleml:href="#example1"/> <ruleml:_body> <swrlx:individualPropertyAtom swrlx:property="hasParent">
15/86
<ruleml:var>x1</ruleml:var> <ruleml:var>x2</ruleml:var> </swrlx:individualPropertyAtom> <swrlx:individualPropertyAtom swrlx:property="hasBrother"> <ruleml:var>x2</ruleml:var> <ruleml:var>x3</ruleml:var> </swrlx:individualPropertyAtom> </ruleml:_body> <ruleml:_head> <swrlx:individualPropertyAtom swrlx:property="hasUncle"> <ruleml:var>x1</ruleml:var> <ruleml:var>x3</ruleml:var> </swrlx:individualPropertyAtom> </ruleml:_head> </ruleml:imp>
En el ejemplo vemos que tenemos el body que se corresponde con el antecedente ( hasParent and HasBrother el head que se corresponde con el consecuente (hasUncle).
Para la definición de reglas SWRL utilizaremos un software gráfico ORE (veremos más adelante) que nos abstraerá de la representación textual de estas reglas.
3.2.3 PROTÉGÉ
Protégé (http://protege.stanford.edu/) es una plataforma de software libre de la Universidad de Stanford que ofrece un conjunto de herramientas para construir modelos de dominios y aplicaciones basadas en el conocimiento con ontologías. En su núcleo, Protégé implementa un rico conjunto de estructuras de modelado del conocimiento y permite la creación, visualización y manipulación de ontologías en varios formatos de representación. Protégé puede ser personalizado según las características de un determinado dominio, y puede ser extendido mediante una arquitectura modular y una API en Java para construir herramientas y aplicaciones basadas en el conocimiento.
En este proyecto se ha utilizado este software creación y edición de la ontologías que representará nuestro contexto y que será la base del razonamiento.
3.2.4 JENA
JENA, (http://jena.sourceforge.net/), es una plataforma de software libre desarrollada por HB Labs para la creación de aplicaciones de Web Semántica que ofrece un buen número de herramientas con ese objetivo. Entre ellas destaca, por su utilidad para nuestro proyecto, una API para Java que permite trabajar con ontologías en OWL y RDF Schema con una potencia que cubre todos los aspectos del OWL Full, haciendo posible incluso utilizar algoritmos de inferencia, sin perder robustez en ningún momento.
Es por ello que sobresale por encima de otras APIs que tienen el mismo objetivo y que consideramos como opciones a la hora de realizar la implementación, pero que descartamos por su clara inferioridad frente a JENA, tal como ocurre con el caso de OWL API.
Su corazón es la API RDF, la cual soporta la creación, manipulación y consulta de grafos RDF. La API también soporta diferentes tecnologías de almacenamiento y permite lectura y escritura automática para diferentes lenguajes que los desarrolladores pueden usar para representar grafos RDF.
16/86
Esta API proporciona clases java para representar modelos y manipularlos: creación, escritura y lectura, carga en memoria, navegar un modelo a partir de la URI de un recurso, consultar el modelo (se podrá buscar información del modelo y realizar consultas avanzadas), operaciones sobre modelos (unión, intersección y diferencia).
Permite también representar recursos, propiedades, literales y statements. Debido a la gran potencia que presenta esta API, su estructura de clases e interfaces resulta bastante intrincada, por lo que trataremos de resumir muy superficialmente esta compleja jerarquía. En ella, las ontologías vienen representadas por la interfaz OntModel, y cada uno de los elementos de la ontología, por la interfaz OntResource. De esta interfaz se derivan OntClass que representa a las clases, Individual que representa a las instancias o individuos de estas clases y OntProperty que representa a las propiedades de las clases. Cada una de estas interfaces contiene los métodos necesarios para acceder a los elementos de la jerarquía de clases, atributos y relaciones de la ontología, así como a la estructura de ésta, restricciones, etiquetas, comentarios y, en general, a todos los aspectos de la ontología que necesitamos recopilar.
Además, JENA incluye varios componentes, entre los que cabe destacar:
• Soporte para persistencia: permite crear modelos persistentes que son mantenidos de forma transparente al usuario en una base de datos relacional. Jena 2 soporta MySQL, Oracle y PostgreSQL.
• RDQL: lenguaje de consultas para RDF desde un enfoque totalmente declarativo, considera un modelo RDF como un conjunto de tripletas (Objeto, Propiedad, Valor). Permite especificar patrones que son mapeados contra las tripletas del modelo para retornar un resultado y permite realizar consultas en RDQL desde una aplicación Java.
• Validador de OWL: Existe la posibilidad de realizar una validación básica de OWL. Esta validación sólo comprueba la sintaxis, no infiere ni razona. Para validaciones más complejas Jena 2 ofrece soporte para inferencias y detecta la violación de las restricciones definidas en el Schema por las instancias.
• Subsistema de Razonamiento: Inferir es deducir información adicional. Al código que realiza la tarea de inferir se le llama razonador (Reasoner). Jena ofrece mecanismos para añadir nuevos razonadores e incluye un conjunto básico de éstos: o OWL Reasoner. o DAML Reasoner o RDF Rule Reasoner o Generic Rule Reasoner
17/86
3.2.5 ORE
ORE(Ontology Rule Editor) es una aplicación que permite editar y ejecutar reglas de inferencia, consigue este objetivo de forma modular y distribuida a través de una amigable interfaz gráfica.
Es una herramienta desarrollada íntegramente por la Universidad de Murcia.
Principalmente, se basa en el framework de Jena y usa SWRL como lenguaje de reglas.
Las reglas creadas se van acumulando en la base de reglas local del cliente, gestionada por ORE. Podemos ir añadiendo nuevas reglas, editar de nuevo las que ya existen o eliminar aquellas reglas que no nos interesen. Si queremos guardar de forma permanente las reglas que se encuentran en la base local, tendremos que almacenarlas en disco. ORE se encarga de esta tarea mediante el uso del parser SWRL, que convierte las reglas que se encuentran en memoria al lenguaje de reglas abstracto y las guarda en un fichero.
ORE ofrece la posibilidad de comprobar, de forma local, el resultado que se obtendrá al ejecutar este conjunto de reglas sobre el modelo que representa el dominio en el que estamos trabajando. Gracias al razonador genérico Jena que incluye, ORE puede convertir las reglas de la base local al formato especificado por Jena, y junto con la base de conocimiento que nos aporta el modelo de ontología con el que hemos construido las reglas, el cliente realiza el proceso de inferencia. El resultado de este proceso es mostrado al usuario mediante indicaciones de las reglas que se han disparado, el porqué de esos disparos y las acciones o nuevos hechos que acarrea sobre el modelo de ontología.
ORE ofrece las siguientes funcionalidades:
– Cargar ontologías bien a través de archivos OWL, RDFS y XML o bien a través de la URI que identifica a la ontología.
– Editar reglas de una forma guiada y sencilla gracias al Wizard que incorpora . Tanto los antecedentes como los consecuentes de cualquier regla se definen de la misma manera, a
18/86
Ilustración 1: Interfaz ORE
través de tres pasos guiados por el Wizard, en los que se selecciona el sujeto, el predicado y el objeto del antecedente o consecuente.
– Guardar las reglas definidas por el usuario en formato SWRL. Así toda la carga semántica de las reglas se mantiene para un uso posterior.
– Permite testear las reglas definidas por el usuario, bien de forma local o bien de forma remota o distribuida.
3.3 MYSQLMySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario con más de seis millones de instalaciones.
MySQL AB desarrolla MySQL como software libre en un esquema de licenciamiento dual. Por un lado se ofrece bajo la GNU GPL para cualquier uso compatible con esta licencia, pero para aquellas empresas que quieran incorporarlo en productos privativos deben comprar a la empresa una licencia específica que les permita este uso.
SQL (Lenguaje de consulta Estructurado) fue comercializado por primera vez en 1981 oir IBM, desde ese entonces ha sido considerado como un estándar para las bases de datos relacionales.
MySQL persigue el el objetivo de cumplir el estándar SQL pero sin sacrificar velocidad, fiabilidad o usabilidad.
Existen varias APIs que permiten, a aplicaciones escritas en diversos lenguajes de programación, acceder a las bases de datos MySQL, cada uno de estos utiliza una API específica.
MySQL es muy utilizado en aplicaciones web como , Drupal o phpBB, y por herramientas de seguimiento de errores como Bugzilla. MySQL es una base de datos muy rápida en la lectura cuando utiliza el motor no transaccional MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia en la modificación. En aplicaciones web hay baja concurrencia en la modificación de datos y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para este tipo de aplicaciones.
Este proyecto requiere de una muy rápida lectura y no posee ningún grado de concurrencia en modificación, además JENA nos ofrece soporte para la persistencia en MySQL todo esto unido a su característica de software libre hace que MySQL sea una buena opción.
19/86
4 ANÁLISIS Y CASOS DE USO
4.1 PLAN DE TRABAJO
Este proyecto está enmarcado en un proyecto más grande que tiene como objetivo la creación de un dispositivo inteligente que instalado en la casa de una persona de avanzada edad que vive sola, sea capaz de detectar y actuar ante situaciones potenciales de peligro, como por ejemplo un desvanecimiento.
Este proyecto se apoya en el trabajo de otros grupos de investigación de la siguiente manera:
• Hardware: Elección, manejo, programación,.... de los dispositivos sensores que captarán el entorno del atendido. Sensores de movimiento, presión y apertura de puerta. Todo esto queda a cargo de Departamento de Electrónica, Tecnología de Computadoras y Proyectos de la ETSIT de la Universidad Politécnica de Cartagena.
• Desarrollo de adaptadores que recojan la información de los dispositivos sensores y generación de eventos contextualizados a partir de dicha información. En la estructura de ProDia, que veremos en siguientes secciones se corresponde con la capa inferior OCP. A cargo del Grupo de Sistemas Inteligentes perteneciente al Departamento de Ingeniería de la Información y las Comunicaciones de la Universidad de Murcia.
A partir de los objetivos del proyecto se han definido las siguientes tareas a realizar:• Estado del Arte de los dispositivos inteligentes de alerta orientados a favorecer la
independencia de las personas de avanzada edad.• Colaboración en la definición de la estructura global de ProDia.• Estudio de tecnologías existentes a aplicar.• Definición de patrones de comportamiento que podemos inferir a partir de los eventos
captados por los dispositivos sensores.• Definición de ontología de contexto.• Desarrollo de un Sistema Basado en el Conocimiento que infiera el estado del atendido en
todo momento.• Integración del sistema desarrollo con las demás partes del proyecto.• Desarrollo de herramientas Software auxiliares para Prodia:
◦ Configuración y despliegue: ProdiaConfigurator.◦ Simulación de historias: ProdiaSimulator.◦ Data Mining y validación: ProdiaChart.
• Definición y puesta en marcha de un plan de pruebas en casas reales con el sistema instalado.
En las siguiente imágenes se puede ver con detalle la organización y los tiempos de cada una de las tareas descritas.
20/86
4.2 METODOLOGÍA
4.2.1 INGENIERÍA DEL SOFTWARE
El desarrollo de este proyecto sigue el proceso de desarrollo de [Larman, Craig] , que define el
proceso de desarrollo de software como un método de organizar las actividades relacionadas con la
creación, presentación y mantenimiento de los sistemas de software.
Siguiendo el enfoque propuesto por Larman, los pasos principales para desarrollas una aplicación
son:1. Planificación y elaboración: se definen los requisitos de la aplicación, se construyen
prototipos, etc.2. Construcción: Creación del sistema.
3. Aplicación: Transición de la implementación del sistema a su uso.
21/86
Ilustración 2: Diagrama de Gantt 1
Ilustración 3: Diagrama de Gantt 2
Se ha utilizado el lenguaje de modelado UML, lenguaje de modelado visual usado para especificar,
visualizar, construir y documentar artefactos de un sistema de software. UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. UML es sólo un lenguaje,
deja a elección del desarrollador el proceso utilizado para guiar las fases de diseño.UML se ha convertido en el lenguaje de modelado estándar en la industria del software, contando
con el apoyo de organizaciones de estandarización y empresas privadas.
4.2.1.1 ANÁLISIS DE REQUISITOS
Después de realizar un amplio estudio sobre las necesidades a cubrir con nuestro sistema se destacan los siguientes requisitos a cumplir.
1. El sistema deberá detectar en el menor tiempo posible una situación de emergencia en la casa del atendido. Esta posible emergencia puede ser desde una caída o desvanecimiento hasta un estado de enfermedad.
La mayor fuente de emergencias vendrá detectada por la inactividad del usuario. Es decir si lo localizamos en una situación de la casa y en un momento del día en el que nos “extraña” que se encuentre inactivo durante un tiempo determinado podemos empezar el proceso de alarma, es posible que haya sufrido una caída o desvanecimiento.
Por otro lado no debemos olvidarnos de los estados en los que detectamos actividad pero aún así no es normal. Por ejemplo si durante toda la mañana no sale de su habitación, es posible que se encuentre mal y decida no levantarse, a pesar de estar activo (leyendo, viendo la tele…) no tiene un comportamiento habitual y puede que necesite ayuda.
a. Se debe afinar la detección de estas emergencias lo suficiente para que las falsas alarmas sean mínimas.
b. A partir de la detección de una posible emergencia debe existir un proceso de verificación que consiga reducir al mínimo las falsas alarmas. Para ello se realizará una llamada telefónica al atendido en la que verificaremos si se encuentra bien (nos contesta) o si realmente puede estar en una situación en la que necesite de nuestra intervención.
2. En cualquier momento el atendido puede solicitar nuestra ayuda deliberadamente pulsando el botón de emergencia. Con este sistema se acelera la activación del estado de alerta siempre que el atendido sufra una emergencia que no le impida la utilización del botón.
a. A pesar de tratarse de una solicitud explicita se debe verificar el posible estado de emergencia.
3. ProDia debe detectar si el atendido sale de casa. Las salidas y entradas del atendido en
22/86
su hogar serán detectadas por nuestro sistema desactivando o activando respectivamente el proceso de detección de emergencias en cada caso. La salida del atendido debe detectarse con gran fiabilidad ya que esta implica la desactivación del proceso de detección de emergencias.
a. Se debe evitar al máximo las posibles “falsas ausencias” del atendido. Al detectar una ausencia el sistema desactivará el proceso de detección de emergencias por ello una falsa ausencia dejaría al sistema sin funcionar. Habrá que detectar por tanto cualquier situación en la que se abra y cierre la puerta pero en la que el atendido quede dentro de la casa.
b. A pesar de este en es el objetivo de ProDia, detectara y realizará la correspondiente verificación en caso de detectar actividad en la casa cuando el atendido está ausente. Es decir, si detectamos la salida del atendido y sin volver a detectar su entrada se detecta actividad en el hogar, supondremos que estamos ante un posible intruso.
4. El sistema detectará que el atendido está durmiendo o descansando en su cama. Esta detección nos evitará falsos positivos ya que a pesar de estar detectando un tiempo prolongado de inactividad del usuario tenemos la certeza de que se encuentra durmiendo o al menos descansando en la cama.
a. A pesar de esto debemos tener en cuenta las posibles emergencias que puedan surgir en la cama. Se deberá controlar que el tiempo que pase el atendido en la cama (dependiendo del momento del día) no sea excesivo. Un tiempo superior al normal nos llegaría a un posible estado de emergencia, el atendido no despierta o no consigue levantarse.
5. Se detectará que el atendido permanece sentado descansando en el sofá o sillón del salón. Al igual que en el punto anterior la certeza de que se encuentra en el sofá nos justifica de alguna manera la inactividad prolongada del atendido.
a. Se tendrán en cuenta los estados de inactividad prolongados que el atendido pase en el sofá. Un exceso de tiempo “descansando” puede llevarnos a una posible emergencia.
6. ProDia debe proporcionarnos un sistema con una arquitectura extensible. Debe existir una independencia absoluta entre el Hardware y el Software, con el fin de poder incluir nuevos dispositivos que nos proporcionen una percepción más real del entorno y con ello un razonamiento más eficaz.
7. El sistema debe estar preparado para conseguir realizar un aprendizaje de orden superior en próximas versiones. Es decir, a pesar de que la “inteligencia” de nuestro
23/86
sistema en esta primera versión será limitada debemos diseñar el sistema con miras hacia un sistema realmente inteligente. Un sistema que sea capaz de aprender de los hábitos de cada atendido y tenga por tanto afinado al máximo su sistema de alertas.
La personalización automática de nuestro sistema minimizará los falsos positivos y nos dará la posibilidad de detectar pequeños cambios en los hábitos que puedan sugerir una posible enfermedad (depresión, Alzheimer…).
4.2.1.2 CASOS DE USO
Podemos defender dos actores principales en la realización de casos de uso, normalmente el sistema funcionará sin la intervención para nada del atendido. Sólo existe un caso en el que el atendido interacturá con el sistema, será en el aviso voluntario de ayuda.
En la siguiente imagen podemos ver la relación de casos de uso indicando el actor principal de cada uno.
Veamos uno a uno los casos de uso que hemos descrito.
Caso de Uso: Detección de una situación de emergencia
Descripción:Permite detectar una situación de posible emergencia en el hogar del atendido.
Actores: Sistema y atendido de manera pasiva.
24/86
Ilustración 4: Casos de Uso
Precondiciones:El sistema percibe sin problemas técnicos la realidad de la casa del atendido.
Flujo Normal: El atendido realiza su vida cotidiana.El sistema percibe sus movimiento e infiere el estado en el que se encuentra en todo momento.El atendido sufre una situación de emergencia (una caída, un desvanecimiento,...).El sistema detecta inactividad o actividad anormal e infiere, en un tiempo no demasiado excesivo, un estado de potencial emergencia.El sistema envía una mensaje de alarma a la central (caso de uso 2)
Flujo Alternativo:
El atendido no sufre ninguna situación de emergencia pero el sistema si llega a inferir que existe dicha alarma.
La central se comunica con el atendido y descarta la alarma.
Se recoge la información de la alarma para que el sistema pueda aprender de los falsos positivos.
Postcondiciones:
La alarma llega sin problemas a la central y esta se ocupa de asistir al atendido.
Caso de Uso: Envío de Alarmas
Descripción:Se envía un mensaje de alarma a una central receptora de emergencias.
Actores: Sistema y central receptora de alarmas.
Precondiciones:El sistema ha detectado una situación de emergencia en la casa.
Flujo Normal: El sistema compone un mensaje que incluye información sobre el atendido y el tipo de alarma detecta.La central de alarmas recibe el mensaje y lo trata.La central de alarmas se pone en contacto con el atendido, si el atendido no responde inicia el proceso de asistencia.
Flujo Alternativo:
El atendido sí responde a la comunicación con la central y se encuentra en perfecto estado.
25/86
La central descarta la alarma y avisaría al sistema del falso positivo
Se recoge la información de la alarma para que el sistema pueda aprender de los falsos positivos.
Postcondiciones:
La alarma llega sin problemas a la central y esta se ocupa de asistir al atendido.
Caso de Uso: Aviso Voluntario
Descripción:El atendido avisa a la central de que tiene un problema
Actores: Atendido, sistema y central receptora.
Precondiciones:El atendido dispone de un dispositivo para realizar el aviso voluntario, el sistema funciona correctamente en la casa del atendido.
Flujo Normal: El atendido utiliza el dispositivo para realizar un aviso voluntario.El sistema envía el aviso a la centralLa central recibe el aviso y se pone en contacto con el atendido.
Poscondiciones:
El aviso llega sin problemas y la central atiende al usuario.
Este caso de uso, a pesar que desde un principio se incluía en los requisitos del proyecto, no se ha llegado a desarrollar hasta el momento.
Caso de Uso: Detección de ausencia en casa
Descripción:El atendido sale de casa y el sistema detecta este hecho
Actores: Sistema y atendido de forma pasiva.
Precondiciones:La casa del atendido dispone de sensores de puerta comunicados correctamente con el sistema.
26/86
Flujo Normal: El atendido sale de casa, abre y cierra la puerta para llevarlo a cabo.El sistema detecta que el atendido ha salido y no se preocupa ante la ausencia de actividad en casa
Postcondiciones:
Sistema en estado de ausencia
Caso de Uso: Detección de estados de descanso
Descripción:El sistema detecta que el atendido se encuentra en descanso, acostado o en reposo en el sillón.
Actores: Sistema y atendido de forma pasiva.
Precondiciones:La casa del atendido dispone de sensores de presión en cama y en el sillón o sofá preferido del usuario comunicados correctamente con el sistema.
Flujo Normal: El atendido se acuesta en la cama o se tumba en el salón. Se duerme o descansa por un tiempoEl sistema detecta que el atendido está tumbado o descansando y no se extraña de la ausencia de movimiento.
Flujo Alternativo:
Los dispositivos de presión no funcionan correctamente no detectando al usuario en la cama o sillón.
El sistema ante un tiempo prolongado de inactividad podría llegar a inferir un estado de emergencia (Caso de uso 1)
Postcondiciones:
Sistema en estado de descanso
27/86
5 DISEÑO DE LA APLICACIÓN
5.1 ARQUITECTURA DE TRES CAPAS
La arquitectura de ProDia está basada en las ideas presentadas por Kenneth Craik en su libro “The nature of Explanation” [Craik K., 1943], en el que describe los mecanismos por los que los humanos procesamos la información que recibimos. Craik postula la existencia de tres niveles de procesamiento: El primer nivel se encarga de recibir los datos sensoriales en forma de estímulos proveniente del exterior; en el segundo nivel, éstos se traducen a una representación interna que es clave para su posterior procesamiento; finalmente, en el tercer nivel, esta representación es procesada y manipulada mediante procesos cognitivos (memoria, aprendizaje basado en la información almacenada o creencias y prejuicios, razonamiento, lenguaje) y éstas, a su vez, se traducen en acciones como respuesta a los estímulos.
ProDia realizará un procesamiento similar al que acabamos de describir. En primer lugar nuestro sistema es capaz de recibir información de su entorno por medio de los dispositivos sensores (percepción), la información recibida es tratada y representada internamente llegando a componer un contexto (conocimiento). Finalmente, el conocimiento sobre el contexto es procesado, disparando procesos cognitivos que nos permiten detectar diferentes situaciones a partir del contexto (razonamiento). Una vez detectadas dichas situaciones se pueden disparar determinadas acciones (acción), además de asimilar dicha respuesta para futuras presentaciones de ese mismo problema o de otro parecido (aprendizaje).
Desde el punto de vista tecnológico, el contexto, es decir, el entorno en el que se mueve el atendido, es representado mediante una ontología, utilizando OWL1 como lenguaje de representación. Con esta representación conseguimos organizar la información “en crudo” que nos llega desde los sensores en una estructura que permite la anotación semántica de dicha información y, por lo tanto, disparar procesos de razonamiento que determinen el contexto exacto en el que se encuentra le atendido. De esta forma, somos paces de activar procesos de “razonamiento” directamente sobre la ontología, sin necesidad de que dichos procesos trabajen directamente sobre los datos procedentes de los sensores. Para ello, como detallaremos más adelante, los procesos de razonamiento se apoyan en un conjunto de reglas definidas mediante SWRL2, junto el potente motor de razonamiento basado en las aplicaciones Jena3 y Pellet4.
Como se puede ver en la figura 1, la ontología actúa de nexo entre las 3 capas, la capa inferior anota todos los cambios producidos en el entorno en la ontología. Posteriormente la capa superior utiliza esta representación del entorno para determinar el estado en el que se encuentra el atendido, estado que se representará explícitamente en la ontología. A su vez, la capa superior utilizará el contenido de esta, modificado y tratado por las capas inferiores, para realizar un razonamiento más profundo
1 http://www.w3.org/TR/owlref/2 http://www.w3.org/Submission/SWRL/3 http://jena.sourceforge.net/4 http://clarkparsia.com/pellet/
28/86
en base a datos históricos, y realizar las acciones necesarias o resolver posibles inconsistencias. Como se puede apreciar, la ontología es utilizada a “modo de pizarra” entre las diferentes capas siempre de manera ordenada y sin interferir, en ningún caso, las modificaciones o procesamientos que realizan sobre ella las diferentes capas.
Para definir de forma adecuada el contexto necesitaremos datos e información de diferentes tipos y naturaleza. Para ello, dispondremos de datos sobre lo que los dispositivos están percibiendo en el momento actual, previamente preprocesados por la capa inferior (activación o no de los diferentes dispositivos sensores); información sobre la topología de la casa del atendido, que serán inicializados en el momento de la instalación (número de habitaciones, tipos, conexiones entre ellas...); representación explícita de los resultado del proceso de razonamiento desarrollado en la capa intermedia (estado actual del atendido); y, por último, datos temporales e históricos (momento actual del día, tiempo desde la última percepción de movimiento....).
Los datos “en crudo” captados por los dispositivos sensores llegarán hasta la capa inferior de nuestro sistema. Estos datos son recibidos por un driver, especialmente desarrollado para esta aplicación, que sólo nos avisa de los cambios de estado en la información percibida por los
29/86
Ilustración 5: Estructura de 3 capas
sensores, liberando a las capas superiores de la complejidad inherente al tratamiento de los posibles cambios en los dispositivos sensores.
Este driver interactuará directamente con la capa inferior, cuyo principal componente es OCP (Open Context Platform) [Nieto I., et al., 2006] transformando la información en crudo procedente de los sensores en un cambio en el contexto, haciéndola explícita en la ontología. De esta forma, OCP, que será analizado más profundamente en la siguiente sección, gestionará los cambios en el contexto, determinando el estado del entorno a partir de información recibida de dispositivos de diferente naturaleza, en este caso desde los dispositivos sensores que podrán ser de diferente fabricante, arquitectura, etc. Además, OCP registrará de forma automática (persistencia de su ontología) los cambios en el contexto que se van produciendo. El almacenamiento en una ontología propia nos permitirá a posteriori procesar los datos de este histórico en busca de algún patrón de comportamiento, error hardware, etc. OCP es un software desarrollado íntegramente por los grupos de investigación de la UMU que componen este proyecto. Existía previamente a este proyecto [Nieto I., et al.,2006b; Botia, J. et al.,2008] pero se ha ido desarrollando más y ajustando a las necesidades particulares de ProDIA.
Con los datos provenientes del entorno procesados y representados dentro de un contexto, el sistema es capaz de razonar, en base a las reglas definidas en su base de conocimiento, y conseguir definir el estado en el que se encuentra el atendido según los datos que hemos recopilado de su entorno. Esta es el objetivo de la capa intermedia. Para la representación del estado del atendido se ha definido un autómata finito determinista en el que incluimos los posibles estados en los que podemos encontrar al atendido, las transiciones entre ellos están directamente relacionadas con el conjunto de reglas que compone nuestra base de conocimiento. El estado actual del atendido (estado del autómata) forma parte del contexto y, por lo tanto, debe incluirse en la instancia de la ontología que representa nuestro contexto actual.
La base de conocimiento, constituida por un conjunto de reglas SWRL definen lo que podríamos considerar como el comportamiento “inteligente” del sistema. Con ellas definiremos, por ejemplo, qué se considerar un estado de “Actividad Normal”, es decir, el atendido se mueve por su casa libremente y parece tener un comportamiento habitual. Para inferir que el atendido se encuentra en dicho estado utilizaremos los datos de diferente naturaleza que, como ya hemos visto, vienen representados en la ontología. Todas las operaciones que tienen que ver con reglas de conocimiento (i.e. edición, inferencia, etc) están gestionadas mediante una herramienta denominada ORE (Ontology Rule Editor) [Munoz A., et al., 2006; Munoz A., et al., 2008]. Esta herramienta está desarrollada íntegramente por investigadores de la UMU
En el ejemplo del estado de “Actividad Normal” nuestras reglas tendrán en cuenta la percepción de actividad determinada por los sensores, por ejemplo, hay movimiento en el sensorX, a partir de los datos estructurales podremos “localizar” al atendido sabiendo que el sensorX está colocado en la habitacionY que, por ejemplo, se corresponde con el salón principal de la casa. Los datos temporales nos indicarán el momento del día en el que nos encontramos y el tiempo que el atendido está en dicho estado, es decir, son las 6 de la tarde y hace 30 minutos que estamos recibiendo movimiento en el salón. Este sería un ejemplo muy simple de inferencia en la capa intermedia. Como podemos apreciar, los parámetros temporales constituyen un elemento clave para el correcto funcionamiento del sistema. El ejemplo anterior sería muy diferente si fueran las 5 de la
30/86
mañana y se estuviera recibiendo movimiento en el salón durante 3 horas seguidas. El modelado del tiempo y el procesamiento de éste, tanto en la ontología como en la capa intermedia se verá con más detalle en las secciones siguientes.
La capa superior realiza un razonamiento más complejo basándose en los resultados obtenidos por la capa intermedia. La distinción entre la capa intermedia y la superior viene determinada por la existencia de dos bases de conocimiento diferentes, el reparto de responsabilidades y, además, de mejorar el rendimiento del sistema gracias a la modularidad de las bases de conocimiento. La reglas SWRL definidas en esta capa nos llevarán a detectar y resolver inconsistencias, realizar un razonamiento profundo teniendo en cuenta históricos y a la realización de las acciones que vienen determinadas por el razonamiento. Un ejemplo de inconsistencia puede ser la detección de movimiento en al menos 2 sensores que no se encuentran en la misma habitación. En este caso, la capa intermedia inferirá que existe actividad, pero no es capaz de determinar la localización de la misma y, por lo tanto, llega a un estado inconsistente, es decir, tenemos dos contextos posibles. La capa intermedia traspasa la responsabilidad de solucionar este hecho a su capa superior. Será esta capa la que realice el procesamiento necesario (comprobación del funcionamiento de sensores, inferencia de la localización por patrones,...) y consiga resolver la inconsistencia, indicando a la capa intermedia el estado consiste adecuado.
Otra de los cometidos de esta capa, está relacionados con las acciones que el sistema debe realizar cuando se detectan determinados estados. Por ejemplo, cuando se detecte un estado potencialmente peligroso (caída, inactividad anómala, …), tendrá que iniciar un de verificación de dicho estado de alarma e ir realizando las acciones adecuadas según el protocolo descrito y el nivel de alarma en el que nos encontremos (llamada de teléfono, mensaje a un familiar, llamada a 112...).
Por último, en un proyecto futuro, aunque en este momento y gracias a los datos obtenidos en las pruebas piloto, otra de las funciones de está última capa, estará relacionada con el proceso de adaptación. En este sentido, además de poder ajustar la duración de los timers asociados a las transiciones de estado (procedimiento que está siendo analizado en actualmente), se van a desarrollar métodos que permitan la detección de patrones de comportamiento. Básicamente, un patrón de comportamiento se puede definir como una sucesión de estados, relacionados temporalmente (mediante relaciones de precedencia y/o temporales), que ocurren normalmente. Par poder detectar dichos patrones, hay que diseñar nuevos métodos de análisis inteligente de datos, principalmente minería de datos temporales, adaptados a nuestro problema. Para tal fin, ya se han dado algunos pasos, en lo que se refiere a la representación de patrones temporales y su descubrimiento [Palma J., et al., 2006;Campos M. et al, 2002].
5.2 ONTOLOGÍA: NEXO ENTRE CAPAS
El problema de la representación del contexto hoy en día se aborda como un tema abierto y tratándose casi como una nueva área de investigación. En general, los esfuerzos se han dedicado a definir tanto el concepto de contexto [R. Want. ,2000], así como los métodos y mecanismos para la captura o la obtención de información contextual [J. Pascoe et al, 1998] .
31/86
Podemos afirmar que el uso de contexto está estrechamente ligado a la forma en que percibimos y en la interpretación de nuestra percepción para conseguir un buen uso de esta. Esta observación nos conduce al uso de ontologías para proporcionar una definición común del modelo de información que todas las partes implicadas en la aplicación deben utilizar.
El uso de ontologías garantiza un marco común dentro del contexto de información que puede ser intercambiado y reutilizado fácilmente. La interpretación semántica que puede hacerse de la información en forma de conocimiento y su posterior razonamiento pueden llevarse a cabo dentro del contexto con el fin de integración de entidades de información con un bajo nivel junto con otras entidades más de nivel abstracto. Ejemplos de sistemas basados en modelos ontológicos pueden verse en [X. Wang, 2004] y [Tao Gu at el, 2004].
El diseño de la estructura de la ontología depende del conocimiento que deseamos representar y del posterior razonamiento que se desea realizar con esta estructura. En nuestro sistema el entorno en el que se encuentra el atendido será la base de nuestro conocimiento. Cuando hablamos de entorno nos referimos a la casa del atendido y a lo que sucede en ella que nosotros podemos percibir. Además del entorno estructural y perceptivo se incluyen parámetros temporales que serán determinantes en el proceso de inferencia. Por otro lado también necesitamos representar el estado actual inferido del atendido que nos servirá para posteriores razonamientos.
De todo esto podemos definir los siguientes conceptos claves de nuestra ontología:
● Atendido: debe incluir su estado actual inferido, dentro de este estado siempre se indica la localización dentro de la casa. Conceptualmente debe identificar unívocamente al usuario incluyendo toda la información que pueda ser necesaria. A nivel de razonamiento su estado actual y su localización nos serán suficientes.
● Dispositivo Sensor: será el elemento más importante, nos aporta toda la capacidad de percepción del entorno que tiene nuestro sistema. Es un concepto abierto, ya que dentro de él podremos incluir sensores de muy diferentes tipos: movimiento, presión, apertura de puerta, presencia,... Nos interesa saber qué es lo que está detectando en cada momento y dónde lo está detectando, la localización del dispositivo nos permitirá inferir la localización del atendido.
● Habitación: la estructura de la casa define en gran parte el entorno en el que se mueve el atendido. El tipo de cada habitación (salón, cocina, baño,...) será un dato revelador en el momento de la inferencia, la localización del atendido en un tipo de habitación concreto y en un momento del día nos ayudará a intuir que es lo que puede estar haciendo en esse momento y si es por tanto un comportamiento normal.
● Tiempo: el factor tiempo será en muchos casos la clave para la detección de una situación de alarma. Un tiempo determinado de inactividad en la casa del atendido nos puede llevar a
32/86
pensar que algo anda mal en ella. Así mismo, la hora del día en la que nos encontramos o con un concepto más general, el momento del día actual, nos guiará en cuanto a la normalidad o no de lo que está ocurriendo en la casa. Con esto tendríamos dentro del concepto tiempo dos conceptos más específicos: momento del día y timer que nos “mida” ciertos intervalos de tiempo.
En la siguiente figura se ve con detalle el árbol que forman los diferentes conceptos en nuestra ontología. Se especifican los diferentes tipos de timers, habitaciones, sensores.... Es necesario que la estructura de nuestra ontología sea fácilmente extensible para posibles continuaciones de este proyecto. Como vemos, por ejemplo, la inclusión de un nuevo tipo de sensor no afectaría en ningún a la estructura general de la ontología.
33/86
Ilustración 6: Árbol de la ontología
Las relaciones entre los diferentes conceptos son las que darán forma al contexto y definirán por tanto con cierto nivel de detalle el entorno en el que se encuentra el atendido.
En la parte izquierda del árbol de la ontología podemos ver que existen numerosos conceptos en relación con la estructura de la casa. Habitaciones, puertas, ventanas,... todos ellos relacionados nos consiguen darnos una visión detallada de la casa completa del atendido. Inicialmente utilizaremos sólo una parte de estos términos: habitaciones y puertas, pero el modelado completo de la estructura nos permitirá en un futuro utilizar estos conceptos unidos a dispositivos sensores como una base de conocimiento mucho más rica.
En la siguiente figura podemos ver un diagrama simplificado con las relaciones entre los diferentes términos y los atributos principales de estos. En las siguientes secciones veremos con más detalle alguno de estos términos.
35/86
Ilustración 7: Diagrama simplificado de términos
5.2.1 TIMERS EN LA ONTOLOGÍA
Los Timers toman un papel importante en la activación o no de un proceso de alarma. Definiremos diferentes tipos de timers que estimarán en cada caso el tiempo que pasa desde un hecho u otro y que nos puede llevar a un estado de alarma o simplemente a un estado diferentes.
Los intervalos de tiempo definidos en estos timers serán en muchos casos dependientes de otras características. Como hemos visto en el diagrama pueden estar relacionados con un espacio habitable (tipo de habitación) y con un momento del día concreto. Veamos los diferentes tipos de timers y con ellos las posibles relaciones con estos términos:
● Timer de Inactividad: define el intervalo de tiempo en el que si no se recibe ningún signo de movimiento en la casa el atendido pasará a un estado de inactividad. Esta inactividad no constituye un estado de alerta, será el estado intermedio entre la actividad normal y una inactividad anormal con posibilidad de emergencia. Es decir, si nos estamos moviendo y en un momento dado dejamos de movernos durante, por ejemplo 5 minutos, el sistema inferirá que nos encontramos en un estado de inactividad normal. Como veremos más adelante la inactividad a la que nos lleva este timer puede tener variantes, por ejemplo si esta inactividad se produce cuando estamos sentados en el sofá o acostados en la cama.
Este tipo de timer no estará parametrizado por tipo de habitación ni por momento del día. No nos importa en que momento se produzca esa inactividad ni el lugar de esta, ya que es un estado de normalidad no dependiente de ninguna de estas características. Nos da igual que se produzca esta inactividad en el salón por la tarde que en el baño por la mañana, simplemente intenta diferenciar el estado de actividad de un estado en el que no nos movemos en un periodo corto de tiempo, no siempre estamos activos.
● Timer de Inactividad Anómala: estimará el tiempo en el que la inactividad del atendido comienza a ser preocupantes. Este tipo de timer si dependerá directamente del tipo de habitación en la que se encuentre el atendido (última percepción de movimiento) y el momento del día en el que ha comenzado la inactividad. Con esta parametrización estamos incluyendo el sentido común y los hábitos normales de vida en la detección de una emergencia. Si la última localización del atendido es el pasillo y lleva 1 hora sin moverse (al menos eso nos indican los sensores), será más preocupante que si esa hora de inactividad se produce en el salón. Esta última es completamente normal pero no si la localización es el pasillo hay cierta probabilidad de que se trate de una emergencia. Por otro lado la inactividad de, por ejemplo 2 horas en el salón, será muy diferente si se produce a media tarde que si esta se produce de madrugada.
La definición de estos timers será un punto clave del sistema para la detección de situaciones de emergencia. Inicialmente se especificarán unos timers que intentarán abarcar los hábitos cotidianos de la gran mayoría de personas. El afinamiento y personalización de estos timers
36/86
tendrá lugar en siguientes versiones del producto (tanto de este tipo de timers como de los demás).
● Timer de Actividad Anómala: con este tipo de timer se definirá el tiempo estimado en el que la recepción continuada de actividad en una misma localización comienza a ser preocupante. Es evidente que este timer de ser estudiado con más cautela ya que, en principio, la actividad (al menos la recepción de movimiento) es signo de vida, y en principio, de normalidad. Aún así hay que tener en cuenta los posibles casos en los que se percibe actividad de manera prolongada y no forma parte de la normalidad. Pensemos por ejemplo en que estamos recibiendo actividad en el baño durante 2 horas de madrugada, no se trata de un comportamiento habitual y en él se puede esconder por ejemplo, una posible caida com reiterados intentos de incorporación.
Como hemos visto este tipo de timer también debe ir parametrizado por localización y momento del día, estas características harán variar el intervalo de tiempo que controla este timer.
● Timer de Ausencia: uno de los requisitos del proyecto es la detección de la salida y entrada del atendido a su casa. El sistema debe modelar el estado de ausencia como un estando más ya que en él la inactividad registrada en la casa no tiene ninguna trascendencia. Para llegar a detectar la ausencia utilizaremos sensores de apertura de puerta. Una ausencia vendrá determinada por una apertura de puerta, el cierre de esta y posteriormente un tiempo en el que no se registra actividad en la casa. Este intervalo de tiempo será el que controlará este tipo de timer. Com esto se pretende evitar la detección de falsas ausencia, por ejemplo si abrimos la puerta, la cerramos y nos quedamos dentro de la casa. En este caso la inactividad posterior durante un periodo de tiempo será la que nos confirme la ausencia del atendido.
Es importante definir este timer con un intervalo de tiempo suficiente para que la confirmación de esa ausencia sea correcta, en caso de llegar a un estado de falsa ausencia el sistema quedaría incapaz de registrar o inferir cualquier tipo de emergencia que se produzca en el hogar en ese estado.
La definición de este timer no se verá afectada por la localización (esta será la salida de la casa) ni por el momento del día en que esta se produzca.
● Timers de Verificación: el modelado de este tipo de timers se realiza con vistas a siguientes versiones del producto. Como hemos comentado antes existirá un protocolo de actuación ante una emergencia que vendrá determinado por los diferente niveles de alarma. Este tipo de timers controlarán el paso desde cada nivel de alarma al superior siempre que este no surja efecto. Por su definición no viene determinado por localización o momento del día.
37/86
5.2.2 ATENDIDO: ESTADO ACTUAL E INTERMEDIO
La ontología como representación del entorno debe incluir el estado actual inferido para el atendido por el sistema, así como la localización actual de este. Estos datos será utilizados en la inferencia al igual que los datos de percepción de los dispositivos. Todos ellos, como hemos dicho antes, componen en contexto y forman parte de la base de conocimiento.
Como ya se ha comentado el razonamiento y su consecuente inferencia realizada por la capa intermedia nos puede llevar hasta un estado de inconsistencia. Por ejemplo, varias localizaciones diferentes o incluso dos estado diferentes. Para que la capa superior consiga solucionar las posibles inconsistencias es necesario tener recogido tanto el estado del contexto inferido como el actual (anterior razonamiento). Por ello se crea una estado intermedio del contexto (ontología) en el que se van especificando los posibles estado del atendido y las posibles localizaciones, estas se almacenan en las propiedades newState y newLocation del objecto Attend.
Después de realizar el razonamiento se comprobará el estado de la ontología conseguido y si este es un estado válido (1 sola localización y un sólo estado), la información almacenada en estas propiedades que forman el estado intermedio pasarán a componer el estado actual de contexto y en por tanto del atendido.
En caso de que el estado intermedio que se consigue no sea válido se traspasará la responsabilidad a la capa superior que se encargará de conseguir un contexto válido.
El proceso de razonamiento, validación y posterior resolución de inconsistencias se verá con detalle en las siguientes secciones.
38/86
5.3 CAPA INFERIOR: OCPLa capa inferior del sistema está compuesta por OCP (Open Plataform Context). Su tarea principal es recoger información de los dispositivos sensores y transformarla para incluirla dentro del contexto del atendido. Por ejemplo, tomará un valor numérico que proviene de un sensor de presión y lo transformará en conocimiento: “Alguien está sentado en el sofá del salón”.
Para conseguir esto OCP utiliza adaptadores software para los dispositivos sensores que estamos utilizando, actualmente está implementado el adaptador para Crossbow fabricante al que pertenecen los sensores utilizados. Estos adaptadores son capaces de interpretar los datos en bruto de estos dispositivos y permiten al resto del sistema subir un nivel más de abstracción olvidándose de los detalles específicos de cada dispositivo Hardware.
La gestión del contexto de OCP se basa en el almacenamiento de los cambios y/o eventos del entorno en una ontología de representación contextual propia. Estos eventos recibidos por OCP se almacenarán dentro del contexto propio de OCP, a su vez serán transformados y representados en la composición de contexto que se ha definido para ProDia. Es decir, la capa inferior nos ofrece una representación contextual amplia y general de los eventos que se han percibido, consiguiendo gracias a esta representación una base de conocimiento histórico que permitirá a ProDia realizar un razonamiento más profundo, además de esta representación transforma los eventos contextuales en la representación (también de contexto) especifica y obviando históricos de la ontología de Prodia (descrita en la sección anterior).
OCP se basa en una ontología genérica diseñada con los siguientes objetivos en mente. En primer lugar está la consideración por separado de la información invariable y aquella que va cambiando en el tiempo. Para ello, se asume el carácter dicotómico de la información contextual. Por un lado hay información que permanece estática con el tiempo pero que es necesario para describir ciertas situaciones, por otro parte hay información que va cambiando dinámicamente y que desde el punto de vista del modelo debe de ser considerada de forma especial. El primer tipo de información se conoce como static context y la segunda como situation context, como se muestra en la siguiente figura.
La siguiente figura muestra la jerarquiza del contexto actual en OCP. Un contexto incluye toda la información que describe una situación concreta, incluidas las personas, mecanismos y otros objetos. La descripción de una situación determinada se compone de un conjunto de informaciones básicas, para conseguir conocimiento a partir de este conjunto de información en la mayoría de cosas deberemos basarnos en un contexto complejo. Un contexto complejo se componen de varios contextos simples, pero que forman una unidad semántica con coherencia contextual. Esto implica que, si algún elemento se elimina del contexto complejo, la entidad a que se refiere pasará a ser incompleta ya que no existe nos falta parte de la información disponible que es importante para la toma de decisiones.
39/86
La capa inferior actúa por tanto como enlace entre los dispositivos Hardware y el software, además de aportar un nivel superior de abstracción a las siguientes capas. En la siguiente imagen se puede ver como se encadenan las transformaciones de los datos percibidos, desde que son una simple cadena de bytes generados por el sensor, hasta que consiguen transformarse en datos comprensibles con los que se compone la base de conocimiento.
40/86
Ilustración 8: Diagrama de ontología OCP
Ilustración 9: Transformación de bytes percibidos a conocimiento
Hemos visto el modo de comunicación HardwareSoftware en el que los dispositivos sensores se comunican con el Driver y este transforma la información recibida en eventos entendibles por la capa inferior. Es necesaria también la comunicación inversa, es decir, ProDia debe poder comunicarse con cada uno de los dispositivos sensores.
Los dispositivos sensores disponen de un protocolo de comunicación desde el exterior a ellos en el que se puede controlar el modo de funcionamiento, testear el estado actual de cada uno de ellos o pedir una nueva lectura. ProDia utilizará este protocolo en los siguientes casos:
● Modo instalación: a la hora de configurar ProDia en la casa de cada atendido puede ser necesario activar el modo Test de los dispositivos. En este modo encenderán un LED al detectar algo. Se utilizará para testear el buen funcionamiento de estos dispositivos y calibrar la posición en el que hay que colocarlos para conseguir detectar cualquier actividad.
● Nueva lectura: como hemos visto, los dispositivos sensores funcionan a través de eventos en los que nos informan sólo de los cambios que sufre el contexto. En cualquier momento ProDia puede pedir una nueva lectura del estado de una dispositivo para chequear que el último estado recibido por este es realmente el actual. Siempre es posible que se pierda algún mensaje de cambio de estado con lo que es necesaria tener la opción de pedir una lectura en cualquier momento.
Además de servir de puente entre el Hardware y las demás capas la capa inferior se ocupará de la comunicación de ProDia con el exterior en los procesos de Testeo (ProDiaSimulator) e Instalación y Despliegue (ProDiaConfigurator) del sistema. Veremos con detalle en secciones siguientes la necesidad y el desarrollo de un software independiente que nos permita realizar simulaciones hardware y que además se adapte para la posterior instalación y despliegue de ProDia en la casa del atendido. Por la estructura de nuestro sistema esta comunicación entre el software de testeo y despliegue y ProDia se realizará a través de esta capa.
La capa inferior recibirá comandos desde ProDiaSimulator y ProDiaConfigurator que transformará en cambios estructurales en el caso de ProDiaConfigurator (nueva habitación, nuevo sensor,...) y cambios en los sensores para ProDiaSimulator (detecta movimiento sensorX,...). Estos comandos se verán en detalle en secciones siguientes donde se explicará el uso e implementación de ProDiaSimulator y ProDiaConfigurator.
En la siguiente figura se especifican los diferentes canales de comunicación entre la esta capa y el exterior y a la inversa.
41/86
42/86
Ilustración 10: OCP y su Comunicación con el exterior
5.4 CAPA INTERMEDIA: RAZONAMIENTO AUTÓMATA
A partir de la información contextual, captada y tratada por la capa inferior, esta capa debe ser capaz de inferir el estado actual del atendido, detectando si este se encuentra en una situación de emergencia que deba ser tratada. Como se ha comentado, nos basamos en sensores de presión, movimiento y apertura de puerta para mantener en todo momento la localización del atendido en su hogar.
La localización y la actividad o inactividad del individuo y el momento del día que se están registrando estos hechos nos basta para llegar a detectar posibles situaciones de emergencia. Por ejemplo, para la detección de un desvanecimiento o caída nos basamos en una inactividad excesiva producida dentro de un contexto en el no es normal dicha inactividad, el contexto estará constituido por la localización y momento del día de esa inactividad. Es decir, si tenemos localizado al atendido en el pasillo, de madrugada y durante un periodo de tiempo excesivo, las probabilidades de que se trate de una caída o desvanecimiento son muy altas, nuestro sistema actuará ante tal emergencia.
La implementación final del sistema queda en un autómata que recoge todos los estados posibles, consiguiendo definir un patrón de comportamiento general y todas aquellas situaciones que constituyen un estado potencial de emergencia. Las transiciones entre los diferentes estados vendrán definidas por un conjunto de reglas, estas reglas deben tener en cuenta el estado en el que se encuentre el usuario para controlar de esta manera las transiciones no válidas del autómata.
5.4.1 ESTADOS
El sistema inicial contará con los siguientes dispositivos: sensores de movimiento, sensores de presión y sensores de apertura de puerta. Gracias a estos dispositivos y a la información estructural de la casa del atendido podremos inferir los siguientes estados en los que se encontrará el atendido. Estos nos serán suficientes para la detección de una posible emergencia en la casa. Veamos con detalle cada uno de ellos.
● Activo: define el estado de actividad normal del atendido. Llegamos hasta él a partir de la detección de actividad en cualquiera de los dispositivos detectores de movimiento de la casa. A la llegada de este estado siempre actualizaremos la localización del atendido ya que cualquier detección de movimiento en uno de los sensores hará que la localización del atendido pase a aquella donde esta instalado el sensor (siempre que la inferencia de esta localización sea consistente, es decir, exista sólo una localización posible).
Debe ser diferenciada la actividad normal de aquella que pueda llegar a ser preocupante y por tanto signo de una posible emergencia. Para conseguir detectar esta inactividad anómala se iniciará el timer de InactividadAnómala parametrizado según la localización y el momento del día en que nos encontremos. Este timer se eliminará y/o cambiará al salir del estado de actividad o simplemente al localizar esta actividad en una habitación diferente.
43/86
● Activo Inconsistente: nos especifica un estado de actividad normal similar al anterior pero con la característica de que la localización en la que se ha detectado el último movimiento, y que por tanto nos ha llevado a este estado, no es alcanzable desde la localización anterior del atendido. Por ejemplo si nuestra localización actual es el baño y la siguiente percepción se detecta es en el salón y no existe entre ambas ninguna conexión (puerta) que haga posible esta transición. Este estado, en principio, nos indica una actividad normal del atendido con lo que no conlleva ningún signo de emergencia vital. Si que nos indica que existe algún problema en la detención de actividad en la casa.
Es posible que alguno de los dispositivos sensores de las habitaciones intermedias no esté funcionando correctamente ya sea por problemas técnicos o por una mala calibración del mismo. Por ello este estado, a pesar de que no conforma mayor conocimiento sobre el estado vital del atendido, nos informa de posibles problemas técnicos en la instalación de ProDia.
● Inactivo: definirá un estado de inactividad normal del atendido. Hemos visto antes que en la mayoría de casos la inactividad será la que nos lleve a un posible estado de emergencia, aun así este estado de inactividad nos ofrece exactamente la misma tranquilidad que el estado Activo. Los momentos de inactividad son muy habituales durante el día, no siempre estamos en movimiento, y por tanto no siempre nos detectan los sensores de movimiento.
Este estado de inactividad será el intermedio entre el estado de Actividad normal y un estado de Inactividad anormal con posible emergencia.
Llegamos hasta él desde un estado de actividad y a partir de la finalización del Timer de Inactividad que hemos visto anteriormente. Nos indicará por tanto que el atendido lleva un tiempo determinado (timerInactividad) en el que no se ha movido o al menos los dispositivos no lo han detectado.
Será a partir de esta inactividad donde se iniciarán los timers que nos llevan a una inactividad anómala. Es decir, llegados a este estado y a partir de los parámetros que intervienen en los timers de inactividad anómala (localización y momento del día) se lanzará el timer correspondiente y nos llevará al estado de emergencia si no se vuelve a detectar actividad en el hogar, desde el momento de su inicio hasta la finalización de este timer.
Esta inactividad podemos concretarla en dos tipos específicos en los que el atendido está inactivo pero en los que tenemos la certeza de que se encuentra sentado en el sofá o tumbado en la cama.
44/86
○ Dormido: un sensor de presión instalado en la cama del atendido detectará que este se encuentra acostado en su cama. Este dato unido al estado de inactividad visto anteriormente nos lleva a pensar que se encuentra dormido o al menos en reposo. Gracias a esta especificación seremos capaces de discernir entre un estado de inactividad excesiva que se produce en la habitación del atendido. Ante el mismo tiempo de inactividad localizando al atendido en su dormitorio no nos alarmaremos si tenemos constancia de que se encuentra acostado en su cama, si esto no es así es posible que esa inactividad nos lleve a una emergencia. Tendremos por tanto timers de diferente tiempo dependiendo de si se trata de una inactividad o una inactividad especifica en la cama o en el sofá.
○ Descansando: estado idéntico al anterior. Su única variación sera la localización del atendido sentado en su sillón o sofá del salón. Se rige por las mismas reglas vistas en el estado Dormido.
● Inactivo Anómalo: llegaremos hasta este estado a partir de alguno de los tres estados de inactividad anteriores (Inactivo, Dormido y Descansando). La finalización del timer de inactividad anómala activado en los estados de inactividad será lo que nos haga llegar hasta este estado de alarma. Este estado sí nos lleva a una situación potencial de emergencia, será a partir de él donde se activará el proceso de verificación e iremos subiendo el nivel de alarma conforme vayamos realizando los diferentes pasos del protocolo de actuación ante una situación de emergencia.
Dado que a partir de este estado se desencadena todo el procedimiento de verificación ante una posible emergencia los timers que nos llevan hasta él deben ser lo suficientemente amplios para que las falsas emergencias sean mínimas. Además de que el procedimiento a seguir debe pasar inicialmente por un estado de verificación del estado actual del sistema. En él se verificará el corrector funcionamiento de cada uno de los dispositivos ya que es el estado de estos (no percepción de actividad) lo que nos lleva a esta emergencia.
● Activo Anómalo: este estado define una situación de actividad por parte del atendido en la que según la localización donde se está dando y el tiempo que lleva produciéndose nos hace pensar que algo raro está ocurriendo. Llegaremos a este estado a partir de la finalización del timer de actividad anómala que es activado en los estado de actividad normal (activo o activo inconsistente).
Al igual que en el caso del estado Inactivo Anómalo se comenzará el procedimiento de verificación ante un estado potencial de emergencia. Por la naturaleza de este estado de alarma debemos ser cautelosos en la definición tanto de los timers que nos llevan a él como del proceso de verificación que desestime o afirme este estado de emergencia. Por lo general la actividad es un signo inequívoco de vida, a pesar de esto hay que tener en cuenta que la
45/86
actividad viene dada por unos dispositivos hardware que pueden fallar, o que simplemente esta actividad no es tal, por ejemplo si el atendido ha caído y está intentando incorporarse.
En todo momento estamos hablando de una actividad continuada en una determinada localización, saldríamos de este estado al detectar actividad en cualquier otra localización o al dejar de detectar actividad.
● Ausente: se activará este estado al detectar que el atendido ha salido. Para la detección de este estado nos basaremos en el sensor de apertura de puerta colocado en la puerta principal de la casa y el timer de ausencia que se activará al detectar la apertura y el posterior cierre de esta. Ya se comentó en la definición del timer de ausencia que este debía de ser lo suficientemente amplio para no llegar nunca a un estado de falsa ausencia.
A partir de este estado sólo seremos capaces de volver a un estado normal de actividad al detectar de nuevo la apertura y cierre de la puerta seguido de actividad en la casa (estado vuelve a casa). Si detectáramos actividad a partir de este estado sin recoger previamente los eventos de puerta nos iríamos a la posibilidad de que exista un intruso en casa (estado Intruso). Como vemos es importante tener la seguridad de que el atendido se ha marchado para llegar a este estado. En cualquier otro caso el sistema no será capaz de funcionar correctamente.
○ Intruso: llegaremos a este estado a partir de detectar actividad desde el estado de ausencia sin haber recibido los eventos de apertura y cierre de puerta. La detección de este tipo de estado no forma parte del objetivo de nuestro proyecto, se define y se consigue detectar como una alarma más del sistema y por tanto debe llevar consigo su procedimiento de verificación posterior a la detección. Aun así es un estado definido en el proceso inicial y se debe estudiar a fondo la necesidad o no de este estado.
● Acompañado: indica que el atendido se encuentra acompañado por alguien más en su casa. A partir de este estado el sistema dejará de detectar cualquier anomalía en los hábitos del atendido ya que suponemos que se encuentra acompañado y por tanto a salvo de cualquier emergencia.
Detectaremos que estamos en este estado a partir de los eventos de apertura y cierre de puerta seguidos de un patrón de comportamiento que nos de indicios de que existen al menos 2 personas en la casa. En este patrón se incluye la detección de sucesivas inconsistencias de localización al detectar actividad en varias localizaciones a la vez, detectar presión en sofá o cama y estar a la vez detectando movimiento en otra habitación diferente,...
46/86
Como vemos la llegada a este estado nos lleva a la “desactivación” de los procesos de detección de emergencias del sistema. Por ello debemos estudiar con detenimiento la definición del patrón acompañado y tener la certeza de que este cumple para llegar a este estado. Saldremos de este estado al volver a detectarse lo eventos de puerta correspondientes y detectar un patrón de actividad normal.
● Acompañado por Asistente: al igual que el anterior estado detecta que el atendido se encuentra acompañado y desactivará la detección de cualquier emergencia. La diferencia viene en que en este caso está acompañado por el asistente que periódicamente pasará por su casa a realizar las labores del hogar o simplemente a visitarlo. En este caso la detección será muy sencilla ya que el asistente debe fichar su entrada y su salida. Serán por tanto los eventos de fichaje lo que nos lleven a entrar o salir de este estado.
Hay que tener en cuenta los posibles olvidos de fichaje tanto de entrada como de salida. En el caso de olvidar el fichaje de entrada simplemente pasaríamos al estado acompañado visto anteriormente. Además podríamos utilizar la hora de entrada al estado acompañado para verificar el horario del asistente, en caso de que se olvide el fichaje de entrada.
Para el olvido del fichaje de salida se aplicará los últimos eventos de puerta recibidos a partir de este estado.
En la siguiente figura se puede ver el diagrama de estados del autómata simplificado con los eventos y/o características que van guiando las transiciones entre estados. El conjunto de reglas que forman parte de la base de conocimiento de la capa intermedia controlarán las transiciones entre los estados.
47/86
Ilustración 11: Autómata Finito Determinista
La máquina de estados anterior resume de manera muy breve el comportamiento básico del sistema.
Como ejemplo veamos como inferirá el sistema que el atendido ha salido de su casa y como detectará su llegada. Para estas transiciones el sensor de puerta es un elemento clave, tanto la transición hasta el estado Absentee como su opuesta hasta Active van precedidas por un evento de apertura de puerta y su siguiente de cierre de puerta. A partir de estos eventos el sistema esperará un tiempo determinado, en este tiempo si detectamos actividad pasaremos directamente a Active, en caso de no detectar actividad pasado este periodo de tiempo el sistema inferirá que el atendido ha salido de la casa.
Con este tiempo de espera, que se traducirá en implementación en un Timer de ausencia (TimerAbsent), evitamos que estando dentro de la casa el sistema pase a Absentee si abrimos y cerramos la puerta y nos quedamos dentro. De igual modo evitamos que el sistema crea que hemos vuelto si estamos ausentes y volvemos a casa, abrimos la puerta cogemos algo y volvemos a salir.
El siguiente diagrama explica en detalle la transición entre estos dos estados.
49/86
Ilustración 12: Transición entre estados Active y Absentee
5.4.2 REGLAS SWLR E INFERENCIA
Las reglas que interviene en dicha inferencia están codificadas mediante SWRL, se ha utilizado está tecnología ya que la inferencia se realiza directamente sobre la información contextual, en este caso representada mediante una ontología.
Para el razonamiento se utilizará la potencia de Pellet y Jena con este tipo de reglas. Se razonará a partir de los cambios realizados por la capa inferior y se conseguirá el nuevo estado del atendido. El conjunto de reglas será el responsable del razonamiento inteligente del sistema, por ello es lo suficientemente rico como para abarcar los diferentes cambios de estado que se producen en un patrón de comportamiento normal y todos aquellos cambios que nos llevan a un estado de emergencia.
Veamos algunos ejemplos de las reglas SWRL que utilizar nuestro sistema para inferir los cambios de estado del atendido.
En la siguiente figura se puede ver un ejemplo de la regla que controla la transición al estado Activo. A partir de las propiedades del contexto (ontología) detectamos movimiento en alguna de las habitaciones y actualizamos el estado del atendido y su localización. Además se comprueba si la habitación dónde se ha detectado el movimiento es adyacente (o es la misma) que la localización actual. Es decir, es un movimiento posible.
Rule Active:
Treated(?x) ᐱ location(?x,?y) ᐱ MoveSensor(?s) ᐱ detectMove(?s,true) ᐱ inside(?s,?r) ᐱ HabitableSpaceInABuilding(?r) ᐱ haveConnection(?r,?c) ᐱ connectionWith(?c,?c1) ᐱ equal(?y,?c1)
state(?x,”Activo”) → ᐱ location(?x,?r)
Para la detección del estado de Inactividad nos basaremos simplemente en la finalización del timer de inactividad. Como se ha comentado antes este timer se inicia al entrar en el estado de actividad, se reiniciará en cada detección de movimiento y se eliminará al salir de este estado. Por tanto para llegar al estado de inactividad sólo tendremos que comprobar que existe un timer de inactividad finalizado.
Rule Sleep:
Treated(?x) ᐱ location(?x,?y) ᐱ PressSensor(?s) ᐱ detectPress(?s,true) ᐱ inside(?s,?r) ᐱ Bedroom(?r) ᐱ equal(?r,?y)
→ state(?x,”Sleep”)
50/86
5.5 CAPA SUPERIOR: METARAZONADOR
La capa superior se encarga de realizar dos tareas diferentes:
● Resolución de las inconsistencias encontradas en la capa intermedia (varios estados posibles, varias localizaciones,...)
● Actuación con el entorno (envío de alertas en una situación potencial de emergencia...)
● Razonamiendo complejo
Este proyecto fin de carrera abarca sólo la primera de las tareas de esta capa, aún así han quedado definidas las otras dos tareas para trabajos posteriores.
5.5.1 RESOLUCIÓN DE INCONSISTENCIAS
A partir de la arquitectura de la capa intermedia las inconsistencias surgen por la activación de dos o más reglas que nos den varios valores para alguna de las propiedades que definen el estado del atendido. Por ejemplo, el razonamiento en la capa anterior puede llevarnos a inferir dos estados diferentes en el mismo momento, esto es posible porque en la definición de las reglas, que nos llevan a uno u otro estado, se han creado teniendo en cuenta sólo la naturaleza del propio estado, sin tener en cuenta para nada los estados con los que se pueda solapar.
Un ejemplo de esto sería el solapamiento entre los estados Inactivo y Descanso o Dormido. Descanso y Dormido definen un tipo concreto de inactividad en el que el atendido se encuentra en cama o en el sofá. Sin embargo los dos estados incluyen a la inactividad. Por lo tanto siempre que se active los estados Rest o Sleep coincidirán con la activación del estado Inactive.
Otro caso común de inconsistencia es el producido por la detección de más de una localización para el atendido a la vez. La detección de movimiento en dos habitaciones diferentes de la casa a la vez nos daría múltiples localizaciones para el atendido.
En todos estos casos será la capa intermedia la que detecte que el razonamiento nos ha llevado hasta un estado de inconsistencia (múltiples valores para alguna propiedad de valor único), al detectar esto avisará a esta capa para que proceda y consiga un entorno consistente.
La resolución de inconsistencias se realizará a partir de reglas, utilizaremos el mismo procedimiento que para las transiciones entre estados de la capa anterior. Las reglas definirán ante un solapamiento de estados el procedimiento a seguir para resolver cada inconsistencia. Un ejemplo sencillo es el visto anteriormente con los estados Inactivo y Descanso o Dormido, en este caso el procedimiento a seguir es muy simple, nos quedaremos con el estado más concreto, es decir, frente a Inactivo siempre nos quedaremos con Descanso o Dormido.
51/86
Rule RestInactive:
Treated(?x) newState(?x,?s) newState(?x,?s1) equal(?s,”Inactive”) equal(?s1,”Rest”)ᐱ ᐱ ᐱ ᐱ
deletePropertyValue(?x,?s) state(?x,”RestInactive”)→ ᐱ
Además se indica en el nuevo estado el tipo de inconsistencia que se ha resuelto para que el Metarazonador pueda realizar un procesamiento posterior si fuera necesario.
Veamos el ejemplo de la múltiple localización:
Rule ActiveActive:
Treated(?x) newState(?x,Active) newLocation(?x,?l) newLocation(?x,?l1) notequal(?l,?ᐱ ᐱ ᐱl1) equal(?s1,”Rest”)ᐱ
state(?x,”ActiveActive”)→
En este caso se necesita la intervención del Hardware para la resolución de esta inconsistencia, por ello la regla simplemente avisará del tipo de inconsistencia que se ha producido. El procesamiento posterior al encontrar esta inconsistencia será la comprobación de cada uno de los sensores de movimiento de la casa. Si después de la comprobación sigue existiendo la misma inconsistencias (dos o más detectan movimiento a la vez en diferentes localizaciones) se optará por elegir una localización al azar (preferiblemente la última localización consistente si fuera posible).
El histórico de estas inconsistencias de localización nos pueden llevar a detectar posibles solapamientos entre los sensores de la casa.
Hay que tener en cuenta que es posible llegar a un estado de inconsistencia compleja en el que se hayan producido varias inconsistencias a la vez. Para resolver estos estados partimos de que conocemos y sabemos resolver todos los tipos de inconsistencias simples. Un estado de inconsistencia compleja estará compuesto por varias inconsistencias simple, por tanto, nuestro sistema deberá ir resolviendo por separado cada una de las inconsistencias simples. Es posible que se necesiten varias iteraciones para conseguir un estado consistente.
La siguiente figura muestra el proceso de resolución de inconsistencias, desde que se produce algún cambio en el contexto detectado por los sensores hasta que la capa superior soluciona las inconsistencias detectadas por la capa intermedia, en caso de que existan.
52/86
Como vemos después de realizar el proceso de resolución de inconsistencias se chequea la consistencia del contexto, si este no es consistente se realizará una nueva iteración. Se ha estudiado con detenimiento todos los tipos de inconsistencias que pueden surgir, por ello se tiene la seguridad de que el procesos de resolución siempre conseguirá un contexto consistente y podrá seguir la ejecución normal del sistema.
53/86
Ilustración 13: Resolución de múltiples inconsistencias
5.5.1.1 TIPOS DE INCONSISTENCIAS
Veamos uno a uno los tipos de inconsistencias que pueden surgir en el sistema, como detectarlos y como los resolverá el sistema.
5.5.1.1.1 ActividadInactividad
Se produce al coincidir la finalización de algunos de los timers de inactividad (TimerInactividad o TimerInactividadAnomala) con un evento de movimiento. El razonamiento producido por cualquiera de los 2 eventos nos lleva a dos estados diferentes, uno de ellos indica actividad (Active o ActiveInconsistent) y el otro inactividad (Inactive, InactiveAnomalus, Rest, Sleep o Absentee).
Se detecta a partir de que el razonador nos devuelve al menos 2 estados diferentes. El metarazonador contiene un conjunto de reglas para la detección de estos casos, cada una de ellas especifica el solapamiento de 2 de los estados que se han definido. El razonamiento con estas reglas nos dará como resultado el tipo de inconsistencia a tratar (ActiveInacte, ActiveRest,...). Tenemos la información de los 2 estados que han producido la inconsistencia.
En los estados que aquí se detallan siempre deberá prevalecer la actividad frente a la inactividad. La finalización de cualquier timer de inactividad deja de tener efecto al volver a detectarse actividad.
El ejemplo más común de esta inconsistencia es el siguiente:
Se detecta movimiento en alguno de los sensores.
Se inicia el timer de inactividad
Se sigue detectando movimiento en el sensor. Al no cambiar de estado los sensores no avisan a ProDia. El timer sigue contando...Termina el timer y se produce razonamiento. Sólo en este momento ProDia vuelve a tener constancia de que sigue el movimiento ya que no existen cambios en el contexto y el sensor sigue activo. En este momento reiniciamos el timer de inactividad. La finalización de este timer es la que ha disparado el razonamiento ya que sólo los timers o los cambios en el contexto pueden disparar el razonamiento.
5.5.1.1.2 ActividadActividad
Se produce al coincidir la activación de varios sensores de movimiento de diferentes habitaciones a la vez.
El razonador nos devolverá al menos 2 localizaciones diferentes y es posible que nos devuelva 2 estado diferentes, Active y ActiveInconsitent. El Metarazonador posee las reglas suficientes para detectar la activación de 2 o más localizaciones y el solapamiento de Active y ActiveInconsistente. El razonamiento con estas reglas nos dará como resultado el tipo de inconsistencia a tratar (ActiveActive o ActiveActiveInconsitent).
En ambos casos, ActiveActive y ActiveActiveInconsistent serán tratados de igual manera. Se
54/86
solicitará una nueva lectura a los sensores y se volverá a razonar con los nuevos datos. Se debería trazar un plan de acción para los casos en los que no conseguimos consistencia después de n iteraciones.
En principio, este tipo de inconsistencia se dará en casos muy puntuales y en periodos cortos de tiempo. Por ejemplo, debido a que dos sensores en habitaciones contiguas tengan algún punto en el que los dos detectan al atendido. Con lo cual en el razonamiento incluso podríamos simplemente elegir alguna de las localizaciones para conseguir una ontología consistente y esperar a que el contexto vuelva a un estado consistente.
5.5.1.1.3 InactividadDormido/Descansando
Los estados Dormido y Descansando son unos tipos concretos de inactividad. Por ello su activación siempre coincidirá con la activación del estado de inactividad general (Inactive) ya que Dormido y Descansando se definen como Inactividad más una localización concreta y un sensor de presión activado.
Se detectan a partir de la activación de los estados Inactive y Rest o Inactive y Sleep. La capa superior nos especificará el tipo de inconsistencia a tratar.
Ambos casos, InactiveRest e InactiveSleep serán tratados de igual manera. Simplemente se elimina el estado Inactive y nos quedamos con el estado de inactividad concreta, Rest o Sleep.
Este tipo de inconsistencias podría evitarse se definimos el estado Inactive de manera que excluya a los otros dos estado (Sleep y Rest). En principio no se ha hecho así porque la definición del estado Inactive perdería contenido.
5.5.1.1.4 ActividadIntruso
El estado Intruder es un tipo concreto de actividad. Para diferenciar la actividad normal de una actividad que podría venir de intruso existe un estado intermedio (ActiveAgain) al que llegamos al recibir los eventos de apertura de puerta. Cualquier actividad que se produzca desde Absentee sin pasar por ActiveAgain será tomada como un intruso. Por ello tenemos que el estado Intruder es simplemente un estado de actividad en el que incluimos que el estado actual sea Abseente.
Se detectan a partir de la activación de los estados Active e Intruder.
Al igual que pasa con los estados concretos de inactividad (Rest y Sleep) simplemente eliminaremos el estado Active para quedarnos con el estado concreto de actividad Intruder que es el que nos interesa.
Este tipo de inconsistencias podría evitarse se definimos el estado Active de manera que excluya al estado Intruder. Pero como se ha comentado con en puntos anteriores de esta manera estamos
55/86
perdiendo el significado del estado Active.
5.5.2 ACTUACIÓN
Un punto clave del sistema es su actuación ante un estado potencial de emergencia. Cuando la capa inferior detecta una situación anormal que puede tratase de una emergencia notifica a la capa superior. El metarazonador al recibir una notificación de emergencia lo primero que hará será comprobar que el estado de emergencia inferido no se debe a un mal funcionamiento de los sensores. Después de realizar un chequeo completo de los dispositivos de percepción está preparado para lanzar la “voz de alarma” al exterior.
Después de estudiar los posibles sistemas de comunicación con el exterior se decidió utilizar el SMS. El sistema emitirá un SMS con toda la información sobre la emergencia que se ha producido y este será recogido en una central de alarmas. La implementación de la central de alarmas y el procedimiento de envío de SMS's desde Prodia no forman parte de este Proyecto Fin de Carrera.
La idea inicial es que la central de alarmas al recibir una emergencia realice una llamada telefónica a la casa del atendido. El simple hecho de coger esa llamada sacaría al sistema del estado de emergencia, si este fuera a causa de una inactividad prolongada.
5.5.3 RAZONAMIENTO COMPLEJO
En el proceso de razonamiento que actualmente se ha implementado sólo se tiene en cuenta el estado actual del contexto, se trabaja en todo momento con los últimos eventos producidos por cada sensor. Este hecho limita de alguna manera la capacidad de razonamiento del sistema ya que no se apoya en datos históricos del sistema.
La idea a desarrollar es que se pueda realizar razonamientos más complejo teniendo en cuenta el comportamiento histórico del atendido que previamente ha sido almacenado en forma de eventos. Por ejemplo, podríamos detectar que el atendido no ha comido si no ha pasado por la cocina durante el rango horario en el que suele pasar por ahí.
56/86
5.6 SALIDA DEL SISTEMA
Por la naturaleza del sistema su única información de salida, en principio son los mensajes de alerta que enviaría al receptor de alarmas. No es un sistema usado directamente por el usuario, el sistema está trabajando y el usuario (en este caso el atendido) no necesita recibir ni visualizar de ningún modo la ejecución del sistema. Es evidente por tanto que no posee en instalación ninguna interfaz de usuario.
Lo que sí es necesario es que el sistema genere logs que nos permitan evaluar el funcionamiento del sistema a posteriori, los eventos recibidos y las decisiones tomadas en cada capa del sistema.
Aún así se ha desarrollado una interfaz de usuario para poder mostrar el funcionamiento del sistema a personas ajenas a este desarrollo.
Veamos más a fondo los dos tipos de salidas.
5.6.1 LOGS POR CAPAS
Necesitamos tener de manera organizada las salidas que se producen desde cada capa del sistema a partir de los estímulos del exterior. Por ello se decide tener un log de salida por cada una de las 3 capas.
Como vemos en la imagen cada capa genera un fichero de log diferente con las salidas que va generando.
57/86
Ilustración 14: Salida del sistema por capas
Para poder ver de manera general el funcionamiento completo del sistema se genera además de estos tres ficheros un log que uniría la información de los otros tres.
Además se ha definido tres niveles de logs: Min, Default y Max, a partir de los cuales el sistema generará más o menos información.
La capa inferior generaría un logs con los eventos ya procesados y contextualizados provenientes de los sensores. Nos da información del tipo de estimulo que recibe, el identificador del dispositivo que lo ha enviado y la habitación en el que está instalado dicho dispositivo. A parte de esta información también nos ofrece datos sobre el nivel de pilas, temperatura de la habitación,... que en este caso no es tan importante.
[OCP : Day 15 1 2009 , 00 : 59 : 59] :Atributeidentify : 35
[OCP : Day 15 1 2009 , 00 : 59 : 59] :Atributevoltage : 2883
[OCP : Day 15 1 2009 , 01 : 00 : 04] :Change Context: sensor350
[OCP : Day 15 1 2009 , 01 : 00 : 04] :Atributelocation : aseo
[OCP : Day 15 1 2009 , 01 : 00 : 04] :Atributetemprature : 19
[OCP : Day 15 1 2009 , 01 : 00 : 04] :Sensor : sensor350 detected MOVE: true
La capa intermedia nos ofrecería información sobre los cambios de estado y localización que se van produciendo además del inicio, parada o finalización de los timers en ejecución. Para mayor información nos ofrece el resultado de la inferencia en la ontología (sólo en el nivel Max de logs).
Además cuando se detecta una inconsistencia nos informará del tipo de inconsistencia que ha detectado (dos o más localizaciones o dos o más estados) y de que se va a lanzar el metarazonador.
[ Reasoner : Day 15 1 2009 , 00 : 59 : 52] :Reasoning...
[ Reasoner : Day 15 1 2009 , 00 : 59 : 53] :Rules deducted
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22rdfsyntaxns#"
xmlns:j.0="http://www.owl.ontologies.com/ProDia.owl#" >
<rdf:Description rdf:about="http://www.owl.ontologies.com/ProDia.owl#casaCT">
<j.0:newLocation rdf:resource="http://www.owl.ontologies.com/ProDia.owl#aseo"/>
<j.0:newState rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Active</j.0:newState>
</rdf:Description>
</rdf:RDF>
[ Reasoner : Day 15 1 2009 , 00 : 59 : 53] :End Reasoning...
[ Reasoner : Day 15 1 2009 , 00 : 59 : 53] :Consistent Ontology
[ Reasoner : Day 15 1 2009 , 00 : 59 : 53] :Timer TimerInactive Removed
[ Reasoner : Day 15 1 2009 , 00 : 59 : 55] :Timer TimerInactive Start
[ Reasoner : Day 15 1 2009 , 00 : 59 : 55] :New State Active
58/86
[ Reasoner : Day 15 1 2009 , 00 : 59 : 55] :New Location aseo
En la capa superior el metarazonador nos informará de las inconsistencias que se van produciendo y de su resolución. Al igual que la capa anterior también nos ofrece el resultado en crudo de la inferencia sobre la ontología.
[ MetaReasoner : Day 14 1 2009 , 16 : 18 : 29] :Solving inconsistencias....
[ MetaReasoner : Day 14 1 2009 , 16 : 18 : 30] :Rules deducted
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22rdfsyntaxns#"
xmlns:j.0="http://www.owl.ontologies.com/ProDia.owl#" >
<rdf:Description rdf:about="http://www.owl.ontologies.com/ProDia.owl#casaCT">
<j.0:newState rdf:datatype="http://www.w3.org/2001/XMLSchema#string">ActiveActive</j.0:newState>
</rdf:Description>
</rdf:RDF>
[ MetaReasoner : Day 14 1 2009 , 16 : 18 : 30] :Solved inconsistence ActiveActive
[ MetaReasoner : Day 14 1 2009 , 16 : 18 : 30] :Consistent succeede
5.6.2 INTERFAZ GRÁFICA
La interfaz nos muestra el estado y la localización actual del atendido junto con los logs que va generando cada una de las 3 capas. Además nos muestra el tiempo actual y un control del tiempo, sólo útil en las simulaciones, con el que podemos parar, o acelerar el tiempo de simulación del sistema.
59/86
60/86
Ilustración 15: Interfaz gráfica de Prodia
6 A. HERRAMIENTAS AUXILIARES DESARROLLADAS
6.1 INSTALACIÓN Y DESPLIEGE: PRODIACONFIGURATOR
El despliegue del sistema necesita una configuración previa en la que se especificará la estructura de la casa del atendido y los sensores de los que dispondrá en sistema. Para llevar a cabo esta tarea se ha desarrollado un Software adicional que se comunica mediante comandos simples con Prodia y con el que de manera gráfica el usuario podrá configurar la casa a instalar.
La configuración del sistema se realiza en 3 pasos:
1. Añadir las habitaciones de la casa, en el que seleccionaremos el tipo de habitación que estamos añadiendo (Salón, Dormitorio, Cocina,...).
2. Añadir las puertas que actúan de conexión entre las diferentes habitaciones.
3. Añadir los sensores a cada una de las habitaciones, se seleccionará la habilidades del sensor (detecta movimiento, presión, puerta,...) y la localización del dispositivo.
61/86
Ilustración 16: Interfaz ProdiaConfigurator
6.2 SIMULACIÓN: PRODIASIMULATOR
Se necesitó desarrollar ProdiaSimulator como software adicional que permitirá probar en la fase inicial de desarrollo el buen funcionamiento de las 3 capas sin utilizar los dispositivos sensores reales.
ProdiaSimulator se ha definido reutilizando el software ya desarrollado para ProdiaConfigurator, nos permite de igual manera configurar la casa del atendido, con habitaciones, puertas y sensores y además procesar una historia completa de eventos que podría simular los eventos reales de una casa.
Por la estructura en la que está incluido ProDiaSimulator será necesario que este sea capaz de crear una estructura y realizar una determinada simulación a partir de un fichero que contenga la lista de comandos a realizar. De igual manera ProDiaSimulator será capaz de generar un fichero de comandos que refleje todos los cambios de contexto (creación de estructura, eventos de sensores…) a partir una simulación realizado con la ayuda de la interfaz gráfica.
Para poder realizar simulaciones de por ejemplo una noche entera en un tiempo razonable se da la posibilidad de aumentar la velocidad del tiempo de simulación, es decir, se podrá el tiempo en el que se corresponder un segundo real a uno de simulación.
6.2.1 FICHERO DE SIMULACIÓN
El fichero de comandos constará de 3 bloques diferenciados por apertura y cierre de bloque. En el primer bloque se incluirán todos los comandos necesarios para definir la estructura de una casa, se diferenciará por HOME y ENDHOME. El segundo bloque define los datos relativos al tiempo de la simulación, se iniciará y terminará con TIMER y ENDTIMER respectivamente. Por último tendremos el bloque que contendrá todos los eventos que deseamos simular. Todos estos eventos irán etiquetados con la marca de tiempo en el que se ejecutan. Se definirán dentro de las palabras clave SIMULATION y ENDSIMULATION
El fichero tendrá por tanto la siguiente estructura:
HOME……ENDHOME
TIMER…..ENDTIMER
SIMULATION…..ENDSIMULATION
62/86
HOME/ENDHOME
Crearemos la estructura la casa a partir de los siguientes comandos que tenemos disponibles. Las palabras en negrita corresponden a palabras clave, las demás son introducidas por el usuario.
addRoom nameRoomAñade una habitación con el nombre indicado
addDoor nameRoom1 nameRoom2Añade una puerta entre las habitaciones indicadas. Para referirnos a partir de este momento a la puerta creada utilizaremos nameRoom1:nameRoom2.
addSensor nameSensor typeSensor locationEl tipo de sensor estará restringido a los siguientes valores: MoveSensor, OpenDoorSensor, PersenceSensor y PersionSensor.
Añade un sensor con el nombre, el tipo y la localización indicada. En la localización incluiremos el nombre de una habitación o el de una puerta, en caso de ser una puerta utilizaremos la notación nameRoom1:nameRoom2 comentada anteriormente.
removeRoom nameRoomremoveDoor nameDoorremoveSensor nameSensor
Los comandos de borrado de habitaciones, sensores o puertas, en principio, no tienen sentido incluirlo en el fichero de comandos. Aún así el simulador está capacitado para realizar esta funcionalidad
TIMER/ENDTIMER
setTime HH:MM:SS
Se especifica la hora de inicio de la simulación.
SetTiming n (milisec)
Tiempo en milisegundos entre cada marca de tiempo. (1000 miliseg sería tiempo real)
addTimer nameTimer typeTimer stateTimer locationTimer momentDayTimerEl tipo de timer estará restringido a los siguientes valores: TimerInactive, TimerInactiveAnomalus, TimerAbsent.
SIMULATION/ENDSIMULATION
HH:MM:SS add personX locationX
63/86
HH:MM:SS move personX locationX
HH:MM:SS modifySensor sensorX nameProperty value
Todos los eventos a ejecutar irán marcados con el momento exacto de su ejecución.
Para las modificaciones de los sensores se especificará el nombre de la propiedad a modificar y el nuevo valor que se desea actualizar, por ejemplo: modifySensor sensorX hasMove true.
Veamos un ejemplo de fichero de simulación.
64/86
Ilustración 17: Ejemplo de fichero de simulación
Añadimos la persona a la estructura
Eventos de la simulación
Hora de comienzo y frecuencia del reloj (1 segundo > 100 milisegundos)
Creación de sensores.Tipos de sensores: MoveSensor, PressSensor y OpenDoorSensor.
Diseño de estructura. Tipos de habitaciones: Outside, Living, Bathroom, Bedroom, Kitchen, Terrace y Corridor.
6.3 DATA MINING Y VALIDACIÓN: PRODIAMONITOR
En el momento en que se realizaron las primeras instalaciones reales surgió la necesidad de validar de alguna manera que el comportamiento del sistema era el adecuado. Hasta ahora hemos visto que se recogían los logs de salida de cada uno de los niveles, chequear el comportamiento del sistema a partir de estos logs es inviable cuando tenemos logs de varios horas, días...
Esta herramienta permite, entre otras cosas, comprobar de manera visual el comportamiento que el sistema ha tenido durante horas, días e incluso meses. Veamos en detalle toda la funcionalidad que nos ofrece.
6.3.1 VISUALIZACIÓN DE RESULTADOS MEDIANTE GRÁFICAS
A partir de los logs de Prodia generará una gráfica para cada dato importante del sistema, en la siguiente figura vemos una de las gráficas generadas, de abajo arriba tenemos los siguientes datos: detección y no detección de los sensores, localización inferida, estado del atendido inferido e inconsistencia tratada y resuelta.
65/86
Ilustración 18: Interfaz ProdiaMonitor
6.3.1.1 BÚSQUEDA DE ESTADOS
ProdiaChart nos permite agregar los logs de un número ilimitado de días, con lo que el tener tanta información representada nos puede crear confusión. Para ello la herramienta nos permite realizar búsqueda de estados inferidos por el sistema y centrar las gráficas generadas en el punto en el que se ha producido alguno de los estados buscados. Esto es muy interesante por ejemplo para ver el número de alarmas que se han producido y poder centrarnos en las condiciones en las que se produjeron dichas alarmas. ProdiaChart nos informará de los estados encontrados y nos dará la posibilidad de centrar la gráfica entre un tiempo establecido, por ejemplo una hora antes y despúes de que sucediera.
66/86
Ilustración 19: Gráficos de las 3 capas
6.3.2 FILTRADO DE DATOS
De igual manera en la que centramos la gráfica a mostrar al realizar las búsquedas vistas anteriormente, ProdiChart nos permite generar una gráfica filtrando los datos a partir de otra gráfica. Por ejemplo si tenemos la gráfica desde el día 1 a las 9 de la mañana hasta el día 2 a la misma hora podríamos generar una nueva gráfica que nos mostrará sólo el comportamiento desde las 12 de la mañana hasta las 3 de la tarde, para ver de manera más clara y profundizar en el comportamiento del sistema durante estas horas.
6.3.3 ESTADÍSTICAS DE LOCALIZACIÓN DEPENDIENDO DEL MOMENTO DEL DÍA
Resulta interesante para poder realizar una adaptación del sistema al atendido el tener datos
67/86
Botón de filtrado
Área a filtar
Ilustración 21: Filtrado de Gráficos
Ilustración 20: Búsqueda de estados en Gráficos
Búsqueda de estado Sleep y centrado en 2:30
estadísticos sobre su localización durante todo el día. Saber donde pasa la mayor parte de la mañana, la habitación donde suele estar por la tarde..., son datos interesantes para poder detectar cambios en el comportamiento del atendido y poder adaptar nuestro sistema a estos cambios o incluso actuar si el comportamiento es preocupante.
ProdiaChart nos permite generar gráficos de localización del atendido organizados por momento del día o por localización. La herramienta utilizará los datos de localización que contiene los logs de entrada y generará gráficas como las siguientes:
68/86
Ilustración 22: Estadísticas de localización
69/86
6.3.4 ESTUDIO DE TIMERS PARA ADAPTACIÓN
Una de las siguientes tares que queda pendiente a partir de la finalización de este proyecto es desarrollo de la adpatación de los timers que generan alarmas al comportamiento del atendido.
Como ya hemos dicho se definen timers que dependen de la localización y el momento del día en el que se activen. Es necesario que nuestro sistema diferencie una inactividad de 10 minutos en el salón por la tarde y el mismo tiempo de inactividad pero producido en el pasillo de la casa y de madrugada.
A pesar de que este proyecto no incluye el desarrollo de esta adaptación sí se ha desarrollado un modulo en ProdiaChart que nos permite estudiar a fondo el comportamiento de los timers.
Para el estudio del comportamiento y posterior adaptación de los timers es interesante utilizar los tiempos de anulación que se suceden en el sistema a partir del comportamiento del atendido. Este dato nos revela los tiempos de actividad o inactividad continuada en una misma habitación. Por ejemplo, al entrar en en salón se activará el timer de ActividadAnomala del salón, el timer comenzará a contar hasta un límite establecido en el que sería alarmante dicha actividad, cuando el atendido salga de esa habitación o pase a estar inactivo se anulará dicho timer. Ese tiempo de anulación nos da el tiempo exacto de actividad que ha pasado el atendido en el salón en ese momento del día. De igual manera con los timers de inactividad.
El módulo de estudio de timer de ProdiChart utilizará los logs que selección el usuario extraerá toda la información de los timers, mostrando de manera gráfica los tiempos de anulación de cada timer y
70/86
Ilustración 23: Estadísticas de localización por momento del día
además proporcionando los tiempos máximos por día y una media móvil para cada timer.
Para tener mayor información se ha agrupado la información de todos los timers de un mismo tipo para una habitación, de manera que agrupamos en el mismo gráfico la actividad registrada en los diferentes momentos del día.
En la siguiente imagen se puede ver los datos del timer de Actividad del dormitorio durante la madrugada a la izquierda. Los datos reales recogidos corresponden a la gráfica roja, en azul se pueden ver los máximos alcanzados por día y en verde una media móvil. A la derecha de la imagen vemos los datos agregados para la actividad en el dormitorio, en este caso se agrupan los datos de la madrugada, mañana, medio día, tarde y noche.
Es interesante poder trabajar con estos datos numéricos, por ello este módulo también nos ofrece esta posibilidad utilizando el botón “Save Data” que veíamos en la imagen anterior.
6.3.5 DATOS .ARFF PARA WEKA
Para poder realizar procesamiento sobre muchos de los datos que hemos mostrado gráficamente con esta herramienta se da la posibilidad de guardar diferentes datos en el formato .arff de Weka.
Los tipos de ficheros que podemos guardar son los siguientes:
• Información total del sistema organizada en tuplas: para cada cambio que se produce en el sistema se genera una nueva tupla. En cada tupla se especifica la hora de generación, los sensores activos en ese momento, timers activos o finalizados, estado y localización inferida
71/86
Ilustración 24: Gráficas de timers
y si se está produciendo alguna inconsistencia.
• Tiempos de anulación de timers: una tupla por timer anulado en la que se incluye la marca de tiempo de la anulación, el identificador del timer anulado, y el tiempo que ha pasado desde su activación a la anulación.
• Estadísticas de localización: muestran una tupla por cada cambio de localización, se incluye la marca horaria del cambio, la nueva localización, el momento del día en que se produce y el tiempo de estancia en esta localización.
72/86
7 VALIDACIÓN DEL SISTEMA
7.1 PRUEBAS DE VALIDACIÓN En esta sección se detalla el protocolo de pruebas que se llevará a cabo en las primeras casas instaladas con el fin de probar el correcto funcionamiento del sistema.
Se indica un conjunto de casos de prueba definidos por el equipo de trabajo de Prodia que definen el funcionamiento básico del sistema. La correcta ejecución de estos casos asegura que el sistema reacciona de la manera adecuada y que por tanto está preparado para el aviso de cualquier posible emergencia.
Se especifica la infraestructura de comunicaciones necesaria para llevar a cabo el conjunto de pruebas, la preparación del sistema para las pruebas, indicando de manera detallada las modificaciones que se realizarán en Prodia. Por último se relata el conjunto de casos de prueba a ejecutar por el Probador en la casa de la atendida. Cada caso incluye la actuación del Probador y la
salida que Prodia debe proporcionar en cada momento a partir de los movimientos ejecutados por el Probador.
7.1.1 INFRAESTRUCTURA
La verificación del funcionamiento del sistema la realizará un equipo de la Universidad de Murcia en remoto desde la propia Universidad.
Un componente del equipo se desplazará hasta la casa instalada y actuará como si se tratara de la persona atendida. Será el responsable de representar las diferentes historias de prueba que se detallan en las siguientes secciones. En lo siguiente nos referiremos a él como Probador.
El Probador dispondrá de un portátil de pequeñas dimensiones (eePC) dotado con WebCam y conexión de red. El equipo de la UM tendrá en todo momento contacto visual y por voz con el Probador (utilizando por ejemplo Skipe), de esta manera dirigirá las acciones de este y tendrá visión directa de lo que está pasando en cada momento en la casa de la persona atendida.
La verificación del funcionamiento del sistema se realizará utilizando una conexión SSH desde un equipo de la UM hasta Prodia. La conexión SSH es un acceso remoto y seguro al sistema desde un equipo externo utilizando la red. A partir de esta conexión el equipo de la UM podrá visualizar en directo la salida que va generando Prodia a partir de las acciones que el Probador realiza en la casa.
En la ilustración 1 se puede ver el diagrama de comunicaciones entre la casa de la persona atendida y el equipo de la UM que monitorizará las pruebas.
73/86
La ilustración siguiente muestra la comunicación que se realizó en las prueba de la primera casa instalada. Como se puede ver a la derecha de la imagen tenemos la conexión vía WebCam con el Probador, que en este caso, estaba realizando una de las pruebas de caída de cama. El resto de la imagen muestra la salida que Prodia está proporcionando, en directo, a partir de los movimientos y acciones del Probador.
74/86
Ilustración 26: Pruebas realizadas en la primera casa
Ilustración 25: Estructura de comunicaciones para pruebas
7.1.2 PREPARACIÓN DEL SISTEMA
Para hacer viable la simulación de las diferentes situaciones de emergencia que se describen en el protocolo de pruebas, es necesario adaptar el sistema haciendo que los tiempos de espera sean mucho más cortos que los reales. Es decir, si en uno de los casos de prueba deseamos simular un desvanecimiento, no es necesario ni viable, someter al Probador a simular un desvanecimiento durante el tiempo real (por ejemplo 1 hora) que necesita el sistema para inferir que se encuentra en un estado de emergencia.
La reducción controlada de esos tiempos de espera hará posible que el sistema consiga inferir un estado de emergencia en un tiempo muy inferior al real. Reducimos los tiempos de manera que una caída de 1 hora pueda simularse en, por ejemplo, 5 minutos.
La adaptación de Prodia radica en la reducción de los tiempos de espera para la activación de las diferentes alarmas. Se asegura por tanto que el núcleo del sistema permanece intacto reaccionando exactamente igual que la versión de Prodia que será instalada posteriormente, siendo la reducción de tiempos su única diferencia.
Los tiempos de detección serán los siguientes:
● Estado de Inactividad (no alarmante): 1 minuto de inactividad
● Alarma por Inactividad: 2 minutos de inactividad a partir del estado de Inactividad ( 3 minutos de inactividad en total)
● Alarma por exceso de Actividad (caída con movimiento): 5 minutos.
● Detección de Ausencia: 2 minutos de inactividad a partir de la apertura y cierre de la puerta.
Los tiempos de detección para las pruebas no difieren del momento del día ni de la habitación en la que se realicen (Prodia sí diferencia estos parámetros).
Para hacer efectivos los cambios será necesario la parada y posterior puesta en marcha del sistema. Al finalizar el protocolo de pruebas el sistema volverá a su estado inicial, recuperando los tiempos iniciales de alarma.
7.1.3 CASOS DE PRUEBA
Se proponen los siguientes casos de prueba que verificarán el correcto funcionamiento de Prodia en la casa instalada.
La batería de pruebas se compone de los 3 casos que se incluyen en las siguientes secciones, en cada uno de ellos se explica con detalle como debe actuar el Probador para simular cada caso y la salida correcta que debe proporcionar Prodia en cada prueba.
Se deja a juicio del Probador el realizar o no las variantes que se especifican en alguno de los casos de prueba, no son estrictamente necesarias para la prueba integral del sistema.
75/86
7.1.3.1 CASO 1: MOVIMIENTO Y CAÍDA
Ejemplo de Historia:
El atendido se encuentra en el dormitorio, se mueve hasta el baño pasando (o no) previamente por las habitaciones que los conectan. Estando en el baño resbala y cae. Intenta levantarse pero no lo consigue. Después de varios intentos desiste.
Eventos en sensores:
● Se activa el sensor de movimiento del dormitorio.
● Deja detectase movimiento en el dormitorio
Actividad en habitaciones conectoras ( si existen)
Se activa el sensor de movimiento del baño.
Deja de detectase actividad en el baño
Reproducción de la Historia:
Se realiza el recorrido desde el dormitorio al baño pasando por el salón y por el pasillo.
Durante el recorrido se debe comprobar si existe solapamiento en alguno de los sensores y el posible retardo entre la detección de los sensores y el procesamiento del sistema.
Una vez en el baño se tumba en el suelo durante 2 minutos.
Caso 1.1: Se mueve lentamente
Caso 1.2: No se mueve.
Probar varias localizaciones en el suelo del baño para ver como influye en la detección del sensor.
En la caída con movimiento después de 5 minutos de movimiento continuado en el baño debe saltar la alarma de actividad anómala.
Resultados esperados:
● T=1
○ OCP detecta moveSensorDormitorio true
■ Reasoner: Estado: Activo, Localización: Dormitorio.
TimerInactividad Iniciado
● T=2
○ OCP detecta moveSensorDormitorio false
■ Reasoner: No cambia de estado.
T=3
○ OCP detecta moveSensorBaño true
■ Reasoner: Estado: Activo, Localización: Baño.
76/86
TimerInactividad Reiniciado.
T=4
○ OCP detecta moveSensorBaño false
T= (T4 + timerInactividad)
■ Reasoner: Finaliza timerInactividad. Estado: Inactivo, Localización: Baño
TimerInactividadAnomalaBaño Iniciado
● T=/T4 + timerInactividad + timerInactividadAnomalaBaño)
■ Reasoner: TimerInactividadAnomalaBaño finalizado. Estado: InactivoAnomalo, Localización: Baño. Alarma!!.
7.1.3.2 CASO 2. AUSENCIA Y ESTADO DE DESCANSO
Ejemplo de Historia:
Atendido se encuentra en el salón, se sienta a ver la televisión y descansa durante un tiempo. Después de un rato se levanta y se sale de la casa. Un tiempo después abre la puerta y vuelve a casa.
Eventos en sensores:
Se activa el sensor de movimiento del salón.
Se detecta presión en el sensor del sofá.
Deja de detectarse actividad en el sensor de movimiento del salón.
Se activa el sensor de movimiento del salón.
Deja de detectarse presión en el sensor del sofá.
Se detecta apertura de puerta.
Se detecta cierre de puerta.
Deja de detectarse movimiento en el salón.
Pasado un tiempo. Se detecta apertura de puerta.
Se detecta cierre de puerta.
Se detecta movimiento en el salón.
Reproducción de la Historia:
Localizado en el salón se sienta en la silla que contiene el sensor de presión. Permanece inactivo durante un tiempo (2 minutos) hasta llegar al estado de descanso.
Durante ese periodo sería interesante probar movimientos leves (lectura de un libro, balanceo del balancín...).
77/86
Pasado un tiempo se levanta abre y cierra la puerta para salir fuera. Pasará fuera el tiempo necesario para detectar la ausencia (2 minutos). Pasado este tiempo volverá a entrar.
Resultados esperados:
T=1
○ OCP detecta moveSensorSalon true
■ Reasoner: Estado: Activo, Localización: Salón. TimerInactividad iniciado
T=2
○ OCP detecta pressSensorSofa true
■ Reasoner: Estado: Activo, Localización: Salón, Eventos: PressSofa
TimerInactividad reiniciado
T=3
○ OCP detecta moveSensorSalon false
■ Reasoner: No actualiza estado. Eventos: PressSofa.
T=2 + timerInactividad
■ Reasoner: Finaliza TimerInactividad, Estado: Rest, Localización: Salón. Eventos: PressSofa
TimerInactividadAnomalaRest iniciado.
T=10
○ OCP detecta moveSensorSalon true
■ Reasoner: Estado: Activo, Localización: Salón. Eventos: PressSofa
TimerInactividadAnomalaRest eliminado
TimerInactividad iniciado
T=11
○ OCP detecta pressSensorSofa false
■ Reasoner: No actualiza estado.
TimerInactividad reiniciado
T=12
○ OCP detecta openDoorMain true
■ Reasoner: No actualiza estado. Eventos: OpenCloseDoor
TimerInactividad reiniciado
T=13
○ OCP detecta openDoorMain false
78/86
■ Reasoner: No actualiza estado. Eventos: CloseOpenDoor
TimerAusencia iniciado.
T=14
○ OCP detecta moveSensorSalón false
■ Reasoner: No actualiza estado.
T=13 + timerAusencia
■ Reasoner: TimerAusencia finalizado. Estado: Absentee.
T=x
○ OCP detecta openDoorMain true
■ Reasoner: No actualiza estado. Eventos: OpenCloseDoor
T=x+1
○ OCP detecta openDoorMain false
■ Reasoner: Estado: ActiveAgain . Eventos: CloseOpenDoor
T=x+2
○ OCP detecta moveSensorSalón true
■ Reasoner: Estado: Active, Localización: Salón
TimerInactividad Iniciado
7.1.3.3 CASO 3. PRESIÓN EN CAMA Y CAÍDA
Ejemplo de Historia:
El atendido se encuentra en el dormitorio y se acuesta a dormir, en medio de la noche cae de la cama y no consigue levantarse.
Eventos en sensores:
Se detecta movimiento en el dormitorio.
Se detecta presión en la cama.
Deja de detectarse movimiento en el dormitorio.
Se detecta movimiento en el dormitorio.
Deja de detectarse presión en cama.
Deja de detectarse movimiento en el dormitorio.
Reproducción de la Historia:
79/86
Localizado en el dormitorio se tumbará en la cama.
Se probarán diferente localizaciones en la cama para comprobar si existen puntos muertos en los que el sensor no consigue detectar la presión (partimos de que actualmente sí parecen existir).
Localizados estos puntos descansará durante 2 minutos hasta conseguir el estado dormido.
Después de esto simulará una caída de la cama, comprobando si existe la posibilidad de que el sensor de movimiento no detecte el movimiento de caída. Se simulará la caída hacía los dos lados de la cama para comprobar los puntos muertos del sensor de movimiento.
Resultados esperados:
T=1
○ OCP detecta moveSensorDormitorio true
■ Reasoner: Estado: Activo, Localización: Dormitorio
TimerInactividad Iniciado
T=2
○ OCP detecta pressSensorCama true
■ Reasoner: Estado: Activo, Localización: Dormitorio, Eventos: PressCama
TimerInactividad reiniciado
T=3
○ OCP detecta moveSensorDormitorio false
■ Reasoner: No cambia de estado. Eventos: PressCama
T=3 + timerInactividad
■ Reasoner: Finalizar TimerInactividad. Estado: Sleep, Localización: Dormitorio. Eventos: PressCama
TimerInactividadAnomalaSleep iniciado.
T=7
○ OCP detecta moveSensorDormitorio true
■ Reasoner: Estado: Activo, Localización: Dormitorio.
TimerInactividad Reiniciado.
T=8
○ OCP detecta moveSensorDormitorio false.
T= (T9 + timerInactividad)
80/86
■ Reasoner: Finaliza timerInactividad. Estado: Inactivo, Localización: Dormitorio
TimerInactividadAnomalaDormitorio Iniciado
● T=(T9 + timerInactividad + timerInactividadAnomalaDormitorio)
■ Reasoner: TimerInactividadAnomalaDormitorio finalizado. Estado: InactivoAnomalo, Localización: Dormitorio. Alarma!!.
81/86
8 CONCLUSIONES Y TRABAJOS FUTUROS.En el presente proyecto se ha desarrollado un sistema inteligente no intrusivo para la vigilancia en el hogar de personas mayores que viven solas. Este sistema es capaz de detectar situaciones potencialmente peligrosas (caídas, desfallecimientos,.. ) y lanzar las correspondientes alarmas. Concretamente, las principales aportaciones del proyecto se pueden resumir en:
1. Análisis del estado del arte en el campo de las tecnologías aplicadas al desarrollo de sistemas inteligentes de alerta.
2. Definición de una arquitectura de tres capas que hace posible la identificación del contexto en el que se encuentra el atendido y la realización de procesos de razonamiento sobre el mismo.
3. Definición de una ontología que hace posible la caracterización del contexto y mecanismos básicos de inferencia
4. Desarrollo un capa sensible al contexto apoyada en la anterior ontología y con mecanismos de razonamiento basado en tecnologías de la web semánticas.
5. Desarrollo de una capa de metarrazonamiento centrada en la la resolución de inconsistencias.
6. Desarrollo de herramientas de apoyo que permiten la configuración del dispositivo y el la verificación del correcto funcionamiento del dispositivo y el análisis de la actividad del atendido.
7. Diseño de un plan de validación en entornos reales y desarrollo de la infraestructura que posibilita su realización.
Todos estos resultados han sido validados en entornos reales gracias al plan de validación desarrollo como contribución nº 7. Además, desde el punto de vista científico, la validez de los resultados de este proyecto están avalados por las siguientes publicaciones:
1. Juan A. Botía, José Palma, Ana Villa, David Pérez, and Emilio Iborra. “A Software Architecture for Senior Citizens Custodial Care”. In proceedings of the International Conference On Computer Aided Systems Theory (Eurocast 2009). Las Palmas de Gran Canaria.
2. An unobstrusive system for senior citizens under custodial care. Lessons learned. Juan A. Botía Blaya, Jose Palma, Ana Villa and David Pérez. Special Session on the Role of Knowledge Based Systems in supporting Elderly Care at Home in the IWINAC Conference, 2009. (Under review) .
3. Juan A. Botia, Ana Villa, Jose T. Palma, Emilio Iborra. Detecting domestic problems of elderly people: simple and unobstrusive sensors to generate the context of the attended. International Workshop on Ambient Assisted Living (IWAAL), 2009. (Under review).
Entre los trabajos futuros podemos destacar:1. Aprovechar las capacidades de inferencia de la ontología para realizar una identificación
82/86
más rápida de los posibles estados.
2. Diseñar mecanismos inteligentes que permitan adaptar el funcionamiento del sistema a los hábitos de comportamiento de las personas atendidas. Parte de este trabajo está ahora mismo en desarrollo y los resultados previos han sido presentados en la siguiente publicación:
3. Extender la arquitectura propuesta a otros dominios de aplicación como el de la eficiencia energética en edificios.
Todos estros trabajos futuros se desarrollaran en el seno de la empresa AMI2 a la que me incorporaré en breve plazo.
83/86
9 BIBLIOGRAFÍA
[Botia J., et al., 2008] Juan A. Botia, Hoa Ha Duong, Isabelle Demeure and Antonio F. GómezSkarmeta. A Contextaware Data Sharing Service over MANet to Enable Spontaneous Collaboration. The 6th International Workshop on Distributed and Mobile Collaboration (DMC 2008). WETICE. June, 2008. Rome, Italy.
[Craik K., 1943] Kenneth Craik. K. “The Nature of Explanation”.
[Nieto I., et al., 2006] I. Nieto, J. Botía and A. GómezSkarmeta. Information and Hybrid Architecture Model of the OCP Contextual Information Management System. Journal of Universal Computer Science. 2006
[Nieto I., et al., 2006b] Ignacio Nieto, Juan A. Botia and Antonio F. Gomez Skarmeta. Semantic Tuple Spaces: Application in a Contextual Information Management System. 1st Workshp of Artificial Intelligence Techniques for Ambient Intelligence. ECAI 2006.
[Munoz A., et al., 2006] Andres Munoz and Antonia Vera and Juan A. Botia and Antonio F. Gomez Skarmeta. Defining basic behaviours in ambient intelligence environments by means of rulebased programming with visual tools. 1st Workshp of Artificial Intelligence Techniques for Ambient Intelligence. ECAI 2006.
[Munoz A., et al., 2008] Andrés Munoz, Ignacio Nieto, Juan A. Botía and Antonio F. GómezSkarmeta. On defining rule based behaviours for context awareness: an approach based on a visual ontology. Workshop on Artificial Intelligence Techniques for Ambient Intelligence. ECAI 08. Patras, Greece. July 2008.
[Palma J. et al., 2006] J. Palma, JM Juárez, M. Campos and R. Marín. “Fuzzy theory approach for temporal modelbased diagnosis: An application to medical domains”. In Arificial Intelligence in Medicine, Volume 38 , Issue 2, Pages 197218. 2006.
[Campos M. et al., 2002] Campos, M., Cárceles, A., Palma, J., Marín, R.: A general purpose fuzzy temporal information management engine. In: EurAsiaICT 2002, Advances in information and communication technology, pp. 93–97 (2002)
[A. Wood. Et al., 2006] “ALARMNET: Wireless Sensor Networks for AssistedLiving and Residential Monitoring,” Technical Report CS200611, Department of Computer Science, University of Virginia, 2006.
84/86
[G. Virone. Et al., 2002] “A system for automatic measurement of circadian activity deviation in telemedicine,” IEEE Transactions on Biomedical Engineering, vol. 49, no. 12, pp. 14631469, Dec. 2002.
[Intel Research. AgeinPlace Advanced SmartHome]. http://www.intel.com/research/prohealth/csaging_in_place.htm
[Jennifer Hou et al, 2007] "PAS: A WirelessEnabled, SensorIntegrated Personal Assistance System for Independent and Assisted Living", in Proc. of Joint Workshop on High Confidence Medical Devices, Software, and Systems (HCMDSS) and Medical Device PlugandPlay (MD PnP) Interoperability (HCMDSS/MD PnP'07), June, 2007.
[University of Virginia, Smart inHome Monitoring System] http://marc.med.virginia.edu/projects_smarthomemonitor.html.
[Siddharth Dalal et al, 2005] A RuleBased Approach to the Analysis of Elders’ Activity Data:Deteccion of Health and Possible Emergency Conditions. AAAI Fall 2005 Symposium (EMBC). Sep. 2005.
[Kidd, Cory D., 1999] "The Aware Home: A Living Laboratory for Ubiquitous Computing Research". In the Proceedings of the Second International Workshop on Cooperative Buildings October 1999
[Larman, Craig] UML y patrones, Introducción al análisis y diseño orientado a objetos y al proceso
unificado. Prentice Hall, Madrid, 2003
[Pedro Salcedo] CommonKADS y el Lenguaje de Modelado Unificado – UML Departamento de
Metodología de la Investigación e Informática Educativa, Facultad de Educación, Universidad de Concepción .
[A. GómezPérez, M. FernándezLópez and O. Corcho], Ontological Engineering, Springer, 2003.
[Amparo Alonso Betanzos, Bertha Guijarro Berdiñas, Adolfo Lozano Tello, José Tomás Palma
Méndez, Mª Jesús Tabeada Inglesias]. Ingeniería del Conocimiento. Aspectos Metodológicos. Pearson Educación, S.A., Madrid, 2004.
[Anind K. Dey ,2000] Providing Architectural Support for Building ContextAware Applications.
PhD thesis, College of Computing, Georgia Institute of Technology, December 2000.
[J. Pascoe et al, 1998], N. S. Ryan and D. R. Morse. Humancomputergiraffe interaction HCI in the field. Workshop on Human Computer Interaction with Mobile Devices, 1998.
[X. Wang, 2004] Ontologybased context modeling and reasoning using owl. In Context
85/86
Modeling and Reasoning Workshop at PerCom 2004., 2004.
[Tao Gu, et al.2004] Hung Keng Pung, and Da Qing Zhang. Toward an OSGIbased infrastructure for contextaware applications. IEEE PERVASIVE Computing, pages 66–74, OctoberDecember
2004.
86/86