DESCRIPCIÓN

Sistema y método de gestión remota de dispositivos de naturaleza heterogénea en arquitecturas Machine-to-Cloud.

OBJETO DE LA INVENCIÓN

La invención se refiere a un sistema computacional y a un método para la gestión de dispositivos remotos heterogéneos a través de protocolos basados en Internet. La presente invención aporta una solución para trasladar a la nube la gestión remota de un parque distribuido de dispositivos de distinta naturaleza.

El método de gestión que implementa el sistema transforma los procesos de control, monitorización y supervisión desasistida de los distintos dispositivos conectados hacia esquemas ubicuos de Internet, independientemente del tipo de dispositivo, capacidades de comunicación del mismo, formatos de envío de datos o incluso política de asignación de dirección IP, ya sea ésta estática o dinámica. Así, se alcanza una independencia total de la naturaleza de los dispositivos que se conecten por medio de este sistema.

ESTADO DE LA TÉCNICA ANTERIOR

La invención que se propone define un método de gestión remota Machine-To- Cloud (M2CI) capaz de manejar dispositivos de distinta naturaleza de forma ubicua y la arquitectura que lo implementa.

Así, se extiende la arquitectura básica Machine-to-Machine (M2M) para dotarla de mayor flexibilidad para resolver, a menor coste, los problemas de interacción entre dispositivos de diferente naturaleza, minimizando los costes de comunicación y aprovechando las sinergias que se derivan de la creación de un entorno distribuido (cloud-computing) basado en comunicación a través de Internet.

La tecnología M2M se basa en la idea de que los dispositivos se vuelven mucho más valiosos cuando se encuentran conectadas a una red de comunicaciones, así como las redes de comunicaciones incrementan su valor conforme aumenta el número de dispositivos conectados a ellas. Sin embargo, la gran cantidad de dispositivos electrónicos distintos, tecnologías de comunicación y de software que se combinan para configurar un sistema M2M, hacen que la mayoría de soluciones del mercado sean "ad-hoc", es decir, muy condicionadas por el fabricante del dispositivo y por el objetivo que se persigue en cada caso concreto, hablamos por tanto de soluciones particulares y específicas que no podrían aplicarse nunca de forma general.

Con respecto a los sistemas de comunicación e intercambio de datos, en la actualidad existen numerosos formatos de intercambio de datos M2M, pero están desarrollados de forma particular para cada sector industrial. Cada uno está optimizado para su uso particular y su escenario de aplicación concreto. Esta multiplicidad de estándares supone un riesgo de incompatibilidad entre sistemas y aplicaciones y un freno a la expansión de las tecnologías M2M.

Otro aspecto a destacar es el referido a la sincronización del envío de datos por parte de los dispositivos M2M que, en la actualidad, suelen seguir una de las siguientes modalidades:

• Acceso de forma centralizada por parte de un servidor

• Acceso autónomo a la red de comunicaciones por parte del dispositivo

• Acceso a una determinada fecha y hora

El primer modo, control centralizado por un servidor, obliga al dispositivo M2M a estar permanentemente en contacto con el sistema central, con el consiguiente incremento de costes de comunicación y de consumo energético. Así mismo, se reduce la escalabilidad del sistema al tener que particularizar el tráfico de comunicaciones para cada dispositivo M2M individualmente. El segundo modo, no tiene en cuenta los aspectos de cobertura y carga de la red en el momento de la transmisión y puede poner en peligro la comunicación.

El tercer modo, establece de forma estática cuándo se debe realizar el envío o la recepción de datos en el dispositivo, lo cual perjudica la escalabilidad del sistema si un número creciente de dispositivos M2M se conectan a la vez para transmitir.

De esta forma, el uso individualizado de una de estas tres estrategias de comunicación tiene las limitaciones que se indican y que suponen problemas a la hora de escalar el sistema o de tener una comunicación o transmisión de forma dinámica sin riesgo.

A continuación se cita una selección de las patentes relacionadas con la presente invención y los inconvenientes que presentan en relación a la invención que se describe. Las patentes EP2192807, US8185629, US20100146117 realizan un análisis de la carga de la red para propiciar una comunicación más correcta de los dispositivos M2M. La patente US20130017827 se centra en la interoperatividad de los dispositivos M2M a través de la línea celular independizando la comunicación del proveedor de servicios. La patente US2013031 1554 establece un protocolo de comunicaciones para determinar si el dispositivo M2M está ubicado en el lugar correcto o su distancia supera un umbral, comunicando la incidencia si la hubiera. La patente WO2013072925 permite el seguimiento en tiempo real de parámetros y atributos de sensores que son enviados a un servidor de Cloud-Computing, donde se realiza el análisis de los mismos. La patente US20130016657 desarrolla una solución de servicios M2M utilizando la red celular a través del protocolo 3GPP Evolved Packet Core (EPC). Por último, la patente WO2013009345 establece un sistema de comunicación M2M basado en exclusiva en comunicación optimizada a través de SMS utilizando Radio Access Network (RAN). A continuación se describen los antecedentes indicados.

Si analizamos en detalle estos antecedentes, vemos que las patentes EP2192807, US8185629, US20100146117 no establecen un modelo que pueda adaptarse a diferentes contextos M2M, controlando exclusivamente la carga de la red para que se logre la comunicación y por consiguiente no resuelven cómo optimizar la información enviada con un protocolo flexible, compacto y eficiente. La patente US20130017827 se centra en la "capa de transporte" pero no establece una arquitectura de servicios M2M que, aparte de independizar del proveedor de servicios, resuelva de forma homogénea las necesidades de comunicación entre un sistema de información corporativo y cualquier servicio M2M. El protocolo desarrollado en la patente US2013031 1554 se centra exclusivamente en la determinación geográfica y envío de la posición de cada dispositivo M2M. Estos aspectos son ampliamente superados en la presente invención. La patente WO2013072925 plantea de forma genérica el tratamiento de información de sensorización remota con el objetivo de ser analizado, establece las estrategias de análisis con vista de incorporarlos en Platform as a service (PaaS), pero no desarrolla la arquitectura para el envío y recepción de datos eficiente y que permita a los dispositivos M2M funcionar en modo "servidor" o "cliente" según las necesidades del servicio o el contexto de funcionamiento. La patente US20130016657 plantea una solución M2M, en exclusiva, para la comunicación a través de redes de telefonía móvil con protocolo 3GPP, no entrando a desarrollar su planteamiento bajo otras condiciones de red. Por último, en la patente WO2013009345 se encuentra la limitación de que la comunicación M2M se logra exclusivamente a través de SMS, siendo este planteamiento una solución muy particular no aplicable para el caso general.

Como conclusión a la revisión de propuestas anteriores, las patentes analizadas plantean soluciones eficientes pero únicamente en entornos concretos y para un uso muy específico, adoleciendo de falta de flexibilidad para abordar problemas heterogéneos sin cambios sustanciales de la arquitectura o del protocolo de comunicaciones y poder trabajar de forma general con dispositivos de naturaleza heterogénea.

En vista de los antecedentes, se hace necesario a la luz de todo lo expuesto, encontrar una forma de gestionar dispositivos de naturaleza diferente y con objetivos también diferentes en una arquitectura M2CI. EXPLICACIÓN DE LA INVENCIÓN

La presente invención representa un avance significativo en la gestión remota de dispositivos ya que define un método de gestión remota que establece un protocolo de comunicación homogéneo e independiente del sector objetivo de la implantación, y aporta un sistema que comprende los medios necesarios para ejecutar el método antes indicado.

La presente invención se desmarca de los sistemas tradicionales planteando un modelo flexible que conjuga estrategias de comunicación síncronas y asincronas mediante el aprovechamiento de las capacidades de comunicación del dispositivo M2M. De esta forma es capaz de modificar su comportamiento para adaptarse a cada situación, actuar como cliente o servidor, según el caso, y tener un comportamiento síncrono o asincrono en función de las necesidades de la aplicación. Con estas características los dispositivos no necesitan estar conectados permanentemente, lo que mejora la eficiencia de su funcionamiento.

Muchos sectores industriales se caracterizan por disponer de un parque de dispositivos distribuidos geográficamente que configuran sus procesos de negocio. Por ejemplo, el sector de la alimentación con su red de máquinas de vending para el autoservicio de productos alimentarios, el sector reprográfico con su red de impresoras y fotocopiadoras instaladas en empresas, el sector industrial de ascensores y elevadores, el sector de alquiler de vehículos, etc. Normalmente, estas máquinas requieren de tareas de mantenimiento periódicas para la puesta a punto, reabastecimiento, supervisión o monitorización de su funcionamiento. El control a distancia de estos aparatos permite establecer esquemas de gestión de recursos distribuidos que mejoran la calidad de servicio y la productividad de su negocio. Las nuevas tecnologías de la información y de las comunicaciones e Internet han permitido llevar este modelo a otros sectores, como por ejemplo, la teleasistencia sanitaria o el control de elementos de tráfico y mobiliario de las ciudades inteligentes.

Sin embargo, la gran diversidad de dispositivos, fabricantes y modelos disponibles en cada sector dificulta la existencia de un método de gestión remota capaz de manejar de forma flexible un sistema que está formado por dispositivos de distinta naturaleza. La invención permite superar inconvenientes en los aspectos que se enumeran a continuación:

• Relativos a la comunicación con el conjunto de dispositivos conectados: se establece un protocolo de comunicación flexible que permite acoplar las comunicaciones a las demandas reales de información en ambos sentidos.

• Relativos a los formatos de comunicación heterogéneos de sectores de aplicación diferentes: según sea necesario el método de gestión puede adaptar los mensajes a los formatos adecuados para cada sector o utilizar el formato normalizado que tiene en cuenta las características conjuntas.

• Relativos a la gestión remota de dispositivos para diferentes sectores industriales: se facilita la integración de aplicaciones de gestión de alto nivel y su interacción con sus dispositivos mediante el método de gestión propuesto utilizando protocolos de comunicación por Internet. Se establece un protocolo de comunicación común independiente de la naturaleza de los dispositivos y de su sector de aplicación.

• Relativos al acceso ubicuo de dispositivos: la invención propuesta traslada a la nube los procesos de gestión de los dispositivos distribuidos y permite su implementación por aplicaciones web y otros servicios de internet.

• Relativos a la gestión de transacciones: el método de gestión propuesto en esta invención simplifica los mecanismos de coordinación de transacciones entre los dispositivos y las aplicaciones de alto nivel.

• Relativos al procesamiento de transacciones masivas: la invención que se describe en este documento proporciona un método de gestión eficiente y capaz de absorber una cantidad muy numerosa de transacciones presente en muchos sectores industriales debido al despliegue de un gran número de dispositivos y la gestión remota de los mismos.

La presente invención aporta un enfoque novedoso que da solución a este problema ya que combina las características de los sectores de trabajo para transformar, en caso necesario, las demandas de servicio genéricas de las aplicaciones de gestión a los formatos adecuados de cada sector. De ese conocimiento se extraen las características fundamentales que definen las funciones de comunicación para establecer un método que permita comunicaciones con dispositivos de sectores heterogéneos. Con la invención propuesta se facilitan los procesos de control remoto de dispositivos de distinta naturaleza diseminados geográficamente y se establece un método estándar y una arquitectura común basada en esquemas Cloud Computing sobre la que construir los modelos de gestión remota incluso para dispositivos pertenecientes a sectores diferentes. De este modo, se superan los inconvenientes derivados de la incompatibilidad entre protocolos y esquemas de comunicación y se trasladan sus procesos de gestión a la nube. Con todo esto, se facilita una comunicación (M2CI) entre los dispositivos (Machine) y la nube (Cloud) para su gestión remota independientemente del tipo y de las características del dispositivo.

Para cumplir con este propósito se han analizado los requerimientos de gestión de aplicaciones avanzadas de múltiples sectores industriales para extraer los elementos característicos que las definen y, así mismo, se ha estudiado un parque heterogéneo de dispositivos conectados para identificar los aspectos que determinan su funcionamiento. A partir de la información obtenida se ha desarrollado el método de gestión propuesto con un protocolo de comunicación homogéneo que permite establecer la gestión remota de dispositivos de distinta naturaleza en un ejemplo de sistema presentado.

El método de gestión remota consiste en establecer un interfaz único para la capa de aplicación de usuario y una puerta de enlace común para todos los dispositivos conectados. De este modo, los comandos de las aplicaciones de gestión y las interacciones en ambas direcciones con todo dispositivo a controlar pasan a través de estos elementos. De este modo, las aplicaciones de gestión de usuario enlazadas configurando una capa de middleware, tienen un interlocutor común con el conjunto de dispositivos que gobiernan y los dispositivos disponen de una puerta de enlace única con la que relacionarse para todas las aplicaciones. La capa middleware, por la que deben pasar todos los requerimientos de control y transacciones de los dispositivos en ambos sentidos, permite definir el método de gestión homogéneo para todos ellos.

Cuando llega una solicitud de alto nivel de una aplicación de gestión de dispositivos, el método de gestión planteado define las acciones necesarias para traducirla al protocolo de comunicación y formato adecuado y canalizarla hacía el conjunto de dispositivos correspondiente. Adicionalmente, si uno de los dispositivos solicita comunicación con el alto nivel, por ejemplo debido a la existencia de un evento en el dispositivo, se recoge la solicitud y se realizan las etapas inversas para transformarla en un mensaje de alto nivel estructurado y hacerla visible para la aplicación oportuna.

El método de gestión diferencia dos modos de operación según si las comunicaciones se realizan hacía o desde los dispositivos y las aplicaciones de gestión:

A. Modo 1 : Solicitud de operación de gestión proveniente de aplicaciones de usuario de alto nivel. Comprende las siguientes etapas: solicitud de gestión, despertado de dispositivo, requerimiento de instrucción, secuencia instrucción-respuesta, respuesta de transacción y cierre de comunicación. Cuando llega una solicitud de gestión de una aplicación de gestión de dispositivos de alto nivel, el método define las acciones necesarias para traducirla al esquema de comunicación y formato adecuado y canalizarla hacía el conjunto de dispositivos correspondiente.

B. Modo 2: Solicitud de comunicación proveniente de los dispositivos a iniciativa suya. Comprende las siguientes etapas: solicitud de comunicación, respuesta de transacción, solicitud de gestión, secuencia instrucción-respuesta, respuesta de gestión y cierre de comunicación. Cuando uno de las dispositivos solicita comunicación con el alto nivel, se recoge la solicitud y se realizan las etapas inversas para transformarla en un mensaje de alto nivel estructurado y hacerla visible para la aplicación oportuna.

Además, la presente invención incluye el sistema que comprende los medios necesarios para ejecutar el método de gestión remota de la invención.

A grandes rasgos, el sistema comprende los siguientes elementos:

1. Dispositivos que se gestionan remotamente que pueden ser de naturaleza distinta. 2. Transceptor que es un elemento acoplado a los dispositivos a gestionar que aporta conectividad para permitir la conexión a través de Internet e interpretar los comandos recibidos independientemente del dispositivo asociado. Los transceptores pueden transferir y leer información del estado de cada dispositivo y comunicarse con el sistema a través de Internet. Adicionalmente permiten su programación en un lenguaje de alto nivel y su actualización o mantenimiento remoto a través de Internet.

3. Arquitectura M2CI basada en módulos que permiten interconectar las aplicaciones de gestión de alto nivel con los dispositivos remotos.

4. Aplicaciones de gestión de alto nivel que realizan las tareas de control, supervisión, monitorización y gestión de la red de dispositivos enlazados en la capa middleware.

BREVE DESCRIPCIÓN DE LAS FIGURAS

En la figura 1 se muestra un esquema general del funcionamiento del método de gestión de dispositivos. Esta figura contiene los elementos fundamentales del sistema y los flujos de información entre los mismos.

En la figura 2 se muestra una posible configuración de la conectividad entre transceptores y dispositivos que contempla un transceptor para cada dispositivo a gestionar.

En la figura 3 se muestra una posible configuración de la ubicación Cloud de las aplicaciones de gestión de alto nivel que contempla que estas aplicaciones se alojen en la misma infraestructura que la arquitectura.

En la figura 4 se muestra el detalle y los módulos que componen la arquitectura M2CI.

En la figura 5 se describe la secuencia de comunicación entre los dispositivos y las aplicaciones de gestión cuando se parte de un requerimiento de estas últimas. En la figura 6 se describe la secuencia de comunicación entre los dispositivos y las aplicaciones de gestión cuando se parte de un requerimiento de los dispositivos.

EXPOSICIÓN DETALLADA DE MODOS DE REALIZACIÓN

Tal como se ha descrito anteriormente, el método de gestión remota de dispositivos de naturaleza heterogénea en arquitecturas M2CI está caracterizado porque transforma las solicitudes de gestión y las comunicaciones con los dispositivos haciendo uso de la arquitectura M2CI mediante un interfaz común para la capa de aplicación de usuario y una puerta de enlace común para todos los dispositivos conectados.

A continuación, se describe inicialmente el sistema para poder identificar los elementos a la hora de describir el método de gestión remota en detalle.

Más en detalle, el sistema comprende los siguientes elementos:

1. Dispositivos 1 que se gestionan remotamente. Estos dispositivos pueden ser de naturaleza distinta, es decir, máquinas distintas (por ejemplo: una máquina de vending, un ascensor, un vehículo, etc.).

2. Al menos un transceptor 3. Elemento acoplado a los dispositivos a gestionar que aporta la conectividad necesaria para enlazar con el sistema a través de Internet e interpretar los comandos recibidos independientemente del dispositivo asociado.

3. Arquitectura M2CI 5 que contiene los módulos que permiten interconectar las aplicaciones de gestión alto nivel con los dispositivos remotos. Los módulos son:

• Módulo Machine Interface 9

• Módulo Parser 10

• Módulo Application Interface 11

• Módulo de Almacenamiento 12

• Módulo de Administración 13

4. Aplicaciones de gestión de alto nivel 7 que realizan las tareas de control, supervisión, monitorización y gestión de su red de dispositivos enlazados al sistema. Son aplicaciones que funcionan con un esquema Cloud y por tanto accesibles de forma ubicua a través de Internet. Una de estas aplicaciones realiza la propia tarea de administración del sistema.

Las comunicaciones entre las aplicaciones y los dispositivos se realizan a través de Internet 8.

Los flujos de comunicación que se producen son:

1. Datos 2 hacía o desde los dispositivos derivados de la ocurrencia de eventos o el envío de comandos. La comunicación de esta información se realiza mediante un medio físico conectado al dispositivo, normalmente un cable.

2. Transacciones 4 hacía o desde los dispositivos derivados de la ocurrencia de eventos o el envío de comandos. La comunicación de esta información se realiza a través de Internet.

3. Solicitudes y respuestas 6 provenientes de las aplicaciones de alto nivel.

Esta información tiene un aspecto estructurado con un formato concebido para el sistema. La interacción mediante estas aplicaciones se realiza también a través de Internet.

La diferencia entre el envío de datos y las transacciones es que estas últimas se pueden codificar en un formato de comunicación homogéneo diseñado para el sistema.

La conectividad entre los dispositivos y los transceptores admite diferentes configuraciones según la relación entre los mismos. Los casos extremos contemplan un único transceptor 3 para el conjunto de dispositivos 1 a gestionar como se muestra en la figura 1 , o un transceptor para cada dispositivo como se muestra en la figura 2. Entre estos dos casos, la configuración adoptada para cada sector industrial depende de aspectos como las facilidades de conexión a Internet de los dispositivos, su capacidad de procesamiento, su conectividad exterior, la proximidad de otros dispositivos o el coste de acoplar elementos de comunicación embebidos.

La disponibilidad y características de los transceptores juegan un papel relevante en la flexibilidad del sistema. Si se dispone de capacidad para incorporar los transceptores adecuados a los dispositivos, pueden usarse los formatos de comunicación normalizados diseñados para esta invención en la comunicación y no será necesario la traducción a los esquemas particulares del sector. El transceptor incorpora entonces la capacidad para adecuar esos mensajes estándares al lenguaje comprensible para sus dispositivos. En caso de no disponer de estos elementos, será necesario transmitir las comunicaciones directamente en el formato del sector haciendo uso de la información del módulo de administración y del sistema de información de la arquitectura.

La arquitectura M2CI 5 tiene como principal objetivo el de proporcionar un servicio de control y comunicación transparente y homogéneo entre las aplicaciones de gestión y los dispositivos a gestionar. Realiza la interpretación de los comandos de alto nivel recibidos desde las aplicaciones y los traduce a las secuencias de comunicación con los dispositivos conectados. Así mismo, recibe las transacciones provenientes de los dispositivos y las envía a las aplicaciones correspondientes en forma de respuesta a los comandos o actualiza el sistema. Se basa en una estructura modular con interfaces entre los elementos bien definidos que facilitan actualizaciones e incorporaciones futuras de nuevas funcionalidades. La comunicación entre los módulos que lo forman combina diferentes tecnologías con el propósito de ofrecer la mayor versatilidad y facilidad de interacción. La estructura de esta arquitectura se ilustra en la figura 4.

En cuanto a la ubicación de las aplicaciones de gestión de alto nivel, esta invención contempla su ubicación en un servidor cloud externo o junto con la arquitectura como muestra la figura 3. En este caso, se favorece la comunicación entre los procesos de gestión y de administración ya que todos ellos quedan dentro de la misma infraestructura cloud.

Una vez detallado el sistema, se describe en detalle el método de gestión remota especificando las etapas de los dos modos de operación.

El método de gestión consta de dos modos de operación según el origen de la comunicación:

A. Modo 1 : Solicitud de operación de gestión proveniente de aplicaciones de usuario de alto nivel (Figura 5). Las etapas son: Solicitud de gestión: las solicitudes de las aplicaciones provienen de peticiones de servicio mediante la ejecución de llamadas al sistema. El Módulo Application Interface 11 contiene el conjunto de llamadas al sistema 16 que pueden ser usadas por las aplicaciones de alto nivel para gestionar los dispositivos remotos haciendo de interfaz con el exterior. La colección de llamadas al sistema disponibles inicialmente responde a la funcionalidad requerida para un conjunto de sectores de aplicación heterogéneo, aunque es lo suficientemente genérica como para extenderla a otros sectores reutilizando las llamadas existentes o ampliando con otras nuevas para proporcionar nuevos servicios. La implementación de las llamadas al sistema se hace mediante tecnología de servicios web.

Una vez recibida la solicitud de gestión, que se corresponde con solicitudes de servicio a los dispositivos, el Módulo Parser 10 la procesa y la transforma al formato adecuado de comunicación con los dispositivos. El Módulo Parser 10 traduce los requerimientos de información solicitados en las funciones concretas que se deben enviar a cada dispositivo. La comunicación con el módulo superior se realiza exclusivamente a través de servicios web 15 definidos en esta capa. Los servicios de este nivel están normalizados y configuran un conjunto completo para comunicar la funcionalidad deseada. Mediante la invocación de esos servicios se procesa el comando para que sea interpretado y preparado para su transmisión al dispositivo. En su versión más básica, la relación de servicios corresponde con el juego de funciones individuales, aunque su diseño permite agruparlas en funciones más generales ofreciendo la capacidad de redefinir la propia funcionalidad. Este módulo utiliza la información de configuración disponible en el módulo de Almacenamiento 12 y de Administración 13. El Módulo de Almacenamiento 12 define el modelo de datos que da soporte a la extensa funcionalidad y la gran versatilidad del objeto de esta invención. Este módulo posee la información relevante sobre los procesos de construcción de los mensajes para cada caso teniendo en cuenta los formatos y protocolos particulares de cada sector. La comunicación con este módulo se realiza mediante conexiones a servidor SQL 17.

El Módulo de Administración 13 se encarga de configurar las características que definen la funcionalidad del sistema. El acceso a la administración se realiza mediante una aplicación de gestión que puede estar alojada en la misma infraestructura o en otra plataforma cloud. Una vez que las peticiones de servicio están adaptadas al formato del dispositivo se envían al módulo Machine Interface 9.

El Módulo Machine Interface 9 implementa la comunicación con los dispositivos a gestionar mediante transacciones y corresponde con la puerta del enlace (conexión de los dispositivos con el Cloud). El módulo se encarga de procesar las solicitudes de alto nivel y los eventos de los dispositivos. Las características de funcionamiento del módulo exigen que se puedan tener abiertas múltiples conexiones simultáneas con dispositivos externos así como comandos a ejecutar provenientes de las aplicaciones de alto nivel. Por este motivo, la implementación aprovecha las capacidades multiprocesador de los sistemas actuales. Esta comunicación se realiza mediante el envío de mensajes de tipo socket 14. Las peticiones de servicio que llegan al módulo Machine Interface están preparadas entonces para ser enviadas a los dispositivos implicados en la función de gestión de alto nivel. Para su construcción se instrumenta un doble servidor de sockets TCP/IP que escucha tanto los mensajes que se reciben desde la capa superior 14 como los provenientes de los dispositivos 2. Para separar ambos tipos de mensajes, el servidor escucha los mensajes provenientes de cada parte de un puerto de comunicación distinto. Cada socket es procesado de forma independiente en un thread de ejecución distinto. La correspondencia entre las solicitudes y respuestas procesadas en elementos de proceso distintos se realiza empleando estructuras de memoria compartida. En aquellas aplicaciones de gestión en las que es necesario reforzar la seguridad de las comunicaciones se incluye en esta capa un protocolo de conexión segura SSL.

Despertado de dispositivo: los mensajes que llegan al módulo Machine Interface se deben enviar a los dispositivos correspondientes. Sin embargo, debido a su funcionamiento particular, pueden estar en un estado de desconexión o de stanby. En ese caso, el sistema despierta a los dispositivos implicados mediante el envío de una comunicación asincrona utilizando su elemento de comunicación. En esta acción, cada dispositivo puede configurarse para que sea despertado, según el caso, mediante un SMS o una llamada perdida.

c) Requerimiento de instrucción: cuando los dispositivos transceptores reciben la señal anterior, despiertan y se conectan a la red. A continuación se conectan al sistema con un requerimiento de instrucciones.

d) e) Secuencia instrucción-respuesta: una vez el dispositivo está activo, el módulo Machine Interface 9, envía el comando que deben ejecutar en el formato adecuado para cada dispositivo, ya sea el propio del sector o el estándar. Ante este requerimiento, cada dispositivo procesa el comando y devuelve la respuesta.

f) Respuesta de transacción: cada respuesta anterior es recogida por el módulo Machine Interface 9, que lo envía a las aplicaciones.

Las acciones a, d), e) y f) relativas a las peticiones de servicio de las aplicaciones y respuesta de los dispositivos pueden realizarse repetidamente mientras sea necesario para culminar las gestiones necesarias.

g) Cierre de comunicación: cuando finalicen las operaciones, el módulo Machine Interface 9 envía un comando de fin de comunicación al dispositivo para informar que puede pasar de nuevo al estado de desconexión. Modo 2: Solicitud de comunicación proveniente de los dispositivos a iniciativa suya (Figura 6). Las etapas son:

a) Solicitud de comunicación: las solicitudes de comunicación por parte de los dispositivos son enviadas directamente ya que el sistema debe estar siempre disponible.

b) Respuesta de transacción: el requerimiento de la transacción anterior es recogido por el Módulo Machine Interface 9 y procesado según la aplicación asociada al dispositivo para transformar los datos enviados a información relevante para las aplicaciones de gestión.

c) Solicitud de gestión: en función de la naturaleza de la información enviada en la acción anterior, se puede crear y enviar una solicitud de gestión al dispositivo por parte de las aplicaciones de alto nivel. En caso de que no sea así, se pasa directamente a la última acción.

d) e) Secuencia instrucción-respuesta: en función de la naturaleza de la información enviada se desencadena una secuencia de comandos y respuestas hasta dar fin a la transacción.

f) Respuesta de gestión: las respuestas recibidas, son enviadas, a su vez, a las aplicaciones de gestión de alto nivel por el Módulo Application Interface 11.

Al igual que en el modo anterior, las acciones c, d), e) y f) relativas a las peticiones de servicio de las aplicaciones y respuesta de los dispositivos pueden realizarse repetidamente mientras sea necesario para culminar las gestiones necesarias ante la solicitud de comunicación inicial.

g) Cierre de comunicación: cuando termina el flujo anterior, se envía un comando de fin de comunicación al dispositivo para informar que puede pasar de nuevo al estado de desconexión.

Como se ha indicado, se incluye un ejemplo de sistema con los elementos necesarios mínimos para explicar el correcto funcionamiento del método de gestión remota, pero sin la intención de ser limitativos, pues existen diferentes distribuciones y estructuras viables de sistemas.