PORTAL PARA UN SISTEMA LOCAL DE CONEXIÓN EN RED
CAMPO DE LA INVENCIÓN La invención se relaciona con un portal para un sistema local de conexión en red, tal como un sistema para controlar dispositivos dentro de un ambiente de hogar. ANTECEDENTES DE LA INVENCIÓN Es considerable el interés sobre los dispositivos de conexión en red dentro de una ambiente de hogar y en el control remoto de los dispositivos, ya sea desde dentro de un hogar o desde una ubicación remota del hogar. Una variedad de protocolos han sido desarrollados en los años recientes para utilizarse en el control de dispositivos, tal como el protocolo de Sistemas de Hogar Europeo (EHS, por sus siglas en inglés), protocolos ZigBee, XlO, y Conexión y
Reproducción Universal (UPnP, por sus siglas en inglés) . En un intento por crear un marco coherente para conexiones en red, la Iniciativa Abierta de Portal de
Servicios (OSGi, por sus siglas en inglés) ha propuesto un marco gestionado, abierto que ayuda en la habilitación de aplicaciones (o 'servicios') a ser utilizados, instalados y ejecutados en redes de conexión locales tal como en hogares, carros y oficinas pequeñas. El centro de la red de conexión local es un portal que soporta una plataforma de servicio OSGi la cual ejecuta la red de conexión OSGI . La Plataforma No. Ref. : 178022 de Servicio está basada con respecto a una Maquina virtual Java (JVM, por sus siglas en ingles) . La última versión publicada de la Especificación de Plataforma de Servicio OSGI es la versión 3, de marzo de 2003 de "The OSGi Alliance" y se puede encontrar mayor información acerca de OSGI en www.osgi.org. El OSGi ha sido definido tanto para un Modelo de Servicio de Portal Residencial y un Modelo de Portal Virtual. Un ejemplo simplificado del Modelo de Servicio de Portal Residencial se muestra en la Figura 1. La plataforma de servicio 112, sobre la cual se pueden ejecutar aplicaciones (servicios) de usuario 130, esta localizada en el cliente, tal como un hogar de un usuario. Los dispositivos destino 20-23 los cuales deben ser controlados son conectados al portal 110 mediante redes de conexión locales 40,45, las cuales cada una puede estar basada en diferentes protocolos de conexión en red, tal como ZigBee y XlO, también pueden diferir en sus conexiones físicas. El portal 110 está conectado con un servidor remoto 50 a través de una red de conexión 55. El servidor remoto 50 inicialmente puede suministrar las aplicaciones 130 con la plataforma de servicio 112, proporcionar soporte de operaciones de servicio y otras funciones. Este modelo requiere una Maquina Virtual Java
(JVM) en el cliente, lo cual puede ser un requerimiento oneroso para los clientes quienes solamente desean soportar aplicaciones simples, tales como instrucciones de encendido/apagado para dispositivos, termostatos e iluminación. El Modelo de Portal Virtual OSGi se muestra en la Figura 2. Aquí la Plataforma de Servicio 115, sobre la cual se ejecutan las aplicaciones 130, está ubicada en el servidor 50, remota del cliente, y está conectada con el cliente a través de una red de conexión 55. En este modelo el cliente no requiere una Máquina Virtual Java en sus premisas puesto que el portal 120 actúa como una simple interface entre el servidor 50 y las redes de conexión locales 40, 45. Los mensajes recibidos desde la plataforma de servicio 115 son retransmitidos hacia las redes de conexión locales 40,45 y los mensajes recibidos desde los dispositivos 20-23 en las redes de conexión locales 40,45 son enviados a través de la red de conexión 55 hacia la plataforma de servicio 115. Una desventaja con el modelo de Portal Virtual es que el éxito de la operación de la red de conexión del cliente depende de una conexión de comunicación continua entre el servidor remoto 50 y el portal 120, puesto que todo el procesamiento ocurre en la plataforma de servicio 115 en el servidor remoto 50. Sí se interrumpe la comunicación, o si la plataforma de servicio 115 se encuentra fuera de operación, tal como por mantenimiento o debido a una falla, no es posible controlar los dispositivos 20-23 en el cliente. Las consecuencias de esto podrían ser que el usuario no pueda operar sus dispositivos 20-23 dentro del hogar, o que no se pueden ejecutar las aplicaciones de seguridad o monitoreo. SUMARIO DE LA INVENCIÓN La presente invención busca proporcionar un arreglo alternativo para controlar dispositivos dentro de una red de conexión local . Por consiguiente, un primer aspecto de la presente invención proporciona un portal para controlar una red de conexión local de dispositivos destino, que comprende: una función de manejo de eventos la cual almacena eventos, los cuales pueden ocurrir y, para cada evento, los comandos para controlar los dispositivos destine- una interface de servidor para la comunicación con un servidor remoto, el servidor remoto soporta una aplicación, la interface de servidor recibe los comandos de la aplicación los cuales configuran la función de manejo de eventos para controlar los dispositivos destino; y, Una interface para la comunicación con los dispositivos destino; en donde el portal se puede operar para permitir una operación continua de los dispositivos destino si se interrumpe la comunicación con el servidor remoto. El portal y los servicios destino operan de forma eficaz como una "célula de supervivencia" en el evento de una interrupción de la comunicación con el servidor remoto. Esto puede ser particularmente importante con aplicaciones criticas tal como el monitoreo de equipo medico y seguridad domestica . La invención puede ser utilizada como un mejoramiento del Modelo de Portal Virtual OSGi, con una aplicación Java OSGi que es soportada por una Máquina Virtual Java sobre el servidor. Sin embargo, más que depender por completo de un enlace de comunicación entre los dispositivos destino y la aplicación para el control de dispositivos, el portal por si mismo puede proporcionar el control de los dispositivos destino si se interrumpe la comunicación con la aplicación remota. Las funciones del portal pueden ser suministradas mediante una plataforma de procesamiento la cual es considerablemente menos poderosa, y por lo tanto más barata, que la requerida para soportar una JVM. Preferiblemente, la función de manejo de eventos se logra mediante la ejecución de una aplicación escrita en el código nativo del portal. Se prefiere que sea utilizado un protocolo común en el portal, y también preferiblemente para la interface entre el portal y el servidor. Un protocolo particularmente conveniente es el Lenguaje de Control Uniforme de Hogar
(HUCL) . Este es un protocolo ligero lo cual puede minimizar las demandas de un dispositivo huésped, tal como potencia de procesamiento y consumo de energía. En donde el HUCL es utilizado para comunicarse directamente con los dispositivos destinos, los dispositivos destino también obtienen beneficios similares de procesamiento reducido y consumo de energía reducidos . El uso de un protocolo común proporciona una interface estándar para todos los servicios. Un aspecto adicional de la presente invención proporciona un sistema para controlar dispositivos destino que comprende un servidor y por lo menos un cliente, en donde el cliente comprende: un portal que cuenta con: una función de manejo de eventos la cual almacena eventos, los cuales pueden ocurrir y, para cada evento, los comandos para controlar los dispositivos destine- una interface de servidor para la comunicación con el servidor; y, una interface para la comunicación con los dispositivos destino; y el servidor soporta una aplicación la cual configura la función de manejo de eventos para el control de los dispositivos destino, el portal se puede operar para permitir una operación continua de dispositivos destino, si se interrumpe la comunicación entre el portal y el servidor. Aquí, la funcionalidad descrita puede ser implementada en un programa computacional, equipo físico o en una combinación de estos. La invención puede ser implementada por medio de equipo físico que comprende varios elementos distintos, y por medio de una computadora programada apropiadamente . Por consiguiente, otro aspecto de la invención proporciona instrucciones para un portal para controlar una red de conexión local de dispositivos destino, las instrucciones provocan que un procesador del portal soporte: una función de manejo de eventos la cual almacena eventos lo cuales pueden ocurrir y, para cada evento, los comandos para controlar los dispositivos destino; una interface de servidor para la comunicación con un servidor remoto, el servidor remoto soporta una aplicación, la interface de servidor recibe comandos de la aplicación los cuales configuran la función de manejo de evento para el control de dispositivos destino; y, una interface para la comunicación con los dispositivos destino; en donde el portal se puede operar para permitir una operación continua de dispositivos destino, si se interrumpe la comunicación con el servidor remoto. Se deberá apreciar que el programa computacional puede ser instalado en el portal en cualquier punto durante la vida del equipo. El programa computacional puede ser almacenado en el dispositivo de memoria electrónica, disco duro, disco óptico, u otro medio de almacenamiento legible-con-máquina . El programa computacional puede ser entregado como un producto de programa computacional en una portadora legible-por-máquina o puede ser descargado directamente con el portal a través de una conexión de red. BREVE DESCRIPCIÓN DE LAS FIGURAS Las modalidades de la presente invención ahora se describirán, solamente a manera de ejemplo, con referencia a las figuras anexas, en las cuales: la Figura 1 muestra un Modelo de Servicio de Portal Residencial OSGi simplificado; la Figura 2 muestra un Modelo de Portal Virtual OSGi simplificado; la Figura 3 muestra un portal de conformidad con una modalidad de la invención; la Figura 4 muestra un sistema de mensajería utilizado en el portal de la Figura 3; la Figura 5 muestra al manejador de eventos y la base de datos utilizados dentro del portal de la Figura 3; las Figuras 6 y 7 muestran flujos de mensajes dentro del portal de la Figura 3 ; la Figura 8 muestra una jerarquía de servicio de dispositivo; y la Figura 9 muestra equipo físico para implementar el portal de la Figura 3. DESCRIPCIÓN DETALLADA DE LA INVENCIÓN La Figura 3 muestra el total de la arquitectura de un portal 150 de conformidad con una modalidad de la invención. El portal 150 está ubicado en las premisas en donde se requiere una red de conexión local. El portal 150 está conectado con una pluralidad de dispositivos destino 20-23, los cuales pueden incluir equipos, luminarias, interruptores de luz, termostatos y por el estilo. La colección total de los dispositivos destino 20-23 pueden operar de conformidad con diferentes protocolos de conexión en red. En este ejemplo, los dispositivos destino 20, 21 son parte de una red de conexión 40 que opera de conformidad con el protocolo ZigBee. La capa de red de conexión física para cada dispositivo de equipo físico 20-23 puede ser inalámbrica (por ejemplo IEEE 802.15.4 en el caso de ZigBee, IEEE 802.11, Bluetooth™ o similar) o cableada (por ejemplo, bus en serie, cableado de Eternet, cableado eléctrico (XlO) ) . El portal 150 también se conecta a una red de conexión 55 que proporciona un enlace de comunicación con un servidor remoto 50. El servidor 50 soporta una o más aplicaciones 130 el cual puede comunicarse con una interface de servidor 177 en el portal 150. La interface de servidor 177, la cual es una aplicación cliente del portal 150, ya sea que interactúe directamente con el sistema de mensajería HUCL 172 o actualice una base de datos 163 con información de evento activado/temporizado. El portal 150 incluye un controlador 160 que soporta una funcionalidad para el control de los dispositivos 20-23. En efecto, el controlador 160 junto con las redes locales 40, 45 y dispositivos 20-23 forman una 'célula de supervivencia' la cual puede permitir a los dispositivos 20-23 en el cliente operar aun si se interrumpe la comunicación con el servidor remoto 50. El controlador 160 opera de conformidad con un protocolo común, el cual en una modalidad preferida es el Lenguaje de Control Uniforme de Hogar (HUCL) . Las características principales del HUCL son descritas en las Solicitudes de Patente Internacional: WO 2004/015926, WO 2004/015927, WO 2004/015928 y WO 2004/015929. Un conjunto de controladores de protocolo de dispositivo 170 interactúan (o puentea) entre el protocolo usado sobre las redes de conexión 40, 45 y el lenguaje común (HUCL) utilizado por el controlador 160. Un sistema de mensajería HUCL 172 distribuye mensajes entre los controladores de protocolo 170, las unidades funcionales dentro del controlador 160, y la interface de programación de aplicación (API) 169, de acuerdo a lo mostrado en la Figura 4. El HUCL es un protocolo ligero que realiza bajas demandas sobre el equipo anfitrión, con el uso de mensajes XML comprimidos. El HUCL también proporciona una descripción de dispositivo básica y extendida, lo cual puede reducir encabezados de mensajería entre las unidades funcionales en el controlador 160. El HUCL API 169 interactúa con la aplicaciones 175 ejecutadas localmente. El controlador 160 opera de forma continua, prestando atención a los eventos de las redes de conexión 40, 45 y después verifica la base de datos 163 para ver si necesita tomar alguna acción en respuesta a los eventos. Si es así, el controlador toma las acciones necesarias (denominada un evento activado) . Si un temporizador expira, este también inicia un evento (llamado un evento temporizado) . Si la interface de servidor 177 recibe un mensaje del servidor 50, esta ya sea que actualice la tabla de eventos 173 (Figura 5) almacenados en la base de datos 163 (por ejemplo, un mensaje de aplicación 130 dice "Cuando el interruptor de luz es presionado, enciende la luz A", o "a las 8pm, enciende la lavadora"), o conversa con el sistema de mensajería HUCL para emitir un comando hacia un dispositivo destino tal como "enciende la luz A ahora" . Las aplicaciones remotas 130 solamente se comunican con la interface de servidor 177. Si la comunicación entre el portal 150 y el servidor 50 se interrumpe, entonces el controlador 160 continua para operar y continúa para responder a eventos activados y a eventos temporizados que previamente han sido almacenados en la base de datos 163. Ciertas características, limitadas no pueden ser soportadas durante un periodo de interrupción. Si la acción requerida por un evento activado involucra una comunicación con el servidor 50, entonces ésta no se puede obtener. También, durante un periodo de interrupción, el portal 150 no puede ser accedido por el servidor 50 o por cualquiera de las terminales remotas 200 para modificar la operación del controlador 160, o para emitir comandos directamente hacia los dispositivos destino (por medio de la interface de servidor 177 y el sistema de mensajería HUCL 172) . De acuerdo a lo descrito más adelante, un servidor local de red 176 también puede ser acondicionado para permitir que el portal 150 sea configurado localmente durante periodos de interrupción. Sobre el servidor 50, hay una Interface de Control de Hogar 135 la cual enviará/recibirá mensajes HUCL a través de la red de conexión 55 hacia la interface de servidor 177. La interface de servidor 177 entonces se comunica con el controlador 160, el cual a su vez se comunica con los diferentes dispositivos 20-23 sobre las redes de conexión locales 40, 45 por medio de los controladores de protocolo 170. Estos convierten los mensajes HUCL en el protocolo específico de red de conexión y viceversa para una comunicación ascendente. La base de datos 163 almacena información (una representación de programa computacional llamada un servicio de dispositivo) sobre cada dispositivo destino en las redes de conexión 40, 45. Se prefiere que esta información sea almacenada como un dispositivo compuesto HUCL. Un dispositivo compuesto HUCL es registrado con la estructura OSGi soportada por la plataforma de servicio 115 sobre el servidor 50, y el dispositivo compuesto a su vez representa el conjunto de dispositivos destino 20-23 en las redes de conexión 40, 45. El concepto de un dispositivo compuesto HUCL se describe en la Solicitud de Patente Internacional WO 2004/015927. El uso de un dispositivo compuesto HUCL convierte al sistema más escalable tanto que puede ser más fácilmente completado con un gran número de dispositivos destino 20-23. Los componentes principales del API 169 son los comandos SendHuclMsg ( ) y ReceiveHUCLMsg( ) y alguna información direccionada adicional para identificar cuál sub-dispositivo del dispositivo compuesto HUCL sea identificado en cada mensaje. El uso de un dispositivo compuesto HUCL permite una interface simple entre el portal 150 y el servidor 50. De conformidad con una característica del protocolo HUCL, de acuerdo a lo descrito en la Solicitud de Patente Internacional WO 2004/015956, una aplicación 130 puede requerir información al dispositivo compuesto HUCL para una simple descripción y una descripción extensa de cada dispositivo destino. El servidor 50 puede operar de una manera en la cual solicita información acerca de los dispositivos destino 20-23 conforme sea necesario, o puede almacenar información localmente. Almacenar información en el servidor 50 puede ser útil en el evento de que sea necesario reconfigurar el portal 150. El controlador 160 incluye un manej ador de eventos 162, un mecanismo de registro 166 y un gestionador de base de datos 164. El gestionador de base de datos 164 controla el almacenamiento y recuperación de datos de la base de datos local 163. El manejador de eventos 162 tiene dos aspectos principales : - la Configuración de evento, en el cual se presentan las activaciones, condiciones y acciones posibles y los comandos HUCL correspondientes son construidos y almacenados en la base de datos 163 de conformidad con un requerimiento del usuario, o de acuerdo a lo configurado por la aplicación remota 130. Los eventos pueden ser establecidos por cualquier cliente local (en este caso la interface de servidor 177 o el Servidor de Red local 176) . Las aplicaciones remotas 130 se comunican con la interface de servidor 177 para establecer, actualizar o cancelar eventos. - Manejador de Eventos de Dispositivos HUCL, en el cual el controlador 160 se suscribe para recibir todos los Eventos de Dispositivos HUCL generados por los protocolos de dispositivo, y verifica si alguno activa un Evento local almacenado. Si se detecta una activación se verifica la condición (si hay alguna) , y se expiden las acciones de comando HUCL pre-configuradas . Los eventos almacenados son configurados por las aplicaciones de cliente 175 o las aplicaciones remotas 130, con el uso de llamados al Manejador de Eventos 162 para establecer las activaciones, condiciones y acciones. Los Eventos de Dispositivo generados por los dispositivos destino, tal como "la lavadora ha concluido", o "el interruptor de luz se ha accionado", los eventos almacenados son asociados con la ocurrencia de eventos de dispositivo particulares, por ejemplo, "Cuando un detector infrarrojo pasivo (PIR, por sus siglas en inglés) sensa un movimiento dentro de un cuarto, suena la alarma contra robos" . El proceso de monitorear con respecto a la ocurrencia de eventos locales, y actuar en base a ellos, continua en la célula de supervivencia autónomamente en el evento de una interrupción de la conexión con el servidor 50. Una lista es mantenida en la base de datos de aquellos clientes quienes se suscribieron a Eventos de Dispositivo particulares. De acuerdo a lo mostrado en la Figura 5, el manejador de eventos 162 almacena datos de evento local 173 en la base de datos 163. Los eventos almacenados pueden ser activados por Eventos de Dispositivo HUCL de los Manejadores de Protocolo de Dispositivo (por ejemplo, un interruptor de luces que es encendido o un termostato ha alcanzado una temperatura particular) , o por la expiración de un temporizador 161 en el manejador de eventos 162 (por ejemplo en respuesta a datos de evento almacenados para encender una luz a las 8 p.m., o apagar un calefactor después de un periodo de 30 minutos) . El manejador de Eventos 162 almacena, para cada evento, cualquiera de las condiciones que aplican para ese evento (por ejemplo, un tiempo real o un tiempo culminado el cual puede ser monitoreado por la función temporizador 161) y un conjunto de acciones que deben ser ejecutadas en respuesta a ese evento (por ejemplo, encender la luz de seguridad) . Otras condiciones posibles que se pueden aplicar son, por ejemplo, "solamente encender las luces a las 8 p.m. cuando estoy de vacaciones", o una condición la cual es dependiente del estado de los dispositivos, por ejemplo "solamente encender la luz exterior si el medidor de luz indica está oscuro" . El mecanismo de registro 166 permite al sistema registrar datos, tal como eventos y errores, al escribir datos para un archivo de registro. Este puede ser utilizado para registrar datos acerca del sistema. El servidor local de red 176 es acondicionado en el portal 150 como un respaldo para permitir una configuración local desde un programa de navegación de red ubicado sobre la misma red de conexión local 150. Este también está conectado con el controlador 160. La página de red para interactuar con el sistema podría ser configurada podría ser configurada para una primera observación del servidor de red local 176. Éste entonces podría probar la conexión remota y redirigirla hacia un usuario si está disponible. Si no, omitiría las páginas de red locales . La interface de servidor 177 puede interactuar con la base de datos 163 y recuperar una lista de eventos actuales y enviar ésta con la aplicación 130 para mostrarla al usuario.
Si se interrumpe la comunicación con el servidor 50 entonces el servidor-de-red local 176 también puede hacer esto. Ahora se describirán los flujos de mensaje ejemplar para dos escenarios con referencia a las Figuras 6 y 7. Primeramente, la figura 6 muestra los flujos de mensaje cuando un comando es enviado desde una aplicación 130 hacia un dispositivo destino en la red de conexión. La iniciación del comando que es enviado desde la aplicación 130 puede originarse desde una aplicación de usuario remota, por ejemplo un programa de navegación de red, que se ejecuta en la terminal 200, conversando directamente con la aplicación 130, o a través de un servidor de red en 50 el cual entonces conversa con la aplicación 130. En el paso 601, la aplicación 130 envía un mensaje HUCL a través de la red de conexión 55, por medio de la Interface de Control de Hogar 135, hacia la interface de servidor 177. La interface 177 entonces genera un mensaje 602q ue describe al comando de dispositivo. En el paso 603, el sistema de mensajería HUCL 172 entrega el mensaje de comando al controlador de protocolo de dispositivo 170. Opcionalmente, en el paso 604, el controlador de protocolo de dispositivo 170 solicita información almacenada de la base de datos 163 por medio de la API de base de datos y en el paso 605, la respuesta es regresada como un mensaje HUCL. En general, cada red de conexión 40, 45 tiene una manera diferente de direccionar los dispositivos y las operaciones de búsqueda de base de datos en los pasos 604, 605 es una forma de recuperar información específica de red de conexión. Sobre una red de conexión XlO, los dispositivos son referidos por sus códigos de hogar y dispositivo, mientras que el HUCL solamente tiene una ID de dispositivo individual. Sobre una red de conexión Zigbee hay una red de conexión y direcciones de dispositivo. En un método alternativo, toda la información en conexión de red es depositada dentro de los Controladores de Protocolo de Dispositivo 170. En el paso 606 el controlador de protocolo de dispositivo 170 convierte el comando en un mensaje el cual es enviado hacia un dispositivo destino particular 20-23 sobre la red de conexión destino 40, 45. Como una alternativa a lo anterior (pero no se muestra en la Figura 6) , la aplicación remota 10 envía un mensaje a través de la red de conexión 55 la cual está prevista para configurar un evento en la base de datos 163. Los pasos 601 y 602 son los mismos como los anteriores. Sin embargo, en el paso 603 un mensaje HUCL es enviado hacia el manejador de eventos 162 el cual incluye detalles del evento que deben ser almacenado (mostrado como un 'comando de configuración' en la Figura 5) . El manejador de eventos 162 entonces actualiza la base de datos 163 con esta información. El evento puede ser un evento activado o un evento temporizado. Como resultado de que un dispositivo destino sea controlado, en la forma descrita anteriormente, o en respuesta a una interacción de usuario con un dispositivo destino (por ejemplo, encender un interruptor de luces) , se puede generar un nuevo evento de dispositivo.
Esto provocará la secuencia de mensajes mostrada en la Figura 7. En la Figura 7, un evento de protocolo de dispositivo es enviado desde un controlador de protocolo. En el paso 701, se detecta actividad por el equipo físico sobre la red de conexión 45 y es comunicada por medio de controladores de bajo-nivel, tal como controladores Linux. Un controlador de protocolo de dispositivo 170 llega a enterarse de la actividad sobre la red de conexión 45. En los pasos opcionales 702, 703 los mensajes HUCL transfieren datos hacia/desde la base de datos 163 la cual incluye suscriptores de evento de protocolo de dispositivo y posiblemente el estado del dispositivo en-curso y actualizado. Cada operación incluye una solicitud 702 y una respuesta 703. En los pasos 704a, 704b el controlador de protocolo de dispositivo 170 genera un mensaje de evento HUCL que representa un evento de protocolo de dispositivo y lo envía por medio del sistema de mensajería HUCL 172 hacia todos los destinos suscritos. El manejador de eventos 162 suscribe para todos los eventos de dispositivo y así siempre se encontrará en una posición para responder a eventos dentro de la red de conexión. Las aplicaciones de cliente 175 también pueden suscribir a los eventos de dispositivo, incluyendo la interface de servidor 177. En el paso 705 el manejador de eventos 162 solicita información de los datos de evento 173 mantenidos en la base de datos 163 para determinar si existen algunas condiciones asociadas con el evento y regresa datos en el paso 706. El manejador de eventos 162 entonces puede determinar si las condiciones de evento (si hay alguna) se han cumplido y, en ese caso, emite los comandos UHCL asociados con ese evento en el paso 707.
Se deberá observar que esta operación puede ocurrir aún cuando se interrumpa la comunicación con el servidor remoto. Una de las características de esta arquitectura la cual permite al controlador 160 suministrar un nivel útil de funcionalidad con solamente un procesamiento y capacidades de almacenamiento limitados, es el dispositivo tipo jerárquico de HUCL. Esto se describirá con referencia a la Figura 8. El HUCL tiene un arreglo jerárquico de servicios de dispositivo. La Figura 8 muestra una jerarquía ejemplar de servicios de dispositivo 300, con un dispositivo HUCL general 301 en la parte superior. La función 'getSubDevices ( ) ' regresa el servicio de dispositivo de la capa siguiente de sub-dispositivos, si alguno se encuentra presente. Desplazándose hacia abajo de la jerarquía, los servicios de dispositivo tienen un nivel incrementado de detalle/funcionalidad. Así, el servicio de dispositivo 302 representa un dispositivo destino que tiene la capacidad de encender/apagar. Desplazándose hacia abajo del lado izquierdo de la jerarquía, el servicio de dispositivo 303 define a una lámpara básica, la cual hereda la característica de la clase anterior, en este caso también puede encender/apagar. El servicio de dispositivo 304 define una lámpara de luz que se puede atenuar, en este caso una lámpara con la función de ser establecida para un valor de brillantez particular dentro de un intervalo de posibles valores. El servicio de dispositivo 304 también hereda las características de 302 y 303 acerca de este, en este caso es una lámpara y puede encenderse/apagarse. Desplazándose hacia abajo del lado derecho de la jerarquía, el servicio de dispositivo 305 define un timbre de puerta el cual hereda las características de un dispositivo HUCL de encendido/apagado 302. En este ejemplo, si una aplicación (por ejemplo aplicación 130) no conoce como conversar con un dispositivo del tipo "HUCLDimmableLamp" , este aún puede utilizar la definición "HUCLBasicLamp" o aún la definición básica "HUCLDevice" con la certeza de que el servicio de dispositivo comprenderá esa funcionalidad. Efectivamente, el HUCL permite una aplicación para "caminar hacia arriba del diagrama jerárquico", y si una aplicación encuentra que este no reconoce un tipo de dispositivo (por ejemplo lámpara de atenuación de luz) entonces verifica los otros tipos de dispositivos listados en la lista de tipos de dispositivos proporcionada como parte del servicio de dispositivo. Similarmente, una aplicación la cual tiene la capacidad de encender/apagar algo, puede controlar una lámpara, timbre de puerta o cualquier otro tipo de dispositivo el cual tenga la capacidad de ser encendido/apagado puesto que los servicios de dispositivo que representan todos los dispositivos destino seguirán la jerarquía. Un dispositivo destino es representado en cualquier nivel arriba de su representación "más baja", la representación más precisa. Este acercamiento permite que los dispositivos sean manipulados a su grado más completo, aun en situaciones en donde el desarrollador no conoce los detalles completos de un dispositivo en particular. Esto permite a lo fabricantes de los dispositivos destino proporcionar productos los cuales inter-operarán hasta un cierto nivel, pero también agregar características únicas a sus productos las cuales los diferencian de otros productos.
El portal 150 descrito anteriormente puede ser implementado sobre una variedad de plataformas de procesamiento, tal como una PC de propósitos generales o una unidad de procesamiento dedicada, aun cuando la arquitectura es particularmente apropiada para plataformas de procesamiento con una modesta potencia de procesamiento, ya que no es necesario soportar una Máquina Virtual Java y una Aplicación Java OSGi. La Figura 9 muestra los componentes principales de la plataforma de procesamiento. Una unidad central de procesamiento 401 ejecuta el programa computacional, de acuerdo a lo descrito previamente, para soportar al controlador 160 y las aplicaciones cliente 175. Típicamente, la unidad central de procesamiento 401 tiene un sistema de operativo nativo (por ejemplo, basado en Linux) . La memoria no-volátil 402 y la memoria volátil 403, tal como un disco duro, almacenan el programa computacional operativo utilizado por la unidad de procesamiento 401. Un módem 406, tal como un módem ADSL de banda ancha o un módem por cable, se conecta con la red de conexión 55 la cual conecta el portal 150 con un servidor remoto (50, Figura 3) sobre el cual se soportan las aplicaciones. El módem de banda ancha 406 puede ser externo al portal 150. Los mensajes de control hacia/desde dispositivos controlados son portados mediante las conexiones de redes de conexión local 415, las cuales utilizan una combinación de tecnologías cableadas 412 e inalámbricas 411. Se puede proporcionar equipo físico apropiado para soportar la red de conexión local particular tal como: una tarjeta de red de conexión de área local; un módem inalámbrico, infrarrojo o con de suministro de energía por cable (por ejemplo XlO) . Las entradas de usuario pueden ser proporcionadas directamente al portal mediante dispositivos de entrada 410 tal como teclado numérico, teclado, ratón o tablero. Alternativamente, las entradas de usurario pueden ser recibidas desde una unidad de control remoto que está localmente conectada en red con el portal 150, o desde la terminal 200 conectada con la red de conexión 55. Como un ejemplo, si un usuario se encuentra lejos de su hogar y desea enviar instrucciones al portal para controlar dispositivos dentro del hogar, un usuario interactuará con una terminal remota 200 y enviará instrucciones, por medio de una conexión de red de conexión hacia el portal 150. Una salida puede ser presentada directamente a un usuario por medio de un controlador de pantalla 408 y de la pantalla 409, hacia una unidad de control local 220 o hacia una terminal remota 200. Un bus 405, o una combinación de buses de diferentes tipos, conectarán las unidades anteriores. Una amplia variedad de aplicaciones 130 pueden ser ejecutadas sobre el servidor remoto 50. Ejemplos de estas incluyen: controles de hogar, tal como simulación de ocupación de un edificio mediante el encendido y apagado de lámparas en períodos predeterminados, control de la ventilación y calefacción, programación de una videograbadora; control de dispositivos electrónicos de entretenimiento y consumo; monitoreo remoto de seguridad para un edificio o de la salud de un ocupante de un edificio; diagnóstico/reporte remoto de fallas. Se deberá observar que las modalidades ilustradas-anteriormente son una ilustración más que una limitación de la invención, y que las personas experimentadas en la técnica tendrán la capacidad de diseñar varias modalidades alternativas sin separarse del alcance de las reivindicaciones anexas. En las reivindicaciones, cualquier signo de referencia colocado entre paréntesis no se deberá interpretar como una limitación de la reivindicación. Las palabras "comprende" e "incluye" no excluyen la presencia de otros elementos o pasos diferentes a los listados en la reivindicación. En donde las reivindicaciones de sistemas/dispositivos/aparato describan varios medios, varios de estos medios pueden ser caracterizados por uno y por el mismo artículo de equipo físico. En la descripción anterior y con referencia a las figuras se describe un portal 150 el cual está conectado con las redes de conexión local 40, 45 de los dispositivos destino 20-23. El portal 150 tiene una función de manejo de eventos 162 la cual almacena eventos 173 los cuales pueden ocurrir y, para cada evento, los comandos para controlar los dispositivos destino 20-23. Un servidor remoto 50 soporta una aplicación 130 la cual configura la función de manejo de eventos 162 para el control de los dispositivos destino así como para la comunicación directamente con los dispositivos destino 20-23. El portal 150 continúa para permitir la operación de los dispositivos destino 20-23 si se interrumpe la comunicación con el servidor remoto 50. La invención puede ser utilizada como una mejora del Modelo de Portal Virtual OSGi, con una aplicación Java OSGi 130 que es soportada por una Máquina Virtual Java sobre el servidor 50. La función de manejo de eventos 162 se puede obtener al ejecutar una aplicación escrita en el código nativo del portal 150. Se hace constar que con relación a esta fecha, el mejor método conocido por el solicitante para llevar a la práctica la citada invención, es el que resulta claro de la presente descripción de la invención.