MXPA03003182A - Metodo para generar una interconeccion de usuario en un dispositivo havi para el control de un dispositivo que no es havi. - Google Patents

Abstract

La invencion se relaciona con tecnologia de interconexion de redes caseras, especificamente una red casera HAVi y una red basada en IP tal como una red UPnP. Cuando se combinan ambas redes por medio de la compuerta (10), se proporcionara un servicio. para controlar un dispositivo UPnP desde un dispositivo HAVi. Surge un problema del hecho de que para cada dispositivo UPnP, no existe un modulo de control de dispositivo correspondiente en la tecnologia de red HAVi de manera que algunos de los dispositivos UPnP no pueden ser controlados por un modulo de control de dispositivos (DCM). correspondiente. La invencion resuelve este problema por medio de dos elementos de software basicos, especificamente un modulo de control de funcion (FCM) especializado que va a ser implementado en la compuerta (10) y un programa JAVA (HAVLET) que corre en el controlador (31) HAVi. La red UPnP es una red basada en IP. Por lo tanto, cada dispositivo UPnP es representado por lo que se denomina un documento XML. Tal documento XML incluye varias de las descripciones XML, las cuales son nada menos que descripciones de funcion para los elementos controlables. Un modulo de control de funcion (FCM) de acuerdo con la invencion incluye un medio para solicitar las descripciones de funcion del dispositivo UPnP y para enviar estas descripciones de funcion al controlador (31) HAVi. El modulo de control de funcion (FCM), puede incluir un medio para traducir las descripciones de funcion recuperadas antes de enviarlas al controlador (31) HAVi. En el controlador (31) HAVi, se corre el programa JAVA (HAVLET) y este programa toma las descripciones de funcion recibidas desde la compuerta (10) y genera una interconexion de usuario con esta informacion. El programa JAVA puede ser cargado en el controlador 31 HAVi durante la fase de configuracion de la red HAVi.

Description

- - MÉTODO PARA GENERAR UNA INTERCONEXIÓN DE USUARIO EN UN DISPOSITIVO HAVi PARA EL CONTROL DE UN DISPOSITIVO QUE NO ES HAVi DESCRIPCIÓN DE LA INVENCIÓN La invención se relaciona con un método para generar una interconexión de usuario en un dispositivo HAVi para el control de un dispositivo que no es HAVi. En particular, esta invención se aplica al campo de redes de comunicación domésticas. La invención también se relaciona con una compuerta para el uso en el método para generar una interconexión de usuario así como dos tipos de productos de programa de computador .

ANTECEDENTES DE LA TÉCNICA Hace algunos años, las instalaciones de equipo casero de audio/video típicas estaban caracterizadas por una mezcla de dispositivos CE de diferentes tipos, por ejemplo un receptor de radio, un reproductor de CD, un par de altavoces, un equipo de televisión, una grabadora de videocasetes , una grabadora de cintas, un reproductor de DVD, un receptor de satélite y similares. Para la interacción de los dispositivos debía realizarse una conexión punto a punto de salida de - - entradas/salidas analógicas/digitales. Para este propósito estaban disponibles varias clases de cables diferentes como los cables Scart, cables Cinch, cables coaxiales, fibra óptica, etc . Mientras tanto, ha habido fuertes actividades en el campo de la electrónica del consumidor para evitar este tipo de conexiones punto a punto. Ya existen muchas de las normas para redes caseras que se pueden utilizar para conectar todos los componentes diferentes entre sí por medio de un solo tipo de cable de red. En el campo de electrónica del consumidor, primero que nada está la norma de enlace común IEEE1394 que debe mencionarse aquí. El sistema de enlace común IEEE1394 proporciona una comunicación de alta velocidad de datos entre los dispositivos CE. La versión de cable soporta velocidades de datos de 100, 200 y 400 Mbit/s. Esto es suficiente para transportar datos asincronos para controlar una estación de red así como corrientes de audio y video isócronas en paralelo. Se ha soportado en modos de transferencia de datos isócronos y asincronos. Sin embargo, la norma IEEE1394 especifica únicamente las capas inferiores del modelo de referencia ISO/OSI, específicamente la capa física, la capa de enlace de datos y la capa de transfección . Por lo tanto, las capas superiores específicamente la capa de transporte, la capa de sesión, la capa de presentación y la capa de aplicación se dejan abiertas para definición registrada.

Se ha especificado un consorcio de compañías de equipos electrónicos para el consumidor que trabajan sobre una norma para equipo electrónico de audio/video y la industria multimedia en donde se especifican capas de comunicación superiores. Esta norma se denomina como la norma HAVi , en donde HAVi son las siglas para interoperabilidad de audio/video casero. Esta norma se ha definido principalmente en los sistemas medios de interoperabilidad que aseguran que los productos de vendedores diferentes pueden operar de manera relacionada, es decir cooperar para realizar tareas de aplicación. La capa de aplicación permanece completamente abierta a soluciones registradas. Otro consorcio de compañías, en particular las compañías de computadoras que incluyen a Microsoft, iniciaron otra iniciativa para establecer un apilado de software de control de red basado en protocolos de internet (IP) . Este sistema de red se denomina una red UPnP (conexión y reproducción universal) . Este sistema se abrirá a toda clase de componentes electrónicos que se puedan integrar en una red, en particular computadoras personales, pero también dispositivos electrónicos en el ámbito casero como refrigeradores, hornos de microondas, control de calentamiento, control de aire acondicionado, sistemas de seguridad, máquinas de lavado y similares. El sistema de red UPnP soporta el control de todos estos dispositivos vía la internet, por lo tanto, incluso si - - alguien está de viaje, puede administrar vigilar y controlar sus dispositivos en casa. Aunque algunas veces se han visto a HAVi y UPnP como competidores, en algunas maneras atienden a mercados un poco diferentes y con objetivos algo diferentes. Por lo tanto, se anticipa que existen de manera paralela un escenario para que existan ambas redes en el ámbito casero y que es posible la interconexión entre las dos para intercambio de datos e interacción entre los componentes de la red UPnP y los componentes de la red HAVi. Sin embargo, esto implica la creación de la tecnología de conexión entre las redes HAVi y UPnP . Cuando se habla de una conexión entre las redes UPnP y HAVi, esto significa técnicamente que los paquetes de datos se transfieren al otro lado en una capa de enlace de datos. Cuando se transfiere un paquete de datos a una capa superior del modelo de referencia ISO/OSI, el dispositivo de conexión se le denomina una compuerta. Dado que los paquetes de datos se transfieren de una red HAVi a UPnP o viceversa en una capa superior, el dispositivo de interconexión se denominará en lo siguiente como compuerta. Sin embargo, de ninguna manera esto es limitante . Con la compuerta entre ambas redes, es posible controlar un dispositivo HAVi en la red HAVi desde un dispositivo UPnP en la red UPnP. Además, se podrá soportar el - - control del dispositivo UPnP de un dispositivo HAVi . Para el control de un dispositivo HAVi desde un dispositivo UPnP se requiere que se represente al dispositivo HAVi como un dispositivo UPnP. Aquí, existen problemas específicos que necesitan resolverse los cuales no son parte de esta invención. La invención se relaciona con el problema de control del dispositivo UPnP desde un dispositivo HAVi. Para comprender la invención, resulta útil explicar primero la arquitectura del sistema HAVi . De acuerdo con la arquitectura HA i, un dispositivo CE en la red se controla mediante representaciones abstractas del dispositivo CE. La arquitectura permite que un módulo (por ejemplo un dispositivo de representación, controlador, étc.) envíe instrucciones o información de control a otro módulo en la red casera. Un dispositivo de acuerdo con HAVi contiene datos (por encima de la representación abstracta a la que se hace referencia como el módulo de control del dispositivo DCM) en relación a su interconexión de usuario y sus capacidades de control. Estos datos incluyen, por ejemplo, códigos de octetos HAVi (código Java) que se pueden cargar y ejecutar por otros dispositivos en la red. Un dispositivo que cumple con HAVi tiene, como un mínimo, suficiente funcionalidad para comunicarse con otros dispositivos en la red HAVi. Durante la interacción, los dispositivos pueden intercambiar datos de control y datos de aplicación de una manera entre iguales. La especificación HAVi diferencia entre controladores y dispositivos controlados. Un controlador es un dispositivo que actúa como un huésped para un dispositivo controlado. Un controlador alberga la representación abstracta de los dispositivos controlados. La especificación HAVi define dispositivos CE de acuerdo con HAVi en las siguientes categorías; dispositivos completamente AV (FAV) , dispositivos AV intermedios (IAV) y dispositivos AV de base (BAV) . Un FAV contiene un conjunto completo de componentes de software de la arquitectura de software HAVi. Una FAV está caracterizado porque tiene un ambiente de tiempo de funcionamiento para un código de octetos HAVi . Esto significa que tiene una máquina virtual Java. Esto permite a un dispositivo FAV descargar códigos de octetos Java de otros dispositivos, por ejemplo, para proporcionar capacidad mejorada para su control. Se puede producir un FAV, por ejemplo, por una instalación de caja superior de acuerdo con HAVi, un receptor de TV digital de acuerdo con HAVi o una computadora personal casera. Por ejemplo, un receptor de TV inteligente puede tener un controlador HAVi u otros dispositivos conectados a la red. El receptor obtiene el código de octetos descargados de otro dispositivo en la red. Un icono que representa a este dispositivo puede volverse visible en la pantalla de TV y el usuario puede interactuar con el icono y provocar que los - - elementos del programa de control actúen en el dispositivo representado, de una manera especificada previamente. Un IAV no proporciona un ambiente de tiempo de funcionamiento para el código de octetos HAVi , pero puede proporcionar un soporte nativo para el control de dispositivos específicos en la red casera. Un IAV comprende elementos de software incrustados que proporcionan una interconexión para controlar funciones generales de los dispositivos específicos. Estos elementos de software no necesitan ser códigos de octetos HAVi y se pueden implementar como aplicaciones nativas en el IAV que utilice interconexiones nativas para tener acceso a otros dispositivos. Un BAV puede proporcionar un código de octetos HAVi susceptible de ser cargado, . pero no alberga ninguno de los elementos de software de la arquitectura HAVi. Un BAV es controlable a través de un FAV por medio del código de octetos cargado anterior. Un BAV es controlable a través de un IAV por medio de su DCM/FCM que se ha cargado por un FAV. Por otra parte, la comunicación entre un FAV o un IAV, y por otra parte con un BAV, requiere que se inicie un código de octetos HAVi por un FAV. La especificación HAVi incluye muchos de los elementos de software principales que se incluyen a continuación. Para una explicación más detallada de estos elementos se hace referencia a la especificación de HAVi. Una versión existente de la especificación HAVi es de VI .1 , publicada el 15 de mayo del 2001 y disponible de HAVi , INC., 2694 Bishop Drive, Suite 275 San Ramón, CA 94683, E.U.A. 1. El administrador de medio de comunicaciones (CMM) 1394 actúa como una interconexión entre los otros elementos de software y el enlace común IEEE1394. 2. Un administrador de sucesos (E ) informa de los diversos elementos de software de sucesos en la red tales como los cambios en la configuración de la red que se produzcan cuando se agregan o se retiran dispositivos (aparatos) de la red. 3. Un registro que mantiene información acerca de los dispositivos conectados a la red y las funciones que ofrecen. Las aplicaciones pueden obtener esta información del registro. 4. Un sistema de mensajes (MS) - que sirve como un API (interfaae de programación de aplicación) que facilita la comunicación entre los elementos de software y los diversos dispositivos en la red. El sistema de mensajes proporciona los elementos de software HAVi con instalaciones de comunicación. Es independiente de la red y de las capas de transporte. El sistema de mensajes está a cargo de asignar identificadores para las representaciones abstractas en FAV o IAV. Estos identificadores se utilizan primero por las representaciones abstractas para registrar el FAV o IAV. Después se utilizan por las representaciones abstractas para identificar cada una dentro de la red casera. Cuando una primera representación abstracta busca enviar un mensaje a otra representación abstracta debe utilizar el identificador de esta última mientras solicita los mensajes de API. 5. Un módulo de control dispositivo (DCM) - que representa un dispositivo en la red. Un programa de aplicación puede interactuar directamente con un DCM. Dentro de un DCM, pueden estar contenidos muchos de los módulos de control funcionales (FCM) . En una red HAVi , una funcionalidad está representado por un FCM. Hablando jerárquicamente, un FCM siempre está contenido en un DCM, que representa un dispositivo. Un DCM puede contener más de un FCM (por ejemplo, un DCM que representa un VCR digital que contiene un FCM de sintonizador y un FCM de VCR) , pero existe únicamente un DCM para cada dispositivo HAVi. 6. Un administrador DCM - instala los DCM. Reacciona automáticamente a cambios en la red al instalar los DCM nuevos para dispositivos BAV nuevos. 7, Un controlador de interacción impulsado por datos (DDI) - vuelve a una GUI (interconexión de usuario gráfica) en una pantalla de exhibición a nombre de elemento de software HAVi. Soporta una amplia gama de exhibiciones que varían de gráfico a texto únicamente. 8. Un administrador de corriente (SMGR) genera conexionea y rutas de corrientes de AV en tiempo real entre dos o más dispositivos en la red. La interoperabilidad HAVi resuelve la necesidad general para permitir que los dispositivos existentes se comuniquen a un nivel básico de funcionalidad. Para obtener esto, HAVi define y utiliza un conjunto genérico de mensajes de control que permite a un dispositivo comunicarse con otro dispositivo y un conjunto de mensajes de suceso que se esperarían razonablemente de un dispositivo dado su clase (TV, VCR, reproductor de DVD) . Para soportar este enfoque, se requiere un conjunto básico de mecanismos: descubrimiento del dispositivo; comunicación; y un conjunto de mensajes HAVi .-Respecto al descubrimiento del dispositivo: cada dispositivo en la red casera necesita un método bien definido que permita que se difundan sus capacidades a otros. La solución HAVi es utilizar los denominados datos SDD: datos autodescriptivos . Los datos SDD se requieren en todos los dispositivos HAVi en la red. Los datos SDD contienen información acerca del dispositivo, el cual puede ser accesado por otros dispositivos. Los datos SDD contienen información suficiente mínima para permitir la particularización de un denominado módulo de control de dispositivo incrustado (DCM incrustado) . Un DCM incrustado es una pieza de código preinstalada en un IAV o FAV de control en un código dependiente de plataforma y que utiliza interconexiones nativas para que los IAV tengan acceso a los - recursos de FAV. Como se menciona en lo anterior, un DCM para un dispositivo es un elemento de software que proporciona una interconexión para control de funciones generales del dispositivo. La particularización de un DCM incrustado resulta en el registro de las capacidades de los dispositivos con un registro. El registro proporciona un servicio de directorio y permite al objeto en la red localizar otro objeto en la red. El registro permite que las aplicaciones infieran el conjunto básico de mensajes de instrucciones que pueden ser enviados a un dispositivo específico en la red. Respecto a la comunicación: Una vez que la aplicación ha determinado las capacidades de un dispositivo, la aplicación necesita ser capaz de tener acceso a esas capacidades. Esto requiere una instalación de comunicación general que permite que las aplicaciones emitan solicitudes a los dispositivos. El servicio se proporciona por el sistema de mensajes HAVi y los DCM. La aplicación envía mensajes HAVi a los DCM, el DCM después se acopla en comunicación registrada con los dispositivos . Respecto a loa conjuntos de mensajes HAVI con el fin de soportar la interoperabilidad básica así como un conjunto bien definido de mensajes, se requiere que deben ser soportados por todos los dispositivos de una clase conocida particular (por ejemplo la clase de receptores de TV, la clase de VCR, la clase de reproductores de DVD, etc.) . Esto asegura que un dispositivo puede trabajar con loa dispositivos existentes, así como con dispositivos futuros, sin importar el fabricante. Estos tres requerimientos básicos soportan cierto nivel mínimo de interoperabilidad . Dado que cualquier dispositivo puede solicitar las capacidades de otro dispositivo vía el registro, cualquier dispositivo puede determinar el conjunto de mensaje soportado por otro dispositivo. Puesto que las aplicaciones tienen acceso al sistema de mensajes, cualquier dispositivo puede interactuar con cualquier otro dispositivo. La interoperabilidad de HAVi básica asegura que los dispositivos puedan interoperar a nivel básico de funcionalidad. Sin embargo, se necesita un mecanismo más extendido de manera que permita a un dispositivo comunicarse con otros dispositivos con cualquier funcionalidad adicional que no esté presente en los DCM incrustados en un FAV. Por ejemplo, los DCM incrustados pueden no soportar todas las características de los productos existentes y es raro que soporten aquellos totalmente nuevos de las categorías de productos futuros . La interoperabilidad de HAVi "nivel 2" proporciona este mecanismo. Para obtener esto, la arquitectura HAVi permite que existan DCM cargables como una alternativa a los denominados módulos de control de dispositivo incrustados. Se puede proporcionar un DCM cargable por cualquier fuente adecuada, pero una técnica probable es colocar el DCM cargable en los datos de SDD de HAVi sobre el dispositivo BAV y cargarlo desde el BAV al dispositivo FAV cuando el BAV se conecta a la red casera. Debido a que la arquitectura HAVi es neutra respecto al vendedor, es necesario que el DCM cargado funcione en una diversidad de dispositivos FAV, todos con arquitectura de hardware potencialmente diferentes. Para obtener esto, los DCM cargados se implementa'n en código de octetos HAVi (JAVA) . El código de octetos Java de un ambiente que corre en tiempo sobre los dispositivos FAV soporta la particularización y ejecución de los DCM cargados. Una vez creados y en funcionamiento dentro de un dispositivo FAV, el DCM se comunica con los dispositivos BAV de la misma manera a la descrita en lo anterio . Bajo el escenario nuevo, en donde se conecta una red HAVi con una red UPnP vía una compuerta, y un dispositivo UPnP se controlará por un dispositivo FAV HAVi, se presenta un problema adicional en donde ninguno de los dispositivos UPnP proporciona un DCM HAVi que pueda ser cargado al dispositivo FAV HAVi. Por lo tanto, ni el nivel básico ni el nivel 2 de interoperabilidad están disponibles para el control de los dispositivos UPnP desde una estación de red HAVi.

INVENCIÓN Un objetivo de la invención es resolver los problemas de controlar un dispositivo que no está fabricado de acuerdo con HAVi , en una red que no es HAVi desde un dispositivo FAV fabricado de acuerdo con HAVi en una red HAVi por medio de una compuerta. Para algunos de los dispositivos UPnP, puede existir en el dispositivo de compuerta una representación correspondiente en forma de un DC con un FCM específico para el dispositivo incrustado. Este DCM/FCM se puede utilizar para generar una interconexión de usuario en el dispositivo FAV de HAVi para el control del dispositivo UPnP utilizando interoperabilidad básica. Por lo tanto, el usuario puede generar instrucciones de control para el dispositivo UPnP que necesiten ser interpretadas en la compuerta y transformadas en las instrucciones UPnP correspondientes que deben ser entendidas en el dispositivo UPnP que se va a controlar. Sin embargo, un problema es que ciertamente existen dispositivos UPnP para los cuales no hay una representación correspondiente en forma de un FCM que exista en el sistema HAVi. Para tal caso, en donde existe la posibilidad de implementada en el sistema HAVi de generar lo que se denomina un FCM genérico. En caso de un dispositivo UPnP desconocido, la compuerta puede proporcionar únicamente un DCM que tenga incrustado un FCM genérico para el control del dispositivo UPnP. Con este FCM genérico, el dispositivo FAV de HAVi no puede generar una interconexión de usuario debido a que ninguna de las funciones del dispositivo UPnP son conocidas en el FCM - - genérico. Esta es la médula del problema subyacente a la invención . La invención resuelve el problema por medio de las reivindicaciones independientes 1, 8, 12 y 15. La invención utiliza la posibilidad en el sistema HAVi de descargar desde un DCM lo que se denomina un HAVLET, que es un código de octetos Java ejecutable para generar una interconexión de usuario en el controlador HAVi. Esta pieza de software HAVLET interactúa con el DCM para los dispositivos que no son HAVi almacenados y ejecutados en la compuerta. El DCM que no es HAVi contiene un FCM que no es HAVi especializado que incluye las rutinas de software para solicitar las descripciones de función de un dispositivo que no es HAVi y para enviarlas al dispositivo FAV de HAVi. El HAVLET que corre en el dispositivo FAV de HAVi toma las descripciones de función del dispositivo que no es HAVi y genera una interconexión de usuario correspondiente con estas descripciones de función. Las particularidades ventajosas, modi icaciones y mejoras en la invención se incluyen en las reivindicaciones dependientes. Resulta muy útil, si el FCM que corre en la compuerta comprende un medio para traducir las descripciones de función leídas desde el dispositivo (23) que no es HAVi dentro de forma de datos soportadas por el sistema HAVi antes de enviarlos al controlador HAVi. Esta mejora simplifica mucho el software HAVLET que corre en el controlador HAVi . El medio para traducir la descripción de función del dispositivo que no es HAVi no necesita incluirse en el HAVLET y de esta manera se vuelve innecesario cargar un código de software correspondiente dentro del dispositivo FAV de HAVi, y de esta manera se reducen los requerimientos de memoria en el dispositivo FAV de HAVi. De igual manera, se libera al procesador del dispositivo FAV de HAVi. La invención puede utilizarse de mejor manera si una red HAVi necesita ser combinada con una red basada en IP, por e emplo una red UPnP. En el caso de una red UPnP, un dispositivo UPnP se representa por medio de lo que se denominan descripciones XML para cada función de un dispositivo UPnP. Las descripciones XML se solicitarán por el módulo de control de función especializada el cual es del tipo de FCM genérico (de acuerdo con la especificación HAVi) que corre en la compuerta, traducido y que después se enviará al HAVLET ejecutado por el controlador HAVi. Para cada descripción de función traducida, el HAVLET generará una representación gráfica preferiblemente en forma de un botón, una barra deslizable, un botón de solicitud o un campo que se introduce, junto con un símbolo o expresión que explica el significado. En la reivindicación 8, independiente se reclama una compuerta de acuerdo con la invención. La reivindicación 12 independiente reclama un producto de programa de computadora, específicamente un módulo - - de control de función FCM para la compuerta de acuerdo con la invención . La reivindicación 15 independiente reclama un producto de programa de computadora, en particular un HAVLET, que corre en el controlador HAVi, de acuerdo con la invención.

DIBUJOS LAS MODALIDADES EJEMPLARES DE LA INVENCIÓN SE ILUSTRAN EN LOS DIBUJOS Y SE EXPLICAN CON MAYOR DETALLE EN LA SIGUIENTE DESCRIPCIÓN En las figuras: La figura 1 muestra un ejemplo de una red HAVi y una red UPnP conectadas entre sí vía una compuerta; la figura 2 muestra los elementos de software básicos que interactúan entre sí del dispositivo UPnP, la compuerta y el controlador HAVi ; la figura 3 muestra un ejemplo de una interconexión de usuario para el control de una cámara de seguridad UPnP exhibida en el controlador HAVi; la figura 4 muestra una lista de programa para un módulo de control de función para el uso en la compuerta, de acuerdo con la invención; la figura 5 muestra una lista de programa para un HAVLET que va a ser ejecutado por un controlador HAVi , de acuerdo con la invención; y la figura 6 muestra una lista de programa para una rutina de descripción de servicio que será solicitado cuando se ejecute el módulo de control de función.

MODALIDADES EJEMPLARES DE LA INVENCIÓN La figura 1 muestra la estructura principal de dos redes que se conectan entre sí por medio de la compuerta 10. En el lado izquierdo de la figura se muestra una red UPnP. Como un ejemplo, el número de referencia 21 indica una lavadora, el número de referencia 11 un ref igerador, el número de referencia 23 una cámara de seguridad, el número de referencia 24 una unidad de control de calentamiento y el número de referencia 25 una computadora personal que tiene una conexión de internet ISDN/DSL. Todos estos dispositivos UPnP se conectan a un enlace común 20 Ethernet para intercambio de datos. Las líneas de enlace común Ethernet también se conectan con la compuerta 10. En el lado derecho de la figura 1 se muestra una red HAVi. El número de referencia 31 indica una televisión, el número de referencia 32 indica una VCR, el número de referencia 33 indica un reproductor de DVD y el número de referencia 34 indica una caja superior tal como un receptor de satélite - - digital . Las estaciones de red HAVi se conectan a un enlace común 30 IEEE1394 para intercambio de datos. La compuerta 10 también está conectada al enlace común 30 1394. La compuerta 10 comprende un apilamiento 11 de protocolo IP, en un lado, un apilamiento 12 de protocolo HAVi en el otro lado así como software para llevar a cabo la traducción o el mapeo de mensajes de control y de sucesos desde una red a otra. Las especificaciones HAVi así como las UPnP son conocidas en la técnica. Por lo tanto, no hay necesidad de explicar todos los detalles en estas especificaciones con el propósito de describir la presente invención. Por lo tanto, se hace referencia expresamente a las especificaciones HAVi así como a la especificación UPnP para este propósito. La especificación UPnP se puede obtener de UPnP Forum administrado por Microsoft Incorporatio . Como se menciona en lo anterior, el sistema de red UPnP se basa en protocolos de internet existentes. Una interconexión de usuario gráfica (GUI) para controlar dispositivos UPnP desde un controlador UPnP, por ejemplo la computadora personal 25, pueden consistir de una pluralidad de iconos exhibidos en el monitor de computadora. Cuando un usuario selecciona un icono, se recuperan páginas de HTML del dispositivo en cuestión. Las páginas HTML se exhiben para el usuario. Esto permite que el usuario controle al dispositivo dado. En la especificación UPnP se define que cada dispositivo - - UPnP comprende una lista de servicios, los cuales se proporcionan por el dispositivo. Cada uno de estos servicios se describe en un documento X L, en donde XML indica lenguaje marcado de extensión, es decir, tecnología de internet. Cada documento XML contiene una descripción detallada de todas las posibilidades de control dentro del servicio. Estos documentos XML se utilizarán para controlar un dispositivo UPnP desde un controlador HA i . El proceso de control del dispositivo UPnP desde un dispositivo FAV de HAVi se ilustra en la figura 2. Números de referencia idénticos indican los mismos componentes, como se muestran en la figura 1 y no necesitan explicarse nuevamente.-En la figura 2, el circuito 26 de interconexión Ethernet, con el cual se equipan los dispositivos UPnP asi como la compuerta, como se muestran de manera separada. Similarmente , la interconexión de enlace común 1394 35 para los componentes de red HAVi y la compuerta 10 se muestran de igual manera. Además de los elementos de software básicos de la cámara 23 de seguridad, la compuerta 10 y la televisión 31 se muestran en la figura 2. Una cámara 23 de seguridad contiene un documento XML en el cual se incluyen las posibilidades de control para la cámara de seguridad. El elemento de software importante de la compuerta es un módulo de control de dispositivo DCM que contiene un módulo FCM de control de función especificado así como un HAVLET de programa Java ejecutable. El HAVLET de programa Java se proporciona para una carga a un dispositivo FAV de HAVi durante la fase de configuración de la red HAVi . Por lo tanto, el elemento de software muy importante del controlador HAVi 31 se relaciona con este HAVLET . Para controlar la cámara 23 de seguridad, la compuerta interactúa con la cámara 23 de seguridad y la TV 31 como sigue. Después de terminar la fase de configuración en ambas redes, todos loa componentes de red dentro de la red HAVi así como en la red UPnP se pueden controlar desde la TV 31. Una interfaz de usuario para controlar estos dispositivos se construye en forma de una lista de iconos para cada dispositivo controlable. Es el administrador de medio de comunicaciones C M, el administrador de sucesos EM, el sistema de registro y de mensajes MS del apilamiento de protocolo HAVi los que se utilizan para recolectar la información de todos los elementos controlables que están en la red HAVi o en las redes UPnP . Por supuesto, la compuerta 10 incluye elementos de software correspondientes e interconexiones de manera que es posible el mapeo de los dispositivos UPnP en el registro HAVi. Sin embargo, este proceso es un elemento supuesto previamente en la técnica anterior y no se explicará con mayor detalle aquí. Un usuario puede no desear controlar la cámara de seguridad desde la TV 31 en la red HAVi. Para este propósito, selecciona un icono correspondiente en la pantalla de TV. Este - - suceso comenzará con la descarga del HAVLET dentro de la memoria interna de la TV 31. Justo después de la descarga, se inicia la ejecución del HAVLET. El HAVLET es un programa de Java ejecutable. Puesto que JAVA es una plataforma del lenguaje de programación independiente correrá en cada dispositivo FAV de HAVi que tenga un ambiente de tiempo de funcionamiento para el control de octetos JAVA. En tercer lugar, el HAVLET ejecutado enviará una solicitud para recuperar información acerca de la cámara 23 de seguridad a la compuerta 10. Esta solicitud se aceptará por el módulo de control de función FCM de UPnP que está en funcionamiento, que en sí mismo recupera el documento XML/s almacenado en el servidor de red de la cámara 23 de seguridad. Cada documento XML contiene descripciones de las posibilidades de control para la cámara 23 de seguridad. El FCM traduce las descripciones XML en una estructura (conjunto de variables) y las envía al HAVLET que corre en la TV 31. El HAVLET después toma estas descripciones de función y genera para cada elemento controlable una representación gráfica tal como un botón, una placa deslizable, un botón de solicitud, un campo de introducción o similar para generar una interconexión gráfica con el usuario para el control de la cámara de seguridad en la pantalla de TV. El flujo de información se ilustra en la figura 2, con flechas y numeración que expresa el orden de la interacción. - 2 La interconexión de usuario gráfica para la cámara 23 de seguridad se muestra en la figura 3. Para cada elemento controlable de la cámara de seguridad se genera una representación gráfica, por ejemplo para la brillantez se establece una barra deslizable que se muestra en la pantalla de TV. Con un puntero de ratón se puede controlar directamente la brillantez por medio de los botones izquierdo/derecho que se colocan del lado izquierdo o derecho de la barra deslizable. Además, la barra deslizable en sí misma puede ser arrastrada a la posición deseada, como es conocida en una gran variedad de menús de computadora. En el lado izquierdo de la barra deslizable para ajuste de brillantez se muestra de manera escrita la expresión establecer brillantez. Esta expresión se toma directamente encima desd la descripción de XML para este elemento controlable. El FCM que corre en la compuerta no necesariamente conoce el significado de esta expresión. Esto es evidente si uno considera que se ha integrado un tipo nuevo de producto en la red UPnP para el cual actualmente nadie sabe qué elementos controlables tiene. En tal caso, el usuario debe realizar una interpretación correcta de este elemento controlable por sí mismo. Debajo de la barra deslizable de brillantez se coloca un botón de establecer brillantez. Este es un ejemplo de un botón de solicitud. Al dejar de presionar el botón de solicitud, el valor de brillantez actual establecido se libera y se exhibirá al lado del botón. Debajo del botón de - - obtener brillantez se colocan botones sencillos de aumentar brillantez y disminuir brillantez. Estos botones tienen el mismo efecto que los botones derecho e izquierdo de la barra deslizable de establecer brillantez. Un ejemplo de un campo introducido es el campo establecer rotación implícita. Aquí un número se solicita con este campo y se introducirá en la máscara de entrada. El parámetro introducido determina la rotación de la cámara de seguridad para adquirir otra vista. En vez de exhibir la expresión extraída del elemento de control respectivo derivado de la descripción XML, se exhibirá en la interconexión del usuario un símbolo autoexplicativo . Sin embargo, esto requiere la necesidad de tener componente de interconexión de usuario definido previamente instalados en el HAVLET para los diferentes servicios de los diversos dispositivos de UPnP posibles. Incluso si un tipo nuevo de dispositivos se integrara en la red UPnP, el componente de interconexión de usuario definido previamente debe ser utilizado en este nuevo dispositivo que proporciona un servicio para el cual los componentes de interconexión de usuario ya se han proporcionado en el HAVLET. Sin embargo, para servicios desconocidos, esta solución no funcionará. Otra solución es que exista una mezcla de ambas soluciones diferentes para un servicio. Para todos los parámetros en la descripción XML para los cuales ya se ha asignado un símbolo de antemano, se puede exhibir un símbolo correspondiente en la interconexión de usuario. Sin embargo, para parámetros desconocidos, no necesita mostrarse las expresiones correspondientes. El documento XML de un dispositivo UPnP se puede considerar como una implementación estándar de la especificación UPnP. Para la realización de la presente invención no necesita realizarse a uí programación extraordinaria. Los elementos de software básicos para la realización de la presente invención son el FCM de UPnP que corre en la compuerta y el HAVLET cargado en el dispositivo FAV de HA i . Ambos elementos de software incluyen rutinas extraordinarias para la realización de la invención. La figura 4 muestra una lista de programa del módulo de control de función para la red UPnP. De alguna manera es un FCM "genérico" que siempre se utilizará para el control de cualquier dispositivo UPnP. El lenguaje de programación es JAVA. Este es un lenguaje de programación bien conocido utilizado ampliamente de manera que no se explicará aquí la sintaxis particular. Las rutinas importantes para implementar la invención están marcadas. Con la marca @ , la rutina para extraer los servicios del documento XML es marcada. Esta rutina por lo tanto extrae la información respecto a qué clase de servicio proporciona el dispositivo UPnP solicitado. Por ejemplo, la cámara de seguridad UPnP proporciona el servicio de proporcionar una corriente de imágenes de video en un formato similar como JPEG o imagen a cierto nivel de compresión y de resolución . La rutina GET_SERVICE_DESCRIPTION marcada con la etiqueta ® solicita la información de cuántos servicios ofrece el dispositivo UPnP. Con la rutina GET_SERVICE_INFORMATION_LIST marcada con la etiqueta 5) , la información acerca de cada posibilidad de control del servicio seleccionado se puede recuperar. La rutina PERFORM_C0NTR0L_C0MMA D se proporciona para enviar una instrucción de control a un dispositivo UPnP, véase etiqueta . La rutina PERFORM_DEVICE_VARIABLE_QUERY se proporciona para recuperar el valor variable actual para un dispositivo UPnP, véase etiqueta (E¡ . Estas rutinas se ejecutarán ante una solicitud del HAVLET que corre en el dispositivo HAVi . Para la rutina que solicita las instrucciones correspondientes que se mantienen en la segunda parte de los métodos de encabezado de lista de programa para responder a la solicitud que entra. De manera expresiva, se denomina a la rutina llamada DO_GET_SERVICE_DESCRIPTION marcado con la etiqueta (0 y DO_GET_SERVICE_INFOR ATIO _LIST marcado con la etiqueta S Una rutina importante adicional para la implementación de la invención es la rutina sendControlCommand (enviar instrucción de control) para enviar una instrucción de control al dispositivo UPnP. Esta rutina se marca con la etiqueta @ Dentro de esta rutina también se evalúa un mensaje de respuesta y se envía al HAVLET en el dispositivo HAVi.

También es importante en la implementación de la invención con la rutina queryDeviceVariable (solicitud variable de dispositivo) marcada con la etiqueta . Esta rutina se inicia en el HAVLET que ha enviado una solicitud correspondiente. Por ejemplo, si el usuario ha presionado un botón de solicitud, se solicitará esta rutina. Nuevamente, en esta rutina se enviará de regreso un mensaje de respuesta al dispositivo HAVi . Con la rutina receiveHttpNotifyData (recibir datos notificados por http) marcada en la etiqueta (5 se manejarán los sucesos UPnP . El código de fuente JAVA de un HAVLET que implementa la invención se muestra en la figura 5. La tarea principal del HAVLET es construir la interconexión de usuario para controlar un dispositivo UPnP. La rutina completa para construir la UI está marcada como @L El HAVLET que contiene las rutinas correspondientes para obtener las descripciones de servicio para el dispositivo UPnP marcadas con la etiqueta (L), para obtener la lista de información de servicio marcado con la etiqueta (í para realizar una instrucción de control marcada con la etiqueta @ y para realizar una solicitud de variable de dispositivo marcada con la etiqueta (§). El módulo de control de función se integra en un módulo de control del dispositivo de acuerdo con la especificación HAVi . Por lo tanto, lo que necesita realizarse es programar un módulo de control de dispositivo que tenga incrustado el módulo de control de función de la figura 4. Este programa se considera que es la implementación estándar de la especificación HAVi que no necesita explicarse en detalle. Este es el motivo por el cual no se muestra la lista del DCM. La parte del programa que realiza la traducción de las descripciones de XML en forma de datos soportados por el sistema HAVi, se incluye en una rutina denominada rutina de descripción de servicio, que se muestra en la figura 6. Las descripciones XML básicamente están en formato de texto. Estas descripciones XML son evaluadas. Por ejemplo, la parte de programa marcada con la etiqueta ? evalúa si las descripciones XML contienen algunas acciones. Estas acciones corresponden a los elementos controlables del dispositivo UPnP . Se traducen en una forma típica de HAVi de un conjunto variable denominado "estructura" . Esto se realiza al analizar la descripción XML y almacenar toda la información de interés en sus variables de instancia local.

Claims (19)

REIVINDICACIONES

1. Método para generar una interconexión de usuario en un dispositivo HAVi para el control de un dispositivo que no es HAVi, en donde HAVi ndica interoperabilidad de audio/video casero, el dispositivo HAVi es una estación de red HAVi y el dispositivo que no es HAVi es una eBtación de una red que no es HAVi, ambas redes se conectan entre sí por una compuerta, el método está caracterizado porque la compuerta corre un módulo de control de función para los dispositivos que no son HAVi que solicitan las descripciones de las funciones del dispositivo que no es HAVi que va a ser controlado y las envían al dispositivo HAVi que genera los componentes de interconexión de usuario correspondientes para las funciones del dispositivo que no es HAVi por medio de un programa JAVA (HAVLET) que corre en el dispositivo HA i.

2. El método como se describe en la reivindicación 1, en donde el módulo de control de función (FCM) traduce las descripciones de función leídas desde el dispositivo que no es HAVi en una forma de datos soportada por el sistema HAVi antes de enviarlo al dispositivo HAVi.

3. El método como se describe en la reivindicación 1, en donde el programa JAVA (HAVLET) traduce las descripciones de función leídas desde el dispositivo que no es HAVi en forma de datos soportados por el sistema HA i.

4. El método como se describe en una de las reivindicaciones 1 a 3, en donde la compuerta carga el programa JAVA (HAVLET) al dispositivo HAVi durante la configuración.

5. El método como se describe en una de las reivindicaciones previas, en donde el dispositivo HAVi sobre el cual se genera una interconexión de usuario para controlar al dispositivo que no es HAVi, es un dispositivo HAVi del tipo FAV, en donde FAV significa dispositivo HAVi de audio y video completo .

6. El método como se describe en una de las descripciones previas, en donde la red que no es HAVi es una red basada en IP, en particular una red UPnP, en donde UPnP indica un sistema de red de conexión y reproducción universal .

7. El método como se describe en la reivindicación 6, en las descripciones de función del dispositivo que no es HAVi son descripciones XML, en donde XML indica lenguaje marcado de extensión.

Una compuerta para uso en un método, como describe en una de las reivindicaciones previas, que comprende una interconexión para una red HAVi y que comprende una interconexión para una red que no es HAVi, la compuerta está caracterizada porque comprende un módulo de control de función que incluye medios para solicitar las descripciones de función del dispositivo que no es HAVi y medio para enviar las descripciones de función a la estación de red de la red HAVi en la cual se generará una interconexión de usuario para controlar al dispositivo que no es HAVi.

9. La compuerta, como se describe en la reivindicación 8, que comprende un programa JAVA (HAVLET) que incluye un medio para generar una interconexión de usuario con las descripciones de función de un dispositivo que no es HAVi , este programa JAVA (HAVLET) se proporciona para una carga en un dispositivo HAVi .

10. La compuerta, como se describe en la reivindicación 8 ó 9, en donde el módulo de control de función (FCM) comprende un medio para traducir las descripciones de función leídas desde un dispositivo que no es HAVi en forma de datos soportados por el sistema HAVi antes de enviarlo a la red HAVi .

11. La compuerta, como se describe en la reivindicación 9, en donde el programa JAVA (HAVLET) comprende un medio para traducir las descripciones de función leídas desde el dispositivo que no es HAVi en una forma de datos soportada por el sistema HAVi.

12. Un productor de programa de computadora, en particular un módulo de control de función (FCM) cargable directamente en una memoria interna de una compuerta, como se describe en una de las reivindicaciones 8 a 11, que comprende un medio para solicitar descripciones de función de un dispositivo que no es HAVi y un medio para enviar las descripciones de función a una estación de red de una red HAVi en la cual se generará una interconexión de usuario para controlar al dispositivo que no es HAVi cuando tal producto es ejecutado por un procesador de la compuerta.

13. El producto de programa de computadora, como se describe en la reivindicación 12, que comprende además un medio para traducir las descripciones de función leídas desde el dispositivo que no es HAVi, en forma de datos soportados por el sistema HAVi antes de enviarlo a la red HAVi .

14. El producto de programa de computadora, como se describe en las reivindicaciones 12 ó 13, en donde las descripciones de función del dispositivo que no es HAVi son descripciones XML, en donde XML indica lenguaje marcado de extensión.

15. Un producto de programa de computadora, en particular un programa JAVA (HAVLET) , cargable directamente en la memoria interna de un dispositivo HAVi de una red HAVi, que comprende un medio para generar una interconexión de usuario para el control de un dispositivo que no es HAVi, con las descripciones de función recuperadas desde el dispositivo que no es HAVi, cuando el producto se ejecuta por un procesador del dispositivo HAVi.

16. Un producto de programa de computadora, como se describe en la reivindicación 15, en donde las descripciones de funciones recuperadas son descripciones XML traducidas del dispositivo que no es HAVi, en donde XML indica lenguaje de marcado de extensión y las descripciones XML son traducidos en forma de datos soportados por el sistema HAVi.

17. El producto de programa de computadora, como se describe en la reivindicación 15, que comprende además un medio para traducir las descripciones de función recuperadas del dispositivo que no es HAVi, en una forma de datos que es soportada por el sistema HAVi y las descripciones de función son descripciones XML, en donde XML indica lenguaje marcado de extensión .

18. El producto de programa de computadora, como se describe en una de las reivindicaciones 15 a 17, en donde el medio para generar una interconexión de usuario comprende un medio para asignar a una descripción de función traducida la representación gráfica apropiada junto con un símbolo o expresión que explique el significado de la descripción de función.

19. Un producto de programa de computadora, como se describe en la reivindicación 18, en donde la representación gráfica está en forma de un botón, una barra deslizable, un botón de solicitud c un campo para introducción. RESUMEN La invención se relaciona con tecnología de interconexión de redes caseras, específicamente una red casera HAVi y una red basada en IP tal como una red UPnP . Cuando se combinan ambas redes por medio de la compuerta (10), se proporcionará un servicio para controlar un dispositivo UPnP desde un dispositivo HAVi. Surge un problema del hecho de que para cada dispositivo UPnP, no existe un módulo de control de dispositivo correspondiente en la tecnología de red HAVi de manera que algunos de los dispositivos UPnP no pueden ser controlados por un módulo de control de dispositivos (DCM)-correspondiente . La invención resuelve este problema por medio de dos elementos de software básicos, específicamente un módulo de control de función (FCM) especializado que va a ser implementado en la compuerta (10) y un programa JAVA (HAVLET) que corre en el controlador (31) HAVi. La red UPnP es una red basada en IP. Por lo tanto, cada dispositivo UPnP es representado por lo que se denomina un documento XML. Tal documento XML incluye varias de las descripciones XML, las cuales son nada menos que descripciones de función para los elementos controlables. Un módulo de control de función (FCM) de acuerdo con la invención incluye un medio para solicitar las descripciones de función del dispositivo UPnP y para enviar estas descripciones de función al controlador (31) HA i. El módulo de control de función (FCM) , puede incluir un medio para traducir las descripciones de función recuperadas antes de enviarlas al controlador (31) HAVi . En el controlador (31) HAVi , se corre el programa JAVA (HAVLET) y este programa toma las descripciones de función recibidas desde la compuerta (10) y genera una interconexión de usuario con esta información. El programa JAVA puede ser cargado en el controlador 31 HAVi durante la fase de configuración de la red HAVi .