ES2346169T3 - Propiedad de control correlacionada con elemento de gui modalmente compatible. - Google Patents

Abstract

Sistema (100) de procesamiento de información que comprende un dispositivo (102) electrónico y un controlador (104, 112) para el control de una funcionalidad del dispositivo, en el que: - se proporciona al controlador una representación (108) de la funcionalidad; - el controlador permite controlar la funcionalidad a través de la interacción con la representación; caracterizado porque en el sistema - dicha representación es una representación abstracta, - la representación expone una modalidad para controlar la funcionalidad; y - la modalidad determina asociar el control de la funcionalidad con una capacidad de control modalmente compatible del controlador sin que el controlador sepa cuál es la funcionalidad.

Description

Propiedad de control correlacionada con elemento de GUI modalmente compatible.

Campo de la invención

La invención se refiere a un sistema de procesamiento de información y a un procedimiento para controlar dispositivos.

Antecedentes de la técnica

Un consorcio de fabricantes de electrónica de consumo, entre los que se encuentra Philips Electronics, ha estado trabajando en especificaciones para un núcleo de API (interfaces de programación de aplicaciones) para aparatos digitales de electrónica de consumo en una red doméstica para proporcionar una norma para la electrónica de audio/vídeo y las industrias multimedia. Una API especifica el procedimiento requerido para realizar peticiones a un sistema operativo o programa de aplicación. La red doméstica se considera una plataforma de cálculo distribuida. El objetivo principal de la norma, denominada arquitectura HAVi (interoperabilidad de audio/vídeo doméstica) es garantizar que puedan interoperar productos de diferentes vendedores, es decir, que puedan cooperar para realizar tareas de aplicación. Los dispositivos de EC actuales, tales como los equipos de entretenimiento domésticos (reproductores de DVD, cámaras de vídeo de mano de DV, aparatos de televisión digitales, etc.) son sistemas de procesamiento digital y almacenamiento digital. La conexión de estos dispositivos en redes hace posible compartir recursos de procesamiento y almacenamiento. Esto permite coordinar el control de varios dispositivos de EC simultáneamente, por ejemplo, con el fin de simplificar la interacción del usuario. Por ejemplo, un primer dispositivo puede instanciar la grabación en un segundo dispositivo mientras que accede a una EPG (guía electrónica de programas) en un tercer dispositivo. La red doméstica proporciona la estructura para conectar los dispositivos de EC. Permite que los dispositivos conectados intercambien tanto datos de control (un dispositivo envía una orden a otro) como datos de AV (audio/vídeo) (un dispositivo envía un flujo de audio o vídeo a otro dispositivo). La red debe cumplir con varios requisitos con el fin de conseguir todo esto. Debe soportar una transferencia a tiempo de flujos de AV de alta tasa de transmisión de datos. La red debe soportar autoconfiguración, autogestión y una capacidad instantánea de conectar y ejecutar (hot plug-and-play). Debe requerir interfaces y cableado de bajo coste.

La arquitectura de software HAVi es independiente de la plataforma y se basa en Java. HAVi usa el protocolo de bus serie de alto rendimiento IEEE 1394 para el transporte de control y contenido entre los dispositivos conectados a la red. La norma IEEE 1394 es una red digital de bajo coste dinámicamente configurable. La norma IEEE 1394 define tanto una capa física de plano posterior como implantaciones de bus virtual conectadas por cable entre iguales. La versión de plano posterior opera a 12,5, 25 ó 50 Mbits/seg. La versión por cable soporta tasas de transmisión de datos de 100, 200 y 400 Mbits/seg. La norma especifica los medios, la topología y el protocolo. El protocolo de transporte IEEE 1394 es particularmente útil para soportar protocolos de comunicación de audio y vídeo, debido a su capacidad de alta tasa de transmisión de datos.

La arquitectura HAVi controla los dispositivos de EC en la red a través de representaciones abstractas de los dispositivos de EC. Sobre las representaciones abstractas se opera mediante un controlador y ocultan las idiosincrasias de los dispositivos de EC reales asociados. La representación abstracta proporciona así una interfaz uniforme para mayores niveles de software. Las representaciones abstractas se registran con sus propiedades de control que reflejan las del dispositivo representado. Las representaciones abstractas exponen sus API de interoperabilidad a las aplicaciones y juntos forman un conjunto de servicios para construir aplicaciones distribuidas portátiles en la red doméstica.

La arquitectura permite a un dispositivo enviar una información de control u orden a otro dispositivo en la red doméstica. Un dispositivo compatible con HAVi contiene datos (arriba la representación abstracta, que se denomina modelo de control de dispositivo o DCM, véase más adelante) en relación con su interfaz de usuario (por ejemplo, GUI) y con sus capacidades de control. Estos datos incluyen, por ejemplo, código de bytes HAVi (Java) que puede cargarse y ejecutarse por otros dispositivos en la red. Un dispositivo compatible con HAVi tiene, como mínimo, suficiente funcionalidad para comunicarse con otros dispositivos en el sistema. Durante la interacción, los dispositivos pueden intercambiar control y datos de una manera entre iguales. Esto garantiza que a nivel de comunicación, no se requiera que ninguno de los dispositivos actúe como maestro o controlador del sistema. Por otro lado, permite a un controlador o maestro lógico imponer una estructura de control en el modelo básico de comunicación entre iguales. HAVi distingue entre controladores y dispositivos controlados tal como se explica más adelante. Un controlador es un dispositivo que actúa como anfitrión para un dispositivo controlado. Un controlador alberga la representación abstracta para el dispositivo controlado. La interfaz de control se expone a través de la API de la representación abstracta. Esta API es el punto de acceso para aplicaciones para el control del dispositivo.

Los dispositivos de EC compatibles con HAVi son dispositivos clasificados de la siguiente manera: dispositivos de AV completos (FAV), dispositivos de AV intermedios (IAV) y dispositivos de AV base (BAV).

Un FAV contiene un conjunto complete de los componentes de software de la arquitectura de software HAVi (véase a continuación). Un FAV se caracteriza porque tiene un entorno de tiempo de ejecución para códigos de bytes HAVi. Esto permite a un FAV cargar un código de bytes desde otros dispositivos para, por ejemplo, proporcionar capacidades mejoradas para su control. Un FAV puede estar formado, por ejemplo, por un decodificador compatible con HAVi, un receptor de televisión digital compatible con HAVi y un ordenador personal doméstico. Por ejemplo, un receptor de televisión inteligente puede ser el controlador HAVi de otros dispositivos conectados en la red. El receptor obtiene el código de bytes cargado desde otro dispositivo para crear una IU para este dispositivo y para proporcionar control externo de este dispositivo. Puede hacerse que un icono que presenta este dispositivo aparezca en la pantalla de televisión y la interacción del usuario con el icono puede hacer que los elementos del programa de control accionen el dispositivo representado de una manera previamente especificada.

Un IAV no proporciona un entorno de tiempo de ejecución para códigos de bytes HAVi, pero puede proporcionar un soporte nativo para el control de dispositivos específicos en la red doméstica. Un IAV comprende elementos de software incrustados que proporcionan una interfaz para controlar funciones generales de los dispositivos específicos. Estos elementos de software no tienen que ser un código de bytes HAVi y pueden implementarse como aplicaciones nativas en el IAV que usan interfaces nativas para acceder a otros dispositivos.

Un BAV puede proporcionar un código de bytes HAVi que puede cargarse pero no alberga ninguno de los elementos de software de la arquitectura HAVi. Un BAV puede controlarse a través de un FAV por medio del código de bytes cargado anterior. Un BAV puede controlarse a través de un IAV a través del código nativo. La comunicación entre un FAV o IAV, por un lado, y un BAV por otro lado requiere trasladar el código de bytes HAVi a y desde el protocolo de orden usado por el BAV.

Los elementos de software principales incluidos en la especificación de núcleo de la arquitectura HAVi son los enumerados a continuación. Para una explicación más detallada de estos elementos, véase la especificación HAVi, incorporada en el presente documento por referencia.

1) Un gestor de medios de comunicaciones (CMM) 1394 - actúa como interfaz entre los otros elementos de software y la IEEE 1394.

2) Un gestor de eventos (EM) - informa a los diversos elementos de software sobre eventos en la red tales como los cambios en la configuración de red que se producen cuando se añaden o eliminan de la red aparatos (dispositivos).

3) Un registro - contiene información acerca de los aparatos conectados a la red y las funciones que ofrecen. Las aplicaciones pueden obtener esta información a partir del registro.

4) Un sistema de mensajería (MS) - sirve como API que facilita la comunicación entre los elementos de software de los diversos aparatos en la red. El sistema de mensajería proporciona a los elementos de software HAVi características de comunicación. Es independiente de la red y las capas de transporte. Un sistema de mensajería se incrusta en cualquier FAV e IAV. El sistema de mensajería se encarga de asignar identificadores para las representaciones abstractas en el FAV o IAV. Estos identificadores se usan en primer lugar por las representaciones abstractas para registrarse en el FAV o IAV. Entonces se usan por las representaciones abstractas para identificarse entre sí dentro de la red doméstica. Cuando una primera representación abstracta desea enviar un mensaje a otra representación abstracta tiene que usar el identificador de esta última mientras que invoca la API de mensajería.

5) Un módulo de control de dispositivo (DCM) - representa un aparato en la red. Los programas de aplicación pueden interactuar directamente con un DCM. Esto los protege frente a las idiosincrasias de cada aparato individual.

6) Un gestor de DCM - instala los DCM. Reacciona automáticamente a cambios en la red instalando nuevos DCM para nuevos aparatos.

7) Un controlador de interacción accionada por datos (DDI) - proporciona una GUI (interfaz gráfica de usuario) en la pantalla de un aparato para un elemento de software HAVi. Soporta una amplia gama de representaciones, que varían desde gráficas hasta sólo texto.

8) Un gestor de flujo (SMGR) - crea conexiones y encamina flujos de AV en tiempo real entre dos o más aparatos en la red.

La arquitectura HAVi especifica al menos dos niveles de interoperabilidad, denominados nivel 1 y nivel 2.

La interoperabilidad de nivel 1 trata la necesidad general de permitir a dispositivos existentes comunicarse a un nivel básico de funcionalidad. Para conseguir esto, la interoperabilidad de nivel 1 define y usa un conjunto genérico de mensajes de control (órdenes) que permiten a un dispositivo comunicarse con otro dispositivo, y un conjunto de mensajes de eventos que esperará razonablemente desde un dispositivo dada su clase (televisión, VCR, reproductor de DVD, etc.). Para soportar este enfoque se requiere un conjunto básico de mecanismos: descubrimiento del dispositivo; comunicación; y un conjunto de mensajes HAVi.

En cuanto al descubrimiento del dispositivo: cada dispositivo en la red doméstica necesita un procedimiento bien definido que le permita anunciar sus capacidades a otros. El enfoque HAVi es utilizar denominados datos SDD: datos autodescriptivos. Los datos SDD se requieren en todos los dispositivos en la red. Los datos SDD contienen información acerca del dispositivo al que puede accederse por otros dispositivos. Los datos SDD contienen, como mínimo, suficiente información para permitir la instanciación de un denominado módulo de control de dispositivo incrustado (DCM incrustado). Un DCM incrustado es un fragmento de código previamente instalado en un IAV o FAV de control en código dependiente de plataforma y que usa interfaces nativas para acceder a los recursos del IAV o FAV. Tal como se mencionó anteriormente, un DCM para un dispositivo es un elemento de software que proporciona una interfaz para el control de funciones generales del dispositivo. La instanciación de un DCM incrustado da como resultado el registro de las capacidades del dispositivo con un registro. El registro proporciona un servicio de directorio y permite a cualquier objeto en la red localizar a otro objeto en la red. El registro permite a las aplicaciones deducir el conjunto básico de mensajes de orden que pueden enviarse a un dispositivo específico en la red.

En cuanto a la comunicación: una vez que una aplicación ha determinado las capacidades de un dispositivo, la aplicación necesita poder acceder a esas capacidades. Esto requiere una capacidad de comunicación general que permita a las aplicaciones emitir peticiones a dispositivos. Este servicio se proporciona por los sistemas de mensajería HAVi y los DCM. La aplicación envía mensajes HAVi a los DCM, a continuación los DCM se dedican a la comunicación propietaria con los dispositivos.

En cuanto a los conjuntos de mensajes HAVi: con el fin de soportar la interoperabilidad de nivel 1 se requiere un conjunto de mensajes bien definido que debe soportarse por todos los dispositivos de una clase conocida particular (por ejemplo, la clase de receptores de televisión, la clase de VCR, la clase de reproductores de DVD, etc.). Esto garantiza que un dispositivo pueda funcionar con dispositivos existentes, así como con dispositivos futuros, independientemente del fabricante.

Estos tres requisitos básicos soportan un determinado nivel mínimo de interoperabilidad. Puesto que cualquier dispositivo puede consultar las capacidades de otro a través del registro, cualquier dispositivo puede determinar el conjunto de mensajes soportado por otro dispositivo. Puesto que las aplicaciones tienen acceso al sistema de mensajería, cualquier dispositivo puede interactuar con cualquier otro dispositivo.

La interoperabilidad de nivel 1 garantiza que los dispositivos puedan interoperar a un nivel básico de funcionalidad. Sin embargo, es necesario un mecanismo más extendido para permitir también 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 poco probable que soporten las totalmente nuevas de categorías de productos futuros. La interoperabilidad de nivel 2 proporciona este mecanismo. Para conseguir esto, la arquitectura HAVi permite DCM que pueden cargarse como una alternativa a los DCM incrustados anteriormente mencionados. El DCM cargado puede sustituir un DCM existente en un FAV. Un DCM que puede cargarse puede proporcionarse por cualquier fuente adecuada, aunque una técnica probable es situar el DCM que puede cargarse en los datos SDD HAVi del dispositivo BAV, y cargarlo desde el dispositivo BAV al dispositivo FAV cuando el BAV está conectado a la red doméstica. Puesto que la arquitectura HAVi es neutral respecto al vendedor, es necesario que el DCM cargado funcione en una diversidad de dispositivos FAV todos con arquitecturas de hardware posiblemente diferentes. Para conseguir esto, los DCM cargados se implementan en código de bytes HAVi (Java). El entorno de tiempo de ejecución del código de bytes HAVi en dispositivos FAV soporta la instanciación y ejecución de DCM cargados. Una vez creado y funcionando en un dispositivo FAV, el DCM se comunica con los dispositivos BAV de la misma manera tal como se describió anteriormente.

La eficacia de la interoperabilidad de nivel 2 resulta evidente cuando se consideran recursos necesarios para acceder a una funcionalidad de dispositivo específica. El nivel 2 permite controlar un dispositivo a través de un DCM cargado que presenta todas las capacidades ofrecidas por el dispositivo, mientras que para conseguir una funcionalidad similar en el nivel 1, este DCM tendría que incrustarse en algún lugar en la red. Por ejemplo, cuando un nuevo dispositivo se añade a una red, el nivel 1 requiere que al menos un dispositivo diferente comprenda un DCM incrustado compatible con el nuevo dispositivo. En comparación, el nivel 2 sólo requiere que un dispositivo proporcione un entorno de tiempo de ejecución para el DCM cargado obtenido desde el nuevo dispositivo.

El concepto de cargar y ejecutar el código de bytes también proporciona la posibilidad para aplicaciones específicas del dispositivo denominadas aplicaciones de control de dispositivo. A través de estas aplicaciones un fabricante de dispositivos puede proporcionar al usuario una manera de controlar características especiales de un dispositivo sin la necesidad de estandarizar todas las características en HAVi. La aplicación se proporciona mediante un DCM en el código de bytes HAVi y puede cargarse e instalarse mediante cada dispositivo FAV en la red.

Para más información se hace referencia a la especificación HAVi y la especificación IEEE 1394 que están disponibles en el dominio público. La especificación de núcleo HAVi se ha puesto a disposición en la web en, por ejemplo, http://www.sv.philips.com/news/press, y se incorpora en el presente documento por referencia.

Objetivo de la invención

Tal como se describió anteriormente, una aplicación de control debe conocer un conjunto de mensajes de la representación abstracta con el fin de controlar la funcionalidad de un dispositivo. Se usan dos enfoques básicos para garantizar esta compatibilidad: módulos estandarizados/ incrustados y módulos que pueden cargarse. En cuanto a la estandarización: un conjunto de órdenes soportado por un tipo particular de una funcionalidad se define por la especificación. Véanse, por ejemplo, las definiciones para un sintonizador en la especificación HAVi. En cuanto a los módulos que pueden cargarse: un componente de GUI o una aplicación instalada en un dispositivo que puede controlarse puede cargarse desde el dispositivo controlable y puede ejecutarse en el entorno de tiempo de ejecución proporcionado por el controlador HAVi anfitrión. Sin embargo, ninguno de los procedimientos permite que aplicaciones de terceros o el propio entorno de tiempo de ejecución determinen la semántica de las propiedades de un dispositivo nuevo o un dispositivo con funcionalidades desconocidas hasta el momento. Esto implica que en el enfoque actual se requiere no obstante un esfuerzo de estandardización constante para nuevos tipos de dispositivos. En el caso de aplicaciones o controles de GUI que pueden cargarse es el dispositivo, no el controlador más "inteligente", quien se encarga de determinar las modalidades de control o interacción de usuario. Por ejemplo, si el tiempo de ejecución proporcionara un nuevo tipo de interacción de usuario, tal como control de voz, la aplicación de control cargada no podría usarlo si no se hubiera diseñado para ese tipo de entrada. La realización de pruebas para determinar la compatibilidad con nuevos dispositivos presenta un verdadero desafío para los desarrolladores y diseñadores, puesto que las nuevas funcionalidades y la IU aún no se han definido (por definición), ni mucho menos desarrollado.

Es por tanto un objetivo de la invención proporcionar una solución a este problema de compatibilidad que se producirá cuando en una red doméstica aparezcan funcionalidades nuevas (es decir, desconocidas hasta el momento), en el que el control de recursos se basa en representaciones abstractas que pueden cargarse o previamente instala-
das.

El documento "WARMINER, P.; KARAM, K.Z.: ``Proposal for a new domestic automation networking system'' CONSUMER ELECTRONICS, IEEE TRANSACTIONS ON, [Online] vol. 44, n.º 3, 2 de junio de 1998 (02/06/1998), - 4 de junio de 1998 (04/06/1998) páginas 612-616, XP002142896 Newcastle upon Tyne Univ., Reino Unido, ISSN: 0098-3063" describe permitir el control de un dispositivo a través de una red. El dispositivo proporciona un programa de aplicación y una interfaz de hardware. Una vez conectado, el dispositivo se convierte en nodo de objeto. El objeto contiene un perfil de objeto interno, que describe los parámetros de operación y la función del objeto. El perfil contiene un código de tipo que permite al dispositivo reconocer qué tipo de dispositivo es. El tipo decide posteriormente la operación del nodo.

Sumario de la invención

Con este fin la invención proporciona un sistema de procesamiento de información tal como se define en la reivindicación 1, un procedimiento para permitir el control tal como se define en la reivindicación 10 y un dispositivo electrónico tal como se define en la reivindicación 11. Un sistema de red doméstica comprende un dispositivo electrónico y un controlador acoplado al dispositivo. El dispositivo expone una representación abstracta de su funcionalidad al controlador. El controlador permite controlar la funcionalidad del dispositivo a través de la interacción con la representación abstracta. La representación abstracta especifica una modalidad para controlar la funcionalidad. Bajo el control de la modalidad especificada, el sistema asocia el control de la funcionalidad con una capacidad de control modalmente compatible del controlador. La modalidad expuesta puede ser, por ejemplo, "valor booleano", "flotante", "matriz de enteros".

El término "modalidad" se refiere a un atributo que designa el carácter de la capacidad de control de la funcionalidad. En la invención, la modalidad de la funcionalidad se correlaciona con una capacidad modalmente compatible del controlador sin que el controlador tenga que saber realmente de qué trata la funcionalidad del dispositivo. Por ejemplo, supóngase que la modalidad es semánticamente un valor booleano. La propiedad de control del valor booleano puede correlacionarse entonces con un elemento de IU que tiene un carácter booleano y asume uno de dos estados tales como un interruptor "encendido/apagado" o palanca "alto/bajo". Cuando el usuario interacciona entonces con este elemento, la funcionalidad correlacionada con el mismo se pone en uno de los dos estados. En un sistema HAVi, la representación abstracta se carga, preferiblemente incluyendo una IU (por ejemplo para el control de voz) o GUI, y el usuario recibe un contexto para determinar las consecuencias de sus interacciones con la IU. En caso de que la modalidad sea un conjunto de valores discretos, la propiedad de control puede correlacionarse con un elemento de GUI que puede asumir uno de tres o más estados discretos tales como un botón para la selección de un canal en un dispositivo, para la selección entre múltiples dispositivos, etc. Si la modalidad especificada es semánticamente un rango de valores de punto flotante, puede realizarse una correlación con una característica de control variable de forma continua, por ejemplo, el brillo de una imagen en una pantalla o el volumen de sonido. En otro ejemplo, la modalidad especificada es semánticamente una matriz. Una matriz comprende más de un único componente. Por ejemplo, así una matriz de valores booleanos podría correlacionarse con una agrupación de elementos de GUI para implementar, por ejemplo, una selección de menú entre diferentes dispositivos o una lista de casillas de verificación. Una matriz de modalidades de punto flotante podría correlacionarse con una agrupación de elementos de GUI que representan elementos de deslizamiento, por ejemplo, para ajustar los ángulos de una cámara y los factores de zoom de las cámaras en el sistema de seguridad doméstica que se controla a través de la red doméstica. Obsérvese que el controlador no necesita tener conocimiento acerca de la funcionalidad o las funcionalidades del dispositivo que está controlándose. Todo lo que necesita hacer es someter una funcionalidad a una aplicación de control basándose en la semántica de su modalidad.

Obsérvese que la DDI de la arquitectura HAVi especifica la manera en la que un dispositivo se controla a través de widgets de GUI. El término "widget" se usa de diversas maneras en el campo de los ordenadores. Un widget es un elemento de una GUI que visualiza información para que un usuario interaccione con el sistema operativo y programas de aplicación. Los widgets incluyen iconos, menús desplegables, botones, casillas de selección, indicadores de progreso, marcas de verificación de activación/desactivación, barras de desplazamiento, ventanas, bordes de ventana para redimensionar la ventana, botones de palanca, etc. para visualizar funcionalidades de interactividad de usuario. En programación, un widget también hace referencia al programa pequeño que se escribe con el fin de describir el aspecto de un widget particular, cómo se comporta y cómo interactúa en respuesta a acciones de usuario. La mayoría de los sistemas operativos incluyen un conjunto de widgets personalizados que puede incorporar un programador en una aplicación, especificando cómo debe comportarse. Pueden crearse widgets nuevos. La mayoría de los lenguajes de desarrollo de aplicaciones hoy en día, tales como Java y Tcl, vienen con una biblioteca lista de widgets que puede incorporar y modificar un programador. Usando Visual Basic de Microsoft, un widget puede implementarse como o parte de un control ActiveX, etc. (Véase, por ejemplo, www.whatis.com). La IU no necesita conocer la funcionalidad del dispositivo particular que va a controlarse, sólo necesita saber qué widget presentar. Los widgets determinan cómo está estructurada la IU. Ahora, si el paradigma de IU difiere de versiones anteriores o si no existe un widget dedicado (por ejemplo, nuevo control de voz o GUI en 3D) en el entorno disponible, la invención no obstante permite controlar el dispositivo proporcionando los controles de una manera diferente, aunque semánticamente equivalente. El programa de asistente de IU o gestor de widget (denominado de forma más genérica entidad/módulo/servicio/aplicación de configuración) puede combinar una IU funcional por medio de una correlación de los elementos de IU disponibles con la descripción semántica de la modalidad en la representación abstracta del dispositivo.

La entidad de configuración monitoriza el aspecto de nuevos dispositivos. Si aparece un nuevo dispositivo, la entidad comprueba si hay una GUI disponible para este tipo de dispositivo. Si hay una disponible, la entidad la recupera. Si no, la entidad de configuración crea una representación de IU y la pone a disposición del controlador. La entidad de configuración obtiene la descripción de objeto y a continuación activa un correlacionador con la descripción, que dice básicamente: "Esto es una propiedad, ahora dame un elemento de IU asociado". Esto puede realizarse automáticamente o con la intervención del usuario. El correlacionador es a modo de asistente, por ejemplo, una utilidad dentro de una aplicación que ayuda a usar la aplicación para realizar una tarea particular.

Los modelos de software basados en componentes han llegado a estar ampliamente disponibles y a ser aceptados en la industria de desarrollo de software. Tecnologías tales como HTML, COM, DCOM, ActiveX, Java, JavaBeans proporcionan a los desarrolladores una amplia gama de componentes de GUI listos para usar. La semántica de tales componentes se entiende bien por los usuarios finales y permite crear aplicaciones sofisticadas en un periodo de tiempo corto.

Cuando los fabricantes introducen nuevos dispositivos compatibles con HAVi con nuevas características, pueden modificar el código de bytes transportado con el dispositivo. Las modificaciones añadidas al código de bytes representan las nuevas funcionalidades y nuevas características proporcionadas por el dispositivo. De manera similar, pueden añadirse nuevos elementos de IU a la representación de IU disponible del dispositivo. La arquitectura HAVi permite a los fabricantes de dispositivos especificar GUI que pueden proporcionarse en una diversidad de aparatos de visualización, oscilando desde representaciones de sólo texto hasta representaciones de gráficas de nivel elevado. La invención facilita el desarrollo y la entrada en el mercado de sistemas de procesamiento de información tales como el equipo de entretenimiento doméstico basado en HAVi de sistemas de automatización del hogar.

La invención se trata anteriormente dentro del contexto de una arquitectura HAVi. La aplicabilidad de la invención no está limitada a sistemas basados en HAVi. Como otro ejemplo, considérese un modelo de cliente-servidor basado en tecnología de componente objeto modelo (COM) de Microsoft. Para más información, se hace referencia a, por ejemplo, la versión 0.9 de la especificación de componente objeto modelo de octubre de 1995 tal como se proporciona por Microsoft, incorporada en el presente documento por referencia. COM está orientada a objetos. Un objeto tiene propiedades que representan funcionalidades de control de un dispositivo de electrónica asociado expuesto a una aplicación de software. Un cambio de estado de un objeto como consecuencia de un evento desde el exterior se pasa a la aplicación de software. La aplicación manipula los objetos cambiando o ajustando sus propiedades. Cuando la aplicación modifica una propiedad de un objeto asociado con un determinado dispositivo físico se envía una orden al dispositivo asociado.

COM es un mecanismo genérico que permite a las aplicaciones comunicarse de una manera consistente y es una estructura para desarrollar y soportar objetos de componentes de programa. Proporciona capacidades similares a las definidas en CORBA (arquitectura común de intermediarios en peticiones a objetos), la estructura para la interoperación de objetos distribuidos en una red. La tecnología OLE (vinculado e incrustado de objetos) proporciona servicios para el documento compuesto que ven los usuarios en su pantalla, COM proporciona los servicios subyacentes de servicios de eventos y negociación de interfaz (situar un objeto en el servicio como resultado de un evento que ocurrió a otro objeto). En esta implementación los clientes se modelan como objetos de automatización OLE (representaciones abstractas) que usan propiedades para exponer controles y eventos para indicar cambios de estado. La automatización OLE es una tecnología COM que permite secuencias de comandos y un enlace tardío de clientes a servidores. La automatización OLE proporciona comunicación con otros programas a través de llamadas a características (órdenes y consultas) que los programas han puesto a disposición para su uso externo. Antes de usar un objeto, una aplicación de cliente tiene que obtener en primer lugar el puntero de interfaz del objeto. El puntero de interfaz se obtiene a través del directorio de la red vinculando el nombre del objeto o enumerando dispositivos. Pueden usarse API de COM convencionales para enlaces de moniker. Pueden obtenerse referencias a objetos llamando GetObject o CoGetObject con una cadena que especifica el nombre o ID del dispositivo deseado. La aplicación puede manipular entonces el objeto ajustando o recuperando sus propiedades. Cuando una aplicación ajusta o modifica una propiedad de un objeto que se corresponde con un dispositivo, la operación de ajuste de propiedad u operación de modificación se convierte en una orden que se envía a través de la red al dispositivo relevante. Los objetos pueden diferir en cuanto a la implementación, aunque exponen un modelo similar basado en propiedades a aplicaciones de cliente que se ejecutan en un controlador, por ejemplo, un PC con un sistema operativo basado en Windows (por ejemplo, Windows95, Windows98, WinCE, Windows NT). Por consiguiente, una aplicación de control o un elemento de GUI debe conocer el conjunto de propiedades del dispositivo controlable.

De nuevo, en la invención, se hace que los objetos expongan sus propiedades de manera que la modalidad de control de la funcionalidad de la propiedad pueda asociarse con una capacidad de control modalmente compatible del controlador bajo el control de sólo esta modalidad.

Para aún otro ejemplo de una tecnología en la que la invención proporciona una ventaja respecto al estado de la técnica considérese Jini de Sun Microsystems. Jini es una tecnología de software basada en Java que ayuda a interconectar PC y periféricos en la red. Cuando se conecta a una red, un dispositivo habilitado para Jini difundirá su presencia. Los clientes de red que están listos para usar ese dispositivo pueden solicitar el software necesario desde el dispositivo, evitando un servidor o un administrador de red. Esta arquitectura se construye sobre una red existente. Se supone que la propia red se ha configurado de antemano. Las interfaces de programación se identifican por el tipo de sistema del lenguaje de programación Java, y los servicios pueden encontrarse en un servicio de consulta pidiendo los que soportan una interfaz particular. Encontrar un servicio de esta manera garantiza que el programa que está buscando el servicio sabrá cómo usar ese servicio, porque ese uso se define por el conjunto de procedimientos que se definen por el tipo. El conjunto de procedimientos se especifican previamente con el fin de tener una cooperación significativa entre los componentes. En la invención, es la modalidad la que determina una correlación con controles adecuados sin que sea necesario ningún procedimiento previamente especificado.

La invención se refiere también a un procedimiento para permitir el control de una funcionalidad de un dispositivo electrónico a través de un controlador. El procedimiento comprende permitir proporcionar una representación abstracta de la funcionalidad al controlador; permitir que la representación abstracta exponga una modalidad de control de la funcionalidad para permitir que el controlador controle la funcionalidad a través de la interacción con la representación abstracta; y bajo el control de la modalidad expuesta permitir asociar el control de la funcionalidad con una capacidad de control modalmente compatible del controlador. La acción de permitir se refiere a, por ejemplo, proporcionar las herramientas de software necesarias al usuario final como un paquete de software que se proporciona con el dispositivo o con el sistema de automatización del hogar completo, o se descarga a través de Internet, o a actividades por parte de un proveedor de servicios o el propio usuario final mientras establece la configuración de control.

La invención facilita también una personalización de la IU desde el punto de vista del fabricante, no sólo para sistemas basados en oficina o domésticos, sino también para coches por ejemplo. La IU de componentes tales como controles de radio, controles de reproductor de CD, controles de navegación, controles de acondicionamiento de aire, etc. pueden personalizarse a través de un mecanismo de acoplamiento semántico tal como se especificó anteriormente, creando así una capacidad de mejora incorporada. De manera similar la presentación de información de gestión del coche y el motor (tacómetro, contador de revoluciones, odómetro, temperatura de motor, presión de aceite, etc.) puede personalizarse acoplando semánticamente la funcionalidad de presentación de información con un esquema deseado.

Breve descripción de los dibujos

La invención se explica a modo de ejemplo y con referencia a los dibujos adjuntos, en los que:

la figura 1 es un diagrama de un sistema de red doméstica en la invención; y

la figura 2 es un diagrama que ilustra la correlación modal.

A lo largo de todas las figuras, los mismos números de referencia indican características similares o correspondientes.

Realizaciones preferidas

La figura 1 es un diagrama de bloques de un sistema 100 de procesamiento de información de la invención. El sistema 100 comprende un dispositivo 102 electrónico y un controlador 104 acoplado al dispositivo, por ejemplo, a través de una red 106. El sistema 100 puede comprender más dispositivos electrónicos, aunque éstos no se muestran para que el dibujo no sea confuso. El dispositivo 102 expone al controlador 104 una representación 108 abstracta. La representación 108 se carga, por ejemplo, en el controlador 104 tras la conexión funcional del dispositivo 102 a la red 106. La representación 108 podría instalarse también en el controlador 108 de otra manera, por ejemplo, a través de Internet o por parte del usuario a través de un disquete. El controlador 104 controla una funcionalidad del dispositivo 102 a través de la aplicación 110 de software que interactúa con la representación 108. La aplicación 110 permite además al usuario controlar el sistema 100 a través de un dispositivo de interfaz de usuario, por ejemplo, un dispositivo 112 de GUI. La GUI 112 tiene una representación 114 abstracta que establece una interfaz con la aplicación 110. La interfaz 114 se ha cargado en el controlador 104 o la ha instalado el fabricante o el usuario.

Supóngase que el dispositivo 112 de GUI o el controlador 104 no tiene ningún conocimiento previo acerca de la funcionalidad del dispositivo 102. Es decir, el dispositivo 102 es una caja negra desde el punto de vista del dispositivo 112 y el controlador 104. La representación 108 especifica ahora una modalidad del control de la funcionalidad. Es decir, la representación 108 tiene un atributo que indica el carácter del control para la funcionalidad. La representación 108 expone la funcionalidad del dispositivo a la aplicación 110 comprendiendo por ejemplo las siguientes entidades: nombre, tipo, valor(es) permitido(s), nombre de visualización. En el presente documento, "nombre" es una etiqueta a través de la que puede accederse a la funcionalidad por la aplicación 110. "Tipo" especifica la modalidad (por ejemplo, valor booleano, número entero, flotante, matriz) de control para la funcionalidad del dispositivo 102.
"Valor(es)" especifica uno (o más) valor(es) numérico(s) que puede asumir la modalidad con respecto a esta funcionalidad. "Nombre de visualización" indica cómo debe representarse la funcionalidad del dispositivo 102 en la GUI 112 si el "nombre de visualización" es diferente de "nombre".

Por ejemplo, el dispositivo 102 tiene un nombre: "sintonizador" y su funcionalidad tiene un nombre: "canal". El tipo de dispositivo 102 se especifica como "número entero". Los valores para esta funcionalidad se especifican como una lista de valores numéricos discretos 0, 1, 2, ..., 5, 34, 56, ..., 89. Tras la recuperación de esta descripción de la funcionalidad, el controlador 110 genera un fragmento de secuencia de comandos de control, por ejemplo, en la siguiente secuencia:

a) obtener el nombre del dispositivo -> (sintonizador);

b) obtener el nombre de la funcionalidad -> (canal);

c) obtener el tipo de funcionalidad -> (número entero);

d) obtener el/los valor(es) de funcionalidad -> (0, 1, 2, ..., 5, 34, 56, ..., 89);

e) generar un código de secuencia de comandos de prueba usando las reglas de secuencia de comandos del sistema (tal como automatización OLE, Visual Basic Script, JavaScript, etc.) y las cantidades anteriores recuperadas:

para cada valor en valores

Sintonizador.canal = valor

endfor

Esta secuencia de comandos de control permite someter a prueba la capacidad de control de la funcionalidad.

De una manera similar, el controlador 104 genera una secuencia de comandos de control para asociar las modalidades de control tal como se presentan por la representación 108 abstracta con modalidades semánticamente similares disponibles en el sistema 100, por ejemplo, tal como se proporcionan por la interfaz 114 GUI. El controlador lo lleva a cabo con la ayuda de un programa de gestión de widget o un programa asistente de IU. Obsérvese que la correlación se determina mediante la modalidad especificada. Esto se explica adicionalmente con referencia a la figura 2.

La figura 2 es un diagrama que ilustra la correlación modal. Tal como se mencionó anteriormente, la representación 108 proporciona determinada información clave en cuanto al nombre del dispositivo, el tipo, los valores y el nombre de visualización. El dispositivo 112 de GUI tiene una representación 114 abstracta que especifica las capacidades modales del dispositivo 112 de control. Estas capacidades se instalan usando componentes de software de IU estandarizados.

Por ejemplo, el dispositivo 112 puede dejar al usuario ajustar un determinado parámetro en una escala 202 continua como si la cantidad asumiera un valor de punto flotante. Una funcionalidad que tiene un tipo "flotante" se correlaciona con este elemento 202 de GUI. El elemento 202 de GUI se representa en este caso de forma gráfica mediante un elemento de deslizamiento. En una pantalla táctil el usuario puede ajustar la posición del elemento de deslizamiento arrastrándolo a la posición deseada. De manera alternativa, si la IU se representa en una pantalla de visualización de un aparato de televisión (no mostrado), el usuario puede hacer clic sobre el elemento de deslizamiento y arrastrarlo con un ratón (no mostrado) o un teclado inalámbrico (no mostrado) u otro dispositivo de control (no mostrado). Si la IU tiene un botón rotatorio físico o un elemento de deslizamiento físico, el valor flotante puede correlacionarse con esta característica de control. La propia representación gráfica del elemento 202 de GUI puede, aunque no necesita, formar parte de la representación 108 abstracta. Una funcionalidad que puede correlacionarse así con el elemento 202 es, por ejemplo, el volumen de sonido o el brillo de la iluminación ambiente.

Si una funcionalidad controlable del dispositivo 102 tiene una modalidad de "matriz de enteros", el control de esta funcionalidad se correlaciona con el elemento 204 de GUI. El elemento 204 de GUI tiene una pluralidad de botones 206 seleccionables que pueden desplazarse a y fuera de la vista a través de flechas 208 de selección. Un ejemplo de una matriz de enteros es un grupo de valores numéricos indicativos de una selección de canales de televisión o CD en un carrusel. Si una funcionalidad controlable del dispositivo es un valor booleano, los controles se correlacionan con un elemento 210 de GUI a través del que el usuario puede seleccionar uno de dos estados (encendido-apagado; activar-desactivar; alto-bajo, etc.). Si una funcionalidad controlable comprende una matriz de valores booleanos, puede correlacionarse con el elemento 212 de GUI que tiene una pluralidad de teclas 214 programables y que es funcionalmente equivalente a un widget de casilla de verificación.

Con el fin de ayudar al usuario a identificar determinados controles, se proporciona el elemento "nombre de visualización" en la representación 108. "Nombre de visualización" es la etiqueta (por ejemplo, el nombre en caracteres alfanuméricos, o un icono) que va a visualizarse en la GUI 112 para proporcionar el contexto para el usuario. Al usuario se le permite así interpretar la semántica de los controles. Casillas de nombre de visualización se indican mediante los números de referencia 216, 218, 220 y 222.

Se hace referencia al expediente n.º PHA 23,492, presentado el 02/09/98 en nombre de Yevgeniy Shteyn para "LOW DATA-RATE NETWORK REPRESENTED ON HIGH DATA-RATE HAVi-NETWORK", con número de serie estadounidense 09/146,020, incorporado en el presente documento por referencia. Este documento se refiere a un sistema de automatización del hogar basado en PC que usa una capa de transporte de baja tasa de transmisión de datos y componentes de software basados en COM para el control de dispositivos en una red de automatización del hogar. El sistema de automatización del hogar se fusiona con una red HAVi basada en mensajería que usa IEEE 1394 como una capa de transporte de alta tasa de transmisión de datos. La red HAVi controla el equipo de audio/vídeo en un sistema de entretenimiento doméstico. Los dispositivos y servicios de automatización del hogar se registran como elementos compatibles con HAVi con el dispositivo FAV o IAV de la red HAVi. Los recursos de automatización del hogar (dispositivos y servicios) tienen tanto interfaces de automatización OLE de COM como interfaces compatibles con HAVi para permitir el control del sistema de automatización del hogar desde la red HAVi.

Se hace referencia al expediente n.º PHA 23,488, presentado el 13/08/98 en nombre de Lawrence Freeman para "HOME-NETWORK AUTOCONFIGURATION", con número de serie estadounidense 09/133,622, incorporado en el presente documento por referencia. Este documento se refiere a una configuración automática de PC en una red, preferiblemente una red doméstica, con el fin de compartir recursos registrados en los PC individuales. Los servicios y recursos locales de un PC se registran con el otro PC y viceversa. El registro oculta si un servicio o recurso es remoto o local. En el uso operacional de la red, un recurso o servicio local de un PC es direccionable desde el PC remoto como si fuera local de este último.

Se hace referencia al expediente n.º PHA 23,438, presentado el 30/06/98 en nombre de Yevgenyi Shteyn y Gregory Gewickey para "DYNAMIC DE-REGISTERING OF DEVICES IN SYSTEM WITH MULTIPLE COMMUNICATION PROTOCOLS", con número de serie estadounidense 09/107,525, incorporado en el presente documento por referencia. Este documento se refiere a un sistema de procesamiento de información que tiene subsistemas electrónicos primero y segundo, y medios de control para controlar los subsistemas. Al menos el primer subsistema tiene una representación de software registrada con los medios de control. Los medios de control cambian un estado del primer subsistema interactuando con la representación de software. Los subsistemas primero y segundo pueden interactuar también directamente entre sí sin que se impliquen los medios de control. Para evitar conflictos, al menos el primer subsistema puede darse de baja con los medios de control para deshabilitar funcionalmente su representación de software en los medios de control.

Se hace referencia al expediente n.º PHA 23,169, presentado el 15/10/96 en nombre de Paul Chambers y Saurabh Srivastava para "TASK-DRIVEN DISTRIBUTED MULTIMEDIA CONSUMER SYSTEM", con número de serie estadounidense 08/731,624, incorporado en el presente documento por referencia. Este documento se refiere a un sistema de control que comprende múltiples dispositivos de electrónica de consumo y medios de control orientados a tareas acoplados a los dispositivos para controlar una interacción entre los dispositivos. Los medios de control actúan en respectivas representaciones de software de cada dispositivo de consumo respectivo de los dispositivos de consumo. Encapsulando la complejidad variable de la tarea dentro de una representación de software, puede hacerse tan simple o tan sofisticada como sea necesario para llevar las capacidades hasta un nivel común. Puesto que el nivel de interfaz es común a los dispositivos, las aplicaciones pueden manipular de manera uniforme los dispositivos que realizan niveles muy diferentes de sofisticación.

Claims (16)

1. Sistema (100) de procesamiento de información que comprende un dispositivo (102) electrónico y un controlador (104, 112) para el control de una funcionalidad del dispositivo, en el que:

- se proporciona al controlador una representación (108) de la funcionalidad;

- el controlador permite controlar la funcionalidad a través de la interacción con la representación;

caracterizado porque en el sistema

- dicha representación es una representación abstracta,

- la representación expone una modalidad para controlar la funcionalidad; y

- la modalidad determina asociar el control de la funcionalidad con una capacidad de control modalmente compatible del controlador sin que el controlador sepa cuál es la funcionalidad.

\vskip1.000000\baselineskip

2. Sistema según la reivindicación 1, en el que la modalidad se especifica semánticamente como un valor (210) booleano.

3. Sistema según la reivindicación 1, en el que la modalidad se especifica semánticamente como un conjunto de valores (206) discretos.

4. Sistema según la reivindicación 1, en el que la modalidad se especifica semánticamente como un rango de valores (202) de punto flotante.

5. Sistema según la reivindicación 1, en el que la modalidad se especifica semánticamente como una matriz (206, 214).

6. Sistema según la reivindicación 1, en el que la modalidad se especifica semánticamente como otra representación abstracta.

7. Sistema según la reivindicación 1, en el que la capacidad de control está incorporada en una GUI (112).

8. Sistema según la reivindicación 1, que comprende una red (106) de automatización del hogar.

9. Sistema según la reivindicación 8, que comprende una red basada en HAVi.

10. Procedimiento para permitir el control de una funcionalidad de un dispositivo (102) electrónico a través de un controlador (104, 112) para el control de la funcionalidad, comprendiendo el procedimiento:

- permitir proporcionar una representación (108) de la funcionalidad al controlador;

- permitir al controlador controlar la funcionalidad a través de la interacción con la representación;

caracterizado porque el procedimiento comprende

- proporcionar dicha representación que es una representación abstracta,

- permitir que la representación abstracta exponga una modalidad para controlar la funcionalidad para dicha acción de permitir al controlador controlar la funcionalidad; y

- bajo el control de la modalidad expuesta permitir asociar el control de la funcionalidad con una capacidad de control modalmente compatible del controlador sin que el controlador sepa cuál es la funcionalidad.

\vskip1.000000\baselineskip

11. Dispositivo (102) electrónico para su uso con un controlador para el control de una funcionalidad controlable del dispositivo, en el que:

- el dispositivo comprende una representación (108) de la funcionalidad para permitir al controlador controlar la funcionalidad a través de la interacción con la representación;

caracterizado porque

- dicha representación es una representación abstracta,

- la representación abstracta puede exponer una modalidad para controlar la funcionalidad al controlador;

- la modalidad controla asociar el control de la funcionalidad con una capacidad de control modalmente compatible del controlador sin que el controlador sepa cuál es la funcionalidad.

\vskip1.000000\baselineskip

12. Dispositivo según la reivindicación 11, en el que la modalidad se especifica semánticamente como un valor (210) booleano.

13. Dispositivo según la reivindicación 11, en el que la modalidad se especifica semánticamente como un conjunto de valores (206) discretos.

14. Dispositivo según la reivindicación 11, en el que la modalidad se especifica semánticamente como un rango de valores (202) de punto flotante.

15. Dispositivo según la reivindicación 11, en el que la modalidad se especifica semánticamente como una matriz (206, 214).

16. Dispositivo según la reivindicación 11, en el que la modalidad se especifica semánticamente como otra representación abstracta.