ES2339741T3 - Bloque de funcion web en un equipo de automatismo. - Google Patents
Bloque de funcion web en un equipo de automatismo. Download PDFInfo
- Publication number
- ES2339741T3 ES2339741T3 ES01401675T ES01401675T ES2339741T3 ES 2339741 T3 ES2339741 T3 ES 2339741T3 ES 01401675 T ES01401675 T ES 01401675T ES 01401675 T ES01401675 T ES 01401675T ES 2339741 T3 ES2339741 T3 ES 2339741T3
- Authority
- ES
- Spain
- Prior art keywords
- web
- function block
- communication system
- reception
- application program
- 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
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
-
- 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
- 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)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Computing Systems (AREA)
- Computer Security & Cryptography (AREA)
- Medical Informatics (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
- Selective Calling Equipment (AREA)
- Stored Programmes (AREA)
- Information Transfer Between Computers (AREA)
Abstract
Sistema de comunicación de un equipo de automatismo (10) en una red TCP/IP (50), cuyo equipo de automatismo (10) controla una aplicación de automatismo desarrollando un programa aplicación (20) escrito en uno o varios lenguajes conformes a la norma IEC1131-3 donde el sistema de comunicación comprende: - una función servidor WEB implementada en el interior del programa aplicación (20), - medios de intercambio que comprenden al menos un bloque función WEB de recepción (21) y al menos un bloque función WEB de emisión (22) que están integrados en el programa aplicación (20) y que interactúan con el programa aplicación (20), - una interfaz HTTP (15) en el equipo de automatismo (10) capaz de conducir los mensajes procedentes de la red TCP/IP (50) a un bloque función WEB de recepción (21) identificado por una dirección URL, y realizar la conducción de los mensajes procedentes de un bloque función WEB de emisión (22) a una dirección URL en la red TCP/IP (50) caracterizándose el sistema de comunicación porque comprende igualmente: - una función cliente WEB implementada en el interior del programa aplicación.
Description
Bloque de función WEB en un equipo de
automatismo.
La presente invención se refiere a un sistema de
comunicación de un equipo de automatismo en una red global de tipo
Internet, Intranet o Extranet, que permite implementar una función
servidor WEB y una función cliente WEB en el interior de una
aplicación de automatismo, gracias a por lo menos un bloque función
WEB que puede interactuar con el programa de la aplicación de
automatismo. La presente invención se refiere igualmente a un
equipo de automatismo que integra dicho sistema de comunicación así
como una estación de programación capaz de parametrar bloques
función WEB. Este sistema de comunicación puede aplicarse a
cualquier aplicación perteneciente al ámbito de los automatismos
industriales, automatismos del edificio o del control/accionamiento
de las redes eléctricas de distribución.
Bajo el término "equipo de automatismo", se
designará a continuación un autómata programable, una estación de
control/accionamiento, un control digital o cualquier equipo que
pueda contener y desarrollar un programa usuario que controle una
aplicación de automatismo. Este programa usuario, llamado también
programa de aplicación, está encargado de realizar el control y el
accionamiento de una aplicación de automatismo por medio
particularmente de entradas/salidas dirigidas por este programa
aplicación. Es elaborado por un diseñador y está escrito en uno o
varios lenguajes gráficos de automatismo que integran
particularmente esquemas de contactos, (lenguaje Ladder), diagramas
funcionales en secuencia (Sequential Function Chart o lenguaje
Grafcet), bloques funciones (Function Block Description) o bien en
lenguajes textuales de automatismo de tipo IL (Instruction List) o
ST (Structured Text). Estos lenguajes de automatismo están
ventajosamente conformes con la norma IEC1131-3,
con el fin de facilitar la programación por un diseñador
automaticista que no domina forzosamente los lenguajes
informáticos. Se pueden utilizar en estaciones de programación que
son equipos informáticos, particularmente ordenadores personales de
tipo PC, conectables con el equipo de automatismo a programar.
Ya es conocido que un equipo de automatismo de
este tipo pueda integrar un servidor WEB con el fin de poder
intercambiar datos relativos a este equipo de automatismo con un
cliente WEB distante, tal como un navegador, conectado con una red
global de tipo Internet, Intranet o Extranet, conforme a la norma
TCP/IP, llamada a continuación red TCP/IP. Estas funcionalidades se
describen particularmente en los documentos W099/63409, W09913418,
US6061603 y US5805442. Los datos relativos al equipo de automatismo
son entonces conformados y enviados por el servidor WEB, por
ejemplo en forma de páginas HTML o XML. Es igualmente posible que un
servidor WEB implantado en un equipo de automatismo cargue un
programa, generalmente llamado Applet, en un cliente WEB, cuyo
programa se desarrolla en el cliente WEB con el fin de intercambiar
con el servidor WEB del equipo de automatismo peticiones
transportadas por el protocolo TCP/IP.
Sin embargo, estas soluciones están más
orientadas a la utilización de un navegador (o browser) y no
permiten al diseñador de una aplicación de automatismo controlar
los datos intercambiados en la red TCP/IP. En efecto, el diseñador
no tiene la posibilidad de crear, directamente a partir del programa
aplicación, una comunicación cliente-servidor en la
red TCP/IP.
Ahora bien, esta funcionalidad seria interesante
en algunos casos, para comunicar en una red TCP/IP con el fin de
recibir pedidos o peticiones por parte de un cliente WEB distante y
responder a estas peticiones, controlando los datos intercambiados
en la red TCP/IP. Además, seria interesante que un programa
aplicación pueda comportarse como un cliente WEB activo y ser capaz
de enviar peticiones y recibir datos de un servidor WEB distante.
Se podría así colocar una comunicación en una red TCP/IP entre el
programa aplicación de un equipo de automatismo y un servidor
WEB/cliente WEB distante, tal como un ERP, para intercambiar por
ejemplo órdenes e informes de fabricación.
Para ello, la invención describe un sistema de
comunicación de un equipo de automatismo en una red TCP/IP que
comprende medios de intercambios para implementar una función
servidor WEB o una función cliente WEB en el interior de un
programa aplicación de una aplicación de automatismno cargado en el
equipo de automatismo, comprendiendo estos medios de intercambio al
menos un bloque función WEB que puede interactuar con el programa
aplicación, pudiendo este escribirse en uno o varios lenguajes
conformes a la norma IEC1131-3. El sistema de
comunicación comprende al menos un bloque función WEB de recepción
para implementar una función servidor WEB y/o al menos un bloque
función WEB de emisión para implementar una función cliente WEB en
un programa aplicación.
El sistema de comunicación comprende igualmente
una interfaz HTTP frontal en el equipo de automatismo capaz de
realizar por una parte el encaminamiento de los mensajes procedentes
de la red TCP/IP a un bloque función WEB de recepción identificado
por una dirección URL, y por otra parte el encaminamiento de
mensajes procedentes de un bloque función WEB de emisión a una
dirección URL en la red TCP/IP.
La invención describe igualmente un equipo de
automatismo que integra dicho sistema de comunicación así como una
estación de programación que permite a un diseñador de una
aplicación de automatismo visualizar, introducir, suprimir,
modificar y parametrar al menos un bloque función WEB integrado en
un programa aplicación, con el fin de poner en práctica el sistema
de comunicación descrito.
Así, gracias a la presente invención, se podrá
igualmente colocar una comunicación directa utilizando las
capacidades de la WEB, entre los programas aplicación de varios
equipos de automatismo distantes, por ejemplo para realizar la
sincronización de fabricación. Si esta comunicación se coloca en
programas aplicación de equipos de automatismo utilizando lenguajes
que son utilizados regularmente por los diseñadores de estos
programas aplicación, a saber los lenguajes conformes a la norma
IEC1131-3, entonces eso les permitirá ventajosamente
concebir muy fácilmente aplicaciones de automatismo distribuidas en
la WEB.
De igual modo, será desde ahora posible
introducir en una arquitectura WEB de los equipos de automatismo
actuales modificando ligeramente sus programas aplicación.
Otras características y ventajas aparecerán en
la descripción detallada que sigue haciendo referencia a un modo de
realización dado a titulo de ejemplo y representado por los dibujos
adjuntos en los cuales:
- la figura 1 representa un primer ejemplo de
comunicación de un equipo de automatismo según un sistema de
comunicación conforme a la invención con un aparato cliente,
- la figura 2 representa un segundo ejemplo de
comunicación en el cual un equipo de automatismo se comunica con un
equipo a la vez cliente y servidor,
- la figura 3 muestra un tercer ejemplo de
comunicación entre dos equipos de automatismo,
- las figuras 4 y 5 detallan respectivamente un
bloque función WEB de recepción y un bloque función WEB de emisión
en una representación de tipo esquemas de contactos (lenguaje
LADDER).
La figura 1 muestra un equipo de automatismo 10
que se comunica con un aparato 40 en una red TCP/IP 50. El equipo
de automatismo 10 comprende una interfaz HTTP 15 frontal y un
programa aplicación 20. El aparato 40 comprende un módulo cliente
41, que puede ser un navegador WEB, capaz de emitir en la red TCP/IP
50 peticiones 51 conformes al protocolo HTTP, conteniendo una
dirección URL destinataria y recibir respuestas 52 conformes al
protocolo HTTP. El contenido de una petición HTTP 51 o de una
respuesta HTTP 52 puede estar codificado en diferentes formas,
tales como por ejemplo una trama XML, una trama URL codificada
("URL encoded"), una trama HTML, WML, SOAP u otros formatos
ASCII o binarios.
La figura 2 muestra un equipo de automatismo 10
que se comunica por una parte con un módulo cliente WEB 31 capaz de
emitir por la red TCP/IP 50 peticiones HTTP 51 y recibir respuestas
HTTP 52, y por otra parte con un módulo servidor WEB 32 capaz de
recibir peticiones HTTP 51 procedentes de la red TCP/IP 50 y enviar
respuestas HTTP 52. Los módulos cliente WEB 31 y servidor WEB 32
pueden eventualmente pertenecer a un mismo equipo 30 conectado con
la red TCP/IP 50 y que comprende, por ejemplo, una aplicación ERP
(Enterprise Resource
Planning).
Planning).
La figura 3 muestra dos equipos de automatismo
10, 10' que se comunican entre si por una red TCP/IP 50. Cada
equipo de automatismo 10, 10' comprende una interfaz HTTP 15, 15'
frontal y un programa aplicación 20, 20'.
Un programa aplicación 20, 20' se encarga de
realizar el control/accionamiento de una aplicación de automatismo
por medio de entradas/salidas dirigidas por este programa
aplicación. Es elaborado por un diseñador y está escrito en uno o
varios lenguajes que integran particularmente esquemas de contactos
(LD), diagramas funcionales en secuencia (SFC), listas de
instrucciones (IL), de la programación estructurada (ST) o de los
bloques funciones (BF). Estos lenguajes son preferentemente
conformes a la norma IEC1131-3, con el fin de
facilitar la programación por un diseñador automaticista, que no
domina forzosamente los lenguajes informáticos.
Uno de los objetos de la invención es integrar
en un programa aplicación 20 (respectivamente 20') medios de
intercambio que permiten al diseñador del programa aplicación abrir
una comunicación en la red TCP/IP 50. Para ello, el sistema de
comunicación descrito en la invención comprende al menos un bloque
función WEB 21, 22 (respectivamente 21', 22') configurable y que
puede interactuar con el programa aplicación 20 (respectivamente
20') de un equipo de automatismo 10 (respectivamente 10'). Según un
modo de realización preferido, se pueden considerar dos tipos
distintos de bloques función WEB: un primer tipo se llama bloque
función WEB de recepción 21 (respectivamente 21') y permite
implementar una función servidor WEB en el programa aplicación 20
(respectivamente 20') y un segundo tipo se llama bloque función WEB
de emisión 22 (respectivamente 22') y permite implementar una
función cliente WEB en el programa aplicación 20 (respectivamente
20').
Así, gracias a un bloque función WEB de
recepción 21, el programa aplicación 20 de un equipo de automatismo
10 se encuentra en espera de una petición HTTP 51 que emana de un
cliente WEB, tal como un módulo cliente WEB 31, 41 o un bloque
función WEB de emisión 22' de un programa aplicación 20' de un
equipo de automatismo 10', y reenvía una respuesta HTTP 52 a esta
petición 51. Gracias a un bloque función WEB de emisión 22, el
programa aplicación 20 de un equipo de automatismo 10 puede tomar la
iniciativa de emitir una petición 51 a un módulo servidor WEB 32 o
a un bloque función WEB de recepción 21' de un programa aplicación
20', y esperar una respuesta HTTP 52 a esta petición 51.
Según la invención, los bloques función WEB
están integrados en el programa aplicación 20 que puede estar
escrito en uno o varios lenguajes conformes a la norma
IEC1131-3. Los bloques función WEB están inspirados
de los bloques función de comunicación definidos en la norma
IEC1131-5, pero tales bloques función WEB no están
descritos en la norma. Así, en las figuras 4 y 5, un bloque función
WEB de recepción 21 y un bloque función WEB de emisión 22 se
simbolizan gráficamente con el formalismo de un lenguaje de tipo
esquemas de contactos (Lenguaje LADDER). Comprenden un número de
servicio o identificación 214, 224 y están dotados de parámetros de
entrada 212, 222 y de parámetros de salida 213, 223 que están
conectados lógicamente con elementos del programa aplicación 20,
tales como las variables 215, 216, 225, 226. Los parámetros de
entrada 212, 222 corresponden a órdenes o a controles dados por el
programa aplicación 20 al bloque función WEB 21, 22 y los
parámetros de salida 213, 223 corresponden a informes de fabricación
o a resultados facilitados por el bloque función WEB 21, 22 al
programa
aplicación 20.
aplicación 20.
Con referencia a un ejemplo de realización
presentado en la figura 4, los parámetros de entrada 212 de un
bloque función WEB de recepción 21 comprenden:
- -
- una entrada de tipo booleano RESP ("Respond") que, en el momento del paso al estado VRAI, provoca el envió de una respuesta 52 a una petición 51. En el ejemplo de la figura 4, esta entrada está conectada con un contacto de una variable del programa aplicación 20 denominada SEND ANSWER 215, de tal forma que el estado de la entrada RESP del bloque función WEB 21 sea igual al estado de esta variable SEND ANSWER,
- -
- una entrada de tipo booleano EN_R ("Enable Receive") que, cuando se encuentra en estado VRAI, valida la toma en cuenta de la recepción de una petición por el bloque función WEB 21,
- -
- una o varias entradas IN_1 a IN_n que contienen diferentes parámetros que serán reenviados en la respuesta 52 al cliente WEB emisor de la petición 51.
De igual modo, los parámetros de salida 213 de
un bloque función WEB de recepción 21 comprenden:
- -
- una salida de tipo booleano NDR ("New Data Received") que, en el momento del paso al estado VRAI, señala al programa aplicación 20 que una petición 51 acaba de ser recibida por el bloque función WEB 21. En el ejemplo de la figura 4, esta salida está conectada con la bobina de una variable del programa aplicación 20 llamada REQUEST RECEIVED 216, de tal forma que el estado de esta variable REQUEST RECEIVED sea igual al estado de la salida NDR del bloque función WEB 21,
- -
- una salida de tipo booleano ERROR que indica que el bloque función WEB 21 es erróneo,
- -
- una salida de tipo entero STATUS que proporciona el último estado válido del bloque función WEB 21,
- -
- una o varias salidas OUT_1 a OUT_n que están cargadas con parámetros contenidos en la petición 51.
Con referencia a un ejemplo de realización
presentado en la figura 5, los parámetros de entrada 222 de un
bloque función WEB de emisión 22 comprenden:
- -
- una entrada de tipo booleano REQ que, en el momento del paso al estado VRAI, provoca el envío de una petición 51. En el ejemplo de la figura 5, esta entrada está conectada con un contacto de una variable del programa aplicación 20 llamada START REQUEST 225, de tal forma que el estado de la entrada REQ del bloque función WEB 22 sea igual al estado de esta variable START REQUEST,
- -
- una entrada de tipo booleano R que permite reinicializar el bloque función WEB 22,
- -
- una o varias entradas IN_1 a IN_n que contienen parámetros que serán enviados en la petición 51 al servidor WEB destinatario.
De igual modo, los parámetros de salida 223 de
un bloque función WEB emisión 22 comprenden:
- -
- una salida de tipo booleano NDR que, en el momento del paso al estado VRAI, señala al programa aplicación 20 que una respuesta 52 a la petición 51 acaba de ser recibida por el bloque función WEB 22. En el ejemplo de la figura 5, esta salida está conectada con la bobina de una variable del programa de aplicación 20 llamada ANSWER RECEIVED 226, de tal forma que el estado de esta variable ANSWER RECEIVED sea igual al estado de la salida NDR del bloque función WEB 22,
- -
- una salida de tipo booleano ERROR que indica que el bloque función WEB 22 es erróneo,
- -
- una salida de tipo entero STATUS que proporciona el último estado válido del bloque función WEB 22,
- -
- una o varias salidas OUT_1 a OUT_n que están cargadas con parámetros reenviados por el servidor WEB en la respuesta 52.
Un bloque función WEB 21, 22 comprende un código
programa genérico que es común a cada tipo de bloque función WEB, en
este caso bloque función WEB de tipo recepción 21 y bloque función
WEB de tipo emisión 22. Un bloque función WEB 21, 22 comprende
también datos de configuración específicos 219, 229, que son por
ejemplo almacenados en un fichero de configuración propia para cada
bloque función WEB. Estos datos de configuración 219, 229 contienen
particularmente:
- \bullet
- el número del servicio o identificación que tiene lugar, en el caso de un bloque función WEB de recepción 21, de dirección URL relativa en el equipo de automatismo 10 y que permite a cualquier cliente WEB identificarlo y enviarle una petición,
- \bullet
- la dirección URL destinataria en el caso de un bloque función WEB de emisión 22,
- \bullet
- el tipo de petición HTTP (llamado método HTTP) que el bloque función WEB 21, 22 es capaz de emitir o de recibir (generalmente de los métodos POST o GET, pero también de los métodos PUT, DELETE, TRACE, OPTIONS,...),
- \bullet
- el contenido del mensaje o la localización de un mensaje indexado (por ejemplo una página HTML, un mensaje XML, u otros) que se integrará en la respuesta 52 del bloque función WEB de recepción 21,
- \bullet
- en el caso de los datos de configuración 229 de un bloque función WEB de emisión 22, medios para realizar una correspondencia entre por una parte los parámetros de entradas IN_1, IN_n del bloque función WEB de emisión 22 y por otra parte de los elementos de una petición HTTP 51 (headers), de los elementos de una trama XML o de una trama URL codificada contenidos en una petición HTTP 51,
- \bullet
- en el caso de los datos de configuración 229 de un bloque función WEB de emisión 22, medios para realizar una correspondencia entre por una parte elementos de una respuesta HTTP 52 (headers) o elementos de una trama XML contenidos en una petición HTTP 52 y por otra parte los parámetros de salidas OUT_1, OUT_n del bloque función WEB de emisión 22,
- \bullet
- en el caso de los datos de configuración 219 de un bloque función WEB de recepción 21, medios para realizar una correspondencia entre por una parte elementos de una petición HTTP 51 (headers), elementos de una trama XML o de una trama URL codificada contenidos en una petición HTTP 51 y por otra parte los parámetros de salidas OUT_1, OUT_n del bloque función WEB de recepción 21,
- \bullet
- en el caso de los datos de configuración 219 de un bloque función WEB de recepción 21, medios para realizar una correspondencia entre por una parte los parámetros de entradas IN_1, IN_n del bloque función WEB recepción 21 y por otra parte elementos de una respuesta HTTP 52 (headers) o elementos de una trama XML contenidos en una petición HTTP 52,
- \bullet
- el formato de las tramas (llamado "Content Type") que un bloque función WEB estará en condiciones de generar o de interpretar. Este aspecto es importante pues así se autorizará la toma en cuenta de las futuras evoluciones de la WEB. En efecto, gracias a este parametrado y a partir de protocolos estabilizados (HTTP y XML), será posible integrar librerías de datos (esquemas XML) con el fin de poder implementar nuevos protocolos en evolución.
Los medios para realizar una correspondencia
entre los parámetros de entradas/salidas de un bloque función y los
elementos de una trama XML, de una trama URL o de una
petición/respuesta HTTP son implementados por el bloque función y
pueden recurrir a una sofisticación variable según la flexibilidad
de uso deseada y la complejidad del formato a interpretar.
Para una buena comprensión de la presente
invención, ejemplos de medios para realizar una correspondencia se
describen a continuación. Estos ejemplos se ciñen a una
implementación simple, que corresponde al caso de bloques función
capaces de aceptar solo un formato rígido de petición y de producir
igualmente solo un formato rígido de respuesta. Sin embargo el
estado de la técnica informática permitía fácilmente producir, a
partir de este caso, variantes más sofisticadas tanto en lo que
respecta a los formatos de conversión entre los datos del equipo de
automatismos y los datos textuales WEB como en lo que respecta al
formato del documento WEB propiamente dicho.
Para satisfacer los cuatro casos mencionados
anteriormente, los medios para realizar una correspondencia se
basan en dos mecanismos:
- a)
- el análisis de una trama entrante (respuesta o petición recibida) para extraer de ella los parámetros de salidas OUT_1, OÜT-n del bloque función. Este análisis se basa en una descripción de la trama que permite encontrar de nuevo el lugar de los parámetros y, para cada parámetro, una descripción de la conversión entre el formato textual contenido en la petición y el formato interno del equipo de automatismo. Este caso se aplica tanto en la emisión de una petición por un bloque función WEB de emisión como en la emisión de una respuesta por un bloque función WEB de recepción.
- b)
- la síntesis de una trama a emitir (petición o respuesta a emitir) a partir de los parámetros de entrada IN_1, IN-n del bloque función. Esta síntesis utiliza igualmente dos tipos de elementos: una trama-tipo y reglas de sustitución que permiten introducir el valor de los parámetros.
La configuración de un bloque función dado
comprende por consiguiente dos partes específicamente asignadas al
análisis y a la síntesis.
Ejemplo de la descripción de conversión para una
petición entrante en un bloque función WEB de recepción formateado
según el lenguaje XML:
Al inicio de la aplicación, el código programa
del bloque función analiza esta descripción y registra la
correspondencia entre las zonas del documento esperado (en el
interior de las etiquetas: <type> y <num_requete>, por
si mismos incluidos en una etiqueta <surveillance>) y los
parámetros del bloque función.
A la recepción de la petición siguiente:
el código programa del bloque
función posiciona los parámetros de salida indicados: OUT_1 =
"alarma", OUT_2 =
58.
Ejemplo de la descripción de conversión para la
respuesta a emitir en un bloque función WEB de recepción:
Al inicio de la aplicación, el código programa
del bloque función registra esta descripción así como los
emplazamientos donde deberá fijar los valores de los parámetros de
entradas así como la dirección de estos parámetros de entradas en
la memoria del equipo de automatismo.
En la activación de la respuesta por el programa
aplicación, convierte los parámetros de entradas IN_1 a IN_5 e
introduce el resultado de esta conversión en los emplazamientos
memorizados y luego provoca el envió de la respuesta recurriendo a
una función de la parte genérica de un bloque función WEB.
Así, para valores corrientes tales como: IN_1 =
2, IN_2 = true, IN_3 = "Alarme temperature", IN_4 = 1234, IN 5
= 58, es fácil generar el documento de respuesta siguiente:
Como ya se ha precisado anteriormente, el
ejemplo es sencillo pero se podrán utilizar representaciones más
flexibles por ejemplo:
- -
- Control de la conversión de datos, por ejemplo utilizando el formalismo del lenguaje C (printf y scanf);
- -
- Control de la validez y del formato de un documento recibido, por ejemplo utilizando un analizador con formato SAX ó DOM, ó XSL-T;
- -
- Generación de un documento de forma variable, utilizando los valores de los parámetros de entrada IN_x para dirigir una transformación XSL-T.
La concepción de un programa aplicación se
realiza habitualmente gracias a una estación de programación que
ofrece particularmente todas las funcionalidades de
lectura/escritura de un programa aplicación de automatismo, de
carga/descarga en un equipo de automatismo y de
vigilancia/visualización de su desarrollo en el equipo de
automatismo. Una de las ventajas de la presente invención reside en
el hecho de que la integración de los bloques función WEB en el
programa aplicación 20 es inmediata ya que la conexión de los
bloques función WEB con las instrucciones del programa aplicación
20 se realiza directamente con la estación de programación que
permite escribir este programa aplicación. Por medio de dicha
estación de programación, el diseñador de un programa de aplicación
es por consiguiente susceptible de visualizar, modificar, introducir
o suprimir bloques función WEB 21, 22 sin otro conocimiento
particular que los que le permiten concebir el programa aplicación
20, lo cual facilitará grandemente la apertura de las comunicaciones
WEB en las aplicaciones de automatismo.
La estación de programación puede parametrar
directamente en forma de texto los datos de configuración 219, 229
de los bloques función WEB 21, 22, haciéndolos también fácilmente
accesibles al diseñador del programa aplicación. Se puede, por
ejemplo, considerar que los datos de configuración 219, 229 sean
visualizables en lenguaje claro y modificables en una ventana
específica, que se abre cuando el diseñador apunta sobre la
representación gráfica de un bloque función WEB en la estación de
programación.
Además, la estación de programación puede
utilizar librerías de bloques función WEB preconfigurados,
memorizables y manipulables a partir de la estación de programación
y ofrecer juegos de bloques función WEB especializados en un tipo
de contenido y/o un protocolo implementado con la ayuda de HTTP.
Entre los ejemplos que pueden ser incluidos en tales librerías, se
pueden citar: un bloque función servidor HTML, un bloque función
servidor WML, un bloque función cliente o servidor SOAP, etc... Así,
estas librerías facilitan el trabajo de un diseñador proponiéndole
varios bloques función preconfigurados, que puede introducir e
instalar rápidamente en su programa aplicación.
Cuando una petición 51 es recibida por un equipo
de automatismo 10, la interfaz HTTP 15 del equipo de automatismo 10
la analiza y detecta si la dirección URL destinataria contenida en
la petición 51 corresponde a la dirección URL de un bloque función
WEB de recepción 21 del equipo de automatismo 10. Sí este es el
caso, la interfaz HTTP 15 juega el papel de servidor HTTP
realizando el encaminamiento y señalando al bloque función WEB de
recepción 21 la llegada de la petición 51. La dirección URL del
expedidor de la petición 51 se memoriza para estar en disposición
de reenviar la respuesta 52 que será elaborada por el bloque función
WEB de recepción 21.
Cuando una petición 51 es emitida por un bloque
función WEB de emisión 22 de un equipo de automatismo 10, la
interfaz HTTP 15 de este equipo de automatismo juega el papel de
cliente HTTP y encamina la petición a la dirección URL destinataria
contenida en la petición 51.
Se entiende que se puede, sin salir del marco de
la invención, concebir otras variantes y perfeccionamientos de
detalle y de incluso considerar la utilización de medios
equivalentes.
Claims (13)
1. Sistema de comunicación de un equipo de
automatismo (10) en una red TCP/IP (50), cuyo equipo de automatismo
(10) controla una aplicación de automatismo desarrollando un
programa aplicación (20) escrito en uno o varios lenguajes
conformes a la norma IEC1131-3 donde el sistema de
comunicación comprende:
- -
- una función servidor WEB implementada en el interior del programa aplicación (20),
- -
- medios de intercambio que comprenden al menos un bloque función WEB de recepción (21) y al menos un bloque función WEB de emisión (22) que están integrados en el programa aplicación (20) y que interactúan con el programa aplicación (20),
- -
- una interfaz HTTP (15) en el equipo de automatismo (10) capaz de conducir los mensajes procedentes de la red TCP/IP (50) a un bloque función WEB de recepción (21) identificado por una dirección URL, y realizar la conducción de los mensajes procedentes de un bloque función WEB de emisión (22) a una dirección URL en la red TCP/IP (50) caracterizándose el sistema de comunicación porque comprende igualmente:
- -
- una función cliente WEB implementada en el interior del programa aplicación.
\vskip1.000000\baselineskip
2. Sistema de comunicación según la
reivindicación 1, caracterizado por el hecho de que un bloque
función WEB (21, 22) comprende un código programa genérico así como
datos de configuración (219, 229) que son específicos a cada bloque
función WEB.
3. Sistema de comunicación según la
reivindicación 2, caracterizado por el hecho de que los datos
de configuración (219, 229) de un bloque función WEB (21, 22)
incluyen el formato general de tramas intercambiadas por el bloque
función WEB (21, 22), el tipo de petición HTTP que el bloque función
WEB (21, 22) recibe o emite y la dirección URL relacionada con el
bloque función WEB (21, 22) en el equipo de automatismo (10).
4. Sistema de comunicación según la
reivindicación 2, caracterizado por el hecho de que un
diseñador del programa aplicación (20) es capaz de configurar en
forma textual los datos de configuración (219, 229) de los bloques
función WEB (21, 22) integrados en un programa aplicación (20).
5. Sistema de comunicación según la
reivindicación 2, caracterizado por el hecho de que los datos
de configuración (219) de un bloque función WEB de recepción (21)
contienen medios para realizar una correspondencia entre los
elementos de una petición HTTP (51) y los parámetros de salidas
(OUT_1, 0UT_n) del bloque función WEB de recepción (21) y para
realizar una correspondencia entre los parámetros de entradas (IN_1,
IN_n) del bloque función WEB recepción (21) y de los elementos de
una respuesta HTTP (52).
6. Sistema de comunicación según la
reivindicación 2, caracterizado por el hecho de que los datos
de configuración (229) de un bloque función WEB de emisión (22)
contienen medios para realizar una correspondencia entre los
parámetros de entradas (IN_1, IN_n) del bloque función WEB de
emisión (22) y elementos de una petición HTTP (51) y para realizar
una correspondencia entre elementos de una respuesta HTTP (52) y los
parámetros de salidas (OUT_1, OUT_n) del bloque función WEB de
emisión (22).
7. Sistema de comunicación según la
reivindicación 2, caracterizado por el hecho de que el
contenido de una petición HTTP (51) o de una respuesta HTTP (52) es
una trama XML.
8. Sistema de comunicación según la
reivindicación 7, caracterizado por el hecho de que los datos
de configuración (219) de un bloque función WEB de recepción (21)
contienen medios para realizar una correspondencia entre los
elementos de una trama XML contenidos en una petición HTTP (51) y
los parámetros de salidas (OUT_1, OUT_n) del bloque función WEB de
recepción (21) y para realizar una correspondencia entre los
parámetros de entradas (IN_1, IN_n) del bloque función WEB de
recepción (21) y de los elementos de una trama XML contenidos en
una respuesta HTTP (52).
9. Sistema de comunicación según la
reivindicación 7, caracterizado por el hecho de que los datos
de configuración (229) de un bloque función WEB de emisión (22)
contienen medios para realizar una correspondencia entre los
parámetros de entradas (IN_1, IN_n) del bloque función WEB de
emisión (22) y los elementos de una trama XML contenidos en una
petición HTTP (51) y para realizar una correspondencia entre los
elementos de una trama XML contenidos en una respuesta HTTP (52) y
los parámetros de salidas (OUT_1, OUT_n) del bloque función WEB de
emisión (22).
10. Sistema de comunicación según la
reivindicación 2, caracterizado por el hecho de que el
contenido de una petición HTTP (51) es una trama URL
codificada.
11. Sistema de comunicación según la
reivindicación 10, caracterizado por el hecho de que los
datos de configuración (219) de un bloque función WEB de recepción
(21) contienen medios para realizar una correspondencia entre los
elementos de una trama URL codificada contenidos en una petición
HTTP (51) y los parámetros de salidas (OUT_1,
OUT-n) del bloque función WEB de recepción (21).
12. Sistema de comunicación según la
reivindicación 10, caracterizado por el hecho de que los
datos de configuración (229) de un bloque función WEB de emisión
(22) contienen medios para realizar una correspondencia entre los
parámetros de entradas (IN_1, IN_n) del bloque función WEB de
emisión (22) y los elementos de una trama URL codificada contenidos
en una petición HTTP (51).
13. Equipo de automatismo, caracterizado
por el hecho de que contiene un programa aplicación que integra un
sistema de comunicación en una red TCP/IP según una de las
reivindicaciones anteriores.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| FR0008567A FR2811183B1 (fr) | 2000-06-30 | 2000-06-30 | Bloc fonction web dans un equipement d'automatisme |
| FR0008567 | 2000-06-30 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2339741T3 true ES2339741T3 (es) | 2010-05-25 |
Family
ID=8852007
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES01401675T Expired - Lifetime ES2339741T3 (es) | 2000-06-30 | 2001-06-25 | Bloque de funcion web en un equipo de automatismo. |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US6915330B2 (es) |
| EP (1) | EP1168768B1 (es) |
| DE (1) | DE60141433D1 (es) |
| ES (1) | ES2339741T3 (es) |
| FR (1) | FR2811183B1 (es) |
Families Citing this family (34)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2813471B1 (fr) * | 2000-08-31 | 2002-12-20 | Schneider Automation | Systeme de communication d'un equipement d'automatisme base sur le protocole soap |
| US7072946B2 (en) | 2001-05-31 | 2006-07-04 | Juniper Networks, Inc. | Network router management interface with API invoked via login stream |
| US7054901B2 (en) * | 2001-05-31 | 2006-05-30 | Juniper Networks, Inc. | Network management interface with selective rendering of output |
| US8650321B2 (en) * | 2001-07-24 | 2014-02-11 | Digi International Inc. | Network architecture |
| US7111206B1 (en) | 2001-09-19 | 2006-09-19 | Juniper Networks, Inc. | Diagnosis of network fault conditions |
| CN100351828C (zh) * | 2002-06-06 | 2007-11-28 | 联想(北京)有限公司 | 基于分布式文件系统的文件存储系统及其文件访问方法 |
| EP1315358A1 (en) * | 2002-09-12 | 2003-05-28 | Agilent Technologies Inc. a Delaware Corporation | Data-transparent management system for controlling measurement instruments |
| US7904583B2 (en) * | 2003-07-11 | 2011-03-08 | Ge Fanuc Automation North America, Inc. | Methods and systems for managing and controlling an automation control module system |
| DE10336648A1 (de) * | 2003-08-09 | 2005-03-03 | Abb Research Ltd. | System und Verfahren zur web-basierten Überwachung und Steuerung mehrerer räumlich verteilter Anlagen |
| US7171454B2 (en) * | 2003-08-13 | 2007-01-30 | Siemens Energy & Automation, Inc. | Method for providing real-time production information using in-situ web services embedded in electronic production equipment |
| US8554877B2 (en) * | 2005-08-19 | 2013-10-08 | Rockwell Automation Technologies, Inc. | Motor drive with integrated server module |
| US7587251B2 (en) * | 2005-12-21 | 2009-09-08 | Rockwell Automation Technologies, Inc. | Remote monitoring and control of an I/O module |
| EP1821165B1 (de) * | 2006-02-17 | 2010-01-20 | Siemens Aktiengesellschaft | Nutzung von Variablen in mehreren Automatisierungssystemen |
| EP2093676A1 (de) * | 2008-02-20 | 2009-08-26 | Siemens Aktiengesellschaft | Verfahren zur Generierung von Funktionsbausteinen für Webdienste. |
| EP2148281A1 (de) * | 2008-07-22 | 2010-01-27 | Siemens Aktiengesellschaft | Speicherprogrammierbares Steuerungssystem und Verfahren zur automatisierten Erstellung von zusammengesetzten Webseiten |
| US8909641B2 (en) | 2011-11-16 | 2014-12-09 | Ptc Inc. | Method for analyzing time series activity streams and devices thereof |
| US9098312B2 (en) | 2011-11-16 | 2015-08-04 | Ptc Inc. | Methods for dynamically generating an application interface for a modeled entity and devices thereof |
| US9576046B2 (en) | 2011-11-16 | 2017-02-21 | Ptc Inc. | Methods for integrating semantic search, query, and analysis across heterogeneous data types and devices thereof |
| DE102012112225B3 (de) * | 2012-12-13 | 2014-01-30 | Schneider Electric Automation Gmbh | Verfahren zum Austausch von gerätespezifischen Daten zwischen Geräten und/oder Systemen verschiedener Netzwerksysteme sowie Bussystem zur Durchführung des Verfahrens |
| FR3001553B1 (fr) * | 2013-01-31 | 2018-11-02 | Wesby Sarl | Dispositif de commande pour un systeme d'automatisme |
| EP2770434B1 (de) | 2013-02-21 | 2016-09-14 | dSPACE digital signal processing and control engineering GmbH | Verfahren zur Durchführung einer Inventarisierung der an ein Steuergeräte-Testsystem angeschlossenen Hardware-Komponenten |
| EP2770389B1 (de) | 2013-02-21 | 2019-05-08 | dSPACE digital signal processing and control engineering GmbH | Verfahren zur Durchführung einer Konfiguration eines Steuergeräte-Testsystems |
| JP6285010B2 (ja) | 2013-03-15 | 2018-02-28 | ピーティーシー インコーポレイテッド | 意味論的モデル化およびタグ付けを使用してアプリケーションを管理する方法およびその装置 |
| WO2015143416A1 (en) | 2014-03-21 | 2015-09-24 | Ptc Inc. | Systems and methods for developing and using real-time data applications |
| US9961058B2 (en) | 2014-03-21 | 2018-05-01 | Ptc Inc. | System and method of message routing via connection servers in a distributed computing environment |
| US9462085B2 (en) | 2014-03-21 | 2016-10-04 | Ptc Inc. | Chunk-based communication of binary dynamic rest messages |
| US9350812B2 (en) | 2014-03-21 | 2016-05-24 | Ptc Inc. | System and method of message routing using name-based identifier in a distributed computing environment |
| US9762637B2 (en) | 2014-03-21 | 2017-09-12 | Ptc Inc. | System and method of using binary dynamic rest messages |
| US9560170B2 (en) | 2014-03-21 | 2017-01-31 | Ptc Inc. | System and method of abstracting communication protocol using self-describing messages |
| US10313410B2 (en) | 2014-03-21 | 2019-06-04 | Ptc Inc. | Systems and methods using binary dynamic rest messages |
| US9350791B2 (en) | 2014-03-21 | 2016-05-24 | Ptc Inc. | System and method of injecting states into message routing in a distributed computing environment |
| US10025942B2 (en) | 2014-03-21 | 2018-07-17 | Ptc Inc. | System and method of establishing permission for multi-tenancy storage using organization matrices |
| US9467533B2 (en) | 2014-03-21 | 2016-10-11 | Ptc Inc. | System and method for developing real-time web-service objects |
| CN103941675B (zh) * | 2014-03-27 | 2016-06-29 | 北京卓越经纬测控技术有限公司 | 基于无线网络的安全监测管理系统 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5956487A (en) * | 1996-10-25 | 1999-09-21 | Hewlett-Packard Company | Embedding web access mechanism in an appliance for user interface functions including a web server and web browser |
| US6282454B1 (en) * | 1997-09-10 | 2001-08-28 | Schneider Automation Inc. | Web interface to a programmable controller |
| US6370569B1 (en) * | 1997-11-14 | 2002-04-09 | National Instruments Corporation | Data socket system and method for accessing data sources using URLs |
| US6201996B1 (en) * | 1998-05-29 | 2001-03-13 | Control Technology Corporationa | Object-oriented programmable industrial controller with distributed interface architecture |
| FR2804218B1 (fr) * | 2000-01-26 | 2002-03-29 | Schneider Automation | Automate programmable dote de fonctions de communication dans une architecture client-serveur |
-
2000
- 2000-06-30 FR FR0008567A patent/FR2811183B1/fr not_active Expired - Fee Related
-
2001
- 2001-06-25 EP EP01401675A patent/EP1168768B1/fr not_active Revoked
- 2001-06-25 DE DE60141433T patent/DE60141433D1/de not_active Expired - Lifetime
- 2001-06-25 ES ES01401675T patent/ES2339741T3/es not_active Expired - Lifetime
- 2001-06-29 US US09/893,662 patent/US6915330B2/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| FR2811183B1 (fr) | 2006-09-01 |
| EP1168768B1 (fr) | 2010-03-03 |
| DE60141433D1 (de) | 2010-04-15 |
| FR2811183A1 (fr) | 2002-01-04 |
| US20020016815A1 (en) | 2002-02-07 |
| US6915330B2 (en) | 2005-07-05 |
| EP1168768A1 (fr) | 2002-01-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2339741T3 (es) | Bloque de funcion web en un equipo de automatismo. | |
| US7366752B2 (en) | Communication system of an automation equipment based on the soap protocol | |
| US6697967B1 (en) | Software for executing automated tests by server based XML | |
| EP0576574B1 (en) | Programming language structures for use in a network for communicating, sensing and controlling information | |
| RU2426234C2 (ru) | Система, способ и устройство для контроля и управления удаленными приборами | |
| US8812684B1 (en) | Messaging configuration system | |
| CN108667807A (zh) | 一种基于监控云平台与网关的协议自适应方法及系统 | |
| CN101421722A (zh) | 用于提供剪辑以在远程设备上进行查看的方法 | |
| CN101197833A (zh) | 分布式消息引擎和系统 | |
| CN103095609A (zh) | 一种基于物联网终端的接入适配方法和装置 | |
| Johansson | Profinet industrial internet of things gateway for the smart factory | |
| WO2021171125A1 (en) | Messaging campaign manager, messaging campaign manager system, bulk or mass messaging system, method of bulk or mass messaging, computer program, computer-readable medium, graphical user interface. | |
| JP2014106938A (ja) | 機器管理システム | |
| CN109995782B (zh) | 一种信息处理方法、设备、系统及计算机存储介质 | |
| CN110177030B (zh) | 工业网关控制测试方法 | |
| CN114095303A (zh) | 通信设备、数据传输方法及电子设备 | |
| US20070112793A1 (en) | Model publishing framework | |
| CN111209613A (zh) | 一种智能产品的快速设计方法及系统 | |
| Culler et al. | Embedded web services: making sense out of diverse sensors | |
| Altamirano et al. | A scalable intelligent room based on wireless sensor networks and RFIDs | |
| WO2018095637A1 (en) | Device and method for transmitting data | |
| CN116016717A (zh) | 一种基于多协议通信的物联设备接入方法及系统 | |
| Yıldırım | Data sharing using mqtt and zigbee-based dds on resource-constrained contiki-based devices | |
| Ismail et al. | Service-Oriented Architectures for Interoperability in Industrial Enterprises | |
| CN117130318A (zh) | 工业数据采集方法、装置、系统和可读存储介质 |