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 Actividad­Inactividad.......................................................................................54 5.5.1.1.2 Actividad­Actividad..........................................................................................54 5.5.1.1.3 Inactividad­Dormido/Descansando..................................................................55 5.5.1.1.4 Actividad­Intruso..............................................................................................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 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

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

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

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/owl­ref/]. La web: OWL Web Ontology Language Overview [http://www.w3.org/TR/owl­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 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 '(' 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:

http://www.w3.org/2003/11/swrlx    ,  http://www.w3.org/2003/11/rulemlhttp://www.w3.org/2003/05/owl­xml  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/owl­ref/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 Hardware­Software 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  Actividad­Inactividad

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  Actividad­Actividad

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  Inactividad­Dormido/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  Actividad­Intruso

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/22­rdf­syntax­ns#" 

    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/22­rdf­syntax­ns#" 

    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ómez­Skarmeta.   A   Context­aware   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ómez­Skarmeta.   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 rule­based 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ómez­Skarmeta. 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 model­based diagnosis: An application to medical domains”. In Arificial Intelligence in Medicine, Volume 38 ,  Issue 2,  Pages 197­218. 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:  EurAsia­ICT 2002,  Advances   in   information  and communication technology, pp. 93–97 (2002) 

[A.   Wood.   Et   al.,   2006]  “ALARM­NET:   Wireless   Sensor   Networks   for   Assisted­Living   and Residential   Monitoring,”  Technical   Report   CS­2006­11,   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. 1463­1469, Dec. 2002.

[Intel Research. Age­in­Place Advanced Smart­Home]. http://www.intel.com/research/prohealth/cs­aging_in_place.htm

[Jennifer   Hou   et   al,   2007]  "PAS:   A   Wireless­Enabled,   Sensor­Integrated   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 Plug­and­Play (MD PnP)  Interoperability (HCMDSS/MD PnP'07), June, 2007.

[University of Virginia, Smart in­Home Monitoring System] http://marc.med.virginia.edu/projects_smarthomemonitor.html.

[Siddharth Dalal et al, 2005] A Rule­Based 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ómez­Pérez, M. Fernández­Ló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 Context­Aware Applications. 

PhD thesis, College of Computing, Georgia Institute of Technology, December 2000. 

[J. Pascoe et al, 1998], N. S. Ryan and D. R. Morse. Human­computer­giraffe interaction ­ HCI in the field. Workshop on Human Computer Interaction with Mobile Devices, 1998. 

[X. Wang, 2004] Ontology­based 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 OSGI­based infrastructure for context­aware applications. IEEE PERVASIVE Computing, pages 66–74, October­December 

2004. 

86/86