Dispositivo inteligente de alerta domiciliaria. Tecnologías de la Web Semántica para aplicaciones sensibles al contexto.

Transcripción

1 UNIVERSIDAD DE MURCIA INGENIERÍA EN INFORMÁTICA PROYECTO 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éndez Juan Botía Blaya Facultad de Informática Febrero 2009

2 Índice General 1 Introducción Marco del Proyecto Alcance y Objetivos Estructura del Trabajo Estado del Arte Tecnologías utilizadas JAVA Ontologías OWL SWRL Protégé JENA ORE MySQL Análisis y casos de uso Plan de Trabajo Metodología Ingeniería del Software Análisis de Requisitos Casos de Uso Diseño de la aplicación Arquitectura de tres capas Ontología: Nexo entre capas Timers en la Ontología Atendido: estado actual e intermedio Capa Inferior: OCP Capa intermedia: Razonamiento Autómata Estados Reglas SWLR e Inferencia Capa superior: MetaRazonador Resolución de inconsistencias Tipos de Inconsistencias Actividad Inactividad Actividad Actividad Inactividad Dormido/Descansando Actividad Intruso Actuación Razonamiento Complejo Salida del Sistema Logs por Capas Interfaz gráfica A. Herramientas Auxiliares Desarrolladas Instalación y Despliege: ProdiaConfigurator Simulación: ProdiaSimulator Fichero de Simulación /86

3 6.3 Data Mining y Validación: ProdiaMonitor Visualización de resultados mediante gráficas Búsqueda de estados Filtrado de Datos Estadísticas de Localización dependiendo del Momento del Día Estudio de Timers para Adaptación Datos.arff para Weka Validación del Sistema Pruebas de Validación Infraestructura Preparación del Sistema Casos de prueba Caso 1: Movimiento y Caída Caso 2. Ausencia y estado de descanso Caso 3. Presión en cama y caída Conclusiones y trabajos futuros Bibliografía /86

4 Índice de ilustraciones Ilustración 1: Interfaz ORE...18 Ilustración 2: Diagrama de Gantt Ilustración 3: Diagrama de Gantt Ilustración 4: Casos de Uso...25 Ilustración 5: Estructura de 3 capas...30 Ilustración 6: Árbol de la ontología...35 Ilustración 7: Diagrama simplificado de términos...36 Ilustración 8: Diagrama de ontología OCP...41 Ilustración 9: Transformación de bytes percibidos a conocimiento...41 Ilustración 10: OCP y su Comunicación con el exterior...43 Ilustración 11: Autómata Finito Determinista...49 Ilustración 12: Transición entre estados Active y Absentee...50 Ilustración 13: Resolución de múltiples inconsistencias...54 Ilustración 14: Salida del sistema por capas...58 Ilustración 15: Interfaz gráfica de Prodia...60 Ilustración 16: Interfaz ProdiaConfigurator...61 Ilustración 17: Ejemplo de fichero de simulación...64 Ilustración 18: Interfaz ProdiaMonitor...65 Ilustración 19: Gráficos de las 3 capas...66 Ilustración 20: Búsqueda de estados en Gráficos...66 Ilustración 21: Filtrado de Gráficos...67 Ilustración 22: Estadísticas de localización...68 Ilustración 23: Estadísticas de localización por momento del día...68 Ilustración 24: Gráficas de timers...70 Ilustración 25: Estructura de comunicaciones para pruebas...72 Ilustración 26: Pruebas realizadas en la primera casa /86

5 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

6 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

7 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

8 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 espacio temporal 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 C OWL [Bouquet et al., 2003], además de propuestas de ontologías genéricas para este tipo de 8/86

9 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 (Assisted Living 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 semi automatizado, 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 Age in Place Advanced Smart Home [Intel Research. Age in Place Advanced Smart Home]. 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

10 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 in home Monitoring System at University of Virginia [University of Virginia, Smart in Home 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

11 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

12 3 TECNOLOGÍAS UTILIZADAS 3.1 JAVA Java 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: Debería usar la metodología de la programación orientada a objetos. Debería permitir la ejecución de un mismo programa en múltiples sistemas operativos. Debería incluir por defecto soporte para trabajo en red. Debería diseñarse para ejecutar código en sistemas remotos de forma segura. 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

13 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 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 [ ref/]. La web: OWL Web Ontology Language Overview [ features/] 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 una subclase 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

14 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 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

15 La sintaxis abstracta tendría la siguiente forma: rule ::= 'Implies(' [ URIreference ] { annotation } antecedent consequent ')' antecedent ::= 'Antecedent(' { atom } ')' consequent ::= 'Consequent(' { atom } ')' atom ::= description '(' i object ')' datarange '(' d object ')' individualvaluedpropertyid '(' i object i object ')' datavaluedpropertyid '(' i object d object ')' sameas '(' i object i object ')' differentfrom '(' i object i object ')' builtin '(' builtinid { d object } ')' 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(I variable(x1) I variable(x2)) hasbrother(i variable(x2) I variable(x3))) Consequent(hasUncle(I variable(x1) I variable(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: xml 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

16 <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 PROTÉGÉ Protégé ( 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 JENA JENA, ( 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

17 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

18 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. Ilustración 1: Interfaz ORE 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

19 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 MYSQL MySQL 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

20 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

21 Ilustración 2: Diagrama de Gantt 1 Ilustración 3: Diagrama de Gantt METODOLOGÍA 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

22 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 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

23 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