MXPA99003084A

MXPA99003084A - Una interfase accesible por red para una red de control de proceso

Info

Publication number: MXPA99003084A
Application number: MXPA/A/1999/003084A
Authority: MX
Inventors: H Larson Brent; A Burns Harry; K Brown Larry
Original assignee: Fisher Controls International Inc
Priority date: 1996-10-04
Filing date: 1999-03-31
Publication date: 2000-07-01

Abstract

La presente invención se refiere a una interfase entre una red de comunicaciones remota y un sistema de control de proceso, incluye un dispositivo de almacenamiento, una pila de software de comunicación y una capa de software del usuario. La capa de software del usuario hace posible la interconexión entre la red de comunicaciones remota y el sistema de control de proceso, dirigiendo la pila de software de comunicación para operar en el sistema de control de proceso, utilizando un protocolo de comunicación del proceso, mediante la supervisión del tráfico de mensajes sobre la pila del software de comunicación, o copiando el tráfico de mensajes solicitado hacia el dispositivo de almacenamiento. La capa de software del usuario también incluye un software de interfase de medios que permite tener acceso al dispositivo de almacenamiento mediante la red de comunicaciones remota, para suministrar de esta manera datos específicos a un dispositivo conectado con la red de comunicaciones remota.

Description

UNA I TERFASE ACCESIBLE POR RED PARA UNA RED DE CONTROL DE PROCESO SOLICITUD RELACIONADA Esta es una continuación parcial de la Solicitud de Patente de los Estados Unidos de Norteamérica con Número de Serie 08/726,264 presentada el 4 de octubre de 1996.

CAMPO DE LA INVENCIÓN La presente invención se refiere en general a redes de control de proceso, y más específicamente, a una interfase gue comunica datos entre una red de control de proceso que tiene funciones de control distribuido y una red de comunicaciones remotas .

DESCRIPCIÓN DE LA TÉCNICA RELACIONADA Los procesos grandes, tales como los procesos de manufactura y refinación químicos, de petróleo, y otros, incluyen numerosos dispositivos de campo dispuestos en diferentes localizaciones para medir y controlar los parámetros de un proceso, con el fin de efectuar de esta manera el control del proceso. Estos dispositivos de campo, por ejemplo, pueden ser sensores, tales como sensores de temperatura, de presión, y de velocidad de flujo, así como elementos de control, tales como válvulas y conmutadores. Históricamente, la industria de control de proceso utilizaba operaciones manuales como la lectura manual de los medidores de nivel y de presión, girar las ruedas de válvulas, etcétera, para operar los dispositivos de campo de medición y control adentro de un proceso. Empezando en el Siglo XX, la industria de control de proceso empezó a utilizar un control neumático local, en donde se colocaban controladores neumáticos locales, transmisores, y colocadores de válvulas, en diferentes lugares dentro de una planta de proceso, para efectuar el control de ciertos lugares de la planta. Con el surgimiento del sistema de control distribuido (DCS) basado en microprocesador en la década de 1970, llegó a ser prevaleciente el control de proceso electrónico distribuido en la industria de control de proceso. Como se sabe, un sistema de control distribuido incluye una computadora analógica o digital, tal como un controlador lógico programable, conectada con numerosos dispositivos electrónicos de supervisión y control, tales como sensores electrónicos, transmisores, transductores de corriente a presión, colocadores de válvulas, etcétera, localizados a través de todo un proceso. La computadora del sistema de control distribuido almacena e implementa un esquema de control centralizado y con frecuencia complejo, para efectuar la medición y el control de los dispositivos dentro del proceso, con el fin de controlar de esta manera los parámetros del proceso de acuerdo con algún esquema de control global.

Normalmente, sin embargo, el esquema de control implementado por un sistema de control distribuido es propietario para el fabricante del controlador del sistema de control distribuido, lo cual a su vez hace que el sistema de control distribuido sea difícil y costoso de expandir, perfeccionar, reprogramar, y servir, debido a que el proveedor del sistema de control distribuido debe llegar a involucrarse de una manera integral para realizar cualquier de estas actividades. Además, el equipo que se puede utilizar mediante, o que se puede conectar adentro de, cualquier sistema de control distribuido particular, puede ser limitado, debido a la naturaleza propietaria del controlador del sistema de control distribuido, y al hecho de que el proveedor del controlador del sistema de control distribuido puede no soportar ciertos servicios o funciones de dispositivos fabricados por otros vendedores. Para superar algunos de los problemas inherentes en el uso de sistemas de control distribuido propietarios, la industria de control de proceso ha desarrollado un número de protocolos de comunicación estándares abiertos, incluyendo, por ejemplo, los protocolos HARTR, PROFIBUSR, WORLDFIPR, Device-Net , y CAN, los cuales hacen posible que se utilicen juntos los dispositivos de campo hechos por diferentes fabricantes adentro de la misma red de control del proceso. De hecho, se puede utilizar cualquier dispositivo de campo que se conforme a uno de estos protocolos adentro de un proceso, para comunicarse con, y para ser controlado por, un controlador del sistema de control distribuido u otro controlador que soporte el protocolo, inclusive cuando ese dispositivo de campo sea hecho por un fabricante diferente del fabricante del controlador del sistema de control distribuido. Más aún, ahora hay un movimiento dentro de la industria de control de proceso para descentralizar el control del proceso, y de esta manera, simplificar los controladores de sistemas de control distribuido, o eliminar la necesidad de controladores de sistemas de control distribuido hasta un gran grado. El control descentralizado se obtiene haciendo que los dispositivos de control del proceso montados en campo, tales como colocadores de válvulas, transmisores, etcétera, realicen una o más funciones de control del proceso, y comunicando entonces los datos a través de una estructura de barra colectora para ser utilizados por otros dispositivos de control del proceso en la realización de otras funciones de control. Para implementar estas funciones de control, cada dispositivo de control de proceso incluye un microprocesador que tiene la capacidad para realizar una función de control, así como la capacidad para comunicarse con otros dispositivos de control del proceso, utilizando un protocolo de comunicación estándar y abierto. De esta manera, los dispositivos de campo hechos por diferentes fabricantes se pueden interconectar adentro de una red de control del proceso, para comunicarse unos con otros, y para realizar una o más funciones de control del proceso, formando un ciclo de control sin la intervención de un controlador del sistema de control distribuido. El protocolo de barra colectora de dos alambres, todo digital, que ¡está siendo promulgado ahora por la Fieldbus Foundation, conocido como el protocolo Fieldbus FOUNDATION1^ (en lo sucesivo "Fieldbus"), es un protocolo de comunicación abierto que permite que los dispositivos hechos por diferentes fabricantes interoperen y se comuniquen unos con otros por medio de una barra colectora estándar, para efectuar el control descentralizado adentro de un proceso. Por consiguiente, los sistemas de control de proceso se han expandido desde los ciclos de comunicación local que incluyen un número de dispositivos de campo conectados con uno o más controladores, hasta redes de comunicación a gran escala. Sin embargo, actualmente es difícil transmitir la información del dispositivo de campo sobre una red de control del proceso a otras redes de comunicación, tal vez sobre grandes distancias, para efectuar, por ejemplo, análisis de funcionamiento, prueba de diagnóstico, mantenimiento, y resolución de problemas, y similares. De hecho, no se ha encontrado una técnica satisfactoria para transferir la información del dispositivo de campo a nivel fundamental, tal como los datos de válvula de control del proceso. Aunque la transferencia de la información del dispositivo de campo se ha intentado utilizando comunicación de fibra óptica entre múltiples sitios de control de proceso remotos, esta interconexión de fibra óptica entre los sitios es costosa, y con frecuencia se presentan conflictos cuando los múltiples dispositivos tratan de enviar información al mismo tiempo. Adicionalmente, los sistemas de fibra óptica incluyen complejos controladores de comunicación que arbitran el uso de la barra colectora. Debido a que cada transmisión de datos de este sistema está sincronizada con la recopilación de datos en los dispositivos de campo individuales, se detiene la recopilación de datos mientras se espera el acceso a la línea de fibra óptica, y se detienen las comunicaciones mientras se espera la recopilación de datos. La transmisión de datos de campo sobre una red, involucra convencionalmente pasar paquetes de información encapsulados a través de conexiones de red a red (normalmente redes de LAN a LAN) . Los paquetes se encapsulan y tienen parámetros de transferencia agregados a los mismos en cada nodo de la red, de tal manera que los paquetes de información obtienen información extraña adicional, y requieren de un tiempo de procesamiento en cada nodo. Esta técnica de comunicación remota convencional se hace más lenta por las demoras en cada nodo, y es ineficiente debido a la adición de información extraña en cada encapsulación. Por consiguiente, es deseable proporcionar un dispositivo de interfase simple que comunique datos del dispositivo de campo entre una red de control del proceso y una red de comunicación u otros sitios remotos, sin requerir que los dispositivos de campo adentro de la red de control del proceso detengan su operación mientras están esperando acceso a la red de comunicación, y sin requerir el procesamiento innecesario en cada nodo de la red.

COMPENDIO DE LA INVENCIÓN La presente invención se refiere a un dispositivo de interfase que se interconecta entre una red de comunicaciones y una red de control del proceso, que no altera las comunicaciones que se presentan en la red de control el proceso, y que no requiere de la adición de datos extraños a los paquetes sobre la red de comunicación. El dispositivo de interfase de la presente invención se puede formar mediante una computadora que ejecute un protocolo de comunicación del software asociado con, por ejemplo, el protocolo de comunicación Fieldbus, y una capa de software del usuario que procese las solicitudes Fieldbus desde un solo usuario o desde múltiples usuarios a través de una red de área local (LAN) o una red de área amplia (WAN) . La capa de software del usuario proporciona una interfase directa a la red de comunicación Fieldbus en un dispositivo, hasta un sitio remoto, por medio de una conexión de la red.

De conformidad con la presente invención, una interfase entre una red de comunicaciones y un sistema de control de proceso, incluye una pila de software de comunicación que opera en un sistema de control del proceso, y un software de interfase que incluye una rutina que supervisa el tráfico de mensajes sobre la pila de software de comunicación, una rutina que copia el tráfico de mensajes al almacenamiento, y una rutina de software de interfase del medio que permite el acceso remoto al almacenamiento . Se logran muchas ventajas mediante la interfase y método operativo descritos. Por ejemplo, el dispositivo de interfase de la presente invención convierte una operación de tiempo crítico de supervisión de los datos de campo de nivel bajo, en una operación que no es de tiempo crítico de transmisión de los datos hasta un sitio remoto. Otra ventaja es que la interfase y método descritos son altamente genéricos, y se pueden implementar en una amplia variedad de sistemas de control y redes, virtualmente en cualquier sistema de computación que utilice elementos de software estándares. Además, es conveniente que sólo se transfiera una pequeña cantidad de datos, es decir, los datos pertinentes o solicitados, y que la interfase reduzca sustancialmente el gasto excedente en tiempo y tamaño de transferencia de datos cuando comunique los datos del dispositivo de campo sobre una red de comunicaciones secundaria o remota.

Con la interfase de la presente invención, se pueden realizar o implementar prueba de diagnóstico, mantenimiento, y resolución de problemas desde un sitio remoto conectado con la red de control del proceso, por medio de una barra colectora de comunicaciones, tal como una LAN o una WAN. Los mensajes y la información convenientemente se transmiten muy rápidamente, y los datos se transmiten de una manera asincrónica e independiente entre el usuario local y el usuario remoto, de tal manera que se eliminan los problemas de sincronización.

BREVE DESCRIPCIÓN DE LOS DIBUJOS La Figura 1 es un diagrama de bloques esquemático de una red de control de proceso de ejemplo que utiliza el protocolo Fieldbus . La Figura 2 es un diagrama de bloques esquemático de tres dispositivos Fieldbus que tienen bloques de función en los mismos . La Figura 3 es un diagrama de bloques esquemático que ilustra los bloques de función adentro de algunos de los dispositivos de la red de control de proceso de la Figura 1. La Figura 4 es un esquema del ciclo de control para un ciclo de control de proceso adentro de la red de control de proceso de la Figura 1. La Figura 5 es un esquema de tiempo para un macrociclo de un segmento de la barra colectora de la red de control de proceso de la Figura 1. La Figura 6 es un diagrama de bloques esquemático que ilustra una red de sistema de control, que incluye una interfase Fieldbus accesible por red de conformidad con la presente invención. La Figura 7 es un diagrama de bloques esquemático que ilustra un sistema de computación adecuado que puede implementar una modalidad de una interfase Fieldbus accesible por red de conformidad con una modalidad de la presente invención. La Figura 8 es un diagrama de flujo que ilustra las operaciones realizadas por la interfase Fieldbus accesible por red de la presente invención. La Figura 9 es un diagrama de bloques esquemático que ilustra varios ejemplos de implementaciones de interfase Fieldbus accesible por red.

DESCRIPCIÓN DE LAS MODALIDADES PREFERIDAS Aunque la interfase Fieldbus accesible por red (NAFI) de la presente invención se describe con detalle en conjunto con una red de control del proceso que implementa funciones de control del proceso de una manera descentralizada o distribuida, utilizando un conjunto de dispositivos Fieldbus, se debe observar que el dispositivo NAFI de la presente invención se puede utilizar con redes de control de proceso que realicen funciones de control distribuido utilizando otros tipos de dispositivos de campo y protocolos de comunicación, incluyendo protocolos que se apoyen en otra cosa que no sean barras colectoras de dos alambres y protocolos que soporten comunicaciones analógicas y digitales. Por consiguiente, por ejemplo, el dispositivo NAFI de la presente invención se utilizar en cualquier red de control de proceso que realice funciones de control distribuido, inclusive cuando esta red de control de proceso utilice los protocolos de comunicación HART, PROFIBUS, etcétera, o cualesquiera otros protocolos de comunicación que existan ahora o que se puedan desarrollar en el futuro. De la misma manera, si se desea, el dispositivo NAFI de la presente invención se puede utilizar en redes de control de proceso que no tengan funcionesde control distribuido, sino, que en lugar de eso, utilicen un controlador centralizado o un esquema de control para controlar los dispositivos en el mismo. Antes de discutir los detalles del dispositivo NAFI de la presente invención, se proporcionará una descripción general del protocolo Fieldbus, los dispositivos de campo configurados de acuerdo con este protocolo, y la manera en que ocurre la comunicación en una red de control de proceso que utiliza el protocolo Fieldbus. Sin embargo, se debe entender que, aunque el protocolo Fieldbus es un protocolo de comunicación todo digital relativamente nuevo desarrollado para utilizarse en redes de control de proceso, este protocolo se conoce en la técnica y se describe con detalle en numerosos artículos, folletos, y especificaciones publicadas, distribuidas, y disponibles en, entre otros, la Fieldbus Foundation, una organización no lucrativa con oficinas centrales en Austin, Texas. En particular, el protocolo Fieldbus, y la manera de comunicarse con, y almacenar datos en, dispositivos que utilizan el protocolo Fieldbus, se describe con detalle en los manuales titulados Communications Technical Specification y User Layer Technical Specification de la Fieldbus Foundation, los cuales se incorporan a la presente como referencia en su totalidad. El protocolo Fieldbus es un protocolo de comunicación de dos vías, todo digital, en serie, que proporciona una interfase física estandarizada hacia un ciclo de dos alambres o un equipo de "campo" de interconexión de barra colectora, tal como sensores, accionadores, controladores, válvulas, etcétera, localizados en un medio ambiente de control del proceso o de instrumentación de, por ejemplo, una fábrica o una planta. El protocolo Fieldbus proporciona, en efecto, una red de área local para instrumentos de campo (dispositivos de campo) adentro de un proceso, que hace posible que estos dispositivos de campo realicen funciones de control en lugares distribuidos a través de toda una instalación de proceso, y se comuniquen unos con otros antes y después de la realización de estas funciones de control para implementar una estrategia de control global . Debido a que el protocolo Fieldbus hace posible que se distribuyan las funciones de control a través de toda una red de control de proceso, reduce la carga de trabajo de, o elimina enteramente la necesidad de, el controlador del proceso centralizado normalmente asociado con un sistema de control distribuido. Haciendo referencia a la Figura 1, una red de control de proceso 10 que utilice el protocolo Fieldbus puede incluir una central 12 conectada con un número de otros dispositivos, tales como un controlador lógico del programa (PLC) 13, un número de controladores 14, otro dispositivo central 15, y un conjunto de dispositivos de campo 16, 18, 20, 22, 24, 26, 28, 30, y 32, por medio de un ciclo Fieldbus o barra colectora de dos alambres 34. La barra colectora 34 incluye diferentes secciones o segmentos, 34a, 34b, y 34c, que están separados por dispositivos de puente 30 y 32. Cada una de las secciones 34a, 34b, y 34c interconecta un subconjunto de los dispositivos conectados a la barra colectora 34, para hacer posible las comunicaciones entre los dispositivos de una manera descrita posteriormente en la presente. Por supuesto, la red de la Figura 1 es ilustrativa solamente, habiendo muchas otras maneras en las cuales se pueda configurar una red de control de proceso utilizando el protocolo Fieldbus. Normalmente, se localiza un configurador en uno de los dispositivos, tal como la central 12, y es responsable de establecer o configurar cada uno de los dispositivos (que son dispositivos "inteligentes", porque cada uno incluye un microprocesador que puede realizar comunicación, y en algunos casos, funciones de control) , así como reconocer cuando se conecten nuevos dispositivos de campo a la barra colectora 34, cuando se remuevan los dispositivos de campo de la barra colectora 34, reconocer los datos generados por los dispositivos de campo 16-32, e interconectarse con una o más terminales de usuarios, las cuales se pueden localizar en la central 12 o en cualquier otro dispositivo conectado a la central 12 de cualquier manera. La barra colecta 34 soporta o permite la comunicación puramente digital de dos vías, y también puede proporcionar una señal de energía a cualquiera o todos los dispositivos conectados a la misma, tales como los dispositivos de campo 16-32. De una manera alternativa, cualquiera o todos los dispositivos 12-32 pueden tener sus propios suministros de energía, o se pueden conectar a suministros de energía externos por medio de alambres separados (no mostrados) . Aunque los dispositivos 12-32 se ilustran en la Figura 1 conectados a la barra colectora 34 en una conexión de tipo de barra colectora estándar, en donde se conectan múltiples dispositivos al mismo par de alambres que forman los segmentos de barra colectora 34a, 34b y 34c, el protocolo Fieldbus permite otras topologías de dispositivos/alambres, incluyendo las conexiones de punto a punto, en donde cada dispositivo se conecta con un controlador o con una central por medio de un par de alambres separados (similar a los sistemas DCS analógicos típicos de 4-20 mA) , y conexiones de árbol o "engrane", en donde cada dispositivo se conecta a un punto común en una barra colectora de dos alambres, que puede ser, por ejemplo, una caja de empalmes o un área de terminación en uno de los dispositivos de campo adentro de una red de control de proceso. Los datos se pueden enviar sobre los diferentes segmentos de barra colectora 34a, 34b, y 34c, a las mismas o diferentes velocidades de baudios de comunicación, de acuerdo con el protocolo Fieldbus. Por ejemplo, el protocolo Fieldbus proporciona una velocidad de comunicación de 31.25 Kbits/segundo (Hl) , ilustrado utilizado por los segmentos de barra colectora 34b y 34c de la Figura 1, y una velocidad de comunicación de 1.0 Mbits/segundo y/o de 2.5 Mbits/segundo (H2) , que se utilizará normalmente para el control de proceso avanzado, la entrada/salida remota, y las aplicaciones de automatización en la fábrica de alta velocidad, y se ilustra utilizado por el segmento de barra colectora 34a de la Figura 1. De la misma manera, se pueden enviar datos sobre los segmentos de barra colectora 34a, 34b, y 34c de acuerdo con el protocolo Fieldbus, utilizando la señalización de modo de voltaje o la señalización de modo de corriente. Por supuesto, la longitud máxima de cada segmento de la barra colectora 34 no está estrictamente limitada, sino que, en su lugar, se determina por la velocidad de comunicación, el tipo de cable, el tamaño del alambre, la opción de energía de la barra colectora, etcétera, de esa sección. El protocolo Fieldbus clasifica los dispositivos que se pueden conectar a la barra colectora 34 en tres categorías primarias, es decir, dispositivos básicos, dispositivos maestros de enlace, y dispositivos de puente. Los dispositivos básicos (tales como los dispositivos 18, 20, 24, y 28 de la Figura 1) se pueden comunicar, es decir, envían y reciben señales de comunicación sobre o desde la barra colectora 34, pero no son capaces de controlar el orden o el tiempo de la comunicación que se presenta sobre la barra colectora 34. Los dispositivos maestros de enlace (tales como los dispositivos 16, 22, y 26, así como la central 12 de la Figura 1) , son dispositivos que se comunican sobre la barra colectora 34, y son capaces de controlar el flujo y el tiempo de las señales de comunicación sobre la barra colectora 34. Los dispositivos de puente (tales como los dispositivos 30 y 32 de la Figura 1) , son dispositivos configurados para comunicarse sobre, y para interconectar segmentos o ramificaciones individuales de una barra colectora Fieldbus, con el fin de crear redes de control de proceso más grandes. Si se desea, los dispositivos de puente pueden convertir entre diferentes velocidades de datos y/o diferentes formatos de señalización de datos utilizados en los diferentes segmentos de la barra colectora 34, pueden amplificar las señales que recorran entre los segmentos de la barra colectora 34, pueden filtrar las señales que fluyan entre los diferentes segmentos de la barra colectora 34, y pasan solamente las señales destinadas para ser recibidas por un dispositivo sobre uno de los segmentos de la barra colectora, con el que se acopla el puente, y/o pueden tomar otras medidas necesarias para enlazar diferentes segmentos de la barra colectora 34. Los dispositivos de puente que conectan los segmentos de barra colectora que operan a diferentes velocidades, deben tener capacidades maestras de enlace en el lado del segmento de velocidad más baja del puente. Las centrales 12 y 15, el controlador lógico del programa 13, y los controladores 14, pueden ser cualquier tipo de dispositivo Fieldbus, pero normalmente serán dispositivos maestros de enlace. Cada uno de los dispositivos 12-32 puede comunicarse sobre la barra colectora 34, y de una manera importante, puede realizar independientemente una o más funciones de control del proceso, utilizando los datos adquiridos por el dispositivo, a partir del proceso, o a partir de un dispositivo diferente por medio de señales de comunicación sobre la barra colectora 34. Por consiguiente, los dispositivos Fieldbus son capaces de implementar directamente porciones de una estrategia de control global que, en el pasado, eran realizadas por un controlador digital centralizado de un sistema de control distribuido. Para realizar funciones de control, cada dispositivo Fieldbus incluye uno o más "bloques" estandarizados, los cuales se implementan en un microprocesador adentro del dispositivo. En particular, cada dispositivo Fieldbus incluye un bloque de recursos, cero o más bloques de función, y cero o más bloques transductores. Estos bloques son referidos como objetos de bloque. Un bloque de recursos almacena y comunica datos específicos del dispositivo pertenecientes a algunas de las características de un dispositivo Fieldbus, incluyendo, por ejemplo, un tipo de dispositivo, una indicación de revisión del dispositivo, e indicaciones de si se puede obtener otra información específica del dispositivo adentro de una memoria del dispositivo. Aunque diferentes fabricantes de dispositivos pueden almacenar diferentes tipos de datos en el bloque de recursos de un dispositivo de campo, cada dispositivo de campo que se conforme al protocolo Fieldbus incluye un bloque de recursos que almacena algunos datos . Un bloque de función define e implementa una función de entrada, una función de salida, o una función de control asociada con el dispositivo de campo, y por consiguiente, los bloques de función son generalmente referidos como bloques de función de entrada, de salida, y de control. Sin embargo, pueden existir otras categorías de bloques de función, tales como bloques de función híbridos, o se pueden desarrollar en el futuro. Cada bloque de función de entrada o salida produce cuando menos una entrada de control de proceso (tal como una variable del proceso a partir de un dispositivo de medición del proseso) , o una salida de control de proceso (tal como una posición de válvula enviada a un dispositivo de accionamiento) , mientras que cada bloque de función de control utiliza un algoritmo (que puede ser de una naturaleza propietaria) para producir una o más salidas del proceso desde una o más entradas del proceso y entradas de control. Los ejemplos de los bloques de función estándares incluyen bloques de función de entrada analógica (AI) , salida analógica (AO) , polarización (B) , selector de control (CS) , entrada discreta (DI) , salida discreta (DO) , cargador manual (ML) , proporcional/derivado (PD) , proporcional/integral/derivado (PID) , relación (RA) , y selector de señales (SS) . Sin embargo, existen otros tipos de bloques de función, y se pueden definir o crear nuevos tipos de bloques de función para operar en el medio ambiente Fieldbus . Un bloque transductor acopla las entradas y salidas de un bloque de función con dispositivos de hardware locales, tales como sensores y accionadores de dispositivos, para hacer posible que los bloques de función lean las salidas de los sensores locales, y ordenen a los dispositivos locales que realicen una o más funciones, tales como mover un miembro de válvula. Los bloques transductores normalmente contienen información que es necesaria para interpretar las señales suministradas por un dispositivo local, y para controlar apropiadamente los dispositivos de hardware locales, incluyendo, por ejemplo, identificación de información del tipo de un dispositivo local, información de calibración asociada con un dispositivo local, etcétera. Un solo bloque transductor normalmente está asociado con cada bloque de función de entrada o salida. La mayoría de los bloques de función pueden generar indicaciones de alarma o de eventos, basándose en criterios previamente determinados, y son capaces de operar de una manera diferente en modos diferentes. Hablando en términos generales, los bloques de función pueden operar en un modo automático, en el cual, por ejemplo, el algoritmo de un bloque de función opera de una manera automática; un modo de operador en donde se controla manualmente la entrada o salida de un bloque de función; un modo fuera de servicio, en donde el bloque no opera; un modo en cascada, en donde la operación del bloque es afectada (determinada) por la salida de un bloque diferente; y uno o más modos remotos, en donde una computadora remota determina el modo del bloque. Sin embargo, existen otros modos de operación en el protocolo Fieldbus . Es importante que cada bloque puede comunicarse con otros bloques en el mismo o en diferentes dispositivos de campo sobre la barra colectora Fieldbus 34, utilizando formatos de mensajes estándares definidos por el protocolo Fieldbus. Como un resultado, combinaciones de bloques de función (en los mismos o en diferentes dispositivos) pueden comunicarse unas con otras para producir uno o más ciclos de control descentralizados. Por consiguiente, por ejemplo, un bloque de función PID de un dispositivo de campo, se puede conectar por medio de la barra colectora 34, para recibir una salida de un bloque de función AI en un segundo dispositivo de campo, para suministrar datos a un bloque de función AO en un tercer dispositivo de campo, y para recibir una salida del bloque de función AO como una retroalimentación, para crear un ciclo de control del proceso separado y aparte de cualquier controlador de sistema de control distribuido. De esta manera, las combinaciones de bloques de función sacan las funciones de control de un medio ambiente centralizado del sistema de control distribuido, lo cual permite que los controladores de múltiples funciones del sistema de control distribuido realicen funciones de supervisión o de coordinación, o se eliminen totalmente. Además, los bloques de función proporcionan una estructura gráfica orientada a los bloques para una fácil configuración de un proceso, y hacen posible la distribución de funciones entre los dispositivos de campo de diferentes proveedores, debido a que estos bloques utilizan un protocolo de comunicación consistente.

En adición a contener e implementar objetos de bloque, cada dispositivo de campo incluye uno o más objetos diferentes, incluyendo objetos de enlace, objetos de tendencias, objetos de alerta, y objetos de visión. Los objetos de enlace definen los enlaces entre las entradas y salidas de los bloques (tales como los bloques de función) , tanto internos para el dispositivo de campo, como a través de la barra colectora Fieldbus 34. Los objetos de tendencias permiten sacar las tendencias locales de los parámetros del bloque de función para el acceso por parte de otros dispositivos, tales como la central 12 o los controladores 14 de la Figura 1. Los objetos de tendencias retienen los datos históricos a corto plazo que pertenezcan, por ejemplo, a algún parámetro de bloque de función, y reportan estos datos a otros dispositivos o bloques de función por medio de la barra colectora 34 de una manera asincrónica. Los objetos de alerta reportan alarmas y eventos sobre la barra colectora 34. Estas alarmas o eventos pueden estar relacionados con cualquier evento que se presente adentro de un dispositivo o uno de los bloques de un dispositivo. Los objetos de visión son agrupaciones previamente definidas de parámetros de bloques utilizadas en la interconexión estándar de humano/máquina, y se pueden enviar a otros dispositivos para verse de cuando en cuando . Haciendo ahora referencia a la Figura 2, se ilustran tres dispositivos Fieldbus, los cuales pueden ser, por ejemplo, cualquiera de los dispositivos de campo 16-18 de la Figura 1, incluyendo los bloques de recursos 48, los bloques de función 50, 51, ó 52, y los bloques transductores 53 y 54. En el primer dispositivo, el bloque de función 50 (que puede ser un bloque de función de entrada) se acopla a través del bloque transductor 53 con un sensor 55, el cual puede ser, por ejemplo, un sensor de temperatura, un sensor de indicación de punto establecido, etcétera. En el segundo dispositivo, el bloque de función 51 (que puede ser un bloque de función de salida) se acopla a través del bloque transductor 54 con un dispositivo de salida tal como una válvula 56. En el tercer dispositivo, el bloque de función 52 (que puede ser un bloque de función de control) tiene un objeto de tendencias 57 asociado con el mismo, para determinar la tendencia del parámetro de entrada del bloque de función 52. Los objetos de enlace 58 definen los parámetros de bloque de cada uno de los bloques asociados, y los objetos de alerta 59 proporcionan alarmas o notificaciones de eventos para cada uno de los bloques asociados. Los objetos de visión 60 están asociados con cada uno de los bloques de función 50, 51, y 52, e incluyen o agrupan listas de datos para los bloques de función con los que están asociados. Estas listas contienen la información necesaria para cada una de un conjunto de diferentes vistas definidas. Por supuesto, los dispositivos de la Figura 2 son meramente de ejemplo, y se pueden proporcionar otros números y tipos de objetos de bloque, objetos de enlace, objetos de alerta, objetos de tendencias, y objetos de visión en cualquier dispositivo de campo. Haciendo ahora referencia a la Figura 3, un diagrama de bloques de la red de control de proceso 10, que ilustra los dispositivos 16, 18, y 24, como los dispositivos colocador/de válvulas, y los dispositivos 20, 22, 26, y 28 como transmisores, también ilustra los bloques de función asociados con el colocador/válvula 16, el transmisor 20, y el puente 30. Como se ilustra en la Figura 3, el colocador/válvula 16 incluye un bloque de recursor (RSC) 61, un bloque transductor (XDCR) 62, y un número de bloques de función, incluyendo un bloque de función de salida analógica (AO) 63, dos bloques de función PID 64 y 65, y un bloque de función de selección de señal (SS) 69. El transmisor 20 incluye un bloque de recursos 61, dos bloques transductores 62 , y dos bloques de función de entrada analógica (AI) 66 y 67. También, el puente 30 incluye un bloque de recursos 61, y un bloque de función PID 68. Como se entenderá, los diferentes bloques de función de la Figura 3 pueden operar juntos (comunicándose sobre la barra colectora 34) en un número de ciclos de control, y los ciclos de control en donde se localizan los bloques de función del colocador/válvula 16, el transmisor 20, y el puente 30, se identifican en la Figura 3 mediante un bloque de identificación de ciclo conectado con cada uno de estos bloques de función. Por consiguiente, como se ilustra en la Figura 3, el bloque de función AO 63 y el bloque de función PID 64 del colocador/válvula 16, y el bloque de función AI 66 del transmisor 20, se conectan adentro de un ciclo de control indicado como LOOPl, mientras que el bloque de función SS 69 del colocador/válvula 16, el bloque de función AI 67 del transmisor 20, y el bloque de función PID 68 del puente 30, se conectan en un ciclo de control indicado como L00P2. El otro bloque de función PID 65 del colocador/válvula 16 se conecta adentro de un ciclo de control indicado como L00P3. Los bloques de función interconectados que forman el ciclo de control indicado como LOOP1 en la Figura 3 , se ilustran con mayor detalle en el esquema de este ciclo de control ilustrado en la Figura 4. Como se puede ver en la Figura 4, el ciclo de control LOOP1 se forma completamente mediante enlaces de comunicación entre el bloque de función AO 63 y el bloque de función PID 64 del colocador/válvula 16, y el bloque de función AI 66 del transmisor 20 (Figura 3) . El diagrama del ciclo de control de la Figura 4 ilustra las interconexiones de comunicación entre estos bloques de función, utilizando líneas que unen las entradas y salidas de proceso y de control de estos bloques de función. Por consiguiente, la salida del bloque de función AI 66, que puede comprender una medición del proceso o una señal del parámetro del proceso, se acopla de una manera comunicativa por medio del segmento de barra colectora 34b, con la entrada del bloque de función PID 64, el cual tiene una salida que comprende una señal de control que se acopla de una manera comunicativa con una entrada del bloque de función AO 63. Una salida del bloque de función AO 63, que comprende una señal de retroalimentación que indica, por ejemplo, la posición de la válvula 16, se conecta con una entrada de control del bloque de función PID 64. El bloque de función PID 64 utiliza esta señal de retroalimentación junto con una señal de medición del proceso desde el bloque de función AI 66, para implementar un control apropiado del bloque de función AO 63. Por supuesto, las conexiones indicadas por las líneas en el diagrama del ciclo de control de la Figura 4, se pueden realizar internamente, adentro de un dispositivo de campo, cuando, como con el caso de los bloques de función AO y PID 63 y 64, los bloques de función estén adentro del mismo dispositivo de campo (por ejemplo, el colocador/válvula 16) , o estas conexiones se pueden implementar sobre la barra colectora de comunicación de dos alambres 34 utilizando comunicaciones sincrónicas Fieldbus estándares. Por supuesto, se implementan otros ciclos de control mediante otros bloques de función que se interconecten de una manera comunicativa en otras configuraciones . Para implementar y realizar actividades de comunicación y de control, el protocolo Fieldbus utiliza tres categorías generales de tecnología identificadas como una capa física, una "pila" de comunicación, y una capa del usuario. La capa del usuario incluye las funciones de control y configuración proporcionadas en la forma de bloques (tales como bloques de función) y objetos adentro de cualquier dispositivo de control de proceso particular o dispositivo de campo. La capa del usuario normalmente es diseñada de una manera propietaria para el fabricante del dispositivo, pero debe ser capaz de recibir y enviar mensajes de acuerdo con el formato de mensajes estándar definido por el protocolo Fieldbus, y de ser configurada por un usuario de maneras convencionales . La capa física y la pila de comunicación son necesarias para efectuar la comunicación entre diferentes bloques de diferentes dispositivos de campo de una manera estandarizada, utilizando la barra colectora de dos alambres 34, y pueden ser modeladas mediante el modelo de comunicación en capas bien conocido Open Systems Interconnect (OSI) . La capa física, que corresponde a la capa OSI 1, se empotra en cada dispositivo de campo y la barra colectora 34, y opera para convertir las señales electromagnéticas recibidas desde el medio de transmisión Fieldbus (la barra colectora de dos alambres 34) en mensajes que pueden ser utilizados por la pila de comunicación del dispositivo de campo. La capa física se puede pensar como la barra colectora 34 y las señales electromagnéticas presentes sobre la barra colectora 34 en las entradas y salidas de los dispositivos de campo . La pila de comunicación, que está presente en cada dispositivo Fieldbus, incluye una capa de enlace de datos, que corresponde a la capa OSI 2, una subcapa de acceso Fieldbus, y una capa de especificación de mensaje Fieldbus, que corresponde a la capa OSI 6. No hay una estructura correspondiente para las capas OSI 3-5 en el protocolo Fieldbus. Sin embargo, las aplicaciones de un dispositivo Fieldbus comprenden una capa 7, mientras que una capa del usuario es una capa 8, no definida en el protocolo OSI . Cada capa en la pila de comunicación es responsable de codificar o descodificar una porción del mensaje o de la señal que se transmita sobre la barra colectora Fieldbus 34. Como resultado, cada capa de la pila de comunicación agrega o remueve ciertas porciones de la señal Fieldbus, tales como preámbulos, delimitadores de inicio, y delimitadores de final, y en algunos casos, descodifica las porciones separadas de la señal Fieldbus, para identificar a dónde se debe enviar el resto de la señal o del mensaje, o si se debe descartar la señal debido a que, por ejemplo, contenga un mensaje o datos para bloques de función que no estén adentro del dispositivo de campo receptor. La capa de enlace de datos controla la transmisión de mensajes sobre la barra colectora 34, y administra el acceso a la barra colectora 34 de acuerdo con un programador de barra colectora centralizado determinístico denominado un programador activo de enlace, que se describirá con mayor detalle más adelante . La capa de enlace de datos remueve un preámbulo de las señales sobre el medio de transmisión, y puede utilizar el preámbulo recibido para sincronizar el bloque interno del dispositivo de campo con la señal Fieldbus de entrada. De la misma manera, la capa de enlace de datos convierte los mensajes sobre la pila de comunicación en señales Fieldbus físicas, y codifica estas señales con la información del reloj para producir una señal "sincrónica en serie" que tiene un preámbulo apropiado para transmitirse sobre la barra colectora de dos alambres 34. Durante el proceso de descodificación, la capa de enlace de datos reconoce códigos especiales adentro del preámbulo, tales como delimitadores de inicio y delimitadores de final, para identificar el inicio y el final de un mensaje Fieldbus particular, y puede realizar una suma de verificación para verificar la integridad de la señal o del mensaje recibido desde la barra colectora 34. De la misma manera, la capa de enlace de datos transmite las señales Fieldbus sobre la barra colectora 34 agregando delimitadores de inicio y de final a los mensajes sobre la pila de comunicación, y colocando estas señales sobre el medio de transmisión en el tiempo apropiado. La capa de especificación de mensaje Fieldbus permite que la capa del usuario (es decir, los bloques de función, objetos, etcétera, de un dispositivo de campo) se comunique a través de la barra colectora 34, utilizando un conjunto estándar de formatos de mensajes, y describe los servicios de comunicación, los formatos de mensajes, y los comportamientos de protocolo requeridos para construir mensajes para colocarse sobre la pila de comunicación, y para proporcionarse a la capa del usuario . Debido a que la capa de especificación de mensaje Fieldbus suministra comunicaciones estandarizadas para la capa del usuario, se definen servicios de comunicación de especificación de mensaje Fieldbus específicos para cada tipo de objeto descrito anteriormente. Por ejemplo, la capa de especificación de mensaje Fieldbus incluye servicios de diccionario objeto que permiten a un usuario leer un diccionario objeto de un dispositivo. El diccionario objeto almacena descripciones objeto que describen o identifican cada uno de los objetos (tales como objetos de bloque) de un dispositivo. La capa de especificación de mensaje Fieldbus también proporciona servicios de administración de contexto, que permiten a un usuario leer y cambiar las relaciones de comunicación, conocidas como relaciones de comunicación virtuales (VCR) descritas posteriormente en la presente, asociadas con uno o más objetos de un dispositivo. Todavía además, la capa de especificación de mensaje Fieldbus proporciona servicios de acceso variable, servicios de evento, servicios de carga y descarga, y servicios de invocación de programa, todos los cuales son bien conocidos en el protocolo Fieldbus, y por consiguiente, no se describirán con mayor detalle en la presente. La subcapa de acceso Fieldbus mapea la capa de especificación de mensaje Fieldbus en la capa de enlace de datos. Para permitir o hacer posible la operación de estas capas, cada dispositivo Fieldbus incluye una base de información de administración (MIB) , que es una base de datos que almacena VCRs, variables dinámicas, estadísticas, programas de tiempo del programador activo de enlace, programas de tiempo de ejecución de bloque de función, e información de etiqueta y dirección de dispositivo. Por supuesto, la información adentro de la MIB se puede accesar o cambiar en cualquier momento utilizando mensajes o comandos Fieldbus estándares. Además, normalmente se proporciona una descripción del dispositivo con cada dispositivo para dar a un usuario o a una central una vista extendida de la información en el VFD. Una descripción del dispositivo, que normalmente se debe manejar con fichas para ser utilizada por una central, almacena la información necesaria para que la central entienda el significado de los datos en los VFDs de un dispositivo. Como se entenderá, para implementar cualquier estrategia de control utilizando los bloques de función distribuidos a través de toda una red de control del proceso, se debe programar precisamente la ejecución de los bloques de función con respecto a la ejecución de otros bloques de función en un ciclo de control particular. De la misma manera, se debe programar precisamente la comunicación entre diferentes bloques de función sobre la barra colectora 34, de tal manera que se proporcionen los datos apropiados a cada bloque de función antes de que se ejecute ese bloque. Ahora se describirá la manera en la que se comunican diferentes dispositivos de campo (y diferentes bloques adentro de los dispositivos de campo) sobre el medio de transmisión Fieldbus, con respecto a la Figura 1. Para que ocurra la comunicación, uno de los dispositivos maestros de enlace sobre cada segmento de la barra colectora 34 (por ejemplo, los dispositivos 12, 16, y 26) opera un programador activo de enlace (LAS) , el cual programa y controla activamente la comunicación sobre el segmento asociado de la barra colectora 34. El LAS para cada segmento de la barra colectora 34 almacena y actualiza un programa de comunicación (un programa activo de enlace) que contiene los tiempos en que se programa cada bloque de función de cada dispositivo para iniciar la actividad de comunicación periódica sobre la barra colectora 34, y el tiempo durante el cual se va a presentar esta actividad de comunicación. Aunque puede haber, y solamente hay, un dispositivo LAS activo en cada segmento de la barra colectora 34, otros dispositivos maestros de enlace (tales como el dispositivo 22 sobre el segmento 34b) pueden servir como LASs de respaldo, y pueden llegar a ser activos cuando, por ejemplo, falle el LAS actual. Los dispositivos básicos no tienen la capacidad para llegar a ser un LAS en ningún momento. Hablando en términos generales, las actividades de comunicación sobre la barra colectora 34 se dividen en macrociclos de repetición, cada uno de los cuales incluye una comunicación sincrónica para bloque de función activo en cualquier segmento particular de la barra colectora 34, y una o más comunicaciones asincrónicas para uno o más de los bloques de función o dispositivos activos sobre un segmento de la barra colectora 34. _ Un dispositivo puede estar activo, es decir, puede enviar datos hacia, y recibir datos desde, cualquier segmento de la barra colectora 34, inclusive cuando esté conectado físicamente con un segmento diferente de la barra colectora 34, a través de una operación coordinada de los puentes y los LASs sobre la barra colectora 34. Durante cada macrociclo, cada uno de los bloques de función activos sobre un segmento particular de la barra colectora 34 se ejecuta, normalmente en un tiempo diferente, pero precisamente programado (sincrónico) , y en otro tiempo precisamente programado publica sus datos de salida sobre ese segmento de la barra colectora 34 en respuesta a un comando de datos obligado generado por el LAS apropiado. De preferencia, cada bloque de función se programa para publicar sus datos de salida poco después del final del período de ejecución del bloque de función. Además, los tiempos de publicación de datos de los diferentes bloques de función se programan en serie, de tal manera que no haya dos bloques de función sobre un segmento particular de la barra colectora 34 que publiquen datos al mismo tiempo. Durante el tiempo en que no se esté presentando la comunicación sincrónica, se permite que cada dispositivo de campo, a su vez, transmita datos de alarma, datos de visión, etcétera, de una manera asincrónica, utilizando las comunicaciones impulsadas por ficha. Los tiempos de ejecución y la cantidad de tiempo necesario para realizar la ejecución de cada bloque de función, se almacenan en la base de información de administración (MIB) del dispositivo en el que resida el bloque de función, mientras que, como se mencionó anteriormente, los tiempos para enviar los comandos de datos obligados a cada uno de los dispositivos sobre un segmento de la barra colectora 34 se almacenan en la MIB del dispositivo LAS para ese segmento. Estos tiempos se almacenan normalmente como tiempos desfasados, debido a que identifican las veces en que se va a ejecutar un bloque de función, o va a enviar datos como un desfasamiento desde el principio de un "tiempo de inicio de programa de enlace absoluto", que es conocido por todos los dispositivos conectados con la barra colectora 34. Para efectuar las comunicaciones durante cada macrociclo, el LAS, por ejemplo, el LAS 16 del segmento de barra colectora 34b, envía un comando de datos obligados a cada uno de los dispositivos sobre el segmento de barra colectora 34b de acuerdo con la lista de tiempos de transmisión almacenados en el programa activo de enlace . Al recibir un comando de datos obligados, un bloque de función de un dispositivo publica sus datos de salida sobre la barra colectora 34 para una cantidad de tiempo específica. Debido a que cada uno de los bloques de función se programa normalmente para ejecutarse de tal manera que se realice la ejecución de ese bloque poco antes de que se programe el bloque para recibir un comando de datos obligados, los datos publicados en respuesta a un comando de datos obligados deben ser los datos de salida más recientes del bloque de función. Sin embargo, si un bloque de función se está ejecutando lentamente, y no ha trabado nuevas salidas cuando recibe el comando de datos obligados, el bloque de función publica los datos de salida generados durante la última ejecución del bloque de función, e indica que los datos publicados son datos viejos, utilizando una estampa de tiempo. Después de que el LAS ha enviado un comando de datos obligados a cada uno de los bloques de función sobre un segmento particular de la barra colectora 34, y durante los tiempos en que se están ejecutando los bloques de función, el LAS puede hacer que se presenten actividades de comunicación asincrónicas. Para efectuar la comunicación asincrónica, el LAS envía un mensaje de ficha de paso a un dispositivo de campo particular. Cuando un dispositivo de campo recibe un mensaje de ficha de paso, ese dispositivo de campo tiene acceso absoluto a la barra colectora 34 (o un segmento de la misma) , y puede enviar mensajes asincrónicos, tales como mensajes de alarma, datos de tendencias, cambios de punto establecido del operador, etcétera, hasta que se completen los mensajes, o hasta que haya vencido un "tiempo de sostenimiento de ficha" máximo asignado. Posteriormente, el dispositivo de campo libera la barra colectora 34 (o cualquier segmento particular de la misma) , y el LAS envía un mensaje de ficha de paso a otro dispositivo. Este proceso se repite hasta el final del macrociclo, o hasta que el LAS se programa para enviar un comando de datos obligados, con el fin de efectuar la comunicación sincrónica. Por supuesto, dependiendo de la cantidad de tráfico de mensajes y del número de dispositivos y bloques acoplados con cualquier segmento particular de la barra colectora 34, no todos los dispositivos pueden recibir un mensaje de ficha de paso durante cada macrociclo. La Figura 5 ilustra un esquema de tiempo que ilustra los tiempos en los cuales se ejecutan los bloques de función sobre el segmento de barra colectora 34b de la Figura 1 durante cada macrociclo del segmento de barra colectora 34b, y las veces en que se presentan comunicaciones sincrónicas durante cada macrociclo asociado con el segmento de barra colectora 34b. En el programa de tiempo de la Figura 5, el tiempo se indica sobre el eje horizontal, y las actividades asociadas con diferentes bloques de función del colocador/válvula 16 y el transmisor 20 (de la Figura 3) se ilustran sobre el eje vertical. El ciclo de control en el que opera cada uno de los bloques de función se identifica en la Figura 5 como una designación de subíndice. Por consiguiente, ¿ü-LOOPl se refiere al bloque de función AI 66 del transmisor 20, plD 00Pl se refiere al bloque de función PID 64 del colocador/válvula 16, etcétera. El período de ejecución de bloque de cada uno de los bloques de función ilustrados, se ilustra mediante un cuadro sombreado, mientras que cada comunicación sincrónica programada se identifica mediante una barra vertical en la Figura 5. Por consiguiente, de acuerdo con el programa de tiempo de la Figura 5, durante cualquier macrociclo particular del segmento 34b (Figura 1) , el bloque de función AILOOPÍ se ejecuta primero durante el período de tiempo especificado por el cuadro 70. Luego, durante el período de tiempo indicado por la barra vertical 72, se publica la salida del bloque de función AILOOPI so^,re e^ segmento de barra colectora 34b, en respuesta a un comando de datos obligados desde el LAS para el segmento de barra colectora 34b. De la misma manera, los cuadros 74, 76, 78, 80, y 81 indican los tiempos de ejecución de los bloques de función PIDLOOPI' AILOOP2 ' AOLOOPl' SSLOOP2 ' y pIDL00P3 ' resPectivamente (que son diferentes para cada uno de los diferentes bloques) , mientras que las barras verticales 82, 84, 86, 88, y 89 indican los tiempos en que los bloques de función PIDL00P1, AIL00p2, 0L00p?, SSL00p2 , y PIDL00p3, respectivamente, publican los datos sobre el segmento de barra colectora 34b. Como se podrá ver, el esquema de tiempo de la Figura 5 también ilustra los tiempos disponibles para las actividades de comunicación asincrónicas, que pueden presentarse durante los tiempos de ejecución de cualquiera de los bloques de función, y durante el tiempo al final del macrociclo durante el cual no hay bloques de función ejecutándose, y cuando no está teniendo lugar la comunicación sincrónica sobre el segmento de barra colectora 34b. Por supuesto, si se desea, se pueden programar intencionalmente diferentes bloques de función para ejecutarse al mismo tiempo, y no todos los bloques de función deben publicar los datos sobre la barra colectora si, por ejemplo, ningún otro dispositivo se suscribe a los datos producidos por un bloque de función. Los dispositivos de campo pueden publicar o transmitir datos y mensajes sobre la barra colectora 34, utilizando una de tres relaciones de comunicación virtual (VCRs) definidas en la subcapa de acceso Fieldbus de la pila de cada dispositivo de campo. Se utiliza un VCR de cliente/servidor para las comunicaciones en fila, no programadas, iniciadas por el usuario, una a una, entre los dispositivos sobre la barra colectora 34. Estos mensajes en fila son enviados y recibidos en el orden presentado para su transmisión, de acuerdo con su prioridad, sin sobreescribir mensajes anteriores. Por consiguiente, un dispositivo de campo puede utilizar un VCR de cliente/servidor cuando reciba un mensaje de ficha de paso desde un LAS, para enviar un mensaje de solicitud a otro dispositivo sobre la barra colectora 34. El que solicita se denomina el "cliente", y el dispositivo que recibe la solicitud se denomina el "servidor" . El servidor envía una respuesta cuando recibe un mensaje de ficha de paso desde el LAS. El VCR de cliente/servidor se utiliza, por ejemplo, para efectuar solicitudes iniciadas por el operador, tales como cambios de punto establecido, acceso y cambios al parámetro de sintonización, reconocimientos de alarma, y cargas y descargas del dispositivo. Se utiliza un VCR de distribución de reporte para las comunicaciones en fila, no programadas, iniciadas por el usuario, de una a muchas. Por ejemplo, cuando un dispositivo de campo con un reporte de evento o tendencia recibe una ficha de paso desde un LAS, ese dispositivo de campo envía su mensaje a una "dirección de grupo" definida en la subcapa de acceso Fieldbus de la pila de comunicación de ese dispositivo. Los dispositivos que se configuren para escuchar en ese VCR, recibirán el reporte. El tipo de VCR de distribución de reporte normalmente es utilizado por los dispositivos Fieldbus para enviar notificaciones de alarma a las consolas del operador. Se utiliza un tipo de VCR de publicador/suscriptor para una a muchas comunicaciones puestas en zona de memoria intermedia. Las comunicaciones puestas en zona de memoria intermedia son las que almacenan y envían solamente la última versión de los datos, y por consiguiente, los nuevos datos sobreescriben completamente a los datos anteriores. Las salidas del bloque de función, por ejemplo, comprenden datos puestos en zona de memoria intermedia. Un dispositivo de campo "publicador" publica o transmite un mensaje utilizando el tipo de VCR de publicador/suscriptor, hacia todos los dispositivos de campo "suscriptores" sobre la barra colectora 34, cuando el dispositivo publicador recibe un mensaje de datos obligados desde el LAS o desde un dispositivo suscriptor. Las relaciones de publicador/suscriptor se determinan previamente, y se definen y se almacenan adentro de la subcapa de acceso Fieldbus de la pila de comunicación de cada dispositivo de campo. Para garantizar actividades de comunicación apropiadas sobre la barra colectora 34, cada LAS envía periódicamente un mensaje de distribución de tiempo a todos los dispositivos de campo conectados con un segmento de la barra colectora 34, lo cual hace posible que los dispositivos receptores ajusten su tiempo de aplicación local para quedar en sincronización unos con otros. Entre estos mensajes de sincronización, se mantiene independientemente un tiempo de reloj en cada dispositivo basándose en su propio reloj interno. La sincronización de reloj permite que los dispositivos de campo cronometren los datos a través de toda la red Fieldbus para indicar, por ejemplo, cuándo se generaron los datos. Además, cada LAS (y otro dispositivo maestro de enlace) sobre cada segmento de barra colectora almacena una "lista viva", la cual es una vista de todos los dispositivos que se conectan a ese segmento de la barra colectora 34, es decir, todos los dispositivos que están respondiendo apropiadamente a un mensaje de ficha de paso. El LAS reconoce continuamente los nuevos dispositivos agregados a un segmento de barra colectora, enviando periódicamente mensajes de nodo de sonda hacia direcciones que no están en la lista viva. De hecho, cada LAS se requiere para sondear cuando menos una dirección después de que haya terminado un ciclo de envío de mensajes de ficha de paso a todos los dispositivos de campo en la lista viva. Si está presente un dispositivo de campo en la dirección sondeada, y recibe el mensaje del nodo de sonda, el dispositivo regresa inmediatamente un mensaje de respuesta de sonda. Al recibir un mensaje de respuesta de sonda, el LAS agrega el dispositivo a la lista viva, y confirma enviando un mensaje de activación de nodo al dispositivo de campo sondeado. Un dispositivo de campo permanece en la lista viva siempre que el dispositivo de campo responda apropiadamente a los mensajes de ficha de paso. Sin embargo, un LAS remueve un dispositivo de campo de la lista viva si el dispositivo de campo, después de tres pruebas sucesivas, no utiliza la ficha, o regresa inmediatamente la ficha al LAS. Cuando se agrega o se remueve un dispositivo de campo de la lista viva, el LAS transmite cambios en la lista viva para todos los otros dispositivos maestros de enlace sobre el segmento apropiado de la barra colectora 34, para permitir que cada dispositivo maestro de enlace mantenga una copia actual de la lista viva. Como se mencionó anteriormente, las interconexiones de comunicación entre los dispositivos de campo y los bloques de función de los mismos son determinadas por un usuario, y se implementan adentro de la red de control del proceso 10, utilizando una aplicación de configuración localizada, por ejemplo, en la central 12. Sin embargo, después de configurarse, la red de control del proceso 10 opera sin considerar el diagnóstico del dispositivo o del proceso, y por consiguiente, se interconecta con la central 12 para realizar funciones de entrada/salida estándares, pero no funciones de diagnóstico. Haciendo referencia a la Figura 6, un diagrama de bloques esquemático ilustra un sistema de control de proceso o red 100 que incluye una interfase Fieldbus accesible por red (NAFI) 105, que se conecta con una red de comunicaciones remotas 106. La red del sistema de control ilustrada 100 incluye una computadora 108, tal como una computadora personal o una estación de trabajo, que se conecta con una barra colectora de red 109 mediante un controlador 110, tal como un controlador de sistema de control digital. La computadora 108 se conecta con el controlador 110 por medio de una barra colectora 111. La red del sistema de control 100 se comunica con la red externa o remota 106 mediante una conexión de la barra colectora de red 109 en un nodo 114, e incluye una pluralidad de dispositivos de campo 116 que se conectan con la barra colectora de la red 109 directamente, o que se conectan con la barra colectora de red mediante un dispositivo de puente 118, por medio de una barra colectora local 120. Cada dispositivo de puente 118 se utiliza normalmente para transferir datos desde una barra colectora de más alta frecuencia hasta una barra colectora de más baja frecuencia, y vice versa. ?l dispositivo NAFI 105 se conecta entre la barra colectora de red 109 y una terminal de conexión de red 122, la cual a su vez se conecta con la red remota 106. Por supuesto, la red remota 106 puede tener cualquier configuración de red deseada, incluyendo, por ejemplo, una configuración de red de área amplia (WAN) , una configuración de red de área local (LAN) , una configuración Ethernet, una conexión de módem para comunicaciones telefónicas, una conexión de transmisión por radio, y similares. El dispositivo NAFI 105 es un sistema de computadora, tal como una computadora personal, una estación de trabajo, o cualquier otro sistema que tenga un sistema de comunicación basado en computadora para propósitos especiales, o un controlador de proceso basado en computadora para propósitos especiales. El dispositivo NAFI 105 incluye un sistema de software 124 que sirve como una interfase de software entre la red del sistema de control 100 y la red remota 106, y que incluye una pila de software de comunicación de red de control de proceso estándar 126 (tal como una pila de software de comunicación Fieldbus) , y una capa de software del usuario 128. La pila de software de comunicación 126 es una interfase del software que controla la comunicación de mensajes entre los dispositivos que operan en una capa física del sistema de comunicación de red de control del proceso, es decir, los mensajes que llegan a la pila de software 126. Como se describió anteriormente, la pila de software de comunicación 126 es utilizada por muchos programas de aplicación diferentes para tener acceso a los datos en los dispositivos de campo, y la pila de software de comunicación 126 maneja las comunicaciones utilizando protocolos de bajo nivel, incluyendo el protocolo Fieldbus. La capa del software del usuario 128 realiza operaciones de la interfase del usuario para controlar el dispositivo NAFI 105, controla la pila del software de comunicación 126 para la comunicación sobre el sistema de control del proceso 100, con el fin de, por ejemplo, recuperar datos especificados desde uno o más dispositivos adentro del sistema de control del proceso 100, supervisa el tráfico de mensajes designado en la pila de software de comunicación 126, incluyendo las operaciones de lectura y escritura y los datos correspondientes. Copia el tráfico de mensajes designado a un archivo adentro del dispositivo 105, y transmite el archivo a un sitio remoto a través de la red remota 106. Por supuesto, cuando se utiliza con un sistema Fieldbus, el dispositivo NAFI 105 se interconecta con la barra colectora de la red 109 por medio de una conexión terminal de dos alambres que se utiliza en general para conectar dispositivos, tales como el controlador 110, los dispositivos de puente 118, o los dispositivos de campo 116 a la barra colectora de red 109 ó 120. Sin embargo, el dispositivo NAFI 105 se puede utilizar para interconectarse con otros tipos de sistemas de control del proceso o redes además de las redes Fieldbus, incluyendo, por ejemplo, las redes Profibus . Haciendo referencia a la Figura 7, un diagrama de bloques esquemático de alto nivel ilustra un sistema de computadora 200 adecuado para utilizarse como el dispositivo NAFI 105. El sistema de computadora 200 de la Figura 7 es altamente genérico y aplicable a muchas configuraciones con bloques funcionales extendidos y aplicaciones. El dispositivo NAFI 105 (sistema de computadora 200) tiene un bloque de terminales de dos alambres 202 que se conecta con un medio de dos alambres (tal como una barra colectora) , o que se conecta con una terminal de conexión del medio de dos alambres de un dispositivo. El NAFI 105 también incluye un microprocesador 204, una interfase de comunicaciones 206, una unidad de acceso al medio 208, y una pluralidad de unidades de almacenamiento, tales como una memoria de acceso aleatorio (RAM) 210, una memoria de sólo lectura (ROM) 212, y una memoria de acceso aleatorio no volátil (NVRAM) 214. La interfase de comunicaciones 206 es un circuito que realiza la conversión del protocolo de serie a paralelo, y la conversión del protocolo de paralelo a serie, y que agrega información del marco a los paquetes de datos de acuerdo con la definición del protocolo de comunicación del sistema de control del proceso en el que se esté utilizando el dispositivo 105. Como se ilustra en la Figura 5, la interfase 206 forma una interfase entre el microprocesador 204 y la unidad de acceso al medio 208, que se puede utilizar para convertir, por ejemplo, una señal de comunicación del medio de dos alambres en una representación digital de la señal de comunicación. La unidad de acceso al medio 208 recibe energía desde el medio de dos alambres o desde una fuente de energía convencional, y suministra esta energía a otros circuitos en el dispositivo NAFI 105. La unidad de acceso al medio 208 también realiza configuración de onda y señalización en el medio de dos alambres o barra colectora (tal como la barra colectora 109 de la Figura 6) .

Los dispositivos de almacenamiento 110, 112, y 114 suministran memoria al dispositivo NAFI 105 y a la interfase, con el microprocesador 204. En la modalidad ilustrada, la RAM 210 puede ser una unidad de almacenamiento de 128 Kbytes, la ROM 212 puede ser una unidad de almacenamiento de 250 Kbytes, y la NVRAM 214 puede ser una unidad de almacenamiento no volátil de 32 Kbytes. El dispositivo NAFI 105 ejecuta instrucciones en el microprocesador 204 desde un código del programa almacenado en uno o más de los dispositivos de almacenamiento 210, 212, ó 214, para realizar la interconexión de comunicación. El dispositivo NAFI 105 se puede implementar virtualmente en cualquier sistema de computadora en la red del sistema de control 100, incluyendo sistemas de computadora en el controlador 110, cualquier de los dispositivos de puente 118, y/o los dispositivos de campo 116, así como en un sistema de computadora independiente . Haciendo referencia a la Figura 8, un diagrama de flujo ilustra las operaciones realizadas por el sistema de software NAFI o dispositivo 105. En un paso de comando de recibir del usuario 222, el sistema de software NAFI 105 recibe comandos del usuario desde un usuario, incluyendo: (1) comandos por un usuario local que inicie la recopilación de datos, y que defina el tráfico particular sobre la pila de software de comunicación 126 que se vaya a supervisar, (2) ordena, mediante un usuario local, para inicializar un archivo de transferencia NAFI, (3) ordena, mediante un usuario local, o un usuario remoto en un sitio remoto, para enviar un archivo de transferencia NAFI a un dispositivo remoto, (4) ordena y recibe los datos correspondientes desde un usuario remoto en una fuente remota, y (5) ordena la recepción desde el usuario remoto en el sitio remoto que solicite la transmisión de un archivo de transferencia NAFI designado. El paso de comando de recibir del usuario 222 normalmente es impulsado por interrupción y es asincrónico. Para un comando que inicie la recopilación de datos y que defina el tráfico particular en la pila de software de comunicación 126 que se va a supervisar, un paso de selección de tráfico e inicio de recopilación de datos 224 establece diferentes variables o declaraciones condicionales que definen el tráfico de mensajes que se va a supervisar, y solicita que la pila del software de comunicación 126 transfiera los datos a la capa de software del usuario 128, correspondientes a los datos solicitados. Para un comando que inicialice un archivo de transferencia NAFI, se realiza un paso de inicializar archivo NAFI 226. Durante este paso, los datos se transfieren por medio de la pila del software de comunicación 126, utilizando diferentes programas de aplicación. La capa del software del usuario 128 supervisa cualesquiera datos designados, o todos los datos, si se desea, no importa cual programa de aplicación genere la transferencia de datos. Un ejemplo de un programa de aplicación que utiliza la pila del software de comunicación 126 para las comunicaciones con los dispositivos de campo es el software ValveLink que se comunica con una válvula de control por medio de la red del sistema de control 100. El software ValveLink es fabricado por y está disponible en, Fisher Control Internacional Inc., en conjunto con sus productos ValveLink. El sistema de software NAFI 105 puede supervisar datos con respecto a cualquier sistema de diálogo que lea y escriba, por medio de la pila de software de comunicación 126, y la capa de software del usuario 128 tiene acceso a cualesquiera datos en la barra colectora de red 109 para la comunicación remota. Para que un comando envíe un archivo de transferencia NAFI a un dispositivo remoto, un paso de enviar archivo NAFI 228 transmite los mensajes y los datos del archivo NAFI hasta un sitio remoto, el cual se dirige de acuerdo con, por ejemplo, un argumento del comando de transmisión. Los mensajes y datos que se envían al sitio remoto incluyen solicitudes y respuestas que son manejadas por la pila del software de comunicación 126 durante las operaciones de control y transmisión de datos de la red del sistema de control 100, de acuerdo con el protocolo de comunicación de la red del sistema de control 100, tal como el protocolo Fieldbus. De una manera conveniente, la cantidad de información transferida sobre la red remota 106 es muy pequeña, comparándose con los datos en otras formas, tales como la transmisión de toda una pantalla de computadora, o la transmisión de datos cargados por la información de manejo agregada durante el paso a través de numerosos nodos de la red. Por consiguiente, el dispositivo NAFI 105 reduce convenientemente el gasto excedente en tiempo y tamaño de transferencia de datos para comunicar datos del dispositivo de campo sobre una red. El archivo de transferencia NAFI se envía sobre la red remota 106 hasta el sitio remoto definido, el cual carga el archivo, de tal manera que están disponibles los mensajes y los datos definidos por el protocolo de la red del sistema de control para su análisis y exhibición en el sitio remoto, lo cual a su vez permite que el usuario remoto ejecute aplicaciones correspondientes a las aplicaciones ejecutadas por el usuario local para recrear operaciones y condiciones de prueba durante el diagnóstico remoto y los interrogatorios y las investigaciones del estado del dispositivo y sus problemas. Por supuesto, el usuario remoto debe tener un software apropiado que descodifique o descifre el significado de los datos enviados desde el dispositivo NAFI . En cualquier caso, la comunicación de datos utilizando el dispositivo NAFI 105 permite convenientemente la prueba de diagnóstico, el mantenimiento, y la resolución de problemas, de una manera remota. Además, los mensajes y la información convenientemente se transmiten muy rápidamente utilizando el dispositivo NAFI 105, debido a que los datos se transmiten de una manera asincrónica e independiente entre el usuario local y el usuario remoto, para evitar de esta manera problemas de sincronización. Más aún, los datos y los mensajes se transmiten de una manera asincrónica con respecto a la recopilación de datos, de tal manera que la recopilación de datos y la transmisión de datos convenientemente se desconectan, previniendo una condición de cuello de botella en donde se detenga la recopilación de datos cuando no esté disponible una conexión de comunicación de red y se detenga la comunicación mientras se espera la recopilación de datos . Para un comando y los datos correspondientes recibidos desde una fuente remota, un paso de recibir transmisión remota 230 recibe el comando y los datos, e inicia cualesquiera operaciones comandadas en la red del sistema de control local 100, utilizando dispositivos de comunicación estándares, tales como una pila de comunicación de software asociada con el protocolo de comunicación utilizado por la red del sistema de control 100. En un paso de supervisar la pila 232, el sistema de software NAFI 124 supervisa el tráfico de mensajes en la pila del software de comunicación 126, que sea designado por el usuario. El tráfico se pone a disposición de la capa de software del usuario 128 en respuesta a la solicitud de que la pila del software de comunicación 126 transfiera datos a la capa de software del usuario 128, hecha en el paso de seleccionar tráfico e iniciar recopilación de datos 224. El tráfico de mensajes incluye las solicitudes y respuestas que se comunican mediante la pila del software de comunicación 126 durante las operaciones de control del proceso. Un paso de copiar tráfico de mensajes a un archivo 234, copia las solicitudes de lectura y escritura y los datos en un archivo NAFI . El archivo NAFI puede ser un archivo de una pluralidad de archivos NAFI que estén designados para almacenar información específica, tal como información con respecto a dispositivo de campo o válvula específica, y estos archivos se pueden almacenar en cualquiera de las unidades de memoria 210 ó 214 del dispositivo NAFI 105. Como será evidente, el dispositivo NAFI 105 es un sistema simple que se implementa como un sistema de computación con el sistema de software NAFI 124, eliminando convenientemente el uso de un engranaje de comunicación de alta velocidad costoso y complicado, incluyendo enlaces de fibra óptica y convertidores. Haciendo ahora referencia a la Figura 9, un diagrama de bloques esquemático muestra varias implementaciones posibles de una interfase Fieldbus accesible por red para comunicarse entre uno o más de una pluralidad de elementos de control del proceso y elementos remotos. El dispositivo NAFI 105 se ilustra de acuerdo con la conexión NAFI mostrada en la Figura 6. En adición, se ilustra un dispositivo o interfase NAFI 302 incorporado en el controlador 110. El dispositivo NAFI 302 se puede conectar a la red remota 106 directamente, o mediante una conexión a través de un dispositivo NAFI 304 adicional, ilustrando una conexión NAFI-NAFI. De una manera similar, la computadora 108 puede incorporar un dispositivo NAFI 306 que se conecte a la red remota 106 directamente, o mediante una conexión con el dispositivo NAFI 304. La interfase accesible por red de la presente invención también se puede incorporar en otros dispositivos, incluyendo cualquiera de los dispositivos de puente 118 y/o los dispositivos de campo 116, que pueden ser válvulas de control de fluido o cualesquiera otros tipos de dispositivos de campo, tales como sensores, transmisores, tableros montados en la pared, etcétera. Un dispositivo NAFI 308 incorporado en uno de los puentes 118, y un dispositivo NAFI 310 incorporado en uno de los dispositivos de campo 116, se muestran ambos conectados directamente a la red remota 106, pero si se desea, se pueden conectar indirectamente por medio de un dispositivo NAFI adicional. Por supuesto, la interfase accesible por red de la presente invención puede realizar otras funciones según se desee, y puede realizar cualquier combinación de funciones en cualquier orden deseado, para efectuar comunicaciones entre una red de control del proceso y una red remota. Más aún, aunque la interfase accesible por red descrita en la presente de preferencia se implementa en el software almacenado, por ejemplo, en un dispositivo de control del proceso, un controlador, o una computadora personal, alternativamente o de manera adicional se puede implementar en el hardware, en el firmware, etcétera, según se desee. Es decir, el procesador descrito en la presente puede incluir cualquier arreglo lógico cableado u otros dispositivos de hardware diseñados para implementar la funcionalidad descrita en la presente. Si se implementa en el software, la interfase accesible por red de la presente invención se puede almacenar en cualquier memoria legible por computadora, tal como en un disco magnético, un disco de láser, u otro medio de almacenamiento, en una RAM o en una ROM de una computadora, etcétera. De la misma manera, este software se puede suministrar a un usuario o a un dispositivo por medio de cualquier método de suministro conocido o deseado, incluyendo, por ejemplo, sobre un canal de comunicación, tal como una línea telefónica, Internet, etcétera. Todavía además, aunque el dispositivo de interfase accesible por red se describe en la presente implementando o utilizando una pila de software de comunicación que se conforma al modelo de comunicación en capas Open Systems Interconnet (OSI) para realizar las funciones de comunicación en un sistema de control del proceso, se entenderá que esta pila de software de comunicación se puede implementar mediante cualquier software que realice funciones de comunicación estándares de acuerdo con un protocolo de comunicación, ya sea que estas funciones se implementen o no en un formato de pila, tal como el descrito por el modelo OSI. Por consiguiente, aunque la presente invención se ha descrito con referencia a ejemplos específicos, los cuales se pretende que sean ilustrativos solamente, y no limitantes de la invención, podrá ser visto por los expertos ordinarios en la materia, que se pueden hacer cambios, adiciones, o supresiones a las modalidades dadas a conocer, sin apartarse del espíritu y alcance de la invención.

Claims

REIVINDICACIONES

1. Una interfase entre una red de comunicaciones y un sistema de control del proceso, la cual comprende: un procesador; un dispositivo de almacenamiento acoplado con el procesador; un sistema de software para ejecutarse en el procesador, el cual incluye: una pila de software de comunicación que opera en el sistema de control del proceso; una rutina de supervisión que supervisa el tráfico de mensajes sobre la pila de software de comunicación; una rutina de copiar, que copia el tráfico de mensajes en el dispositivo de almacenamiento, y una rutina de interfase del medio que hace posible el acceso remoto al dispositivo de almacenamiento.

2. La interfase de la reivindicación 1, en donde la pila de software de comunicación incluye una rutina de control que controla las comunicaciones en el sistema de control del proceso, utilizando un protocolo de comunicación digital de dos alambres, de dos vías, energizado por el ciclo.

3. La interfase de la reivindicación 1, en donde la pila de software de comunicación incluye una rutina de control que controla las comunicaciones en el sistema de control del proceso utilizando un protocolo Fieldbus.

4. Un programa de software que implementa una interfase entre una red de comunicaciones y un sistema de control del proceso para ejecutarse en un procesador, acoplándose el procesador con un almacenamiento, y que incluye una pila de software de comunicación que opera en el sistema de control del proceso, comprendiendo el programa de software: una rutina de interfase que supervisa el tráfico de mensajes sobre la pila del software de comunicación; una rutina de copiar, que copia el tráfico de mensajes en el almacenamiento; y una rutina de interfase del medio que permite el acceso remoto al almacenamiento utilizando la red de comunicaciones .

5. Un artículo de manufactura que implementa una interfase de programa de software entre una red de comunicaciones y un sistema de control del proceso para ejecutarse en un procesador, acoplándose el procesador con un almacenamiento, y que incluye una pila de software de comunicación que opera en el sistema de control del proceso, comprendiendo el programa de software : una rutina de interfase que supervisa el tráfico de mensajes sobre la pila del software de comunicación; una rutina de copiar, que copia el tráfico de mensajes en el almacenamiento; y una rutina de interfase del medio que hace posible el acceso remoto al almacenamiento utilizando la red de comunicaciones .

6. Una interfase adaptada para acoplarse entre una red de comunicaciones remota y un sistema de control del proceso que utiliza un protocolo de comunicación para implementar comunicaciones entre dispositivos adentro del sistema de control del proceso, comprendiendo la interfase: un dispositivo de almacenamiento de datos; un dispositivo de comunicación acoplado entre el dispositivo de almacenamiento de datos y el sistema de control del proceso, adaptándose el dispositivo de comunicación para comunicarse sobre el sistema de control del proceso, utilizando el protocolo de comunicación, y para recuperar datos desde el sistema de control del proceso; un controlador acoplado con el dispositivo de almacenamiento de datos, el dispositivo de comunicación, y la red de comunicaciones remota, que almacena los datos recuperados en el dispositivo de almacenamiento, que comunica los datos adentro del dispositivo de almacenamiento sobre la red de comunicaciones remota, y que controla la operación del dispositivo de comunicación.

7. La interfase de la reivindicación 6, en donde el dispositivo de comunicación incluye una pila de software de comunicación que tiene una rutina de comunicación que se comunica en el sistema de control del proceso utilizando un protocolo de comunicación digital de dos alambres, de dos vías, energizado por el ciclo.

8. La interfase de la reivindicación 6, en donde el dispositivo de comunicación incluye una pila de software de comunicación que implementa comunicaciones adentro del sistema de control del proceso.

9. La interfase de la reivindicación 8, en donde la pila de software de comunicación se configura de acuerdo con el modelo de comunicación en capas Open Systems Interconnet, para implementar comunicaciones adentro del sistema de control del proceso.

10. La interfase de la reivindicación 6, en donde el protocolo de comunicación es un protocolo de comunicación Fieldbus .

11. La interfase de la reivindicación 6, en donde el dispositivo de comunicación incluye un procesador que implementa una primera rutina para solicitar datos de un dispositivo adentro del sistema de control del proceso, utilizando el protocolo de comunicación, una segunda rutina para recibir los datos solicitados desde el sistema de control del proceso, y una tercera rutina para suministrar los datos recibidos al controlador.

12. La interfase de la reivindicación 6, en donde el dispositivo de comunicación incluye un procesador que implementa una primera rutina para supervisar los datos de la comunicación adentro del sistema de control del proceso, una segunda rutina para reconocer datos de comunicación específicos, especificados por el controlador, y una tercera rutina para suministrar los datos de comunicación específicos al controlador.

13. La interfase de la reivindicación 6, en donde el controlador se adapta para recibir un mensaje que especifica datos específicos adentro del sistema de control del proceso, se adapta para controlar el dispositivo de comunicación con el fin de recuperar los datos específicos desde el sistema de control del proceso, y se adapta para almacenar los datos específicos en el dispositivo de almacenamiento en respuesta al mensaje .

14. La interfase de la reivindicasión 6, en donde el controlador se adapta para recibir un mensaje que solicita la transferencia de datos específicos almacenados en el dispositivo de almacenamiento sobre la red de comunicaciones remota, e incluye una rutina que transfiere los datos específicos desde el dispositivo de almacenamiento sobre la red de comunicaciones remota en respuesta al mensaje.

15. La interfase de la reivindicación 14, en donde el controlador se adapta para recibir el mensaje desde la red de comunicaciones remota.

16. La interfase de la reivindicación 14, en donde el controlador se adapta para recibir el mensaje desde el sistema de control del proceso.

17. La interfase de la reivindicación 6, en donde el controlador almacena los datos adentro del dispositivo de almacenamiento de una manera asincrónica con respecto al controlador que comunica los datos almacenados en el dispositivo de almacenamiento sobre la red de comunicaciones remota.

18. La interfase de la reivindicación 6, en donde la red de comunicaciones remota es una red de área local o una red de área amplia.