CAPA DE ABSTRACCIÓN DE DISPOSITIVO PARA SISTEMA DE INTEGRACIÓN EN RED LOCAL
DESCRIPCIÓN DE LA INVENCIÓN Esta invención se relaciona con un sistema de integrción en red local, con una plataforma para uso en el sistema y con instrucciones las cuales operan la plataforma. Existe interés considerable en integrar en red aparatos eléctricos dentro del ambiente casero y se han desarrollado en años recientes una variedad de protocolos de integración en red. El protocolo universal de enchufar y reproducir (UPnP) ha sido adoptado principalmente para periféricos de computadoras personales y extensiones audivisuales (AV) del protocolo permite que los dispositivos AV, tales como cortadores de medio y reproductores de medio determinen cuál contenido está disponible sobre dispositivos similares y para controlar la transferencia de dicho contenido entre dispositivos. Se considera a UPnP como un protocolo excesivamente de "peso pesado" el cual establece demandas considerables para un dispositivo hospedador, que incluyen potencia de procesamiento y consumo de energía. En consecuencia, no es ideal para uso en equipo con una baja capacidad de potencia (por ejemplo con baterías) el cual tiene recursos limitados y el cual de otra manera requiere sólo de capacidad de procesamiento mínimo. Otros protocolos, tal como REF:i77357 el protocolo de European Home Systems (EHS), ZigBee y XlO, han sido utilizados cada uno para controlar aparatos eléctricos caseros. Es probable que una red casera incluya un intervalo diverso de equipo, el cual variará de una computadora personal y reproductores de medio con capacidades de procesamiento poderosas, a dispositivos sencillos los cuales únicamente requieren instrucciones de encendido/apagado, tales como aparatos pequeños, termostatos e interruptores de iluminación. La iniciativa de compuerta de servicios abierto (OSGi, por sus siglas en inglés) es una infraestructura administrada abierta que tiene como objetivo permitir que las aplicaciones (o "servicios") sean desplegados, instalados y funcionen en redes locales tales como casas, vehículos y oficinas pequeñas. El núcleo de la red local es una compuerta, la cual soporta una plataforma de servicio OSGi la cual ejecuta la infraestructura OSGi. La versión publicada más reciente de la especificación de la plataforma de servicio OSGi es la versión 3 de marzo del 2003 de la alianza de OSGi, y se puede encontra más información acerca de OSGi en www.osgi.org. Parte de la especificación de plataforma de servicio cubre el acceso de dispositivos conectados a la plataforma de servicio. La especificación introduce dos tipos de entidades para obtener esto: las entidades "dispositivos" las cuales representan conceptos tales como "impresora", "ratón", "lámpara", etc. y las entidades "de mando", las cuales representan conceptos tales como "USB", "en serie", etc. Por ejemplo, para representar un "ratón USB", la entidad selectora de mando OSGi debe seleccionar un dispositivo adecuado y un controlador y colocarlos juntos. Con el fin de que sea abierta y extendible, OSGi no tiene definida una interconexión común para estas entidades de dispositivo a partir de la aplicación ni tan poco una interconexión común entre el dispositivo y las entidades de mando. Esto ha resultado en que las compañías desarrollen sus propias interconexiones de programación de aplicación registradas (API), las cuales reducen lo abierto de la especificación. La figura 1 muestra un modelo simplificado de la especificación de acceso de dispositivo OSGi existente. Una aplicación 10 representa un programa (software) que implementa un servicio particular. En este caso sencillo, la aplicación 10 controla dos lámparas 20, 30, dentro de una casa, encendiéndolas y apagándolas en momentos particulares en el día. La primera lámpara 20 que necesita ser controlada opera de acuerdo con el protocolo de sistemas caseros europeos (EHS) . La segunda lámpara 30 que necesita ser controlada opera de acuerdo con el protocolo ZigBee. Tanto EHS como ZigBee son protocolos existentes para integración de redes caseras . Los controladores de base 22, 32 para cada lámpara 20, 30 respectivos descubren equipos físicos (hardware) nuevo y registran un "servicio de dispositivo" 25, 35 correspondiente con la infraestructura OSGi. Cada servicio 25, 35 de dispositivo es una representación de programa del dispositivo 20, 30 de elemento físico real que va a ser controlado. La aplicación 10 debe saber acerca de cada posible dispositivo 25, 35 de lámpara con el cual interactúe y debe conocer los detalles de cada API 26, 36 que interconecte la aplicación 10 con el servicio 25, 35 de dispositivo. Una representación 25 EHS de un dispositivo de lámpara es muy diferente de una representación 35 ZigBee de dispositivo de lámpara. En consecuencia, la aplicación 10 se vuelve una pieza de programa compleja incluso para aplicaciones sencillas. Además, debido a qu.e los servicios de dispositivo no están estandarizados, un vendedor diferente es libre de representar al mismo dispositivo de elemento físico (por ejemplo lámpara 20) de una manera diferente, utilizando un controlador 21 diferente y una presentación 25 de servicio de dispositivo. Considérese un ejemplo en donde una segunda aplicación 11 se suministra por un vendedor diferente, pero que también necesita encender o apagar una lámpara 20, el desarrollador de la segunda aplicación 11 debe saber los detalles del API 26 o debe proporcionar a su propio dispositivo y controlador el cual pueda controlar a la lámpara 20. La presente invención busca proporcionar una interconexión mejorada dentro de una arquitectura de integración en red local, tal como la infraestructura OSGi. En consecuencia, un primer aspecto de la presente invención proporciona una plataforma para uso en el control de dispositivos objetivo en una red local, que comprende un procesador el cual soporta una infraestructura de compuerta de servicios abiertos y la cual puede ejecutar por lo menos una aplicación para controlar los dispositivos objetivo, en donde cada uno de los dispositivos objetivo está representado por una entidad la cual puede ser manipulada por la aplicación mediante una interconexión de programación de aplicación (API, por sus siglas en inglés), las entidades siguen una estructura jerárquica común de tipos de dispositivo, en la cual una entidad que representa a un tipo de dispositivo inferior en la jerarquía hereda las propiedades de los tipos de dispositivo superiores en jerarquía, por lo que presenta una API consistente para aplicaciones. La infraestructura de compuerta de servicios abierta preferiblemente, aunque no se limita, a la infraestructura de la iniciativa de compuerta de servicios abiertos (OSGi) . El uso de entidades con una estructura jerárquica consistente permite que las aplicaciones se comuniquen de una manera simplificada aunque poderosa, con dos dispositivos objetivo. Las entidades forman parte de una capa de abstracción la cual abstrae de cada API específico de dispositivo y específico de red, y el cual preferiblemente utiliza un lenguaje común. Preferiblemente, la estructura jerárquica es proporcionada como parte de un protocolo de poco peso, tal como el lenguaje de control uniforme casero (HUCL, por sus siglas en inglés) . Esto permite a los desarrolladores de aplicación tener acceso a cada servicio de dispositivo y por lo tanto al dispositivo objetivo en un sistema de una manera estándar y amigable para el usuario. Los desarrolladores independientemente pueden escribir aplicaciones con la certidumbre de que pueden ser utilizados de manera confiable con dispositivos objetivo dentro de la infraestructura OSGi. Además, la interconexión entre un "controlador HUCL" y objetos de "servicio de dispositivo HUCL" en el sistema se estandariza, ahora se utiliza una interconexión HUCL común a través de todas las coincidencias . Esto permite una aplicación sencilla para controlar los dispositivos objetivo, los cuales se conectan a la plataforma por diferentes protocolos de integración en red, en base en un servicio de dispositivo único. Se pueden agregar dispositivos objetivo nuevos utilizando protocolos nuevos, mientras aún se utilizan las aplicaciones de servicio existentes. Se puede utilizar HUCL como un lenguaje común entre la totalidad de los servicios de dispositivo y en controladores de enlace, los cuales se interconectan con los protocolos de red local que se conectan con los dispositivos objetivo. Otras ventajas de utilizar HUCL es la naturaleza de poco peso del protocolo, lo cual establece pocas demandas en el equipo hospedador. HUCL puede utilizar mensajes XML comprimidos y proporciona una descripción básica y extendida lo cual reduce las sobrecargas de envío de mensajes. Las características principales de HUCL se describen en las solicitudes de patentes internacionales: WO 2004/15926, WO 2004/015927, WO 2004/15928 y WO 2004/015929. Originalmente, HUCL se desarrolló como un protocolo de poco peso para controlar dispositivos, pero se ha hecho evidente que HUCL también puede proporcionar un protocolo ideal para uso dentro de una compuerta OSGi. HUCL junto con controladores de base de bajo nivel proporciona independencia de red (un lenguaje común) e independencia de protocolo
(instrucciones de dispositivo estandarizadas dentro de dicho lenguaje, que incluyen conjuntos de instrucciones, parámetros, funcionalidad, etc.). Otros protocolos carecen de la capacidad de enlazar, soportar dispositivos compuestos, la capacidad de soportar más de una capa de subdispositivos o de especificación abierta proporcionada que se suministra por HUCL y por lo tanto no son adecuados para uso como una capa de abstracción. Las aplicaciones se comunican por medio del "servicio de dispositivos" del dispositivo objetivo, el cual es específico para el tipo de dispositivo del dispositivo objetivo y el cual se obtiene del conjunto HUCL, de una manera similar al utilizado para UPnP en OSGi. Estos servicios de dispositivo se pueden ver como "conjuntos auxiliares" dado que están presentes como una interconexión Java específica del dispositivo para la aplicación, pero se pueden comunicar con los controladores de nivel inferior utilizando mensajes XML o XML comprimidos. Si el dispositivo objetivo utiliza un protocolo el cual no es HUCL, por ejemplo UPnP, XlO o ZigBee, los controladores HUCL (controladores de enlace) lo convierten desde HUCL al protocolo utilizado por el dispositivo objetivo. Se proponen dos métodos principales de manejo de servicios de dispositivo. En el primer método, cada dispositivo objetivo está representado por un dispositivo de servicio HUCL el cual se registra con la infraestructura OSGi . Los servicios de dispositivo tienen una estructura jerárquica de tipos de dispositivos los cuales siguen a los dispositivos objetivo, y las funcionalidades de los dispositivos objetivo que representan. Una manera preferida de obtener la estructura jerárquica es mediante el uso de la estructura de clase Java jerárquica en donde las clases Java de nivel inferior heredan las propiedades de las clases de nivel superior de las cuales dependen. No obstante, como se describe de manera más completa en la descripción detallada siguiente, existen otras maneras de obtener esta funcionalidad jerárquica. En el segundo método, un servicio de dispositivo único se registra con la infraestructura OSGi y el servicio de dispositivo es un dispositivo compuesto HUCL el cual es capaz de representar una gran cantidad de subdispositivos. Cada subdispositivo tiene como referencia un identificador e incluye una versión equivalente de HUCL del servicio de dispositivo utilizado en el primer método, el cual sigue la misma estructura jerárquica de los tipos de dispositivo y funcionalidades. El segundo método tiene el beneficio de reducir el número de entidades que se necesitan registrar y seguir por la infraestructura OSGi. Aunque una entidad o servicio de dispositivo habitualmente mapea a un dispositivo objetivo de equipo físico individual, la especificación OSGi hace notar que esto no se limita de esta manera. Esta invención es aplicable a cualquier plataforma que implemente una infraestructura OSGi y que controle dispositivos objetivo. Esto incluye compuertas residenciales, descodificadores, PC, asistentes digitales personales (PDA, por sus siglas en inglés) , servidores de medio y otros dispositivos electrónicos de consumidor o médicos. La funcionalidad que se describe aquí se puede implementar en programas, equipos físicos o una combinación de estos. La invención se puede implementar por medio de equipo físico que comprende varios elementos distintos y por medio de una computadora programada adecuadamente. En consecuencia, otro aspecto de la invención proporciona instrucciones para una plataforma la cual controla los dispositivos objetivo en una red local, las instrucciones provocan que un procesador de la plataforma soporte una infraestructura de compuerta de servicios abierta y ejecute por lo menos una aplicación para controlar los dispositivos objetivo, en donde cada dispositivo objetivo está representado por una entidad la cual puede ser manipulada por la aplicación a través de una interconexión de programación de aplicación (API, por sus siglas en inglés) , las entidades siguen una estructura jerárquica común de tipos de dispositivo, en las cuales una entidad que representa un tipo de dispositivo inferior en la jerarquía hereda las propiedades de los tipos de dispositivo superior en la jerarquía y de esta manera presenta una API consistente para aplicaciones. Se apreciará que el programa puede ser instalado en la compuerta en cualquier punto durante la vida del equipo. El programa puede ser almacenado en un dispositivo de memoria electrónica como un disco duro, un disco óptico u otro medio de almacenamiento legible para una máquina. El programa se puede suministrar como un producto de programa de computadora sobre un portador legible en una máquina o se puede descargar directamente de la plataforma vía una conexión con la red. Un aspecto adicional de la invención proporciona una biblioteca de entidades para uso con una plataforma la cual soporta una infraestructura de compuerta de servicios abierta y la cual puede ejecutar por lo menos una aplicación para controlar los dispositivos objetivo en una red local, cada entidad representa un dispositivo objetivo en la red y es manipulable por una aplicación a través de una interconexión de programación de aplicación (API, por sus siglas en inglés) , y en donde las entidades siguen una estructura jerárquica común de tipos de dispositivo, en la cual una entidad representa un tipo de dispositivo inferior en la jerarquía hereda las propiedades de los tipos de dispositivo superiores en la jerarquía, por lo que presenta una API consistente para aplicaciones. La biblioteca puede ser alojada por la compuerta o por un servidor remoto el cual es accesible por la plataforma. Las modalidades de la presente invención se describirán a continuación, a modo de ejemplo únicamente, con referencia a las figuras anexas, en las cuales: la figura 1 muestra un escenario de ejemplo del control de una lámpara utilizando una infraestructura OSGi convencional ; la figura 2 muestra un modelo general de una compuerta residencial OSGi; la figura 3 muestra una infraestructura OSGi de acuerdo con una modalidad de la presente invención; la figura 4 muestra el mismo escenario que la figura 1 implementado en la infraestructura de la figura 3; las figuras 5A y 5B muestran dos maneras de implementar la infraestructura de la figura 3 ; las figuras 6A y 6B muestran flujos de mensaje que se producen cuando un dispositivo objetivo nuevo se une a la red; las figuras 7A y 7B muestran flujos de mensaje los cuales se producen cuando se retira de la red un dispositivo objetivo existente; las figuras 8A y 8B muestran flujos de mensajes que se producen cuando una aplicación controla a un dispositivo objetivo; las figuras 9A y 9B muestran ejemplos de una jerarquía de servicios de dispositivo utilizada dentro de la infraestructura; la figura 10 muestra un mecanismo para notificar a las aplicaciones de eventos dentro de los dispositivos objetivo; y la figura 11 muestra un ejemplo de una plataforma la cual puede implementar la infraestructura de la figura 3. La figura 2 muestra un modelo general simplificado para una compuerta residencial de iniciativa de compuerta de servicios abierta (OSGi, por sus siglas en inglés) . Una compuerta 110 de servicio se localiza dentro de una casa, oficina, un vehículo o similar. La compuerta 110 de servicio incluye una plataforma 112 de servicio la cual soporta a la infraestructura OSGi. Las aplicaciones 130, las cuales proporcionan diversos servicios dentro de la casa, se ejecutan por la plataforma 112 para controlar los dispositivos 20-23 objetivo. Las aplicaciones pueden tener una diversidad de propósitos que incluyen control de aparatos eléctricos, tales como equipos electrónicos de consumidor, línea blanca, calentamiento y ventilación, iluminación, etc. Los dispositivos 20-23 objetivo puede incluir lámparas 20, aparatos eléctricos 21 o cualquier otro dispositivo eléctrico. La compuerta 110 se conecta con los dispositivos 20-23 objetivo utilizando protocolos de integración en red local. Una casa típica incluirá dispositivos objetivos los cuales operan de acuerdo con una gama de protocolos de red objetivo tales como ZigBee, XlO, UPnP, EHS, KNX y Echelon. La capa de red física para cada dispositivo de elemento físico, puede ser inalámbrica (por ejemplo IEEE 802.15.4 en el caso de ZigBee, IEEE 802.11 o similar) o puede ser cableada (por ejemplo un bus serial, cableado Ethernet, cableado eléctrico (X10)). En la figura 2, la red 40 es una red ZigBee y la red 45 es una red XlO. Un servicio 50 remoto, fuera de la casa, se puede comunicar con la compuerta 110. Se pueden suministrar servicios a la compuerta por el servidor 50, o en algunas circunstancias, las aplicaciones 120 en el servidor 50 puede controlar a los dispositivos 20-23 objetivo control dentro de la casa. El servidor remoto también se puede utilizar para administración de red y para proporcionar servicios nuevos o servicios actualizados a la compuerta 110. La figura 3 muestra la arquitectura general de una compuerta 110 OSGi. Una plataforma 112 de servicio soporta la infraestructura OSGi, la cual típicamente se proporciona por el software ejecutado por un procesador dentro de la compuerta. Las aplicaciones las cuales controlan los dispositivos objetivo en la red se pueden ejecutar de manera remota en el servidor 50 (aplicación 120) o localmente en la plataforma 112 de servicio (aplicación 130) . De acuerdo con una modalidad de la invención, se utiliza el lenguaje de control uniforme casero (HUCL, por sus siglas en inglés) como una capa de abstracción dentro de la infraestructura OSGi soportada por la plataforma 112 de servicio. Cada dispositivo 151-153 objetivo, el cual existe en la red local, está representado por un "servicio de dispositivo" 133. Esto es una representación, en programa, del dispositivo físico 151-153 real. Un servicio de dispositivo incluye la siguiente información: información básica para interactuar con un dispositivo, que incluye la versión de HUCL y la versión de HUCL soportada mínima; información básica para identificar un dispositivo, que incluye: una lista de tipo de dispositivo (una lista de los códigos de tipos de dispositivo HUCL, cada uno estandarizado para representar un tipo de dispositivo especificado, por ejemplo una lámpara) , una lista similar de tipos de dispositivo que pueda controlar este dispositivo; diversos datos extendidos, por ejemplo nombre del dispositivo, cadena de ubicación, fabricante, nombre del modelo, número de serie, Ul URL (interconexión de usuario URL) ; funcionalidad para enviar instrucciones al dispositivo objetivo y para recibir respuestas y eventos. De manera adicional, un dispositivo compuesto, el cual puede representar dispositivos objetivo múlitiples, incluye referencias a los subdispositivos que representa. En contraste a los dispositivos 25, 35 utilizados en la figura 1, los servicios de dispositivo 133 tienen una estructura jerárquica. Esto permite a las aplicaciones 130 controlar los dispositivos objetivo en una extensión tan grande como sea posible, como se explicará en lo siguiente. Los tipos de dispositivos objetivo (aparatos eléctricos) tal como una lámpara, televisión, refrigerador, etc., tienen cada uno un servicio de dispositivo 133 estandarizado. La API la cual permite que una aplicación 130 se comunique con cada servicio de dispositivo 133 está.bien definida y ya no es algo que sea registrado. Esto permite que las aplicaciones 130 se comuniquen con los servicios de dispositivo 133 de una manera sencilla y estandarizada. Una manera de obtener la estructura jerárquica es mediante la utilización de un conjunto estandarizado de objetos Java1™ u otro lenguaje de programación que proporcione una jerarquía de tipos de clase, aunque se pueden utilizar otros métodos. Las aplicaciones 120, 130 que corren dentro de la infraestructura OSGi no necesitan saber cuál tipo de protocolo de integración a la red (por ejemplo UPnP, ZigBee) es utilizado por sus dispositivos objetivo, lo cual simplifica considerablemente la aplicación. Aplicaciones múltiples pueden utilizar los mismos servicios de dispositivo 133 y los API. Un conjunto 140 HUCL conecta los controladores 141,
142, 143, registra los servicios de dispositivos 133 con la infraestructura OSGi y proporciona características de administración generales tales como el sistema de envío de mensajes HUCL. Los controladores 141, 143 para ZigBee y UPnP se muestran cada uno como una entidad única. No obstante, se pueden dividir de la misma manera a la mostrada para los controladores para XlO, con un controlador 163 de base y un controlador 142 de refinamiento, el cual utiliza parte de la funcionalidad del controlador 163 de base. Es posible minimizar el papel de la entidad de administración central al permitir que los servicios de dispositivo 133 se registren a sí mismos con la infraestructura OSGi, administrar eventos de suscripciones (descritos de manera más completa en lo siguiente) y pasar mensajes HUCL a los controladores y permitir que los controladores realicen la totalidad de las traducciones a protocolos utilizados por las redes objetivo. En este caso, las tareas principales del conjunto 140 HUCL son: administración central - ID de la versión almacenada, etc. controladores de pista y servicios de dispositivo (tales como los que se utilizan para los mecanismos de suscripción relevantes de las infraestructuras OSGi ) ; - servicios de dispositivos de registros (para cada servicio de dispositivo en la figura 5A; en la figura 5B un servicio de dispositivo se puede registrar únicamente para dispositivos compuestos) ; acoplamiento en interacciones de localizador de controlador OSGi (o interacciones de red para un controlador HUCL que actúa como un controlador de base de bajo nivel) ; administración de eventos de suscripción (de manera que sea capaz de enviar eventos según se requiera) ; comunicarse utilizando HUCL; - realizar traducciones de protocolo (entre HUCL y el protocolo de red objetivo) ; ordenar/desordenar cadenas de mensaje HUCL hacia/desde una API Java amigable con el programador. Los controladores 141, 142, 143 administran los dispositivos objetivo en las redes objetivo y las presentan como servicios de dispositivo 133 HUCL dentro de la infraestructura OSGi. Esto permite que los servicios de dispositivo 133 se comuniquen con los controladores 141, 142, 143 a través de una interconexión HUCL estandarizada. Los controladores 141, 142, 143 se pueden escribir en Java, código nativo o se pueden escribir en una mezcla de Java y código nativo. Cuando existe un controlador de red objetivo, un controlador de enlace HUCL se convierte al API de HUCL estándar de manera que otras redes también puede utilizar HUCL. La figura 4 muestra el mismo escenario que la figura 1, en una compuerta la cual implementa la capa de abstracción HUCL. Una aplicación 130 de control de lámpara eneiende/apaga dos lámparas 20, 30 en momentos predeterminados. Cada lámpara 20, 30 ahora está representada por un servicio de dispositivo 133 de lámpara genérica común el cual tiene una API 134 estandarizada. La aplicación 130 puede pasar instrucciones al dispositivo 133 de lámpara vía la API 134, de la misma manera sin importar si el dispositivo de equipo físico objetivo es la lámpara 20, conectada a una red EHS o una lámpara 30 conectada a una red ZigBee. Un controlador 144 HUCL/EHS enlaza la capa HUCL a un controlador para el protocolo EHS. De manera similar, un controlador 141 HUCL/ZigBee enlaza la capa HUCL a un controlador para el protocolo ZigBee. Las figuras 5A y 5B muestran las dos opciones principales para el conjunto 140 HUCL. En primer lugar, en la figura 5A, el conjunto 140 HUCL actúa como el controlador base y registra los servicios de dispositivos 133 HUCL individuales, cada uno representa un dispositivo 20 objetivo, con la infraestructura OSGi. La infraestructura OSGi proporciona un servicio de almacén, es decir, una lista solicitable de los servicios de dispositivo 133 registrados. Como una alternativa, el conjunto 140 HUCL puede escuchar por dispositivos nuevos descubiertos por el controlador 160 de base EHS y después los traduce a dispositivos HUCL. En este caso, el conjunto 140 HUCL es un controlador de refinado en vez de un controlador base. Toda la comunicación a través de la interconexión 160 entre el conjunto 140 HUCL y los servicios de dispositivo están en forma de llamadas API, tales como SendHUCLMsg ( ) y ReceiveHUCLMsg( ) . La aplicación 130 llama a las funciones en el servicio de dispositivo 133 HUCL, el cual se comunica directamente o de manera indirecta con el controlador 144 de enlace. El conjunto 140 HUCL realiza un seguimiento de todos los controladores 144 de enlace existentes. En la figura 5B, el conjunto 140 HUCL se registra a sí mismo como un servicio de dispositivo HUCL con la infraestructura OSGi. En este caso, el servicio de dispositivo HUCL es un dispositivo 146 compuesto HUCL. El dispositivo 146 compuesto puede representar una gran cantidad de servicios de dispositivo 147 y esto tiene las ventajas de que si existe una gran cantidad de dispositivos 20 objetivo en la red objetivo conforme se utilizan menos recursos de sistema. Como un ejemplo, si existen diez dispositivos 20 objetivo diferentes en el esquema que se muestra en la figura 5A, esto requeriría diez servicios de dispositivo que se registrarían con la infraestructura OSGi. En contraste, en el esquema de dispositivo compuesto que se muestra en la figura 5B, únicamente se registra un dispositivo 146 compuesto con la infraestructura OSGi. El concepto de un dispositivo compuesto HUCL se describe en la solicitud de patente internacional WO 2004/015927. Esto vuelve al sistema más escalable (ampliable) dado que puede trabajar con mayor facilidad con una gran cantidad de dispositivos 20 objetivo. Los componentes principales de la API 165 (la cual es equivalente a la API 160 en la figura 5A) entre el conjunto 140 HUCL y la aplicación 130 son las instrucciones SendHUCLMsgí ) y ReceiveHUCLMsg ( ) . Aunque se requiere cierta información adicional de direccionamiento dentro de estas llamadas para identificar cuál subdispositivo 147 del dispositivo 146 compuesto HUCL se identifica en cada mensaje, se reduce el volumen total del envío de mensajes. Además de algunas instrucciones inherentes, estas son las únicas instrucciones que se requieren para la API 165. El uso de un dispositivo 146 compuesto también puede permitir una interconexión más sencilla, ya sea entre la compuerta 110 y el servidor 50 de extremo trasero o a través de la interconexión Java-nativa (JNI) . De acuerdo con una característica del protocolo HUCL, como se describe en la solicitud de patente internacional WPI 2004/015956, una aplicación 130 puede solicitar el dispositivo 146 compuesto para una descripción sencilla y una descripción extendida del servicio de dispositivo. Las figuras 6A-8B muestran ejemplos de los flujos de mensaje que se producen dentro de la infraestructura de la figura 3 para tres acciones típicas. En cada ejemplo, los flujos de mensaje se muestran para las situaciones en donde se utiliza un servicio de dispositivo individual (como en la figura 5A) y en donde se utiliza un conjunto HUCL general y un dispositivo 146 compuesto (como en la figura 5B) . Por claridad, se utiliza el pseudocódigo en estos ejemplos y en ejemplos subsecuentes. Por sencillez, el ejemplo muestra una lámpara 20 como el dispositivo objetivo, pero se apreciará que el dispositivo objetivo puede ser más complejo. Las figuras 6A y 6B muestran los flujos de mensaje que se producen cuando se agrega al sistema un dispositivo 20 objetivo nuevo. La figura 6A muestra los flujos de mensaje en donde se utiliza un servicio de dispositivo individual. Cuando se agrega por primera vez al sistema un dispositivo nuevo (la lámpara 20) , esta es reconocida por el controlador 160 EHS y existe actividad de bus en la etapa 201.
El controlador 160 envía un mensaje 202 al conjunto 140 HUCL vía el controlador 144 HUCL/EHS de la forma: eventListener . indicate ( EHSDriver, NEW_DEVICE, <type>) En la etapa 203, un servicio de dispositivo 133 nuevo, que representa una lámpara, se genera con el nombre "myHUCLLamp2 " y la función: Framework. registerNewDevice (myHUCLLamp2 ) se llama en la infraestructura OSGi para registrar el servicio del dispositivo 133 nuevo. La función puede ser solicitada por el controlador 144, el conjunto 140 HUCL o por el servicio de dispositivo 133 mismo. Un seguidor de servicio dentro de la aplicación 130 se notifica del servicio de dispositivo nuevo "myHUCLLamp2 " en la etapa 204. La característica de seguidor de servicio de
OSGi se describe más completamente en la especificación de plataforma de servicio OSGi (Capítulo 19 de la versión 3). Con referencia nuevamente a la etapa 201, la manera exacta en la cual un dispositivo objetivo nuevo se une al sistema varía de acuerdo con el protocolo de red objetivo. En algunos protocolos, un dispositivo 20 objetivo nuevo provoca que un evento de "dispositivo nuevo" en el bus. En otros, los dispositivos objetivo nuevo se descubren por un mecanismo de llamada selectiva dentro de la red objetivo. Para XlO no hay indicación de un dispositivo nuevo, y debe agregarse manualmente al sistema por el usuario. De manera cada vez mayor, los requerimientos de seguridad necesitan que el usuario esté involucrado en la interacción. Para WiFi, una vez que un usuario introduce una clave de cifrado para un dispositivo objetivo nuevo, el controlador 160 debajo del nivel de la compuerta identifica el dispositivo nuevo y puede solicitar una descripción. Un controlador 143 de enlace HUCL/UPnP reconocerá esto y la identificación del dispositivo nuevo continúa guardada. La figura 6B muestra los flujos de mensajes cuando se utiliza el conjunto HUCL general y el dispositivo 146 compuesto. Cuando el dispositivo nuevo (lámpara 20) se agrega por primera vez al sistema, esto es reconocido por el controlador 160 EHS y existe actividad de bus en la etapa 211. Como en lo anterior, el controlador 160 envía un mensaje 212 al conjunto 140 HUCL vía el controlador 144 HUCL/EHS de la forma : eventListener . indicate ( EHSDriver, NEW_DEVICE, <type>) No obstante, el dispositivo nuevo es representado como un subdispositivo dentro del dispositivo 146 compuesto HUCL. La información almacenada para el subdispositivo es un equivalente HUCL de la información que está almacenada para un dispositivo de servicio, como se ha descrito previamente e incluye una lista de tipos de dispositivo en la jerarquía por encima del dispositivo actual. Todas las aplicaciones 130 las cuales se suscriben como escuchas del conjunto HUCL se les envía un mensaje 213: HUCLEvent ( "<deviceDescriptionChanged>" ) La aplicación 130 se suscribe como una escucha del conjunto 140 HUCL. El caso de escucha dentro de la aplicación 130 es notificado, en la etapa 214, de la actualización al conjunto 140 HUCL y describe el subdispositivo recién agregado. El subdispositivo recién agregado no se registra de manera explícita con la estructura OSGi. Las figuras 7A y 7B muestran los flujos de mensaje que se producen cuando el dispositivo existente se retira del sistema. La figura 7A muestra los flujos de mensaje cuando se utiliza un servicio de dispositivo 133 individual. Cuando el dispositivo existente (lámpara 20) se retira del sistema, esto es reconocido por el controlador 160 EHS y existe actividad de bus en la etapa 221. El controlador 160 envía un mensaje 222 al conjunto 140 HUCL vía el controlador 144 HUCL/EHS de la forma : eventListener . indicate ( EHSDriver, GONE_DEVICE, ID) En la etapa 223, se detiene el servicio de dispositivo "myHUCLLamp2" . El seguidor de servicio de la aplicación 130 es notificado de la separación de servicio de dispositivo "myHUCLLamp2" en la etapa 224.
La figura 7B muestra ahora los flujos de mensaje cuando se utiliza el conjunto HUCL general. Cuando se retira del sistema el dispositivo existente (lámpara 20) , esto es reconocido por el controlador 160 EHS y existe actividad de bus en la etapa 231. Nuevamente, el controlador 160 envía un mensaje 232 al conjunto 140 HUCL vía el controlador 144 HUCL/EHS de la forma: eventListener . indicate ( EHSDriver, GONE_DEVICE, ID) El subdispositivo que representa la lámpara es retirado del dispositivo 146 compuesto HUCL en la etapa 233. Se envía un mensaje de la forma: HUCLEvent ( " <deviceDescriptionChanged> " ) a todos los escuchas suscritos, notificándoles de la separación. En la etapa 234, el escucha de eventos de la aplicación 130 es notificado de la actualización y descubre que se ha retirado el subdispositivo. Nuevamente, la infraestructura OSGi no es notificada explícitamente de dicha separación. Se prefiere que el usuario confirme la separación de un dispositivo, por ejemplo al oprimir un icono de confirmación en una interconexión de usuario. En el tercer ejemplo, las figuras 8A y 8B muestran flujos de mensajes los cuales se producen cuando la aplicación
130 busca controlar un dispositivo que está registrado de antemano en el sistema. En este ejemplo, la aplicación 130 envía un mensaje de control para encender la lámpara 20 y la lámpara 20 se registra con el sistema con el nombre "myHUCLLamp" . La figura 8A muestra los flujos de mensaje cuando se utiliza un servicio de dispositivo 133 individual. En primer lugar, la aplicación 130 envía un mensaje, en la etapa 241, al servicio del dispositivo 133 de lámpara HUCL de la forma : myHUCCLamp . on ( ) En la etapa 242, el servicio de dispositivo 133 de lámpara envía un mensaje HUCL de la forma: sendHUCLMsg(" ... <paraml>255</paraml> ... " ) Esto se traduce por el controlador 144 HUCL/EHS en un mensaje, el cual es enviado 243 al controlador 160, de la forma: EHSDev5. sendEHSMsg ( TURN-ON) La traducción simplemente puede ser un reformateo trivial del mensaje, o puede involucrar instrucciones de traducción mediante el uso de una tabla de búsqueda. Finalmente, el controlador 160 emite un mensaje 244 en el formato de la red objetivo a la lámpara 20 la cual provoca que la lámpara 20 se encienda. La figura 8B muestra los flujos de mensaje cuando se utiliza el conjunto 140 HUCL general. En primer lugar, la aplicación 130 envía un mensaje en la etapa 251 al conjunto 140 HUCL de la forma: sendHUCLMsgAddressedTo (DevID, "... <paraml>255</paraml> ... " ) Esto es suministrado al subdispositivo 147 particular del servicio 146 de dispositivo compuesto en donde "DevID" es un identificador el cual identifica al subdispositivo 147 del dispositivo 146 compuesto HUCL que representa a la lámpara 20. El conjunto 140 HUCL emite un mensaje de control el cual es traducido por el controlador 144 HUCL/EHS en un mensaje EHS, en la etapa 252 de la forma: EHSDev5. sendEHSMsg (TURN_ON) Este mensaje es suministrado al controlador 160 EHS. Finalmente, el controlador 160 emite un mensaje 253 en el formato de la red objetivo a la lámpara 20 lo que provoca que la lámpara 20 se encienda. Con referencia nuevamente a la figura 5A, los mensajes que pasan entre la aplicación 130 y los objetos de dispositivo HUCL, a través de API 134, están estandarizados tales como LampOn ( ) , LampOff ( ) , TVOn ( ) , TVOff ( ) , SetChannel ( int num), SetVolume (int level). Los desarroladores de aplicaciones 130 se les proporcionará con un conjunto estándar de estos . Como- se describe en lo anterior, HUCL tiene una distribución jerárquica de los servicios de dispositivo. La figura 9A muestra una jerarquía de ejemplo de los servicios 300 de dispositivo, con un dispositivo 301 HUCL general en la parte superior. La función "getSubDevices ( ) , regresa el servicio de dispositivo a la siguiente capa de subdispositivos, si está presente alguno. El movimiento hacia abajo en la jerarquía, los servicios de dispositivo tienen un nivel aumentado de detalle/funcionalidad. Por lo tanto, el servicio 302 de dispositivo representa un dispositivo objetivo el cual tiene la capacidad para encenderse/apagarse. El hecho de moverse hacia abajo del lado izquierdo de la jerarquía, el servicio 303 de dispositivo defina una lámpara básica, la cual hereda la característica de la clase por encima del mismo, es decir, que también se puede encender/apagar. El servicio 304 de dispositivo define una lámpara graduable, es decir, una lámpara con la función de poder ajustar a un valor de brillantez particular dentro de una gama de valores posibles. El servicio 304 de dispositivo también hereda las características de 302 y 303 por encima del mismo, es decir, es una lámpara y puede encenderse/apagarse. El hecho de moverse hacia abajo al lado derecho de la jerarquía, el servicio 305 de dispositivo define un timbre de puerta el cual hereda las características del dispositivo 302 de encendido/apagado de HUCL. En este ejemplo, si una aplicación
(por ejemplo la aplicación 130) no sabe como hablarle al dispositivo del tipo "HUCLDimmableLamp" , aún puede utilizar la definición "HUCLBasicLamp" o incluso la definición básica "HUCLDevice" con la certidumbre de que el servicio de dispositivo comprenderá dicha funcionalidad. Efectivamente, HUCL permite que una aplicación "suba en el árbol de jerarquía", y si una aplicación encuentra que no reconoce un tipo de dispositivo (por ejemplo una lámpara graduable) , entonces verifica los otros tipos de dispositivos incluidos en una lista de tipo de dispositivo que se proporcionan como parte del servicio de dispositivo 133. De manera similar, una aplicación la cual tiene la capacidad de encender/apagar algo puede activar una lámpara, un timbre de puerta o cualquier otro tipo de dispositivo el cual sea capaz de ser encendido/apagado dado que los servicios de dispositivo que representan a todos los dispositivos objetivo seguirán la jerarquía. Un dispositivo objetivo está representado en cada nivel por encima de su representación "más baja", más precisa. Este enfoque permite que los dispositivos sean manipulados en el máximo grado posible, incluso en situaciones en donde el desarrollador no sabe los detalles completos de un dispositivo particular . La figura 9B muestra un ejemplo adicional de una jerarquía. Una plataforma - en este caso, un asistente 320 digital personal (PDA, por sus siglas en inglés) - soporta la infraestructura OSGi descrita antes y una aplicación de control. La aplicación que corre en la PDA 320 es incapaz de reconocer las instrucciones específicas utilizadas por la lámpara 304 graduable o la lámpara 303, pero reconoce el código del tipo de dispositivo para un dispositivo de encendido/apagado (es decir, un código que representa un tipo de dispositivo el cual puede ser encendido/apagado, y por lo tanto es capaz de controlar la lámpara en un grado completo, aunque no pueda controlar la función graduable de la lámpara 304. De manera similar, la aplicación que corre en la PDA 320 únicamente soporta servicios de dispositivo a nivel del "termostato" 308 y carece de la capacidad para controlar características de un termostato médico o industrial. La aplicación que corre en la PDA 320 no puede utilizar las características avanzadas de un termostato 309 médico o un termostato 310 industrial, pero aún puede encender y apagar cada uno de los termostatos 357, 358 y obtener lecturas básicas de temperatura. Esto permite a los fabricantes de los dispositivos objetivo proporcionar productos los cuales interoperen en cierto nivel pero también agregar características únicas a sus productos lo que los diferenciará de otros productos. En el modelo de dispositivo compuesto descrito previamente con referencia a la figura 5B, la información almacenada en cada subdispositivo 147 dentro del dispositivo 146 compuesto sigue la misma estructura jerárquica. Como se describe en lo anterior, muchos lenguajes de programación ofrecen funcionalidad relacionada. Por ejemplo, en Java"11, cada objeto es una instancia de una "clase" y las clases pueden extenderse a otras clases, formando una jerarquía de clase. La jerarquía que se muestra en las figuras 9A y 9B se puede implementar utilizando esta jerarquía de clase de un conjunto de objetos en Java u otro lenguaje de programación. De manera alternativa, la jerarquía se puede implementar de manera tal que no utilice la jerarquía de clase "interconstruida" del lenguaje de programación. Un método de operar una jerarquía de dispositivo sin utilizar las jerarquías de clase del lenguaje de programación en el cual se implementa, es representar dispositivos por instancias de una clase fija única, tal vez denominada HUCLDevice, esta tiene únicamente métodos no específicos de dispositivo, genéricos tales como "sendMessage (commandText) " , "setVariable (variableID, variableValue) " o " invokeCommand (commandID, co mandParameterl , ...)". En este caso, la jerarquía está documentada en papel y se implementa en los componentes de programación o de programa, ya sea por codificación de la respuesta a cada invocación individual (es decir, código no orientado a objeto) o por un diseño orientado a objeto de las API no expuestas (es decir, utilizando un código orientado a objeto pero que este no esté representado en API. En cada caso, uno puede esperar dispositivos extendidos que reaccionen correctamente a la totalidad de los mensajes, variables y/o invocaciones de instrucciones comprendidas por los dispositivos más sencillos y también que comprenda e implemente respuestas para algunas instrucciones y funcionalidad adicionales. En esta segunda situación, aún existe la jerarquía de dispositivo (de manera muy conceptual) y es útil, pero no está implementada directamente mediante la utilización de la construcción de los lenguajes de programación en una jerarquía de clase. Como un ejemplo, considérese una lámpara básica que soporta las funciones de 0n() y Off O, y una ComplexLamp (lámpara compleja) que también soporta la función Dim(). En un código no orientado a objeto, podríamos implementar esto utilizando una declaración de conmutación. Sigue un ejemplo de pseudocódigo para el programa de HUCLdevice para una lámpara básica: #include <lamp.h> // contiene #defines para
CMD_LAMP*, y declara las funciones On( ) y Off( ). invokeCommand (commandID, commandParamList [ ] ) { switc (commandID) { case CMD_LAMP_ON: On ( ) ; interrumpir; case CMD_LAMP_OFF : Off ();
interrumpir; implícito: UnknownCommand ( coomandID, commandParamList [ ] ) ; } } El pseudocódigo para el programa de HUCL dispositivo para una lámpara compleja es: #incluye <lamp.h> // contiene #defines para CMD_LAMP_*, y declara las funciones On( ) y Off ( ). #incluye <complesLamp.h> //contiene #defines para CMD_COMPLEX_LAMP_* , y declara la función Dim( ) . invokeCommand (commandID, commandParamList [ ] ) { switch ( commandlD) { case CMD_LAMP_ON: On ( ) ; interrupción; case CMD_LAMP_OFF : Off( ); interrupción; case CMD_COMPLEX_LAMP_DIM : Dim ( commandParamList [ 0 ] ) ;
interrupción; implícito : UnknownCommand(commandID, commandParamList [ ] ) ; } } Aquí, el código para "ComplexLamp" implementa la totalidad de la funcionalidad de "lamp", y también la instrucción adicional como se define en la especificación ComplexLamp. Ambos programas también implementarán las funciones On( ), Off ( ) y UnknownCommand (...) , y la
ComplexLamp adicionalmente implementará la función Dim
( dimLevel ) . Este ejemplo implementa una jerarquía de dispositivo sin utilizar la jerarquía de clase del lenguaje de programación. También es posible implementar la jerarquía de una segunda manera, pero con ciertas características de programación orientada a objeto. El pseudocódigo ejemplo para el programa HUCLdevice para una lámpara compleja es: #include <lamp.h> // contiene #defines para CMD_LAMP_*, y declara la clase Lamp. #include <complexLamp.h> // que contiene #defines para CMD_COMPLEX_LAMP_* , y declara la clase ComplexLamp, la cual extiende la clase de lámpara. invokeCommand ( commandID, commandParamList [] ) { ComplexLamp myComplexLamp = environment . getTargetDevice ( ) ; switch( commandID ) { case CMD_LAMP_ON: myComplexLamp.On( ); interrupción; case CMD_LAMP_OFF : myComplexLamp . Off ( ) ; interrupción; case CMD_COMPLEX_LAMP_DIM: myComplexLamp . Dim ( commandParamList [0] ) ; interrupción; implícito: UnknownCommand ( commandID, commandParamList [ ] ) ; } } Aquí, la API presentada a las aplicaciones es la misma que el ejemplo previo, y aún no utiliza directamente la jerarquía de clase del lenguaje de programación. No obstante, en este ejemplo, se han utilizado las clases ComplexLamp y Lamp dentro del pseudocódigo para una lámpara compleja para volver más claro el programa, o más susceptible de ser mantenido.
Los dispositivos objetivos son controlados de una manera que oculta cualquier código HUCL de bajo nivel del desarrollador . En el modelo de la figura 5A, las clases de servicio de dispositivo mismas toman la responsabilidad de traducir las llamadas de método de alto nivel (por ejemplo LampOn(), SetChannel ( int num)) en un código HUCL de bajo nivel, mientras que en la figura 5B, se pueden utilizar funciones 162 de envoltura. Las funciones de envoltura realizan la traducción de las instrucciones Java de alto nivel, amigables para el desarrollador, en códigos HUCL de bajo nivel. En las figuras 8A y 8B, se muestra como una aplicación 130 puede emitir un mensaje de control para controlar un dispositivo 20 objetivo. Esto puede surgir cuando se requiere una aplicación para encender/apagar un dispositivo objetivo en momentos conocidos para la aplicación 130. No obstante, existen situaciones en donde es deseable que una aplicación responda a un evento particular el cual se produce en un dispositivo objetivo. Como un ejemplo, cuando un dispositivo objetivo, en forma de un sensor de movimiento detecta movimiento dentro de una habitación, es deseable informar a una aplicación de seguridad que está funcionando en la compuerta 110, de manera que la aplicación pueda alertar al usuario. La infraestructura OSGi existente no proporciona un mecanismo para soportar este tipo de notificación.
La figura 10 muestra un mecanismo sencillo para alertar aplicaciones de eventos. En el nivel más bajo, el controlador 160 acumula un dispositivo 20 objetivo en una base periódica, por ejemplo cada par de segundos. Si existe un cambio en el estado del dispositivo 20 objetivo, el controlador 160 notifica al servicio de dispositivo 133. Es posible que la API del controlador detecte cualquier cambio en el estado. Esto se puede obtener por medio de una llamada de método desde el controlador 160 al conjunto 140 HUCL o por medio del conjunto HUCL que realiza una llamada selectiva al controlador 160 para observar su estado. El controlador 140 HUCL conforma la información obtenida del controlador 160 en un mensaje de evento HUCL. Estos eventos después se hacen pasar al servicio de dispositivo 133, el cual los formula en objetos de evento Java. Las aplicaciones 130 se suscriben a estos conjuntos de dispositivo que controlan o en los que están interesados en ser informados de su estado. Cada servicio de dispositivo 133 mantiene una lista 180 de suscripción de escucha, escuchando a aquellas aplicaciones que tienen registrado un interés (agregando cada una a un java. util .Vector conforme se registran, por ejemplo). Cada aplicación 130 incluye un escucha 182 de evento para recibir notificaciones de eventos. El mensaje, enviado por el controlador 160, indica que el estado nuevo de la lámpara se recibe por el servicio 133 del dispositivo. El servicio 133 de dispositivo decide 183 si ha ocurrido un evento reportable y, de ser así, notifica a todas las aplicaciones interesadas que estén registradas 180. Un ejemplo de uso de este mecanismo ahora se describirá para un dispositivo objetivo el cual es una lámpara graduable. De acuerdo con la jerarquía mostrada en la figura 9A, el dispositivo 304 DimmableLamp extiende la funcionalidad de un dispositivo 303 Lamp básico HUCL y un OnOffDevice 302. Por lo tanto se prefiere que la jerarquía de evento refleje esta jerarquía de objeto. Esto significa que las aplicaciones que se suscriben al servicio del dispositivo DimmableLamp también recibe notificaciones de cualquier evento de encendído/apagado. Para un dispositivo objeto más complejo, el cual está representado por un servicio de dispositivo que hereda los eventos de muchas clases de nivel superior, una aplicación puede recibir notificaciones de todos los eventos heredados por dicho servicio de dispositivo. Al igual que con la estructura de servicio de dispositivo jerárquica, esto proporciona una herramienta sencilla aunque poderosa para desarrolladores de aplicación. El apéndice incluye detalles adicionales del código para implementar la jerarquía de evento en este ejemplo. Como se describe en lo anterior, la entidad administradora de HUCL es responsable del registro de los controladores y los servicios de dispositivo. La infraestructura OSGi proporciona un mecanismo para notificar cualquier conjunto interesado de la llegada de cualquier servicio de dispositivo nuevo en el sistema. Al proporcionar un conjunto de administración HUCL en el sistema, este puede escuchar por la llegada de cualquier servicio de dispositivo nuevo y puede agregarlo a una colección de servicios de dispositivo si representa dispositivo HUCL. Este conjunto después proporciona acceso a esta colección con cualquier otro conjunto interesado en el uso de estos servicios de dispositivo. HUCLDevice [] devices = huclBundle.getDevices ( ) ; para (int a=0; a<deviees .length; a++) { si (devices [a] instanceof HUCLLamp) { HUCLLamp lamp = (HUCLLamp) devices [a] ; lamp . turnOn ( ) ; } else if (devices [a] instanceof HUCLDoorbell) { HUCLDoorbell bell = (HUCLDoorbell) devices [a]; bell . actívate ( ) ; } } El resumen de página de código anterior muestra conjuntos interesados en utilizar estos servicios de dispositivo los cuales después pueden obtener una lista de la totalidad de servicios de dispositivo del conjunto de administrador HUCL. Los servicios de dispositivo pueden ser solicitados para las interconexiones de dispositivo HUCL que implementan y pueden ser utilizados en consecuencia. Este código es una ilustración de cómo un desarrollador utiliza polimorfismo para descubrir si está interesado en un dispositivo. En este ejemplo, el desarrollador está interesado en HUCLLamp y HUCLDoorbell. El operador "instanceof" se utiliza para ver si el HUCLDevice actual es un "instancia de" un dispositivo de interés. Si es así, el HUCLDevice se une a la clase del dispositivo descubierto. El objeto incluido ahora se puede utilizar para controlar el dispositivo. La compuerta descrita en lo anterior se puede implementar en una diversidad de plataformas de procesamiento, tales como una PC de propósito general o una unidad de procesamiento dedicada. La figura 11 muestra los componentes principales de la plataforma de procesamiento. Una unidad 401 de procesamiento central ejecuta software, como se ha descrito previamente, para soportar la infraestructura OSGi, las aplicaciones y la capa de absorción HUCL. Típicamente, la unidad 401 de procesamiento central tiene un sistema operativo nativo (por ejemplo basado en Linux) el cual soporta una máquina virtual Java (JVM) . La JVM alberga la infraestructura OSGi y las aplicaciones. La memoria 402 no volátil y la memoria 403 volátil, tal como un disco duro, almacenan el software de abertura y las bibliotecas de servicio de dispositivo y se utilizan por la unidad 401 de procesamiento.
Un modem 406, tal como un ADSL de banda ancha o un modem de cable, se conecta a una línea 407 de comunicación la cual conecta la compuerta a un servidor remoto (50, figura 2) sobre el cual también pueden ser soportadas las aplicaciones. El modem 406 de banda ancha puede ser externo en la compuerta 110. Los mensajes de control hacia/desde los dispositivos controlados son transportados por conexiones 415 de red local, las cuales utilizan una combinación de tecnologías cableadas 412 e inalámbricas 411. Se pueden proporcionar los elementos físicos apropiados para soportar la red local particular tal como: una tarjeta de red de área local; un modem inalámbrico, infrarrojo o de línea de potencia (XlO) . Se pueden proporcionar entradas de usuario directamente a la compuerta por dispositivos 410 de entrada tales como un teclado, un cableado de botones, un ratón o una tableta. De manera alternativa, las entradas de usuario se pueden recibir desde una unidad de control remoto la cual está integrada en red localmente con la compuerta 110 o a partir del enlace 407 de comunicación. Como un ejemplo, si un usuario está lejos de casa y desea enviar instrucciones a la compuerta para controlar aparatos eléctricos dentro de su casa, el usuario interactuará con una terminal remota y enviará instrucciones, vía la línea 407, a la compuerta 110. Se puede presentar directamente una salida a un usuario vía el controlador 408 de presentación y la pantalla 409, a una unidad de control remoto local o a una terminal remota vía un enlace 407. Un bus 405 o una combinación de buses de tipos diferentes conectan las unidades anteriores . Se pueden ejecutar una amplia variedad de aplicaciones 130 en la compuerta 110 o sobre un servidor 50 remoto. Los ejemplos de estas incluyen: un control casero tal como la simulación de ocupación de un edificio encendiendo y apagando lámparas en momentos predeterminados , control de calentamiento y ventilación, programación de una grabadora de video; control de dispositivos electrónicos de entretenimiento y del consumidor; monitoreo remoto de la seguridad de un edificio o la salud de un ocupante de un edificio; reporte/diagnósticos de fallas remotas. Debe hacerse notar que las modalidades mencionadas antes ilustran en vez de limitar la invención y que los expertos en la técnica serán capaces de diseñar muchas modalidades alternativas sin apartarse del alcance de las reivindicaciones anexas. En las reivindicaciones, cualquier signo de referencia colocado entre paréntesis no debe considerarse como limitante de la reivindicación. Las palabras "que comprende" y "que incluye" no excluyen la presencia de otros elementos o etapas a las que se incluyen en las reivindicaciones . En la descripción anterior con referencia a las figuras, se describe un sistema de integración en red local el cual comprende una plataforma (110) de procesamiento y dispositivos (151-153), objetivo tales como aparatos eléctricos caseros. La plataforma soporta una infraestructura de compuerta de servicios abierta, tal como la iniciativa de compuerta de servicios abierta (OSGi) y ejecuta aplicaciones
(130) para controlar los dispositivos (151-153) objetivo. Cada uno de los dispositivos objetivo están representados por una entidad (133) la cual puede ser manipulada por la aplicación
(130) a través de una interconexión de programación de aplicación (API, 134) . Las entidades siguen una estructura jerárquica común de tipos de dispositivo, en el cual una entidad que representa a un dispositivo de tipo inferior en la jerarquía hereda las propiedades de los tipos de dispositivo superiores en la jerarquía. Esto presenta una API consistente a aplicaciones. Las entidades pueden formar parte de una capa de abstracción la cual utiliza un lenguaje común, tal como el lenguaje de control uniforme casero (HUCL) . Cada entidad puede ser registrada con la infraestructura como un servicio de dispositivo o como un servicio de dispositivo único el cual puede ser registrado con la infraestructura la cual representa entidades múltiples. APÉNDICE Material explicativo adicional para el caso de reportar una característica. La clase de evento base puede ser: la clase pública OnOffDeviceEvent extiende java .util. EventObject{ /* Utilizado por getEventTrigger ( ) , indica un evento Device ON*/ estático int DEVICE_ON; /* Utilizado por getEventTrigger () , indica un evento Device OFF*/ estático int DEVICE_OFF; /* Regresa una de las constantes de evento, explicando qué activó este evento */ público int getEventTrigger () ; /* Crea un OnOffDeviceEvent nuevo */ público OnOffDeviceEvent (int trigger); } Un DimmableLampEvent, el cual notificará a las aplicaciones suscritas de eventos en el dispositivo DimmableLamp se puede especificar por una clase: clase pública DimmableLampEvent se extiende a OnOffDeviceEvent { estático int BRIGHTNESS_CHANGED; /* Sobrepasado a partir de OnOffDeviceEvent */ público int getEventTrigger () ; público DimmableLampEvent (int trigger); } Se hace constar que con relación a esta fecha, el mejor método conocido por la 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.