CONTROL DEL HOGAR DIGITAL DESDE DISPOSITIVOS MÓVILES

CONTROL DEL HOGAR DIGITAL DESDE DISPOSITIVOS MÓVILES Jesús Friginal López Universidad Politécnica de Valencia, Camino de Vera s/n, Valencia 46022, jefrilo@fiv.upv.es Juan Luis Posadas Yagüe Universidad Politécnica de Valencia, Camino de Vera s/n, Valencia 46022, jposadas@disca.upv.es Juan Carlos Ruiz García Universidad Politécnica de Valencia, Camino de Vera s/n, Valencia 46022, jcruizg@disca.upv.es Jesús Camacho Villanueva Universidad Politécnica de Valencia, Camino de Vera s/n, Valencia 46022, jecavil@upvnet.upv.es Resumen El presente artículo se enmarca dentro del área de investigación de la vivienda inteligente. Se presenta un proyecto cuyo objetivo principal consiste en el desarrollo e implantación de la infraestructura software necesaria para el control de la vivienda desde dispositivos móviles. Dicho sistema que se asienta sobre la arquitectura SCHome para la comunicación entre dispositivos domóticos con protocolos diferentes, pretende la creación de un servidor multiplataforma de servicios web pensado tanto para el mundo.net como para Java. Además se contempla la creación de una aplicación cliente Java ME orientada hacia SmartPhones, que cuide la interacción con el usuario al máximo, y sea configurable. Dicho sistema incluye también la posibilidad de programar ambientes en la vivienda e incorpora un sistema de alertas, para incrementar la seguridad en el hogar. Palabras Clave: vivienda domótica, vivienda inteligente, dispositivo móvil, cliente-servidor, servicio web, SVG. 1 INTRODUCCIÓN Desde siempre, los avances tecnológicos han ido invadiendo gradualmente nuestras vidas hasta el punto de acostumbrarnos a que éstos formaran parte de nuestra vida cotidiana. Hoy en día, no concebiríamos nuestro día a día sin elementos como los teléfonos móviles, las tarjetas de crédito, o los sistemas ABS de los vehículos, por citar unos ejemplos. La rápida evolución tecnológica de la electrónica e informática, ha inundado nuestro entorno con televisores, teléfonos móviles, equipos de fax y módem, redes y sistemas informáticos. Actualmente, vivimos en ciudades donde nuestra relación con las nuevas tecnologías es constante y por tanto, es de esperar que si ya forman parte de casi todos los ámbitos, también lo acaben haciendo de nuestra propia casa. Así es como nacen los conceptos de vivienda domótica y vivienda inteligente. Según Laserna Larburu [1], la domótica se define como la rama de la tecnología que se ocupa de proveer elementos que acerquen a la vivienda a adquirir el calificativo de inteligente. En este caso, hablaríamos de viviendas provistas de dispositivos domóticos que actúan de forma independiente. En cambio, comenzaríamos a hablar de vivienda inteligente en la medida en la que los dispositivos de la vivienda se integran bajo un mismo sistema, colaborando entre sí con el fin de automatizar, o al menos dar soporte informático a la realización de tareas domésticas y al control de electrodomésticos y equipamiento electrónico. Esta diferencia podemos ilustrarla con un ejemplo: en una casa domótica podemos tener un riego automatizado programable, pero en una vivienda inteligente podríamos disponer, además del riego programable, de un sensor de humedad colocado en el jardín que avisará al sistema central para que éste anule el riego cuando llueva. Esto supone una gran ventaja para el propietario de la vivienda no solo en términos de confort sino también de ahorro. 2 CARACTERÍSTICAS DE LA VIVIENDA INTELIGENTE De manera general, el sistema central de una vivienda inteligente, debe disponer de una red de comunicación que permita interconectar aquellos

equipos que permiten obtener información en procedencia del entorno doméstico con aquellos que, basándose en esta información actúan sobre dicho entorno. Por ello las características fundamentales de este tipo de sistemas inteligentes [2] son: Control remoto desde dentro de la vivienda Tal posibilidad se consigue mediante un esquema de comunicación (típicamente cableado) entre los distintos equipos que forman parte del hogar. La consecuencia más inmediata de lo anterior consiste en una reducción considerable de la necesidad de moverse dentro de la vivienda, lo que puede resultar particularmente importante en el caso de personas de la tercera edad o minusválidos. Control remoto desde fuera de la vivienda. Presupone un cambio en los horarios en los que se realizan las tareas domésticas y permite al usuario un mejor aprovechamiento de su tiempo. También permite flexibilizar el control de los electrodomésticos (encender apagar la lavadora, control de la climatización, supervisión del hogar a distancia, etc.) Programabilidad. Permite que los sistemas se puedan programar ya sea para que realicen ciertas funciones con sólo tocar un botón o bien que las lleven a cabo en función de otras condiciones del entorno (hora, temperatura interior o exterior, etc.) Acceso a servicios externos. Aquí podemos incluir servicios como el telebanco, la telecompra o el teletrabajo. 3 CONTEXTO Actualmente, se están llevando a cabo esfuerzos por parte del mercado para conseguir el control remoto de la vivienda. La principal diferencia entre el control remoto desde fuera, y el control remoto desde dentro, radica en la frecuencia de uso de los dispositivos domóticos de la vivienda. El control remoto desde dentro de la vivienda se orienta a un uso más frecuente de los dispositivos domóticos. Serían las tareas que realiza la persona en el ámbito de la vivienda, como podría ser cambiar el canal de la televisión, encender /apagar las luces de casa, subir/ bajar las persianas, etc. Mientras que el control remoto desde fuera de la vivienda, se enfoca hacia un uso puntual de los dispositivos. La persona se encuentra fuera de su vivienda, y desea realizar una actividad concreta como si se encontrara in situ, como por ejemplo, la comprobación de que todas las luces de la vivienda están apagadas. La diferencia que existe en la frecuencia, orienta cada tipo de control remoto hacia aplicaciones que utilicen una conexión concreta. Por ejemplo, si nos referimos al control remoto desde dentro de la vivienda, una conexión WI-FI [3] o bluetooth [4] puede ser la más adecuada, ya que aunque la cobertura de la red es limitada, es suficiente para cubrir el ámbito de la vivienda, y su infraestructura resulta económicamente factible. En cambio, si se habla del control remoto desde fuera de la vivienda, puede interesar más el uso de una conexión GPRS [5], UMTS, etc. ya que al intentar comunicar con nuestra vivienda desde cualquier parte es necesario estar provisto de una gran cobertura que, a día de hoy, sólo las redes de área extendida (GSM o similar) pueden dar. En este caso, el handicap reside en el ancho de banda disponible, así como en el elevado coste de la facturación, aunque estas limitaciones no lo son tanto cuando consideramos el perfil de las aplicaciones a desarrollar, que exigen un servicio con baja frecuencia de peticiones por parte de los usuarios. Actualmente, el mercado de soluciones domóticas por control remoto en dispositivos móviles sigue esta dualidad. Se puede observar como la mayoría de productos enfocados al control remoto desde dentro de la vivienda van dirigidos hacia PDAs, y son sobretodo aplicaciones que pretenden centralizar el control de todos los aparatos multimedia de la vivienda que funcionan bajo el protocolo UPnP [6]. Por otro lado, la mayoría de soluciones para el control remoto desde fuera de la vivienda se basan en sistemas de envío y recepción de alertas de dispositivos domóticos que funcionan sobre EIB [7], vía SMS, más dirigidos hacia la telefonía móvil. En cualquier caso, se aprecia como dichos sistemas no permiten controlar conjuntamente dispositivos que funcionen sobre protocolos distintos. Por tanto, la escalabilidad y crecimiento de dichos sistemas, está más que puesta en entredicho. Desde el Grupo de Informática Industrial - Sistemas de Tiempo Real en el Instituto de Automática e Informática Industrial a través del Proyecto Sistema para la monitorización y control remoto de

dispositivos en el hogar digital 1 de la Universidad Politécnica de Valencia, se trabaja en la línea de conseguir integrar distintos dispositivos domóticos bajo un mismo sistema y de conseguir las características de la vivienda inteligente. La arquitectura denominada SChome [8], es prueba de ello. La primera versión de su desarrollo, dispone actualmente de una pasarela residencial para el acceso remoto a dispositivos conectados a un bus de datos TCP/IP, tales como cámaras de video, y a un conjunto de dispositivos domóticos conectados a través de un bus Konex/EIB. 4 OBJETIVOS De acuerdo al contexto actual, la idea es aprovechar los avances logrados en el Proyecto Sistema para la monitorización y control remoto de dispositivos en el hogar digital en materia de control y comunicación entre los dispositivos domóticos para añadir el matiz de la movilidad. Este trabajo se está efectuando en colaboración con el grupo de sistemas tolerantes a fallos del Instituto de las aplicaciones de las tecnologías de la información y de las comunicaciones avanzadas de la Universidad Politécnica de Valencia. Se marca como objetivo principal la construcción de un sistema que permita poder controlar la infraestructura SChome a través de un cliente inteligente en un dispositivo móvil teniendo en cuenta las siguientes indicaciones: 1 1. Analizar las demandas y tendencias del mercado actual y realizar estudios de viabilidad acerca de las plataformas y tecnologías que se pueden emplear. 2. Dotar al sistema de robustez y seguridad para proteger la información de la vivienda en todas sus facetas, tanto en su almacén, como en su viaje por un canal de comunicaciones. Por eso hay que estudiar los niveles de seguridad que debe conseguir dicha información, así como los mecanismos y técnicas para salvaguardarla. 3. Analizar los factores de rendimiento del sistema. Para una buena aceptación del producto por parte del mercado, es imprescindible una buena respuesta de eficiencia y eficacia a sabiendas de las Proyecto con número de referencia 5656/20060235 financiado por el Vicerrectorado de Innovación y Desarrollo de la Universidad Politécnica de Valencia. limitaciones computacionales de los dispositivos móviles. Por eso resulta vital la depuración del producto en dispositivos reales bajo entornos simulados para sacar conclusiones. 4. Cuidar la interacción del usuario con la aplicación cliente. La aplicación debe ofrecer una interfaz adecuada, y resultar atractiva visualmente, mientras que su funcionamiento debe ser intuitivo y sencillo. Por eso es importante realizar un estudio de interfaces y usabilidad para conseguir el objetivo marcado. 5. Permitir que la aplicación sirva para que usuarios distintos controlen el estado de su vivienda, es decir, conseguir un sistema multiusuario. 6. Integrar un sistema de alertas similar a los actuales productos del mercado, de modo que permita avisar al propietario en caso de que se detecte algún hecho definido por el usuario como excepcional. La conjunción de este sistema con una cámara IP permitiría crear un sistema de vigilancia de la vivienda. 7. Permitir la programación y ejecución automática de tareas. De forma que el usuario pueda elegir modos de funcionamiento de su vivienda. Este mecanismo ofrece opciones que van desde programar el encendido o apagado de las luces a ciertas horas a programar el riego del jardín, o a elegir la atmósfera adecuada para una velada. 8. Plantear una recreación gráfica fiel de los escenarios de la vivienda en la medida en que el dispositivo móvil lo permita. Este aspecto además de permitir una adaptación del producto al usuario, daría un salto cualitativo respecto a otras de soluciones del mercado. 5 DISEÑO DE LA ARQUITECTURA Para desarrollar el sistema que se propone, se ha pensado en diseñar una arquitectura cliente-servidor que utilice una interfaz de servicios. 5.1 INTERFAZ DE SERVICIOS Una interfaz de servicios es una entidad software implementada normalmente como una fachada que controla los servicios de asignación y transformación

para permitir la comunicación con un servicio aplicando un proceso y una política de comunicación. Una interfaz de servicios expone métodos, a los que se puede llamar de forma individual o en una secuencia específica para formar una conversación que implemente una tarea de la capa de negocio. Esto puede verse en la figura 1. 5.2 NIVELES DEL SISTEMA El diseño por capas lleva asociada una jerarquización que permite disminuir la complejidad observable de un sistema y aporta legibilidad, fiabilidad, portabilidad e independencia. 5.2.1 El subsistema servidor Siguiendo esta filosofía, en el servidor se implementan 3 capas o niveles. Figura 1 El diseño de las interfaces de servicios se ha pensado de modo que se obtenga el nivel máximo de interoperabilidad con otras plataformas y servicios, basándose en los estándares de sistemas de comunicación, seguridad, formatos de mensaje estándar o simple (por ejemplo, esquemas XML simples). Se pretende crear un servidor que se pueda invocar a través de mecanismos diferentes, para ello debe agregarse una fachada sobre la capa de interfaz de servicios. Esta fachada ofrece una mayor facilidad de mantenimiento debido a que aísla los cambios en los mecanismos de comunicación de la implementación de los componentes. A continuación el código de la interfaz de servicios trata con los detalles del mecanismo o el canal de comunicación (por ejemplo, analizando los encabezados SOAP [9] del servicio Web) y define el contexto adecuado para la invocación del componente de la lógica de negocio. La figura 2 muestra una visión general del subsistema servidor. La capa de comunicación con el sistema SChome, que es la que se encarga de establecer la conexión con la base de datos del sistema principal. La capa de servicio, donde se alberga la funcionalidad que se ofrecerá al dispositivo móvil cliente. La capa de interfaz del servicio, que encapsula los servicios ofrecidos para que su consumo sea independiente de las plataformas desde donde se invoquen. 5.2.2 El subsistema cliente En el cliente se desarrollan las siguientes capas: La capa de comunicación con el servidor, encargada de establecer la conexión con la capa de interfaz de servicio del servidor y de convertir la información conseguida a la tecnología que implementa la aplicación cliente. La capa de persistencia de datos, desempeña un papel de memoria cache, gracias a la cual, la aplicación establece una conexión con el servidor sólo si los datos de la vivienda están obsoletos. La capa de lógica de negocio, gestiona el comportamiento de la aplicación. La capa de interfaz de usuario, es la encargada de mostrar al usuario los resultados conseguidos por las capas anteriores, de forma clara e intuitiva. 6 IMPLEMENTACIÓN A continuación se detallan los aspectos de implementación más relevantes del sistema, distinguiendo entre el subsistema servidor y el subsistema cliente. Figura 2

6.1 EL SUBSISTEMA SERVIDOR 6.1.1 Un sistema multiplataforma Uno de los objetivos del sistema es conseguir integrar toda su infraestructura en cualquier hogar, por ello, se ha optado por crear una pasarela residencial multiplataforma. Esto pasa por encontrar elementos que nos permitan trabajar indistintamente con varios sistemas operativos. Las bondades de un sistema multiplataforma pasan por permitir al sistema seguir creciendo en su funcionalidad sin necesidad de requerir una tecnología determinada, pero permitiendo la integración entre módulos que usan tecnologías distintas. Además, se ha respetado al máximo que todos los elementos incorporados al sistema se distribuyeran bajo las licencias apropiadas, esto es, si se deseara incorporar la pasarela residencial en un producto comercial pero no distribuirlo bajo licencia GNU GPL, se pueden adquirir licencias comerciales. Java Standard Edition (Java SE), es una de las plataformas de desarrollo más utilizados a nivel mundial. Su máquina virtual le permite trabajar bajo cualquier sistema con lo que cumple con la característica de ser multiplataforma. Este hecho ha decantado su elección para la producción de los servicios que debe proporcionar el servidor. El sistema gestor de base de datos seleccionado para almacenar la información de los dispositivos domóticos de la vivienda es MySQL, un potente gestor que en sus versiones más recientes incorpora soporte a multiplataforma, procedimientos almacenados, triggers, y SSL [10], como características más significativas. Para conectar el sistema gestor de base de datos con las aplicaciones del servidor java, se usará el driver JDBC MySQL Connector/J 5.0. 6.1.2 Servicios Web En cuanto a la implementación de los servicios, se ha optado por utilizar la tecnología de servicios web, de la que pueden consumir servicios tanto clientes Java ME desde teléfonos móviles, como clientes.net CF o Java ME desde PDAs. Básicamente, un servicio web (webservice) es un sistema de entrada/salida, al que se le puede pasar una serie de parámetros con el fin de obtener un resultado en concreto y recuperarlo para ser mostrado en una aplicación. La tecnología de los servicios web es relativamente reciente, y está basada en el protocolo SOAP (Simple Object Access Protocol), consistente en un simple documento XML que habilita el intercambio de información vía HTTP entre diversas aplicaciones. La ventaja de este protocolo radica en una comunicación efectiva independiente del lenguaje de programación que defina a la aplicación. WSDL (Web Services Description Language) es el nombre del lenguaje utilizado para describir un servicio web. El mismo utiliza el formato wsdl como extensión para sus archivos. Estos últimos son referenciados desde una URL, e incluyen una serie de métodos y operaciones que serán llamados desde la aplicación central del lado del cliente. Para la publicación de los servicios web se ha elegido un servidor de aplicaciones de Sun construido a partir del proyecto GlassFish [11] (Open Source JavaEE 5.0 SDK) que da soporte a servicios web seguros gracias a la autenticación a nivel de los mensajes (por ejemplo, firma digital XML y cifrado) de invocaciones de servicios web SOAP utilizando los perfiles de nombre de usuario o contraseña X.509 del estándar de seguridad OASIS WS-Security. 6.1.3 Sistema de alertas El sistema de alertas propone el envío automático de SMS/MMS al usuario cuando se detecte un comportamiento extraño en la vivienda. Dicho sistema se desarrolla utilizando el API WMA siglas de Wireless Message API (JSR-205). 6.2 EL SUBSISTEMA CLIENTE 6.2.1 Java ME A día de hoy existe una gran competencia entre Microsoft y Sun por hacerse con el mercado del las plataformas móviles. Resumiendo las conclusiones de la comparación entre ambas tecnologías [12], se puede concluir que.net CF es la versión ligera de MS.Net Framework y que solo funcionará en los dispositivos con el sistema operativo Windows CE. Sin embargo, Java ME funcionará bajo la mayor parte de las plataformas móviles y es compatible con Java SE. Además, hay que tener presente que la cifra de ventas de teléfonos móviles es muy superior a la de PDAs, y se busca que el producto llegue a un amplio sector de los consumidores. Por ello, la plataforma elegida para desarrollar la aplicación cliente en dispositivos móviles ha sido Java MicroEdition (Java ME). Además, existen entornos de programación robustos y flexibles que proporcionan la emulación de dispositivos móviles para el desarrollo de aplicaciones. Connected Limited Device Configuration (CLDC) [13] es un estándar de Sun que define la configuración en que se basan los perfiles de Java

ME para pequeños dispositivos con capacidades limitadas de comunicación, tales como teléfonos móviles o PDAs. CLDC especifica un conjunto mínimo de paquetes y clases y una máquina virtual Java de funcionalidad reducida que puede ser instalada con las restricciones impuestas por tales dispositivos. Las exigencias mínimas de memoria para la JVM de CLDC son: 128 KB de ROM en versión CLDC 1.0 y 160 KB en 1.1, para almacenamiento persistente de la VM de Java y las librerías de clases de CLDC. 32 KB o más de memoria volátil para alojarla en tiempo de ejecución (carga de clases y reserva en el heap y en la pila para objetos). CDLC proporciona los aspectos básicos para ejecutar Java en pequeños dispositivos, no obstante su funcionalidad es más bien escasa. MIDP es el acrónimo de Perfil para dispositivos de información móvil (Mobile Information Device Profile) y proporciona un perfil que se apoya en CLDC y que proporciona los paquetes y clases necesarios para el desarrollo de aplicaciones. MIDP está orientado principalmente a teléfonos móviles, aunque existen también implementaciones para PalmOS (versión 3.5 y superiores) y PocketPC, por lo que las aplicaciones Java ME son también utilizables en casi cualquier PDA. 6.2.2 Consumo de servicios web Para poder consumir los servicios web en Java ME es necesario conseguir tener acceso. Esto se consigue mediante la especificación JSR-172 de Java ME, que implementa el paquete Remote Procedural Call (RPC) para proporcionar acceso público y privado a servicios Web, mediante el Simple Object Access Protocol (SOAP). Esta API permite que los dispositivos Java ME puedan ser clientes de servicios web mediante un modelo de programación consistente con la plataforma estándar de servicios web. Mirae es la alternativa open-source a la implementación JSR-172 de Sun, que se ha usado en el sistema. Este proyecto proporciona un compilador de stubs que crea el código Java ME necesario para ejecutar las llamadas a un servicio web existente. En este proyecto los stubs del lado de cliente son independientes de la implementación del servicio de web, lo cual permite a las aplicaciones obtenerlos dinámicamente. 6.2.3 Requisitos de entrada/salida Los dispositivos móviles están adquiriendo cada vez una mayor popularidad. La creación de interfaces de usuario adecuadas a las características de la movilidad presenta sus propios retos. En general, la interfaz de usuario de un dispositivo móvil necesita ser capaz de mostrar la información en una pantalla de un tamaño considerablemente menor al de las aplicaciones habituales, y debe ofrecer un nivel aceptable de uso para los dispositivos de destino. Debido a que la interacción del usuario puede resultar un tanto incómoda en un gran número de dispositivos móviles, sobre todo en el caso de los teléfonos móviles, debe procurarse diseñar interfaces de usuario que minimicen al máximo los requisitos de entrada de datos. Una estrategia comúnmente utilizada consiste en combinar el uso de los dispositivos móviles con una aplicación de tamaño completo, de escritorio o web, permitir a los usuarios que registren datos previamente y, a continuación, seleccionarlos utilizando el cliente móvil. Por ejemplo, una aplicación de programación de ambientes en la vivienda puede permitir a los usuarios que registren las características del servicio a través del sitio Web. De este modo, el usuario puede seleccionar un servicio previamente registrado de una lista cuando realice una conexión desde un dispositivo móvil (evitando de este modo la necesidad de escribir los detalles completos a través del teclado numérico del teléfono o el lápiz de una PDA). 6.2.4. Interfaces de usuario Para el desarrollo de las interfaces de usuario se han usado archivos vectoriales escalables, de tipo SVG. Tienen la característica de ser compactos y ofrecen la posibilidad de disponer de gráficos de alta calidad sobre dispositivos con recursos limitados. La especificación SVG (Scalable Vector Graphics) es un estándar del World Wide Web Consortium (W3C) [14] y se usa para describir gráficos bidimensionales. Existe un subconjunto de la especificación SVG dirigido hacia dispositivos móviles llamado SVG- Tiny, cuya versión 1.1 ha sido adoptada por las plataformas Java a través del JSR-226 [15]. En lugar de codificar el contenido de cada píxel como imágenes, de los tipos GIF y JPG, los vectores gráficos contienen solo instrucciones de dibujo para cada píxel, lo cual da a las imágenes vectoriales varias ventajas: Son Escalables, esto significa que la calidad de la imagen permanece igual sobre las pantallas de diferentes tamaños y resoluciones. También se pueden reducir,

voltear e invertir la imagen sin perder la calidad. Soportan scripts y animaciones, lo que los convierte en ideales para interactuar con el usuario. Son compactos. Las imágenes vectoriales pueden ser diez veces más pequeñas e idénticas a una imagen en formato GIF o JPEG. La potencia de este tipo de archivos permite trabajar con objetos 2D en Java ME de forma sencilla, y conseguir crear interfaces de usuario como las que se ofrecen a modo ilustrativo en la figura 3. implementación de un protocolo tipo CHAP [17] en función de la seguridad requerida por el usuario. 7 CONCLUSIONES El sistema SCHome resulta un entorno ideal para ensayar, a bajo coste, diversas alternativas de control domótico, no obstante, la posibilidad de controlar el sistema desde un dispositivo móvil, amplía la visión global del sistema y permite ofrecer no sólo una gestión completamente global de la vivienda, sino también la posibilidad de que ésta se ponga directamente en contacto con el usuario en cualquier lugar del mundo donde se encuentre. Por otra parte, el abanico de posibilidades se abre también a la seguridad de la vivienda, ya que por ejemplo, se puede recibir las imágenes que las cámaras están registrando de cada zona de la vivienda, pudiendo observar intrusiones no deseadas, enviar mensajes SMS asociados, alertando de cualquier incidencia relacionada con fugas de gas, humos, etc. Referencias Figura 3 6.2.5 Persistencia de datos El almacén persistente de datos en el dispositivo móvil se ha conseguido gracias a la utilización de MIDP 2.0. Java ME no dispone de soporte a base de datos SQL como tiene.net CF, no obstante, MIDP proporciona un mecanismo para almacenar datos de forma persistente y poder recuperarlos posteriormente. El mecanismo se llama Sistema de almacenamiento de registros (Record Management System, RMS), y se basa en el modelo simple de base de datos orientada a registros. La integridad de los repositorios RMS depende del dispositivo, incluyendo reinicio y cambios de batería del mismo, al igual que su ubicación. 6.2.6 Seguridad El sistema contempla, independientemente del canal cifrado por donde viaja la información, un mecanismo de seguridad para encriptar el password del usuario basado en el algoritmo MD5 [16]. Las posibilidades de usar un sistema criptográfico en el sistema permiten aumentar la seguridad en la autenticación del usuario. Podría pensarse en la [1] Domòtica i edificis intel.ligents: http://www.xtec.es/~jfresnil/domotica/domow eb/id19.htm [2] Domótica, la revolución del bienestar: http://www.theslogan.com/es_content/index.ph p?option=com_content&task=view&id=4568 &Itemid=20 [3] Wi-Fi: www.aulaclic.es/articulos/wifi.html [4] Bluetooth: http://www.bluetooth.com/bluetooth [5] GPRS: http://es.wikipedia.org/wiki/general_packet_r adio_service [6] UPnP: http://www.upnp.org [7] EIB: http://www.eib.org [8] Raúl Díaz Camps, Juan Luis Posadas Yagüe, José Luis Poza Luján, Pascual Pérez Blasco, Juan Carlos Cano Escribá (2006). Arquitectura SCHome: Acceso remoto al hogar digital. Actas de las XXVII Jornadas de Automática (JA2006) (ISBN 84-689-9417-0). Páginas: 348-354. Almería. [9] SOAP: http://www.w3.org/tr/soap [10] SSL: http://es.wikipedia.org/wiki/transport_layer_ Security [11] Proyecto GlassFish:

https://glassfish.dev.java.net [12] Comparación.Net CF y Java ME: http://www.javaworld.com/javaworld/jw-02-2003/jw-0221-wireless.html? [13] CLDC: http://leo.ugr.es/j2me/cldc/transjava/node12.html [14] W3C: http://www.w3c.es [15] JSR-226 http://wiki.svg.org/index.php?title=jsr_226 [16] MD5: http://es.wikipedia.org/wiki/md5 [17] CHAP: http://es.wikipedia.org/wiki/chap