ES2262828T3 - Sistema para la adquisicion remota de datos basado en la comunicacion de mensajes por correo electronico a traves de redes publicas y privadas. - Google Patents
Sistema para la adquisicion remota de datos basado en la comunicacion de mensajes por correo electronico a traves de redes publicas y privadas.Info
- Publication number
- ES2262828T3 ES2262828T3 ES02760317T ES02760317T ES2262828T3 ES 2262828 T3 ES2262828 T3 ES 2262828T3 ES 02760317 T ES02760317 T ES 02760317T ES 02760317 T ES02760317 T ES 02760317T ES 2262828 T3 ES2262828 T3 ES 2262828T3
- Authority
- ES
- Spain
- Prior art keywords
- data
- protocol
- architecture
- software
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
- H04L41/0253—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
- H04L41/026—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using e-messaging for transporting management information, e.g. email, instant messaging or chat
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/222—Monitoring or handling of messages using geographical location information, e.g. messages transmitted or received in proximity of a certain spot or area
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Business, Economics & Management (AREA)
- Human Resources & Organizations (AREA)
- Entrepreneurship & Innovation (AREA)
- Strategic Management (AREA)
- Operations Research (AREA)
- General Business, Economics & Management (AREA)
- Computer Hardware Design (AREA)
- Economics (AREA)
- Marketing (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Information Transfer Between Computers (AREA)
- Telephonic Communication Services (AREA)
- Burglar Alarm Systems (AREA)
Abstract
Método para transferir datos genéricos adquiridos en una ubicación remota (101, 102) a una base de datos central (105) basándose en comunicación por correo electrónico que comprende las siguientes etapas: a. encapsular los datos adquiridos en un mensaje de correo electrónico, b. enviar el correo electrónico a través de una red pública o privada (107) a un servidor (105) de una base de datos central, c. extraer los datos del mensaje de correo electrónico por medio del servidor de la base de datos central, y d. almacenar los datos extraídos en la base de datos central, caracterizado porque dichos datos adquiridos se comunican, sin usar arquitectura de pasarela, a dicho servidor de base de datos proporcionando una arquitectura para software de comunicación Internet para plataformas incrustadas, estando basada dicha arquitectura en una red de multiplexores y demultiplexores de software controlada por un motor de protocolo integrado, y caracterizado adicionalmente porque se utiliza una base de datos destino que contiene parámetros asociados con una aplicación destino.
Description
Sistema para la adquisición remota de datos
basado en la comunicación de mensajes por correo electrónico a
través de redes públicas y privadas.
La invención se refiere a un método, un aparato
de cliente y a un programa informático para transferir directamente
datos genéricos adquiridos en una ubicación remota a una base de
datos central a través de una red pública o privada basándose en
una comunicación por correo electrónico.
La invención se refiere además a un método para
configurar y gestionar de forma remota dicho aparato.
La invención se refiere a un método para la
adquisición remota de datos genéricos, a la arquitectura de pilas
del protocolo TCP/IP, una interfaz de programación de aplicaciones,
el aparato para ello, y a una arquitectura de comunicación en serie
para la configuración de dicho aparato.
En un primer aspecto, la presente invención se
refiere a un método y un aparato de transferencia de datos
genéricos adquiridos en una ubicación remota a una base de datos
central mediante:
- 1.
- encapsulado de los datos adquiridos por medio de dicho aparato en un mensaje de correo electrónico,
- 2.
- envío del mensaje de correo electrónico por medio de dicho aparato a través de un red (pública o privada) a un servidor de una base de datos central,
- 3.
- extracción de los datos del mensaje de correo electrónico por parte del servidor de la base de datos central,
- 4.
- almacenamiento de los datos extraídos en la base de datos designada,
en el que todas las comunicaciones cumplen los
estándares de Internet.
La realización preferida de la invención se
designa como método de adquisición de datos bf3RDAQ y dispositivo
cliente de adquisición de datos bf3RDAQ.
El método y el aparato permiten el desarrollo de
cualquier adquisición remota de datos sin ninguna limitación en
cuanto a las aplicaciones o la naturaleza de los datos al
proporcionar una interfaz transparente con la base de datos y un
enfoque de arquitectura de diseño modular para dichas
aplicaciones.
Un segundo aspecto de la invención se refiere a
una arquitectura de pilas de protocolo TCP/IP modular y ampliable
diseñada para la comunicación por Internet del lado del cliente de
la aplicación de adquisición remota de datos bf3RDAQ, y otras
aplicaciones que incorporan comunicación de tipo Internet. Este tipo
de arquitectura permite que la aplicación de cliente de adquisición
de datos bf3RDAQ se comunique directamente con el servidor
bf3RDAQ.
Un tercer aspecto de la invención se refiere a
una arquitectura de comunicación para la configuración y el
mantenimiento de la aplicación de cliente de adquisición de datos, y
otras aplicaciones (incrustadas).
Un cuarto aspecto de la invención se refiere a
un método de comunicación por correo electrónico para la gestión
remota de la aplicación de cliente de adquisición de datos mediante
el servidor.
Un quinto aspecto de la invención se refiere a
una interfaz de configuración basada en HTML a la que puede
accederse a través de la interfaz de comunicación del dispositivo de
cliente de adquisición de datos.
El sexto aspecto de la invención se refiere a la
actualización, basada en FTP o HTTP, del software de cliente de
adquisición de datos.
Actualmente, las arquitecturas para aplicaciones
de adquisición remota de datos están basadas en protocolos o
infraestructuras de comunicación propietarios, o en ambos. En muchos
casos, se desarrolla un hardware personalizado para adquirir los
datos y enviarlos a la aplicación del servidor. Esto tiene cuatro
desventajas importantes:
- 1.
- los protocolos propietarios requieren un amplio desarrollo y comprobación, tanto en el lado del cliente, como también del servidor,
- 2.
- las infraestructuras propietarias son costosas en términos de desarrollo, implementación y mantenimiento, y a menudo requieren un gran esfuerzo para alcanzar la aceptación general,
- 3.
- la transferencia de datos a larga distancia es imposible o requiere la conversión a otros protocolos de comunicación (por ejemplo, red telefónica pública conmutada),
- 4.
- las implementaciones de hardware personalizado requieren un desarrollo y comprobación costosos y ofrecen escasas posibilidades de reutilización.
El primer y el segundo punto hacen que el
desarrollo de aplicaciones de adquisición remota de datos sea
innecesariamente costoso, y ambos pueden implicar un gran riesgo de
desarrollo.
El tercer punto hace que las aplicaciones de
desarrollo que recopilan datos de ubicaciones dispersas en grandes
áreas (por ejemplo, el inventario global o ubicaciones de ventas de
una empresa) sean extremadamente difíciles y costosas.
El cuarto punto aumenta el tiempo general de
desarrollo de la aplicación, y la limitada posibilidad de
reutilización da como resultado un coste adicional para la
aplicación.
En la técnica se han descrito métodos para
transferir datos recogidos por medio de mensajes de correo
electrónico. El documento EP 1.045.549 describe un método para
monitorizar y gestionar redes distribuidas. Los datos de
funcionamiento los junta un servidor designado en cada red, el cual
envía los datos de funcionamiento acumulados a uno o varios
servidores centrales. Los servidores centrales juntos constituyen el
sistema supervisor para la monitorización y gestión de las redes
distribuidas.
El documento EP 964.325 describe un método para
gestionar dispositivos de campo en sistemas de procesos
industriales.
Los dos métodos anteriormente descritos se basan
en una arquitectura de pasarela. En el método según el documento EP
1.045.549, por ejemplo, un servidor designado en la red del cliente
asume la tarea de la arquitectura de pasarela: éste recopila los
datos procedentes de los ordenadores anfitriones en la red del
cliente y transfiere los datos acumulados al servidor central. En
el método según el documento EP 964.325, los dispositivos de campo
presentan datos a una pasarela a través de protocolos propietarios o
protocolos que no son de Internet. La pasarela trata y da formato a
los datos y los envía a un servidor central de la parte de los
dispositivos de campo, el cual almacena los datos recibidos en una
base de datos.
Sin embargo, el uso de una arquitectura de
pasarela requiere un gran desarrollo y comprobación, e implica un
proceso que requiere mucho tiempo.
Asimismo, los dos métodos anteriormente
descritos se refieren a campos particulares de aplicación. El método
descrito en el documento EP 1.045.549 se refiere a la gestión de
redes distribuidas, mientras que el método descrito en el documento
EP 964.325 se refiere a la gestión de dispositivos de campo en un
sistema de procesos industriales. Ninguno de los documentos citados
reivindica un método para la adquisición remota de datos genéricos.
El documento WO 00/19681 describe la forma en la que entidades de
protocolos de comunicación que operan de forma independiente
(llamadas "motores") pueden combinarse e integrarse para crear
pilas de protocolos. Las técnicas de este documento hacen uso de
tablas de función unificadas y punteras que vinculan las entidades
de protocolo.
Para evitar las dificultades e inconveniencias
de los métodos de la técnica anterior, sería deseable proporcionar
un método y un aparato que redujeran el tiempo y el esfuerzo
necesarios para el desarrollo de aplicaciones remotas de
adquisición de datos. Asimismo, sería ventajoso proporcionar un
método y un aparato que permitieran la adquisición de datos
genéricos en una ubicación remota sin limitaciones en cuanto a la
naturaleza de los datos o en cuanto a las aplicaciones.
En relación con el segundo aspecto de la
invención, actualmente, las arquitecturas de pilas de protocolos
TCP/IP para aplicaciones incrustadas se basan normalmente en un
modelo de capas de protocolo apiladas. Este modelo deriva de los
conceptos de diseño convencionales utilizados para entornos de
procesadores de alto rendimiento. Como tal, no está bien adecuado
para aplicaciones incrustadas que se basan en procesadores con
recursos de memoria y ancho de banda de procesamiento limitado. La
arquitectura de comunicaciones TCP/IP de la presente invención
proporciona un concepto modular y ampliable para el desarrollo de
sistemas incrustados con posibilidad de conexión a
Internet.
Internet.
En relación con el tercer aspecto de la
invención, actualmente, las interfaces de configuración para las
aplicaciones incrustadas se desarrollan normalmente basándose en la
aplicación. Dado que el desarrollo y la comprobación de la
comunicación subyacente es una tarea que requiere mucho tiempo, ésta
aumenta el riesgo del desarrollo. La arquitectura de comunicación
en serie de la presente invención permite tiempos de desarrollo de
interfaces de configuración que se acortan significativamente.
En relación con el cuarto aspecto de la
invención, actualmente, la gestión de sistemas remotos desde una
ubicación central normalmente se lleva a cabo con aplicaciones
personalizadas. Al hacer uso del método de comunicación por correo
electrónico de la presente invención, puede utilizarse la misma
arquitectura que se utiliza para la aplicación de adquisición
remota de datos para la gestión del aparato de adquisición de datos
del cliente. La naturaleza cliente-servidor de este
tipo de arquitecturas permite que la aplicación cliente de
adquisición de datos se comunique directamente con el servidor.
En relación con el quinto aspecto de la
invención, actualmente, la configuración y gestión de los clientes
de adquisición de datos desde un dispositivo remoto normalmente se
llevan a cabo con hardware, software y protocolos personalizados.
Al hacer uso de un servidor HTTP incrustado (servidor web), la
interfaz de configuración y gestión para el acceso desde un
dispositivo remoto puede basarse en la comunicación TCP/IP y puede
implementarse con un cliente HTTP estándar (navegador web), tal
como Microsoft Internet Explorer.
En relación con el sexto aspecto de la
invención, actualmente, la actualización de versiones de software
desde ubicaciones remotas normalmente se lleva a cabo con
protocolos bootloader (cargador de inicio) propietarios. Al hacer
uso del protocolo FTP, la actualización del software puede basarse
en la comunicación TCP/IP y puede implementarse con cualquier
servidor compatible con FTP.
La presente invención es un sistema, método y
aparato (consistente en hardware, microprogramas y software) para
la transferencia de datos genéricos adquiridos por dicho aparato
desde una ubicación remota a una base de datos central.
El sistema de la presente invención consiste en
un servidor de una base de datos central y un número de clientes de
adquisición de datos bf3RADQ que pueden establecer conexiones de
comunicación con el servidor a través de cualquier red que sea
capaz de aceptar la comunicación Internet. Los clientes de
adquisición de datos procesan y almacenan los datos adquiridos
localmente hasta que necesitan transportarse a la aplicación del
servidor. La aplicación del servidor tiene acceso a la base de
datos.
Es importante el hecho de que el sistema, el
método y el aparato según la invención son adecuados para adquirir
datos genéricos sin ninguna limitación en cuanto a la aplicación o
la naturaleza de los datos.
Una característica esencial de la invención es
el hecho de que los clientes de adquisición de datos bf3RADQ pueden
establecer conexiones de comunicación directas con el servidor
mediante el empleo de una arquitectura
cliente-servidor. El sistema, el método y el aparato
según la invención no requieren el uso de arquitectura de
pasarela.
Otra característica esencial de la invención es
el uso de correo electrónico para el encapsulado de los datos
adquiridos, y para transferir los datos adquiridos encapsulados al
servidor central, que aloja la base de datos de destino o conecta
con ésta. Para la comunicación a través de la capa física, puede
utilizarse cualquier red que permita la comunicación Internet (por
ejemplo, LAN, WAN). Esto implica que cualquier aplicación de
adquisición remota de datos puede basarse en infraestructuras
existentes y estándares de comunicación ampliamente aceptados
(Internet). Por tanto, es un nuevo método y sistema universal y
genuino de adquisición de datos que no se basa en conceptos o
infraestructuras de comunicación propietarios.
El aparato proporciona las siguientes
funciones:
- 1.
- tratamiento de datos genéricos (incluidas memorias RAM y ROM para el almacenamiento de datos/progra-mas),
- 2.
- interfaz de comunicación de capa física (por ejemplo, módem series V, Ethernet, RDSI),
- 3.
- reloj a tiempo real,
- 4.
- gestión de potencia,
- 5.
- almacenamiento no volátil de datos,
- 6.
- interfaces con el hardware de adquisición de datos (por ejemplo, SPI, I^{2}C),
- 7.
- interfaz en serie UART.
Al proporcionar una interfaz API de programación
de aplicaciones bien definida, el desarrollo del cliente de
adquisición remota de datos se limita al hardware y software
específicos de la aplicación.
El segundo aspecto de la presente invención es
la arquitectura en la que se basa el software de comunicación
Internet de la aplicación de cliente. En lugar de seguir un modelo
de pilas convencional, el software de comunicación por Internet
bf3Net se basa en un enfoque de diseño que se usa en el diseño de
estructuras de enrutamiento de señales de hardware. La arquitectura
de comunicación por Internet bf3Net (arquitectura de comunicación
TCP/IP) de la presente invención se basa en una red de multiplexores
y demultiplexores controlada por un motor de protocolo incrustado.
Esta arquitectura tiene las siguientes ventajas:
- 1.
- es independiente de la plataforma (procesador o sistema operativo),
- 2.
- está bien estructurada y es modular
- 3.
- puede configurarse en gran medida
- 4.
- está bien adaptada para las aplicaciones incrustadas.
Al proporcionar una arquitectura de comunicación
Internet de este tipo, los clientes de adquisición de datos pueden
confeccionarse y optimizarse para los requisitos de la aplicación.
Lo mismo se aplica a otras aplicaciones incrustadas.
El tercer aspecto de la presente invención es la
arquitectura de comunicación en serie bf3Scp con la que puede
configurar el cliente de adquisición de datos bf3RDAQ a través de la
interfaz en serie UART proporcionada por el aparato de la
invención. La arquitectura elegida tiene las siguientes
ventajas:
- 1.
- el protocolo de comunicación se implementa mediante un motor protocolo anfitrión y destino que puede reutilizarse para cada una de las aplicaciones,
- 2.
- el desarrollo de la implementación principal de la interfaz de configuración está limitado a las funciones de interfaz de usuario (por ejemplo, elementos de interfaz de usuario Windows con funciones subyacentes).
- 3.
- el desarrollo de la aplicación destino está limitado al tratamiento de los mensajes recibidos y a proporcionar una respuesta.
Se menciona que para otras aplicaciones
incrustadas también puede utilizarse la arquitectura de comunicación
en serie de la presente invención.
Una característica esencial de la invención es
el uso de una base de datos de destino que contiene todos los
parámetros asociados con la aplicación destino (por ejemplo,
parámetros de temporización e identificadores de mensajes). Al
identificar la aplicación destino con los siguientes
identificadores, únicos globalmente:
1. identificador del proveedor en 32 bits.
2. identificador de la aplicación en 32
bits.
estos parámetros pueden recuperarse de la base
de datos de destino. En concreto, pueden asignarse conjuntos de
mensajes a una aplicación destino. La unidad de destino puede
identificarse adicionalmente mediante un número de serie de 32
bits.
El cuarto aspecto de la invención es un método
para la configuración indirecta del cliente de adquisición de datos
mediante la aplicación de servidor. El cliente de adquisición de
datos bf3RDAQ puede configurarse para recuperar mensajes de correo
electrónico desde su buzón de correo en el servidor por medio del
protocolo POP3. Estos mensajes contienen datos de configuración que
el cliente POP3 evalúa para ajustar sus ajustes de configuración
almacenados localmente. De forma ventajosa, tal como se ha
mencionado anteriormente, al hacer uso del método de comunicación
por correo electrónico de la presente invención, la misma
arquitectura de comunicación TCP/IP que se utiliza para la
apli-
cación de adquisición remota de datos puede utilizarse para la gestión del aparato de adquisición de datos del cliente.
cación de adquisición remota de datos puede utilizarse para la gestión del aparato de adquisición de datos del cliente.
El quinto aspecto de la invención es un método
para la configuración directa del cliente de adquisición de datos
bf3RDAQ desde una ubicación remota. Una persona o un motor puede
establecer una sesión de comunicación basada en Internet basándose
en la arquitectura de comunicación TCP/IP con el cliente bf3RDAQ a
través de la red a la que ambos se conectan. Al interactuar a
través de un archivo HTML proporcionado por el servidor HTTP
incrustado del cliente de adquisición de datos bf3RDAQ, pueden
monitorizarse o ajustarse los ajustes de estado y
configuración.
El sexto aspecto de la invención es un método
para la actualización de la versión del software del cliente de
adquisición de datos mediante la descarga de una imagen del software
desde el servidor central con el protocolo FTP o HTTP. Al hacer uso
del protocolo FTP, la actualización del software puede basarse en la
comunicación TCP/IP y puede implementarse con cualquier servidor
compatible con FTP.
En los dibujos se proporcionan tres conjuntos de
figuras. Se han utilizado los mismos números de referencia para
cada uno de los conjuntos 1, 2 y 3 independientes. Las figuras 1, 2
y 3 son, respectivamente, ilustraciones de realizaciones del
primer, del segundo y del tercer aspecto de la invención.
La figura 1.A es una vista general del sistema
de adquisición remota de datos bf3RDAQ según la presente invención,
que incluye dos (2) clientes de adquisición de datos bf3RDAQ [DAC1]
y [DAC2] en las ubicaciones remotas, y un servidor de adquisición
de datos bf3RDAQ [DAS1], todos ellos con acceso y conectadas a una
red compatible con el protocolo de Internet conectados a la
misma.
La figura 1.B es una descomposición de todos los
elementos que constituyen juntos el sistema de adquisición remota
de datos bf3RDAQ según la presente invención.
La figura 1.C es un diagrama de bloques
funcionales de una realización de un cliente de adquisición de datos
bf3RDAQ [DAC3] según la presente invención.
La figura 1.D es un diagrama de la arquitectura
del software de la aplicación de cliente [AS1] de adquisición de
datos bf3RDAQ según la presente invención.
La figura 1.E es un diagrama de la arquitectura
del software de aplicación de servidor [AS2] de adquisición de
datos bf3RDAQ según la presente invención.
La figura 2.A es un diagrama [AD1] de la
arquitectura general [AD1] del software de comunicación por Internet
bf3Net según la presente invención.
La figura 2.B muestra la representación del
elemento de descripción de ruta dentro del software de comunicación
por Internet bf3Net según la presente invención.
La figura 2.C es un diagrama de arquitectura de
enlace de datos [AD2] del software de comunicación por Internet
bf3Net para conexiones de protocolo punto a punto (PPP) según la
presente invención.
La figura 2.D es un diagrama de arquitectura de
enlace de datos [AD3] del software de comunicación por Internet
bf3Net para conexiones Ethernet según la presente invención.
La figura 3.A es una vista general del sistema
de una aplicación de interfaz de configuración basada en la
arquitectura de comunicación en serie bf3Scp según la presente
invención.
La figura 3.B es un modelo de capas de protocolo
de una sesión de comunicación bf3Scp entre una implementación
anfitrión y destino basada en la arquitectura de comunicación en
serie bf3Scp según la presente invención.
La figura 3.C es el formato de datagrama de los
mensajes de la arquitectura de comunicación en serie bf3Scp según
la presente invención.
La figura 3.D es el procedimiento de
establecimiento de enlace de datos de la arquitectura de
comunicación en serie bf3Scp según la presente invención.
La figura 3.E es el procedimiento de intercambio
de datagramas de la arquitectura de comunicación en serie bf3Scp
según la presente invención.
La figura 1.A muestra dos clientes de
adquisición de datos bf3RDAQ 101 y 102 de la presente invención y el
sistema en el que operan. Los dos dispositivos tienen acceso a la
red 106. El sistema consiste adicionalmente en un servidor 103 de
adquisición de datos bf3RDAQ que se conecta a una base de datos 105.
En la figura 1.A un cliente de adquisición de datos bf3RDAQ 101
establece una conexión 107 a través de la red 106 con el servidor
de adquisición de datos bf3RDAQ 103. En función del tipo de red,
puede ser necesario un servidor de acceso remoto 104 (por ejemplo,
para conexiones por módem/RDSI) como un router (encaminadora) entre
el servidor y los clientes.
La figura 1.B proporciona una vista superior más
detallada de los elementos que constituyen el sistema de
adquisición remota de datos bf3RDAQ 201 de la presente invención. El
sistema consiste en los siguientes bloques estructurales:
- 1.
- el módulo de software incrustado bf3RDAQ 208
- 2.
- el módulo de software de comunicación por Internet bf3Net 207
- 3.
- el módulo de hardware de comunicación bf3RDAQ 206
- 4.
- el módulo de software de servidor bf3RDAQ 202
- 5.
- una plataforma de sistema operativo 203 (por ejemplo, Microsoft Windows, UNIX)
- 6.
- un servidor de acceso remoto opcional 204.
El módulo de software de servidor bf3RDAQ 202
tiene acceso a una base de datos 214.
En el lado del cliente, para crear una
aplicación personalizada de adquisición de datos 213 el
desarrollador de la aplicación debe diseñar el hardware de
adquisición de datos 210 específico de la aplicación para recuperar
datos de la fuente de datos 212. En el lado del servidor, el
desarrollador de la aplicación debe diseñar una aplicación de base
de datos que interactúe con la base de datos 214.
El sistema de adquisición remota de datos
bf3RDAQ de la presente invención puede mejorarse adicionalmente
añadiendo el módulo de software destino bf3Scp 209, que interactúa
con una aplicación de interfaz de usuario bf3Scp 211 a través del
módulo de hardware de comunicación bf3RDAQ 206.
Un diagrama de bloques de una realización de un
módulo de hardware de comunicación de cliente para la adquisición
de datos bf3RDAQ de módem según la presente invención se muestra en
la figura 1.C. Todo el tratamiento de los datos y la comunicación
se lleva a cabo por el procesador digital de señales 301. El
procesador digital de señales tiene acceso a la memoria de datos
303 y a la memoria del programa 302, y está temporizado por un
dispositivo de reloj 304. Un reloj de tiempo real (RTC) 311 sirve
como referencia temporal.
El canal de comunicación del módulo de hardware
de comunicación de cliente para la adquisición de datos bf3RDAQ de
módem según la presente invención comprende una interfaz de línea de
telecomunicaciones (LIF) 308 junto con un montaje de acceso directo
(DAA) 307. La ruta de recepción comprende adicionalmente un filtro
de paso bajo (LPF) 309 y un convertidor analógico digital
(A-D) 310. La ruta de transmisión comprende
adicionalmente un convertidor digital analógico
(D-A) 305 y un filtro de paso bajo (LPF) 306. El
conjunto de circuitos de interfaz de línea 308 es capaz de detectar
una llamada entrante y al identificador de la parte que llama. De
esta manera, el cliente de adquisición de datos bf3RDAQ puede actuar
selectivamente como un receptor. El conjunto de circuitos de
interfaz de línea 308 también detecta si la línea telefónica está
siendo utilizada antes de establecer una conexión o se ha
solicitado por otra parte durante una conexión activa. De esta
manera el cliente de adquisición de datos bf3RDAQ puede
configurarse para no interferir con otro equipo y para liberar la
línea en caso de condiciones de
emergencia.
emergencia.
Para la comunicación en serie, se proporciona
una interfaz de receptor y transmisor asincrónicos universales
(UART, Universal Asynchronous Receiver and Transmitter) 313. Para la
interconexión con el hardware de adquisición de datos específico de
la aplicación se proporciona una interfaz de adquisición de datos
312.
En la figura 1.D se muestra un diagrama de
bloques de la arquitectura del software de cliente de adquisición
de datos bf3RDAQ según la presente invención. El elemento central de
la arquitectura es el módulo de software de la interfaz de
programación de aplicaciones (API) bf3RDAQ 407. Ésta se interconecta
con una base de datos incrustada 408 que actúa como un
almacenamiento local de los datos adquiridos por el cliente y de
datos de configuración que controlan el funcionamiento del cliente
de adquisición de datos.
El módulo de software de la interfaz de
programación de aplicaciones (API) bf3RDAQ 407 se interconecta
adicionalmente con el módulo de software de comunicación Internet
bf3Net 402, según la presente invención, a través de los siguientes
módulos de protocolo de aplicación Internet:
- 1.
- módulo de aplicación de cliente de protocolo de transferencia de correo simple (SMTP, Simple Mail Transfer Protocol) 403,
- 2.
- módulo de aplicación de cliente del protocolo de oficina de correo versión 3 (POP3, Post Office Protocol) 404,
- 3.
- módulo de aplicación de servidor de protocolo de transferencia de hipertexto (HTTP, HyperText Transfer Protocol) 405,
- 4.
- módulo de aplicación de cliente de protocolo de transferencia de archivos (FTP, File Transfer Protocol) 406.
El protocolo de transferencia de correo simple
(SMTP) 403 se utiliza para transferir los datos adquiridos por el
cliente bf3RDAQ, encapsulados en un mensaje de correo electrónico,
desde la base de datos incrustada de cliente de adquisición de
datos bf3RDAQ 408 a la base de datos central bf3RDAQ según la
presente invención.
El protocolo de oficina de correo versión 3
(POP3) 404 se utiliza para transferir datos (por ejemplo, datos de
configuración), encapsulados en un mensaje de correo electrónico,
desde la base de datos central bf3RDAQ a la base de datos
incrustada de cliente de adquisición de datos bf3RDAQ 408.
El servidor del protocolo de transferencia de
hipertexto (HTTP) 405 se utiliza para proporcionar interfaces de
configuración HTML a las que puede accederse a través de un
navegador web compatible (por ejemplo, Microsoft Internet
Explorer).
El protocolo de transferencia de archivos (FTP)
406 se utiliza para transferir nuevas versiones de software desde
el servidor bf3RDAQ, según la presente invención, al cliente de
adquisición de datos bf3RDAQ. Entonces, la nueva versión del
software puede almacenarse en la memoria de programas del cliente de
adquisición de datos bf3RDAQ según la presente invención.
El módulo de software de comunicación por
Internet bf3Net 402 se interconecta adicionalmente con el
controlador de comunicaciones de la capa física (PHY) 401, el cual
interactúa con el hardware de comunicaciones 409 (por ejemplo,
interfaz por módem o RDSI).
El módulo de software de la interfaz de
programación de aplicaciones (API) bf3RDAQ 407 proporciona
adicionalmente funcionalidad de interfaz de programación para
facilitar el diseño del software de aplicación personalizada de
adquisición de datos 410.
En la figura 1.E se muestra un diagrama de
bloques de la arquitectura del software de servidor de adquisición
de datos bf3RDAQ según la presente invención. El elemento central de
la arquitectura es el módulo de software de servidor bf3RDAQ 505.
Éste se interconecta con la base de datos central 506, que actúa
como almacenamiento de los datos adquiridos por todos los clientes
del sistema de aplicaciones de adquisición de datos según la
presente
invención.
invención.
El módulo de software de servidor bf3RDAQ 505
interactúa adicionalmente con un servidor de correo de Internet
estándar compatible con POP3 y SMTP 504, desde el cual recupera los
datos adquiridos que se envían al servidor por medio de un cliente
de adquisición de datos bf3RDAQ, según la presente invención. El
servidor de correo por Internet 504 proporciona buzones de correo
electrónicos dedicados con direcciones de correo electrónico
asociadas para la recepción de mensajes de datos procedentes de
clientes de adquisición de datos bf3RDAQ.
El servidor de correo Internet 504 también puede
utilizarse para enviar datos desde la base de datos central 506 a
un cliente de adquisición de datos bf3RDAQ. Para este fin, cada
cliente bf3RDAQ en el sistema de aplicaciones de adquisición de
datos bf3RDAQ debe tener un buzón de correo POP3 en el servidor de
correo Internet
504.
504.
El servidor de correo Internet hace uso del
protocolo de control de transmisiones (TCP, Transmisión Control
Protocol) 503, el protocolo de Internet (IP, Internet Protocol) 502,
y un enlace de datos compatible con Internet (por ejemplo,
Ethernet) 501 para la comunicación a través de la red, según la
presente invención.
Una aplicación de base de datos personalizada
507 es el único componente que necesita proporcionar el
desarrollador de la aplicación para completar el lado del servidor
de la aplicación de adquisición de datos basada en bf3RDAQ, según
la presente invención.
La figura 2.A muestra la arquitectura del
software de comunicación por Internet incrustado bf3Net, según la
presente invención, como una red conceptual de multiplexores y
demultiplexores (o, de forma abreviada, red mxDmx), controlada por
un motor de protocolo (motor bf3Net) 101.
Un nodo en una red mxDmx es, o bien un
multiplexor, o bien un módulo de protocolo. Cada multiplexor tiene
un número de puertos de entrada. Al hacer que el número de puertos
pueda configurarse de forma estática para cada multiplexor, puede
personalizarse la topología de la red mxDmx para la aplicación.
La arquitectura bf3Net, según la presente
invención, se subdivide en un número de capas funcionales. Estas
capas se definen de la siguiente manera:
- 1.
- Capa 0: capa de enlace de datos y encapsulado de tramas
- 2.
- Capa 1: capa de protocolo Internet
- 3.
- Capa 2: capa de conexión y protocolo de transporte.
Es importante resaltar que esta estructura de
capas se basa en propiedades funcionales, no en asignaciones de
capas de comunicación.
La capa 0 de la arquitectura bf3Net, según la
presente invención, sólo se examina en términos generales en el
contexto de la figura 2.A. Remítase a una de las descripciones de
las figuras 2.C y 2.D para obtener detalles específicos de las
implementaciones de capa de enlace de datos. El enlace de datos se
ilustra de forma conceptual como un multiplexor de enlace de datos
104 con un número de módulos de protocolo de enlace de datos
(DL-Px) 105, junto con un módulo de encapsulado de
tramas 103.
La capa 1 de la arquitectura bf3Net, según la
presente invención, está hecho con el multiplexor de protocolo
Internet 105 y los módulos de protocolo de aplicaciones que residen
en esta capa, tal como el módulo de protocolo de mensaje de control
de Internet (ICMP, Internet Control Message Protocol) 111.
La capa 2 de la arquitectura bf3Net, según la
presente invención, está hecho del multiplexor de protocolo de
datagrama universal (UDP, Universal Datagram Protocol) 107, y del
multiplexor del protocolo de transmisión (TCP, transmisión
Protocol) 108. Los dos multiplexores se conectan al módulo de
interfaz de conexión bf3Net 109, que también forma parte de la capa
2 de la arquitectura bf3Net.
El módulo de interfaz de conexión bf3Net 109
actúa como una conexión cruzada entre el protocolo UDP y los
multiplexores TCP y los módulos del protocolo de aplicaciones 110
(indicado como APP-Py en la figura 2.A). El módulo
de interfaz de conexión bf3Net 109 forma parte de la interfaz de
programación de aplicaciones bf3Net 114.
A cada entrada de un multiplexor, se conecta un
módulo de protocolo u otro multiplexor. Cada puerto de multiplexor
se identifica mediante un número que es único para un multiplexor.
También puede configurarse (de forma estática) qué nodo se conecta
con qué puerto. Los identificadores de puerto en cada una de las
capas se utilizan para describir una ruta a través de la red mxDmx.
Tal elemento de descripción de ruta de este tipo puede ser un valor
de 8 bits o 16 bits con un campo para cada una de las capas
funcionales. El formato del elemento de descripción de la ruta se
muestra en la figura 2.B. Por ejemplo, la ruta 113 desde el motor
hasta la conexión TCP 1 se identifica como
7-2-1 (o 0xF1) en una configuración
de 8 bits (3:2:3 bits).
El puerto 0 de cada uno de los multiplexores en
la red mxDmx de la arquitectura bf3Net (por ejemplo puerto 0 112
del multiplexor IP 106), según la presente invención, está reservado
y sirve como sumidero de datos para datos entrantes que deben
eliminarse. La razón de esto se explicará a continuación.
El elemento central de la arquitectura bf3Net es
el motor bf3Net 101. Éste lleva a cabo las siguientes tareas:
- 1.
- gestión de la sesión de comunicación bf3Net,
- 2.
- gestión de la capa de comunicación física 102,
- 3.
- operación de los multiplexores y demultiplexores,
- 4.
- gestión de las memorias intermedias de datos,
- 5.
- gestión del temporizador,
- 6.
- recopilación de información de depuración y perfilado.
La interfaz entre el motor bf3Net 101 y la red
mxDmx la lleva a cabo el multiplexor de enlace de datos 104. El
motor bf3Net también se interconecta con el módulo de encapsulado de
tramas 103 de una forma similar.
El motor bf3Net 101 puede verse como una unidad
de procesamiento central (CPU) del software bf3Net. Como tal, el
motor bf3Net 101 requiere una señal de reloj para mantenerse en
funcionamiento. Esta señal de reloj debe ofrecerse externamente
como un impulso de temporizador o una tarea del sistema operativo.
El motor bf3Net 101 es capaz de (re-) sincronizarse a sí mismo en
este último caso.
Los nodos de la red mxDmx, según la presente
invención, interactúan con el motor bf3Net 101 mediante el envío de
mensajes al motor bf3Net 101 a través de la red mxDmx. Para
identificar al elemento que origina el mensaje se utiliza el
elemento de descripción de la ruta. Están definidos los siguientes
tipos de mensajes:
1. Petición de búfer de datos
2. Concesión de búfer de datos
3. Petición de temporizador
4. Expiración de temporización
5. Mensajes de estado
6. Notificaciones de eventos
7. Informes de errores
El motor bf3Net 101 procesa los mensajes y
responde en correspondencia. El motor bf3Net 101 tiene dos tipos de
mensajes que puede enviar aguas arriba a través de la red mxDmx:
mensajes enrutados (emplean un elemento de descripción de ruta) o
mensajes de difusión general (). Se requiere que cada nodo de la red
transmita mensajes de difusión general a todos los nodos conectados
aguas arriba y que ruta otros mensajes al nodo
apropia-
do.
do.
Los datos se transmiten a través de la red mxDmx
por medio de búferes de datos (no ilustradas en la figura 2.A) que
se identifican mediante un número único. Estos búferes son
gestionados por el motor bf3Net 101. Antes de que pueda utilizarse
un búfer, un nodo necesita solicitar acceso mediante el envío del
mensaje correspondiente al motor bf3Net 101. Lo mismo se aplica
para el uso de los temporizadores.
El acceso a un búfer de datos se concede en
función de la prioridad y edad (primero en llegar, primero servido).
Las respuestas a los nodos también se rutan a través de la red
mxDmx basándose en elementos de descripción de la ruta. Cuando un
nodo ya no requiere el acceso a un búfer, debe abandonar el búfer;
nuevamente, esto se lleva a cabo enviando un mensaje al motor
bf3Net 101 a través de la red mxDmx.
Cuando se reciben datos procedentes de la capa
física 102, se le notifica al motor bf3Net 101 a través de la
interfaz de capa física (PLI) bf3Net 113. El motor bf3Net lo
notifica al módulo de encapsulado de tramas 103, que recupera los
datos de la capa física, y los almacena en un búfer de datos
(solicitado y concedido por medio del motor bf3Net 101).
Una vez que se ha recibido una trama completa,
se le notifica al motor bf3Net 101 mediante el módulo de encapsulado
de tramas 103, y se invoca el siguiente procedimiento de tres
etapas:
- 1.
- el motor bf3Net envía el búfer de datos a la red mxDmx para configurar el elemento de descripción de la ruta.
- 2.
- El elemento de identificación de la ruta está enmascarado en función del estado de la sesión de comunicación.
- 3.
- Se procesa el búfer basándose en el elemento de identificación de la ruta (enmascarado).
La primera etapa se basa únicamente en los
parámetros de la trama recibida (enlace de datos, IP y elemento de
identificación de protocolo TCP/UDP). Dado que un protocolo está
correlacionado con un puerto, un demultiplexor no necesita hacer
nada más que rellenar el campo adecuado del elemento de descripción
de ruta y transmitir el búfer a un multiplexor aguas arriba, si
procede, o finalizar si la ruta conduce a un módulo de protocolo en
su capa. Si no se admite o reconoce un protocolo, debería
introducirse un valor de "0". Durante esta etapa, también se
realiza la verificación de la integridad de los datos (por ejemplo,
suma de comprobación IP). Si esta verificación no es correcta, se
ajusta también la ruta a "0".
La segunda etapa la lleva a cabo el motor bf3Net
101 para enmascarar la ruta aguas arriba en el caso de que no esté
disponible una ruta (por ejemplo, para evitar el procesamiento en un
segmento TCP entrante cuando aún no se ha establecido el enlace de
datos). Todos los campos de ruta no soportados se ajustan a
"0".
La tercera etapa es el verdadero procesamiento
de los datos. Dado que el "puerto cero" está reservado como
sumidero universal para los datos que deben eliminarse, todas los
búferes de datos erráticos se conducen a este puerto, que
simplemente libera el búfer de datos. Si los datos son correctos en
sentido general, se conducen al módulo de protocolo adecuado
basándose en el elemento de descripción de ruta establecido.
Este procedimiento (en combinación con los
puertos cero) es la clave para simplificar el diseño de los
multiplexores, dado que no requieren tener conocimiento de las
otras capas de protocolo (aparte de la información del enrutado)
sean las que sean. Asimismo, al elegir este enfoque de diseño, un
módulo de protocolo puede intercambiarse fácilmente dado que las
funciones de demultiplexión y protocolo están aisladas entre sí.
Otra característica poderosa de esta arquitectura es el hecho de
que la red mxDmx se utiliza para el control y la comunicación de
datos. El diseño de los nodos de protocolo puede basarse en un
entramado de diseño común.
Cuando deben transmitirse los datos, el nodo de
protocolo aplicable debe rellenar su parte del búfer de datos
solicitada (se concede un acceso), y los transmite al nodo de
multiplexor aguas abajo. Obsérvese que esta afirmación implica dos
cosas: (a) un multiplexor nunca solicitará un búfer de datos, (b) un
nodo de protocolo nunca transmitirá un búfer a otro nodo de
protocolo. Esto simplifica nuevamente el diseño de los nodos de red
mxDmx. Antes de que un nodo transmita una búfer de datos aguas
abajo, debe ajustarse el número de puerto aguas abajo en el
elemento de descripción de ruta para el búfer. Todos los
multiplexores dispuestos aguas abajo añadirá su información de
protocolo (por ejemplo, cabecera IP), usando el elemento de
descripción de ruta. Si se ha enviado un búfer completo a través de
la capa física, se notificará al nodo de origen.
Si un canal de comunicación a través de capa
física necesita abrirse (por ejemplo, una conexión por módem), el
módulo de interfaz de conexión bf3Net 109 indicará directamente al
motor bf3Net 101 que lo haga así. Puede transmitirse un elemento de
identificación de canal con esta solicitud. El motor bf3Net 101 le
ordenará a la capa física que comience a abrir la conexión, y
notificará a la red mxDmx una vez que la capa física indique que
está lista. El motor bf3Net 101 coordinará entonces el
establecimiento del enlace de datos y lo gestionará después
basándose en las notificaciones de eventos que recibe de los nodos
de red mxDmx.
El motor bf3Net 101 puede habilitar y
deshabilitar multiplexores de forma individual o colectiva con las
"señales de habilitación" mostradas en la figura 2.A. Cada
multiplexor en la red mxDmx tiene una entrada HABILITAR_MUX para
este fin. De esta manera, si así se requiere, el motor bf3Net 101
puede detener selectivamente el procesamiento de datos (por
ejemplo, en caso de que se haya perdido el enlace de
comunicación).
Finalmente, el motor bf3Net 101 recopila y
mantiene información que puede utilizarse para el perfilado y la
depuración (por ejemplo, historial de errores y uso de búfer). Esta
información puede recuperarse del motor bf3Net 101 con
instrucciones API. Asimismo, pueden modificarse los parámetros a
través de la interfaz API, que permite el perfilado en tiempo de
ejecución.
La figura 2.B muestra la representación del
elemento de descripción de la ruta de la red mxDmx bf3Net según la
presente invención. En la explicación de la figura 2.A ya se ha
proporcionado la descripción funcional de este elemento de
descripción de ruta. El elemento de descripción de ruta consiste en
tres campos de bits (uno para cada capa de la arquitectura bf3Net),
cada uno con una longitud variable. Todas las longitudes juntas de
los campos de bits deben ser iguales a 8 ó 16 bits.
La figura 2.C muestra la arquitectura de enlace
de datos para conexiones de protocolo punto a punto (PPP) en la
arquitectura bf3Net, según la presente invención. La funcionalidad
de encapsulado de tramas la implementa el módulo de control de
enlace de datos de alto nivel 302. El multiplexor de enlace de datos
lo implementa el multiplexor de protocolo punto a punto (PPP)
301.
Un número de módulos de protocolo puede residir
en esta capa de la arquitectura bf3Net, según la presente
invención, tales como: protocolo de control de enlace (LCP, Link
Control Protocol), no autentificación (AUTH), protocolo de
autentificación de contraseña, protocolo de autentificación por
desafío mutuo (CHAP), Microsoft CHAP (MS-CHAP) y el
protocolo de control del protocolo Internet (IPCP).
La figura 2.D muestra las conexiones Ethernet de
la arquitectura del enlace de datos en la arquitectura bf3Net según
la presente invención. La funcionalidad del encapsulado de tramas la
implementa el módulo de encapsulado Ethernet 402. El multiplexor de
enlace de datos lo implementa el multiplexor Ethernet 401.
Un número de módulos de protocolo puede residir
en esta capa de la arquitectura bf3Net, según la presente
invención, tales como: el protocolo de resolución de direcciones
(ARP, Address Resolution Protocol) 403, y protocolo inverso de
resolución de direcciones (RARP, Reverse Address Resolution
Protocol) 404.
La figura 3.A muestra la arquitectura general de
una sesión del protocolo de comunicaciones en serie bf3Scp según la
presente invención. En la terminología bf3Scp, los dos lados de la
sesión de comunicación se denominan "implementaciones". Una
sesión de comunicación consiste en el intercambio de mensajes y
respuestas, de acuerdo con una definición de toma de contacto.
La implementación principal 101 consiste en un
programa de interfaz gráfica de usuario (GUI) 103 que tiene acceso
a una base de datos destino 104 y comunica con la implementación
destino a través del puerto COM integrado 105 del ordenador
personal en el que se ejecuta.
La implementación destino bf3Scp 102 consiste en
el software destino 108 que comunica con la implementación
principal a través del puerto de serie 107 del procesador destino en
el que se ejecuta.
La conversión de nivel de señal RS232 a TTL 106
no se considera parte de ninguna implementación, aunque, debido a
las definiciones de señal bf3Scp, debe proporcionarse. Un cable que
se ha definido para este fin se describirá en la explicación de la
figura 3.F.
La base de datos destino 104 se proporciona para
minimizar el número de parámetros de comunicación que necesitan
configurarse para establecer una sesión de comunicación. Contiene
los parámetros que se fijan en el momento del diseño. Estos
parámetros también pueden estar almacenados en la aplicación GUI, si
esto resulta más ventajoso.
En la figura 3.B se muestra una vista general de
una aplicación de interfaz de usuario basada en la arquitectura
bf3Scp según la presente invención.
Los elementos en los que consiste la invención
bf3Scp 201 se encuentran enmarcados por la línea discontinua:
1. motor del protocolo anfitrión bf3Scp 202,
2. controlador de puerto de serie destino bf3Scp
203,
3. motor del protocolo destino bf3Scp 204.
El motor del protocolo anfitrión bf3Scp 202 es
un objeto ActiveX que trata toda la comunicación en serie
relacionada con el protocolo a través del puerto COM
RSA-232 205. Éste se ejecuta en cualquier plataforma
compatible con Microsoft Windows y es independiente de la
implementación de interfaz de usuario principal 209. Se presenta en
dos versiones: un servidor local que debe ejecutarse en el mismo
ordenador personal principal que la interfaz de usuario, o un
servidor remoto que puede interactuar con la interfaz de usuario a
través de una red haciendo uso de la tecnología DCOM de
Microsoft.
El controlador del puerto de serie destino
bf3Scp 203 trata la comunicación a través de la capa física a través
del puerto de serie destino 207 en el lado de destino. Debe
desarrollarse para cualquier procesador que utilice bf3Scp. Para la
comunicación entre el puerto COM 205 del ordenador personal y el
puerto de serie destino 207 se requiere la conversión de nivel de
RS-232 a TTL 206.
El motor destino bf3Scp 204 es independiente del
procesador; éste trata toda la comunicación relacionada con el
protocolo en el lado destino que no esté cubierta por el motor.
Transmite los mensajes recibidos al software de aplicación destino
personalizado 208, el cual debe realizar la acción adecuada. Con
bf3Scp, el desarrollo de una interfaz de usuario personalizada para
el destino incorporado se limita a los siguientes pasos:
- 1.
- desarrollo del software personalizado de la interfaz de usuario 209,
- 2.
- definición del mensaje específico del destino y los códigos de respuesta,
- 3.
- envío de mensajes al destino desde la interfaz de usuario al destino a través del motor principal bf3Scp 202,
- 4.
- procesamiento de los mensajes recibidos en el lado de destino por medio del software personalizado de aplicación de destino 208
- 5.
- envío de una respuesta estándar o personalizada,
- 6.
- procesamiento de la respuesta recibida en el software personalizado de interfaz de usuario 209.
Esto hace que el desarrollo de interfaces de
usuario sea una tarea sencilla. Una aplicación puede hacer uso
opcionalmente de la base de datos destino 210 (examinada en el
contexto de la figura 3.A).
La figura 3.C muestra el formato 301 del mensaje
bf34Scp según la presente invención. El mensaje bf3Scp consiste en
los siguientes campos:
- 1.
- cabecera fija (valor 0xBF) 302
- 2.
- campo SEQ de secuencias de 4 bits 303
- 3.
- campo FLAGS de indicadores de 4 bits 304
- 4.
- campo S de sincronización de 1 bit 305
- 5.
- campo LENGHT de longitud de 7 bits 306
- 6.
- campo MESSAGE de tipo de mensaje de 8 bits 307
- 7.
- carga útil de múltiples bytes 308
- 8.
- campo FCS de suma de comprobación de trama de 8 bits 309
- 9.
- fin de mensaje fijo (valor 0x03) 310.
La cabecera fija 302, en combinación con el
campo LENGTH 306, el campo FCS 309 y el fin de mensaje fijo 310 le
facilitan a las aplicaciones (incrustadas) la detección del final de
una trama: si la suma acumulada de todos los bytes recibidos es
igual a "0", el último byte recibido es igual a 0x03, y el
número de bytes recibidos es igual al valor del campo LENGTH, la
trama se ha recibido totalmente y por completo.
El campo MESSAGE 307 contiene la cualificación
de la carga útil 308. Los valores impares representan mensajes y
los valores pares se reservan para respuestas. Esto también
simplifica el procesamiento de las tramas entrantes.
El campo SEQ 303 se utiliza para detectar
mensajes y respuestas duplicados o su recepción en estado fuera de
servicio. Su valor se incrementa con cada mensaje enviado (módulo
16) a una dirección determinada (destino-principal
o principal-destino).
El campo FLAGS 304 tiene un valor fijo de 0x05.
Se reserva para futuras aplicaciones.
El campo S de sincronización 305 se utiliza para
la sincronización del enlace de datos. Cuando su valor es "1",
el mensaje bf3Scp se utiliza para este fin.
La figura 3.D muestra el procedimiento de
sincronización para una sesión de comunicación bf3Scp según la
presente invención. El enlace de datos sólo se sincroniza
(nuevamente) mediante la implementación principal, simplificando
con ello la implementación destino.
Un procedimiento de sincronización comienza con
el envío de un mensaje SYNCREQ 401 por el principal al destino.
Cuando se envía este mensaje se establece el campo S. El destino
debe responder enviando una respuesta SYNACK 402 (nuevamente con el
bit S establecido) al principal. El principal acusará recibo de la
recepción de la respuesta SYNCACK 402 enviando un mensaje
ACKNOWLEDGE 403 (otra vez con el bit S establecido) al destino.
Esto completa el procedimiento de sincronización.
La figura 3.E muestra el procedimiento de toma
de contacto para el intercambio de mensajes y respuestas en una
sesión de comunicación bf3Scp según la presente invención. Cada
implementación puede enviar mensajes. La implementación de
recepción siempre debe responder a la recepción de un mensaje de
acuerdo con el procedimiento de toma de contacto descrito.
Una transferencia de mensaje comienza con el
envío de un mensaje 501 por parte de la implementación A a la
implementación B. El campo S se borra cuando se envía un mensaje
normal. La implementación B debe responder enviando una respuesta
502 (también con el bit S eliminado) a la implementación A, que
acusará recibo de la recepción de la respuesta 502 enviando un
mensaje ACKNOWLEDGE 503 (otra vez con el bit S eliminado) al
destino. Esto completa la transferencia del mensaje.
Claims (6)
1. Método para transferir datos genéricos
adquiridos en una ubicación remota (101, 102) a una base de datos
central (105) basándose en comunicación por correo electrónico que
comprende las siguientes etapas:
- a.
- encapsular los datos adquiridos en un mensaje de correo electrónico,
- b.
- enviar el correo electrónico a través de una red pública o privada (107) a un servidor (105) de una base de datos central,
- c.
- extraer los datos del mensaje de correo electrónico por medio del servidor de la base de datos central, y
- d.
- almacenar los datos extraídos en la base de datos central,
caracterizado porque dichos datos
adquiridos se comunican, sin usar arquitectura de pasarela, a dicho
servidor de base de datos proporcionando una arquitectura para
software de comunicación Internet para plataformas incrustadas,
estando basada dicha arquitectura en una red de multiplexores y
demultiplexores de software controlada por un motor de protocolo
integrado, y caracterizado adicionalmente porque se utiliza
una base de datos destino que contiene parámetros asociados con una
aplicación destino.
2. Dispositivo para transferir datos genéricos
adquiridos en una ubicación remota (101, 102) a una base de datos
central (105) basándose en comunicación por correo electrónico, que
comprende:
- a.
- un medio para encapsular los datos adquiridos en un mensaje de correo electrónico en la ubicación remota,
- b.
- un medio para enviar el correo electrónico a través de una red pública o privada (107) a un servidor (105) de una base de datos central,
caracterizado porque el dispositivo está
adaptado para comunicar los datos adquiridos a dicho servidor de
base de datos sin usar una arquitectura de pasarela, comprendiendo
el dispositivo una arquitectura para software de comunicación
Internet para plataformas incrustadas que comprende una red de
multiplexores y demultiplexores de software, controlada por un motor
de protocolo integrado, y, caracterizado adicionalmente
porque el dispositivo comprende un medio para utilizar una base de
datos destino que contiene parámetros asociados con una aplicación
destino.
3. Programa informático adaptado para transferir
datos genéricos adquiridos por un dispositivo en una ubicación
remota (101, 102) a una base de datos central (105) basándose en
comunicación por correo electrónico cuando dicho programa se ejecuta
en dicho dispositivo, estando adaptado adicionalmente dicho programa
para realizar las siguientes etapas:
- a.
- extraer los datos del mensaje de correo electrónico por medio del servidor de la base de datos central; y
- b.
- almacenar los datos extraídos en la base de datos central,
cuando dicho programa está ejecutándose en dicho
servidor de la base de datos central,
caracterizándose el programa porque está
adaptado para comunicar dichos datos adquiridos a dicho servidor de
base de datos sin usar arquitectura de pasarela proporcionando una
arquitectura para software de comunicación Internet para plataformas
incrustadas basándose en una red de multiplexores y demultiplexores
de software controlada por un motor de protocolo integrado, y
caracterizándose adicionalmente el
programa porque está adaptado para proporcionar una base de datos
destino que contiene parámetros asociados con una aplicación destino
cuando dicho programa se ejecuta en un ordenador.
4. Programa informático según la reivindicación
3, en el que:
- a.
- los multiplexores y los módulos de protocolo constituyen nodos en la red de software,
- b.
- los nodos en la red de software están asignados a una estructura de capas basándose en sus propiedades funcionales,
- c.
- cada puerto multiplexor se identifica mediante un número único de identificación del puerto,
- d.
- los identificadores de puerto en cada capa se utilizan para describir una ruta a través de la red, y
- e.
- los multiplexores y los módulos de protocolo interactúan con dicho motor de protocolo integrado, enviando y recibiendo mensajes desde dicho motor de protocolo a través de dicha red, empleando el elemento de descripción de ruta de la etapa (d) para enrutar los mensajes.
5. Método de configuración y gestión de un
dispositivo de la reivindicación 2 mediante un ordenador personal
que comprende las siguientes etapas:
- a.
- utilizar una arquitectura para proporcionar una interfaz gráfica de usuario que se ejecuta en un ordenador personal que comunica con dicho dispositivo a través de una interfaz en serie intercambiando mensajes con el software de aplicación que se ejecuta en dicho dispositivo,
- b.
- intercambiar mensajes utilizando un protocolo de comunicaciones en serie implementado por un motor de protocolo anfitrión que se ejecuta en el ordenador personal y un motor de protocolo destino que se ejecuta en el procesador incrustado de dicho dispositivo,
- c.
- el motor de protocolo anfitrión es un objeto que trata la comunicación en serie relacionada con el protocolo a través de la interfaz en serie, y
- d.
- el motor de protocolo destino es un módulo de software independiente del procesador que transmite el mensaje recibido del motor del protocolo anfitrión al software de aplicación destino para tratamiento adicional,
caracterizado porque el método comprende
las siguientes etapas:
- -
- configurar el dispositivo,
- -
- comunicar los datos adquiridos a un servidor de base de datos sin usar una arquitectura de pasarela, proporcionando una arquitectura para software de comunicación Internet para plataformas incrustadas, estando basada dicha arquitectura en una red de multiplexores y demultiplexores de software controlada por un motor de protocolo integrado,
- -
- configurar un cliente de adquisición de datos y el servidor de base de datos para intercambiar mensajes de correo electrónico,
- -
- proporcionar una base de datos destino que contiene parámetros asociados con una aplicación destino,
caracterizándose adicionalmente el método
porque dicha interfaz es una interfaz RS-232 y
porque dicho objeto que trata la comunicación en serie es un objeto
ActiveX.
6. Método de configuración y gestión del
dispositivo de la reivindicación 2 mediante un servidor de base de
datos, que comprende:
- a.
- configurar el dispositivo para recibir mensajes de correo electrónico procedentes de un buzón de correo en el servidor por medio del protocolo POP3 y dichos mensajes contienen datos de configuración, y
- b.
- evaluar dichos mensajes mediante dicho dispositivo y ajustar los ajustes de configuración almacenados localmente,
caracterizándose el método porque
comprende las siguientes etapas:
- -
- comunicar dichos mensajes sin usar una arquitectura de pasarela a dicho dispositivo proporcionando una arquitectura para software de comunicación Internet para plataformas incrustadas, basándose dicha arquitectura en una red de multiplexores y demultiplexores de software controlada por un motor de protocolo integrado, y
- -
- configurar el dispositivo para utilizar una base de datos destino que contiene parámetros asociados con una aplicación destino.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EP01870183 | 2001-08-24 | ||
| EP01870183 | 2001-08-24 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2262828T3 true ES2262828T3 (es) | 2006-12-01 |
Family
ID=8185011
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES02760317T Expired - Lifetime ES2262828T3 (es) | 2001-08-24 | 2002-08-13 | Sistema para la adquisicion remota de datos basado en la comunicacion de mensajes por correo electronico a traves de redes publicas y privadas. |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7624148B2 (es) |
| EP (1) | EP1419626B1 (es) |
| AT (1) | ATE323364T1 (es) |
| AU (1) | AU2002325941B2 (es) |
| CA (1) | CA2458341A1 (es) |
| DE (1) | DE60210630T2 (es) |
| ES (1) | ES2262828T3 (es) |
| WO (1) | WO2003019883A2 (es) |
Families Citing this family (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070067403A1 (en) * | 2005-07-20 | 2007-03-22 | Grant Holmes | Data Delivery System |
| US20070027955A1 (en) * | 2005-07-28 | 2007-02-01 | Jwj Software, Llc. | Systems, methods and apparatus of an email client |
| US20080086640A1 (en) * | 2005-07-28 | 2008-04-10 | Jmj Software, Llc | Systems, methods and apparatus of an email client |
| JP4477599B2 (ja) * | 2006-04-28 | 2010-06-09 | ブラザー工業株式会社 | 原稿読取装置、画像形成装置及び原稿読取システム |
| US8306883B2 (en) | 2007-04-30 | 2012-11-06 | Textura Corporation | Construction payment management systems and methods with specified billing features |
| US10158590B1 (en) | 2010-07-09 | 2018-12-18 | Gummarus LLC | Methods, systems, and computer program products for processing a request for a resource in a communication |
| US10419374B1 (en) | 2010-07-09 | 2019-09-17 | Gummarus, Llc | Methods, systems, and computer program products for processing a request for a resource in a communication |
| US10171392B1 (en) | 2010-07-09 | 2019-01-01 | Gummarus LLC | Methods, systems, and computer program products for processing a request for a resource in a communication |
| US10212112B1 (en) | 2010-07-09 | 2019-02-19 | Gummarus LLC | Methods, systems, and computer program products for processing a request for a resource in a communication |
| US10015122B1 (en) | 2012-10-18 | 2018-07-03 | Sitting Man, Llc | Methods and computer program products for processing a search |
| DE102011078030A1 (de) * | 2011-06-24 | 2012-12-27 | Endress + Hauser Flowtec Ag | Verfahren zum Betreiben eines Feldgerätes |
| US10021052B1 (en) | 2012-09-22 | 2018-07-10 | Sitting Man, Llc | Methods, systems, and computer program products for processing a data object identification request in a communication |
| US20140172999A1 (en) * | 2012-12-16 | 2014-06-19 | Deep River Ventures, Llc | Methods, Systems, and Computer Program Products for Accessing a Service Via a Proxy Communications Agent |
| US10013158B1 (en) | 2012-09-22 | 2018-07-03 | Sitting Man, Llc | Methods, systems, and computer program products for sharing a data object in a data store via a communication |
| US20140089420A1 (en) * | 2012-09-23 | 2014-03-27 | Deep River Ventures, Llc | Methods, Systems, and Program Products for Processing a Reference in a Communication to a Remote Data Object |
| US10033672B1 (en) | 2012-10-18 | 2018-07-24 | Sitting Man, Llc | Methods and computer program products for browsing using a communicant identifier |
| US10019135B1 (en) | 2012-10-18 | 2018-07-10 | Sitting Man, Llc | Methods, and computer program products for constraining a communication exchange |
| CN111935793A (zh) * | 2020-08-18 | 2020-11-13 | 国网江苏省电力有限公司 | 基于数据采集业务的双模4g公专网在线切换装置和方法 |
| CN112202798B (zh) * | 2020-10-09 | 2022-07-15 | 平安科技（深圳）有限公司 | 数据的协议转化方法、系统、电子设备及存储介质 |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FI114745B (fi) * | 1998-06-01 | 2004-12-15 | Metso Automation Oy | Kenttälaitteiden hallintajärjestelmä |
| WO2000019681A2 (en) * | 1998-09-30 | 2000-04-06 | Xbind, Inc. | System for building and dynamically reconfiguring protocol stacks |
| US6112246A (en) * | 1998-10-22 | 2000-08-29 | Horbal; Mark T. | System and method for accessing information from a remote device and providing the information to a client workstation |
| FR2790629A1 (fr) * | 1999-02-19 | 2000-09-08 | Bull Cp8 | Procede d'activation d'applications localisees dans une carte a puce par un navigateur du type dit "web" |
| FR2791159B1 (fr) * | 1999-03-15 | 2001-05-04 | Bull Cp8 | Procede d'acces a un objet a l'aide d'un navigateur de type "web" cooperant avec une carte a puce et architecture pour la mise en oeuvre du procede |
| EP1045549A1 (en) * | 1999-04-15 | 2000-10-18 | International Business Machines Corporation | System and method for non intrusive monitoring and management of distributed data networks |
| US6446192B1 (en) * | 1999-06-04 | 2002-09-03 | Embrace Networks, Inc. | Remote monitoring and control of equipment over computer networks using a single web interfacing chip |
-
2002
- 2002-08-13 WO PCT/EP2002/009035 patent/WO2003019883A2/en not_active Application Discontinuation
- 2002-08-13 EP EP02760317A patent/EP1419626B1/en not_active Expired - Lifetime
- 2002-08-13 ES ES02760317T patent/ES2262828T3/es not_active Expired - Lifetime
- 2002-08-13 AU AU2002325941A patent/AU2002325941B2/en not_active Ceased
- 2002-08-13 CA CA002458341A patent/CA2458341A1/en not_active Abandoned
- 2002-08-13 DE DE60210630T patent/DE60210630T2/de not_active Expired - Fee Related
- 2002-08-13 AT AT02760317T patent/ATE323364T1/de not_active IP Right Cessation
-
2004
- 2004-02-23 US US10/785,420 patent/US7624148B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| DE60210630D1 (de) | 2006-05-24 |
| CA2458341A1 (en) | 2003-03-06 |
| AU2002325941B2 (en) | 2007-10-04 |
| ATE323364T1 (de) | 2006-04-15 |
| WO2003019883A3 (en) | 2003-10-23 |
| EP1419626B1 (en) | 2006-04-12 |
| WO2003019883A2 (en) | 2003-03-06 |
| EP1419626A2 (en) | 2004-05-19 |
| US7624148B2 (en) | 2009-11-24 |
| DE60210630T2 (de) | 2007-05-03 |
| US20050021640A1 (en) | 2005-01-27 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2262828T3 (es) | Sistema para la adquisicion remota de datos basado en la comunicacion de mensajes por correo electronico a traves de redes publicas y privadas. | |
| ES2342139T3 (es) | Soporte de movilidad ip utilizando un registro de proxi de nodo movil. | |
| CN102316153B (zh) | 对网页邮件本地接入动态构造显示的vpn网络客户端 | |
| CN102333306B (zh) | 一种蜂窝移动设备以及一种用于蜂窝移动设备的系统和方法 | |
| CN102316094B (zh) | 用于移动设备的具有集成加速的多服务vpn网络客户端 | |
| CN102333075B (zh) | 用于移动设备的具有动态故障转移的多服务vpn网络客户端 | |
| CN102333110B (zh) | 用于移动设备的具有动态翻译用户主页的vpn网络客户端 | |
| ES2392037T3 (es) | Pasarela de número de itinerancia IP | |
| CN102316092A (zh) | 用于移动设备的具有快速重新连接的vpn网络客户端 | |
| US20040032881A1 (en) | Distributed application layer protocol converter for communications network | |
| CN102316093A (zh) | 用于移动设备的双模式多服务vpn网络客户端 | |
| WO2005086710A2 (en) | Method and device for coupling a pots terminal to a non-pstn communications network | |
| CN102598592A (zh) | 智能客户端路由 | |
| AU2002325941A1 (en) | System for remote data acquisition based on e-mail message communication through public and private networks | |
| CN108964880A (zh) | 一种数据传输方法及装置 | |
| ES2301249T3 (es) | Señalizacion en un sistema de telecomunicaciones. | |
| US7151780B1 (en) | Arrangement for automated teller machine communications based on bisync to IP conversion | |
| ES2282118T3 (es) | Procedimientos y sistemas para comunicar mensajes ss7 a traves de una red basada en paquetes utilizando una interficie de capa adaptadora de transporte. | |
| CN1947455B (zh) | 支持无线台站之后的网络 | |
| JP3668731B2 (ja) | 仮想プライベートネットワーク（ｖｐｎ）システム及び中継ノード | |
| JP3935823B2 (ja) | Ｈｔｔｐセッション・トンネリング・システム、その方法、及びそのプログラム | |
| Kevin et al. | A wearable internet of things mote with bare metal 6LoWPAN protocol for pervasive healthcare | |
| ES2383368T3 (es) | Procedimiento y sistema de implementación del interacceso de elementos de pila | |
| Cisco | Overview of Access VPNs and Tunneling Technologies | |
| Cisco | Configuring PPP for Wide-Area Networking |