MÓDULO Y MÉTODOS PARA LA INTERCONEXIÓN DE EQUIPOS HETEROGÉNEOS CON RECURSOS LIMITADOS POR MEDIO DE MIDDLEWARES DE COMUNICACIONES ORIENTADOS A OBJETO.

Módulo y métodos para la integración de objetos distribuidos en sistemas empotrados que pueden ser implementados mediante dos alternativas complementarias:

software empotrado y síntesis de hardware. El método permite fabricar dispositivos para sensorización y actuación remota más baratos y pequeños, manteniendo además un muy alto grado de interoperabilidad con el middleware de comunicaciones, lo que facilita sensiblemente sus posibilidades de operación y su integración con otros sistemas preexistentes.

Tipo: Patente de Invención. Resumen de patente/invención. Número de Solicitud: P200803715.

Solicitante: UNIVERSIDAD DE CASTILLA-LA MANCHA.

Nacionalidad solicitante: España.

Inventor/es: LOPEZ LOPEZ,JUAN CARLOS, RINCON CALLE,FERNANDO, MOYA FERNANDEZ,FRANCISCO, BARBA ROMERO,JESUS, VILLA ALISES,DAVID, VILLANUEVA MOLINA,FELIX JESUS.

Fecha de Publicación: 20 de Marzo de 2013.

Clasificación Internacional de Patentes:

G06F9/54 FISICA. › G06 CALCULO; CONTEO. › G06F PROCESAMIENTO ELECTRICO DE DATOS DIGITALES (sistemas de computadores basados en modelos de cálculo específicos G06N). › G06F 9/00 Disposiciones para el control por programa, p. ej. unidades de control (control por programa para dispositivos periféricos G06F 13/10). › Comunicación entre programas.
H04Q9/00 ELECTRICIDAD. › H04 TECNICA DE LAS COMUNICACIONES ELECTRICAS. › H04Q SELECCION (conmutadores, relés, selectores H01H; redes de comunicación inalámbricas H04W). › Disposiciones en sistemas de control a distancia o de telemetría para llamar selectivamente a una subestación a partir de una estación principal, subestación en la cual un aparato deseado es escogido para aplicar una señal de control o para obtener valores medidos.

PDF original: ES-2375026_A1.pdf

Fragmento de la descripción:

Módulo y métodos para la interconexión de equipos heterogéneos con recursos limitados por medio de middlewares de comunicaciones orientados a objeto.

Antecedentes de la invención

Campo técnico

La presente invención tiene relación con el sector técnico del control automático de procesos industriales, telecontrol y telemedida y miniaturización de dispositivos detectores y de accionamiento. También tiene una importante relación con los sistemas de Domótica, Inmótica, Pervasive computing (Informática penetrante) y Ambient intelligence (Inteligencia ambiental).

Algunos ejemplos de posibles aplicaciones de la presente invención son:

• Redes de dispositivos de bajo coste para la automatización de tareas en el hogar, la oficina, explotaciones agropecuarias, instalaciones industriales, etc.

• Integración de dispositivos para la provisión de servicios de valor añadido independientes de tecnología (vídeo-vigilancia, prevención de accidentes, monitorización, tele-asistencia, etc.).

• Implementación de dispositivos hardware que interactúan con software estándar sin necesidad de controladores o firmware específicos.

Descripción de la técnica relacionada

Tradicionalmente, la palabra middleware (software intermedio) se define como la capa de software situada entre el sistema operativo y las aplicaciones; su finalidad es proporcionar los mecanismos para la comunicación entre elementos de un sistema distribuido.

En general, cualquier middleware define interfaces de programación, protocolos de comunicación, y un modelo de información para objetos y servicios. Todo ello para permitir la construcción de aplicaciones distribuidas heterogéneas. Algunos ejemplos de este tipo de plataformas son CORBA (véase referencia [1]), ZeroC Ice (referencia [2]), Web Services (referencia [3]), Jini (referencia [4]), etc.

Muchos de los middlewares para sistemas distribuidos heterogéneos permiten también que aplicaciones escritas en diversos lenguajes y sobre diferentes plataformas puedan interactuar, a base de definir de forma precisa tanto los protocolos de comunicación como las interfaces de programación para cada lenguaje.

Las ventajas de las técnicas de orientación a objetos son bien conocidas en arquitecturas de software, y los middlewares distribuidos orientados a objeto tienen una larga historia de aplicaciones exitosas en muchas áreas de negocio de las tecnologías de la información. Además, muchas de las plataformas distribuidas orientadas a objetos están apoyadas por la industria y sus herramientas, protocolos y servicios han crecido en consenso con ella. El gran número de aplicaciones desarrolladas otorgan a los servicios, protocolos y aplicaciones ciertas garantías de fiabilidad, fruto de la experiencia y es uso continuado en aplicaciones sensibles.

Muchas iniciativas previas se han marcado como objetivo la miniaturización de los middlewares existentes. Por ejemplo, el propio Object Management Group publicó la especificación MinimumCORBA (referencia [5]), una versión ligera de su popular arquitectura CORBA (referencia [1]). MinimumCORBA elimina las prestaciones más costosas del núcleo de comunicaciones manteniendo un buen grado de interoperabilidad con objetos CORBA estándar.

Tal como apunta la referencia [6], existen principalmente tres tipos de propuestas para miniaturización de objetos distribuidos:

1. Eliminar las prestaciones más costosas, pero manteniendo la generalidad. Esta primera estrategia es la utilizada por dynamicTAO (referencia [7]) y sus descendientes: LegORB (referencia [8]) y UIC-CORBA (referencia [9]). LegORB es un ORB modularizado que tiene la capacidad de poderse configurar dinámicamente. La librería monolítica de TAO (referencia [10]) se descompone en un conjunto de bloques funcionales independientes que se pueden omitir en la aplicación objetivo. Según sus autores un cliente CORBA ronda los 20 KB. en un HP Jornada 600 que utiliza Windows CE como S.O., y en un cliente CORBA sobre PalmPilot con PalmOS 3.0. ronda los 6 KB.

UIC (Universally Interoperable Core) define un esqueleto de middleware basado en componentes. Cada componente encapsula un conjunto reducido de características que se puede cargar dinámicamente dependiendo de la plataforma, dispositivo y red concreta. UIC, como su nombre indica, se puede usar para implementar núcleos de comunicaciones para diferentes middlewares además de CORBA, como Java RMI o DCOM. Un servidor CORBA estático ocupa aproximadamente 35 KB en un SH3 con Windows CE.

Un producto comercial similar es e*ORB (referencia [11]), un núcleo de comunicaciones con características de tiempo real capaz de ejecutarse en una HP iPAQ o en un DSP Texas Instruments TMS320C64X DSP.

Otro desarrollo representativo de esta primera estrategia es MicroQoSCORBA (referencia [12]), un núcleo de comunicaciones ajustable a medida que se puede generar a partir de una piezas predefinidas para implementar servidores y clientes para aplicaciones y dispositivos específicos (ha sido probado con SaJe (referencia [14]) y TINI (referencia [15]).

nORB (referencia [13) implementa un conjunto de protocolos de transporte como plug-ins, que incluyen protocolos específicos del entorno (ESIOP en tecnología CORBA). Comparte muchas ideas de from MicroQoSCORBA, como el hecho de utilizar una versión simplificada del protocolo GIOP estándar, llamada GIOPLite.

2. Adaptar el middleware a dispositivos específicos. Una muestra representativa de esta segunda estrategia para el desarrollo de middlewares ligeros es TINIORB (referencia [16]), un núcleo de comunicación basado en MinimumCORBA que ha sido adaptado especialmente para el dispositivo TINI de Dallas Semiconductor. PalmORB (referencia [17]) también es otro ejemplo de esta estrategia.

3. Utilizar una pasarela. Es decir, construir dispositivos con un protocolo propio muy simple, pero requiere que un dispositivo intermedio materialice la interoperabilidad con objetos del middleware estándar. Este es el enfoque usado en UORB (referencia [6]) y una de las alternativas de integración que propone SENDA (referencia [18]).

Otra propuesta interesante del mismo tipo es (referencia [19]). Este trabajo muestra cómo un conjunto de pequeños microcontroladores de 8 bits pueden aparecer como un conjunto de objetos CORBA. El host ejecuta un proxy para cada dispositivo conectado y las comunicaciones entre los dispositivos y el proxy utilizan un protocolo específico no estándar.

La presente invención está fundamentada en algunos artículos previos del grupo ARCO. En particular, los artículos [A] y [B] sientan las bases del concepto que sustenta la presente invención, Los artículos [C] y [D] describen un protocolo de descubrimiento de servicios que puede aplicarse a los módulos de la presente invención.

En cualquier caso, el presente texto introduce mejoras y aportaciones no triviales en el módulo, procedimientos de operación del mismo y en el método para su construcción y despliegue. Dichas aportaciones constituyen el núcleo de las reivindicaciones que se solicitan.

Descripción de la invención

Problemas técnicos planteados

Todos los trabajos previos siguen las mismas reglas básicas: Eliminar los métodos de invocación e instanciación dinámica, simplificar el lenguaje de definición de interfaces (OMG IDL en el caso de CORBA) , eliminar los tipos de datos complejos o grandes, eliminar algunos campos del protocolo de comunicaciones, eliminar o simplificar los tipos de mensajes usados en el protocolo, eliminar el soporte a referencias indirectas y a servicios comunes, modularizar el núcleo de comunicaciones e instanciar sólo aquellos componentes que realmente se necesitan en cada caso.

Es importante señalar que todos los núcleos de comunicaciones que se citan arriba requieren muchas utilidades de soporte adicionales: serialización de tipos de datos, primitivas de comunicaciones, sistema operativo, etc. De modo que los requerimientos... [Seguir leyendo]

Reivindicaciones:

1. Módulo para la interconexión de objetos distribuidos, que aloja al menos un objeto distribuido accesible por un middleware de comunicaciones de propósito general que mediante una máquina de estados finitos, reconoce mensajes de petición procedentes de clientes remotos convencionales y genera respuestas de acuerdo a los mensajes de petición, caracterizado porque está implementado en un circuito integrado específico y comprende:

• un elemento de cómputo implementado en un microcontrolador del circuito configurado para procesar los mensajes de petición y generar las respuestas,

• al menos un dispositivo de comunicaciones conectable a una red de datos a través del que el elemento de cómputo recibe los mensajes y envía respuestas hacia otros módulos o hacia objetos distribuidos remotos,

• una máquina de estados finitos específica para el reconocimiento de los mensajes necesarios para interactuar con los objetos distribuidos alojados en el módulo,

• un transductor para acceder al estado de uno o varios objetos hardware asociados a objetos distribuidos alojados en el módulo.

2. Módulo según la reivindicación 1, caracterizado porque el transductor se conecta a al menos un objeto hardware que es un sensor para leer su estado.

3. Módulo según la reivindicación 1, caracterizado porque el transductor se conecta a al menos un objeto hardware que es un actuador para leer o modificar su estado.

4. Módulo según la reivindicación 1, caracterizado porque el al menos un dispositivo de comunicaciones tiene definidos al menos un punto de acceso local para los objetos alojados en el módulo y al menos un punto de acceso remoto para interoperar con al menos un objeto distribuido remoto independientemente del tipo de objeto hardware asociado al objeto distribuido remoto.

5. Módulo según cualquiera de las reivindicaciones anteriores, caracterizado porque el dispositivo de comunicaciones envía mensajes de invocaciones asíncronas a un objeto distribuido remoto, configurado previamente, para informar del estado del objeto distribuido alojado en el módulo.

6. Módulo según cualquiera de las reivindicaciones anteriores, caracterizado porque la máquina de estados finitos está configurada para reconocer, dentro de los mensajes de peticiones, mensajes de invocaciones a objetos distribuidos alojados en el módulo y, de acuerdo a dichos mensajes de invocaciones, ordenar al elemento de cómputo la generación de una respuesta.

7. Módulo según cualquiera de las reivindicaciones anteriores, caracterizado porque el dispositivo de comunicaciones usa un canal de eventos, que es un objeto distribuido en el que se registran todos los objetos hardware y se vinculan al estado de un determinado objeto hardware asociado a un objeto distribuido alojado en el módulo, vinculando objetos hardware de igual o diferente fabricante y tecnología.

8. Módulo según la reivindicación 7, caracterizado porque el dispositivo de comunicaciones usa direccionamiento, que se selecciona entre broadcast, multicast o any-cast, para enviar un mensaje con datos procedentes de un objeto distribuido alojado en el módulo hacia todos, un grupo o al menos uno de los objetos remotos direccionados.

9. Módulo según cualquiera de las reivindicaciones anteriores, caracterizado porque el dispositivo de comunicaciones envía mensajes a través de una red de datos local a módulos o a objetos hardware conectados a otra red de datos remota.

10. Módulo según la reivindicación 9, caracterizado porque el dispositivo de comunicaciones del módulo se comunica con un módulo puente conectado a una red de datos remota para enviar mensajes de invocación a través del módulo puente a otro módulo que aloja un objeto distribuido asociado a cierto objeto hardware.

11. Módulo según la reivindicación 10, caracterizado porque aloja un objeto distribuido asociado un objeto hardware que se selecciona entre sensor y actuador conectado a una red de control industrial.

Patentes similares o relacionadas:

Sistema para el control de equipo hidráulico móvil, del 17 de Junio de 2020, de Magnetek Inc: Controlador configurable para operar diferentes equipos hidráulicos móviles, según los requisitos de diferentes aplicaciones, comprendiendo el controlador: […]

Dispositivo de monitorización y de mando para una unidad de puerta, del 6 de Mayo de 2020, de Fraba B.V: Dispositivo de monitorización y de mando para un elemento de puerta , como por ejemplo una puerta enrollable o seccional que puede moverse por medio […]

Sistema de control de acondicionamiento de aire para controlar múltiples dispositivos de acondicionamiento de aire, del 6 de Mayo de 2020, de DAIKIN INDUSTRIES, LTD.: Un sistema de control de aire acondicionado que comprende: dispositivos de aire acondicionado que están configurados para acondicionar el aire de un solo espacio y […]

Terminal de funcionamiento para acondicionador de aire, del 8 de Abril de 2020, de MITSUBISHI ELECTRIC CORPORATION: Un terminal de funcionamiento (100a, 100b) que es capaz de controlar un acondicionador de aire que incluye un dispositivo interior y un dispositivo […]

Método para configurar un contador de medición inteligente, del 1 de Abril de 2020, de Diehl Metering Systems GmbH: Método para configurar un contador en una red de medición inteligente a través del ajuste de sus parámetros de radio para la emisión de paquetes […]

Sistema de supervisión de un equipo de una aeronave, del 18 de Marzo de 2020, de Safran Electronics & Defense: Sistema de supervisión de un equipo de una aeronave que incluye un módulo electrónico principal y un módulo electrónico subordinado equipados […]

Sistema de medición y procedimiento de medición para la detección de variables sobre soportes planetarios de un engranaje planetario, del 19 de Febrero de 2020, de Flender GmbH: Sistema de medición para la detección de variables sobre soportes planetarios de un engranaje planetario que comprende al menos varios pasos de rueda planetaria […]

Sistema de irradiador de luz de bajo nivel de tipo adhesivo para la piel basado en tecnología PAMS que usa un dispositivo de comunicación móvil, del 19 de Febrero de 2020, de Color Seven.Co., Ltd: Un sistema de irradiador de luz de bajo nivel de tipo adhesivo para la piel basado en tecnología de modulación fotoactivada de músculos lisos (PAMS) usando […]