consejo directivo - aadeca€¦ · viajando en buena compañía 2 seguir siendo simple 4 fibras...
TRANSCRIPT
CONSEJO DIRECTIVO AADECA 94-96
Presidente: Ing. Jonas Paiuk Vicepresidente 1ro: Ing. Aurelio T. Casucci Vicepresidente 2do: Ing. Zoltan L. Barkasz Secretario General: Ing. Luis M. Buresti Prosecretario: Ing. Daniel O. Lupi Tesorero: Ing. Juan P. Weisz Protesorero: Ing. Ricardo J. Agostinelli Vocal Titulares: Ing. Hector A. Maceri
Ing. Eduardo R. Rondelli Ing. Osvaldo H. Capino
Vocal Suplentes: Ing. Sergio Szklanny Ing. Ruben Bocanera
Administradora: Susana Terlizzi
El Consejo Directivo de AADECA agradece muy especialmente al Ing. Victor Marinescu
por la tarea de recopilación y análisis del material que dio origen al presente
Cuaderno Profesional que trata un tema que consideramos de importancia trascendental para
el presente y el futuro del Control Automático. De igual modo a las empresas auspiciantes
que con su aporte ayudaron a la publicación del mismo.
Jonas Paiuk Presidente
AUSPICIANTES
ABB S.A. AEG Tecnologia de Automatización y Plantas S.A. Aparatos Eléctricos Automáticos S.A. Aumeco S.R.L. Casucci Automatización S.A. Controles Argentinos S.R.L. Editorial Control S.R.L. Esco Argentina S.A. Foxboro Argentina S.A. Honeywell S.A. HT S.A. Industrias Epta S.R.L. Intecva Sudamericana S.R.L. Schillig S.R.L. Siemens Válvulas Worcester de Argentina S.A. Weisz Instrumentos S.A.
SUMARIO BUSES ¿MODA O NECESIDAD? Alternativas a nivel de dispositivos 1 Viajando en buena compañía 2 Seguir siendo simple 4 Fibras ópticas en control 5 Controlando el piso de la planta 5 Mayores capacidades 7 Territorio familiar 8 Buses de mayor nivel 8 Profibus (PROcess FIeldBUS) 8 FIP (Factory Instrumentation Protocol) 9 ISA SP-50/IEC-TC65 11 Fieldbus Foundation (FF) 12 FIELDBUS 1. lntroducción 13 1.1. La razón para la existencia del Fieldbus 13 1.2. Virando al Fieldbus 19 1.3. Requerimientos del Fieldbus 21 2. Cómo trabaja el Fieldbus 25
2.1. Panorama general 25 2.2. Modelo OSI 25 2.3. OSI en Fieldbus 28 2.4. Nivel Físico del Fieldbus 29
Características comunes de los medios 29 Características del cable utilizado
como medio 30 Características del medio cable
de 31,25 Kbit/s 33 2.5. Nivel de Enlace de Datos Fieldbus (FDL) 35
Control de acceso al medio de transmisión Fieldbus 35
Control de Enlace de Datos Fieldbus 36
2.6. Modelo Orientado a Objetos 36 OOD en el Fieldbus 37
2.7. Nivel de Aplicación Fieldbus 38 2.8. Gerenciamiento del sistema y de la red 41 2.9. Bloques de función 45 Enlaces de bloques de función 49 2.10. Bloques transductor 50 2.11. Bloque físico 51 2.12. Parámetros de los bloques 52 2.13. Objeto alerta 55 2.14. Objeto tendencia 56 2.15. Objeto displays 57 2.16. Acceso a parámetros 58 2.17. Optimización 58
3. Usando el Fieldbus 59 3.1. Modos 59
o Selección de salidas 59 o Selección de setpoints 60
3.2. Bits de estado 62 3.3. Estructura en cascada 63 3.4. Aplicaciones 64
4. Aplicación del Fieldbus 66 4.1. Sistema de medición hidrostática de
parque de tanques 66
BUSES ¿MODA O NECESIDAD?
Desde relativamente simples hasta increíblemente complejos, los buses que se encuentran hoy día en el mercado cubren una amplísima gama de especificaciones.
Las redes industriales pueden ser de sensores, de
dispositivos y de fieldbus. Las redes de sensores y de dispositivos son de bajo nivel.
Manejan sensores, interruptores, reles, contactores, válvulas de control, etc.
Las redes de fieldbus son de mayor nivel y están destinadas básicamente para comunicaciones entre controladores de proceso y las CPUs host.
Aunque normalmente se las divide en líneas discretas y de proceso, las redes de dispositivos y las redes de fieldbus presentan cierta superposición funcional. También existen algunos híbridos.
Alternativas a nivel de dispositivos
El protocolo ArcNet es la columna vertebral de una red de área local de Contemporary Control Systems. Destinado a aplicaciones de control en tiempo real, este bus a nivel de dispositivos tiene aplicaciones en el control de procesos y en la automatización de fábricas y edificios.
El funcionamiento de ArcNet se basa en un protocolo de tipo «token-passing» - un nodo solo puede enviar un mensaje cuando recibe un «token» -, lo que les da a todos los nodos igual acceso a la red y elimina las posibles colisiones de transmisión en las redes ocupadas. El protocolo ArcNet también es capaz de reconfigurar automáticamente la red - sin intervención de software -despues de la adición o supresión de un nodo. Las opciones de cableado soportan topologías bus, estrella y estrella distribuida.
1
Viajando en buena compañía
Provisto por Siemens como un bus de red de bajo nivel, ASI (Actuator Sensor Interface) se usa en aplicaciones con sensores/ actuadores binarios, por ejemplo en el procesamiento de productos alimenticios y operaciones de manipuleo de materiales. ASI fue desarrollado por una asociación de fabricantes de sensores y actuadores para resolver requerimientos de conexión tanto de dispositivos binarios simples como de sistemas de control de mayor nivel.
Su tecnología de alta velocidad y bajo costo reemplaza el cableado desde los dispositivos hasta los paneles. La red usa un cable de dos conductores que transporta hacia los nodos tanto la señal de datos como la alimentación. Adecuado para entornos con protección IP67, ASI Bus puede conectar dispositivos de -estantería» en topologías de línea, árbol y estrella.
DeviceNetes una red de dispositivos soportada por una organización de proveedores denominada ODVA (Open DeviceNet Vendor
Association). DeviceNet resuelve aplicaciones de control discreto en industria automotriz, alimenticia, manipuleo de materiales, máquinas herramienta, producción de pulpa y papel, y minería.
Al contar con una gran variedad de componentes, DeviceNet les brinda a sus usuarios flexibilidad y una amplia base de soporte en aplicaciones específicas de producción, controlando los costos y maximizando la performance.
La provisión del gran volumen de datos que requieren las E/S avanzadas es el atributo principal que define el Interbus-S, un bus de dispositivos popular en Europa y que ahora está ingresando en Norte América a través de una organización de usuarios/proveedores conocida como Interbus-S Club.
El protocolo Interbus-S garantiza transmisiones seguras en base a su capacidad de verificación de errores. También incorpora extensas capacidades de diagnóstico y un protocolo de mensajes que permite
enviar datos parametrizados y de mensaje más complejos. Interbus-S está destinado a aplicaciones de fabricación discreta en la industria automotriz, gráfica y manipuleo de materiales.
Seguir siendo simple
Genius, introducido en 1985 por GE Fanuc Automation,
es un sistema de entradas/salidas distribuidas destinado a una amplia gama de aplicaciones desde la industria petroquímica y farmacéutica hasta el manipuleo de materiales.
El sistema se caracteriza por un control determinístico en tiempo real, mientras su tecnología de entradas/salidas distribuidas permite simplificar el cableado de control. La simplicidad del sistema y la aptitud de las E/Ss Genius de proveer automáticamente información de diagnostico a través del cableado de campo permiten reducir en mucho el tiempo de ajuste, la eliminación de errores y la búsqueda de fallas, minimizando así la carga del sistema.
La tecnología de bus Seriplex, soportada por Seriplex Technology Organization, provee control determinístico de dispositivos tanto analógicos como digitales con el mismo bus. Su protocolo es transparente para el usuario y no hay reglas restrictivas para la topología del bus. Acepta configuraciones estrella, anillo y multidrop en cualquier combinación, sin límites en el largo de las conexiones.
Los chips embebidos en esta red de pequeño tamaño, que no están basados en un microprocesador, permiten que los dispositivos de E/S y los bloques inteligentes conectados sean compactos y de bajo costo. La compacticidad también hace posible que un solo cable Seriplex pueda reemplazar numerosos cables paralelos punto a punto, reduciendo y simplificando los costos de instalación y de puesta en marcha.
Fibras ópticas en control
La interface SERCOS (SERial COmmunication System) brinda a los usuarios de accionamientos y controles digitales los beneficios de la comunicación sincrónica con una resolución digital de 32 bits, aportando un medio de transmisión con fibras ópticas inmune al ruido, una extensa capacidad de diagnostico y una buena respuesta en aplicaciones donde se exige control de movimiento multieje digital y distribuido. Esta norma abierta tiene aprobación IEC-1491. Destinada a aplicaciones de control de movimiento, SERCOS está soportada por mas de 30 proveedores de todo el mundo.
Controlando el piso de la planta
El SDS(Smart Distributed System) de Honeywell es un
protocolo de comunicaciones y entorno de control basado en CAN (Controller
5
Area Network) para la automatización del piso de planta. Permite el envió de mensajes entre sensores, actuadores, HMIs (Human Machine Interface), control adores y otros dispositivos del piso de una plants. La arquitectura del sistema provee un entorno de comunicaciones en base al cual se pueden generar plataformas de control de alta velocidad, en tiempo real, centralizado o distribuido.
Según Honeywell, el atributo mss significativo de SDS es la simplicidad. Su protocolo, fácil de entender, permite a los usuarios implementar fácilmente redes del mundo real y a los fabricantes de dispositivos desarrollar con mayor facilidad productos que soportan la red.
ControlNet, de Allen-Bradley Co., fue introducido inicialmente como una red de control de alfa performance y para propósitos generales. Por su capacidad inherente de datos, ControlNet puede soportar instrumentación «inteligente-, ofreciendo asimismo conectividad de proceso a sistemas de accionamiento de velocidad variable, interfaces hombre-maquina y sistemas de control distribuido. Está destinado a aplicaciones de fabricación discreta de alta velocidad y procesos analógicos de tipo general.
El funcionamiento de la red es tanto determinístico como repetible; esto es, ControlNet garantiza el envío de los datos y no cambia el tiempo de transmisión si se agrega o se saca un dispositivo de la red. El resultado es un control mss estricto en la mayoría de las aplicaciones.
Mayores capacidades
LonWorks de Echelon Corp. es la única tecnología de
control digital que soporta el use simultaneo de varios medios de bajo costo, incluyendo par retorcido, línea eléctrica común, infrarrojo, radiofrecuencia y cable coaxial. Adecuado para aplicaciones en piso de planta, edificios comerciales, residencias privadas y control de instalaciones, el sistema LonWorks, que está basado en la tecnología Neuron de chips embebidos, puede ser configurado como un bus de dispositivos/ sensores determinístico, peer to peer y maestro/esclavo, o como un fieldbus de mayor nivel.
Utilizado en numerosas aplicaciones industriales de control,
7
LonWorks, cuando se lo configura en una arquitectura de administration de red de tipo cliente/servidor, ofrece una capacidad de ampliación (escalabilidad) virtualmente ilimitada. El use por parte del sistema de un importante volumen de componentes de bajo costo afecta favorablemente los costos de instalación.
Territorio familiar
El protocolo HART (Highway Addressable Remote Transducer) provee comunicación digital bidireccional con dispositivos de campo inteligentes mientras conserva la compatibilidad y familiaridad de los tradicionales sistemas 4-20 mA. Su protocolo utiliza la norma Bell 200 (Frequency Shift Keying) que permite la superposición simultanea a niveles bajos de una señal de comunicaciones digital - el -1> lógico es representado por 1.200 Hz, mientras el -0» lógico corresponde a 2.200 Hz - en la parte superior de la señal analógica 4-20 mA.
Ya que HART fue diseñado para ampliar las comunicaciones con los instrumentos de medición y control que tradicionalmente se comunicaban con señales 4-20 mA, es aplicable a todo tipo de industrias de proceso. Por tratarse de una superposición a un sistema existente, el HART ofrece una solución sin ningún riesgo para poder gozar de los beneficios que resultan de una comunicación más amplia con los dispositivos inteligentes.
Buses de mayor nivel
Profibus (PROcess FIeldBUS)
Es un bus de alto nivel que ya está normalizado y completamente integrado en Europa y en todo el mundo. También ha ingresado en Norteamérica a través de la Profibus Trade Organization.
Profibus es una propuesta alemana que se traduce en la norma DIN 19 245. Utiliza normas ya existentes para su conjunto de protocolos: RS-485 y MMS (Manufacturing Message Specification). Está basado en el modelo OSI de ISO, del cual utiliza solo eI nivel físico, el nivel de enlace y el nivel de aplicación.
8
El funcionamiento del Profibus es del tipo maestro/esclavo, donde el bus puede poseer distintos maestros. Los maestros pueden ocupar el bus en un tiempo y hora determinados. Lo que determina la ocupación del bus es un permiso denominado token, que circula entre los maestros del bus siguiendo una orientacion logica determinada por las direcciones logicas de las estaciones maestras. La combinacion maestro/esclavo y el acceso por token establecen un acceso al medio Ilamado hibrido.
Destinado a aplicaciones de fabricacion discreta, las especificaciones basicas del Profibus referentes a velocidad y tamano de red varian con el subset funcional orientado a la correspondiente aplicación - Profibus-FMS, Profibus-DP o Profibus-PA.
El atributo mas destacado del Profibus es la flexibilidad. Los usuarios tienen la posibilidad de agregar o remover nodos - sean maestros y/o esclavos - sin ninguna interrupcion operacional. Otra ventaja es la disponibilidad de productos. En la actualidad hay en el mundo mas de 480 productos compatibles de 165 proveedores.
FIP (Factory Instrumentation Protocol)
FIP, que ahora se conoce como WorIdFIP Europe, es una propuesta francesa que se traduce en las normas NF C 46 - 602 y NF C 46 - 607. Se basa también en el modelo OSI de ISO reducido a tres niveles: fisico, de enlace y de aplicación.
FIP se propone ser un sistema de gerenciamiento de una base de datos industrial, en tiempo real y distribuida. Uno de los aspectos más interesantes del FIP es su concepto de modelo productor/ distribuidor/consumidor (PDC). En este modelo, el distribuidor es responsable de Ia transferencia de datos desde el productor hacia el(los) consumidor(es) y está encargado de validar estas transacciones de acuerdo a la restricción de tiempo. El productor es aquel que produce un determinado dato, mientras el consumidor es un proceso de aplicación que necesita datos para estar en condiciones de ejecutar una acción. En este proceso, el distribuidor coloca en el bus el nombre de la variable, e inmediatamente tanto el productor como el(los) consumidor(es) de ésta reconocen el pedido, el productor to transmite al medio y el(los) consumidor(es) lo almacenan.
9
Para que el árbitro pueda enviar los nombres en un orden adecuado, se debe tener organizada una lista de objetos.
Este modo de transmisión combina dos tipos de servicios: • SDN (Send Data with No Acknowledgment) • RDR (Request Data and Reply).
FIP ofrece tráficos periódicos, aperiódicos y mensajes/transfe-rencias con reconocimiento (Acknowledgment). En el tráfico periódico, la nómina de objetos a ser transmitidos en el bus es secuenciada de acuerdo a las especificaciones de la aplicación. Puesto que los algoritmos de control, operación y supervisión están definidos y construidos esencialmente de un modo cíclico, se conoce estadísticamente cuáles son los objetos necesarios como entrada y cuales son los objetos producidos que necesitan ser cambiados. Esta nómina se repite cíclicamente confiriéndole al bus la función principal de buscar status periódicamente.
El tráfico aperiódico es necesario para la transmisión de un evento, de objetos configurados y para la retransmisión de objetos sometidos al tráfico periódico, donde el consumidor detecto un error.
En cuanto a los mensajes y transferencias con reconocimiento, la estación pide el derecho de transmisión al árbitro, que garantiza el derecho emitiendo un identificador (ID), reservado para la estación transmisora. Al recibir el ID, la estación administra la transacción y devuelve el control al arbitro. El árbitro garantiza este derecho para cualquier estación para un solo mensaje. En caso de que la estación necesite enviar un grupo de mensajes, le entrega al árbitro una lists de identificadores que emite cuando puede.
FIP ofrece en el nivel de aplicación dos tipos de servicios: • Servicios de transferencia de mensajes (subconjunto de MMS). • Servicios periódicos/aperiódicos MPS'(Message Periodic/Aperiodic
Services). WorldFIP Europe es un protocolo para operaciones de
proceso, batch y de fabricación discreta. Entre las principales aplicaciones se incluyen las industries automotriz, química, petroquímica, siderurgia, alimenticia y fabricación de papel.
WorldFIP ofrece el nivel físico para todas [as velocidades desde 31,25 Kbit/s a 2,5 Mbit/s. Puede manejar 5,0 Mbit/s con medio óptico. La simplicidad inherente del protocolo le ofrece al usuario una
10
entrega garantizada de variables de tiempo critico y le brinda la posibilidad de transferir archivos de datos en el mismo bus sin ninguna programación especial de las aplicaciones. WorIdFIP cuenta con una oferta importante de hardware y una asociación de proveedores.
ISA SP-50/1EC-TC65
Los trabajos de implementación de Profibus y FIP dieron lugar
al grupo SP-50 de ISA (The International Society for Measurement and Control Standards and Practices Group 50) que colabora con el IEC en la elaboración de una norma internacional. Sus resultados ya pueden verse en la Norma IEC 1158 (Physical Layer Specification).
La arquitectura en esta norma también se basa en el modelo OSI de ISO con los mismos tres niveles de Profibus y FIP. ISA introduce un cuarto nivel (Nivel de Usuario), pero que todavía no está aceptado por I EC.
El Nivel Físico especifica: • Método de transmisión bidireccional y asincrónico; • Velocidad de transmisión: 31,25 Kbit/s, 1 Mbit/s y 2,5 Mbit/s; • Medios físicos: cable retorcido y coaxial; • Topología tipo bus o árbol, utilizando caja de distribución; • Distancia máxima: hasta 1900 m sin repetidor para una velocidad de 31,25 Kbit/s, hasta 750 m para 1 Mbit/s y hasta 500 m para 2,5 Mbit/s.
En baja velocidad se admiten hasta 32 instrumentos por bus sin considerar la seguridad intrínseca, 12 instrumentos con alimentación por bus y sin seguridad intrínseca, y de 2 a 6 instrumentos con alimentación por bus y seguridad intrínseca.
El Nivel de Usuario está destinado a facilitar el funcionamiento de los instrumentos de la red en conjunto,'definiendo la estructura de la base de datos que residirá en cada instrumento de control o de medición. Lo que se busca es que distintos proveedores puedan construir sus productos con algoritmos predefinidos, requiriendo tan solo que la base de datos sea cargada para una configuración específica.
También define el método para escalonar todos los bloques funcionales en base a la necesidad de tiempo crítico de cada bloque.
11
El periodo de ejecución de cada bloque queda determinado por Ia configuración de la base de datos.
Todo bloque funcional contiene un algoritmo y una base de datos asociada que es usada por el algoritmo. Los instrumentos pueden tener tantos bloques funcionales residentes como sea necesario, escalonados conforme la definición de usuario. También es posible la inclusión de nuevos bloques para satisfacer los requerimientos específicos de una determinada aplicación.
El Nivel de Usuario incorpora un lenguaje común de programación para todos los instrumentos de campo, proveyendo una terminal de programación y una metodología de configuración única para instrumentos de distintos proveedores.
Algunos de los bloques funcionales definidos en este nivel son: Analog Input/Output, Discrete Input/Output, Manual Loader, Bias/ Gain Station, Control Selector, P/PD Controller, PID/Pl/l Controller, Ratio Station, Characterization, Splitter, Simple Calculation, Time Related Functions, Relay and Boolean Logic, General Calculation, Discrete Device Control, etc.
Fieldbus Foundation (FF)
Este bus está diseñado para entornos tanto de proceso como
de automatización de fabricación. El control distribuido a través del bus es implementado con un tiempo muerto cero en la transmisión de datos de tiempo crítico. El fieldbus FF soporta redes intrínsecamente seguras y dispositivos alimentados por bus, como así también medios redundantes, bus redundante y maestros sincrónicos, estando diseñado como de "falla operacional".
Se trata de una especificación abierta que cumple con la norma de Nivel Físico aprobada por ISA/IEC y con la norma borrador del Comité de Nivel de Enlace de Datos.
El fieldbus FFse caracteriza por su interoperabilidad multiproveedor y está aceptado por la gran mayoria de los proveedores líderes en automatización de procesos y de fabricación.
12
FIELDBUS 1. Introducción
Si usted piensa que el Fieldbus es simplemente un reemplazo de señales de 4-20 mA a digitales para interconectar los dispositivos de campo con los equipamientos de sala de control, sea un controlador de una sola estación o un sistema de control distribuido, es muy posible que resulte muy sorprendido... ¡Lo anterior es tan solo una fracción de todo lo que puede brindar el Fieldbus!
1.1. La razón para la existencia del Fieldbus
El Fieldbus no es sólo un nuevo protocolo para transmisores
inteligentes. El Fieldbus se caracteriza en cuatro aspectos básicos:
• Reemplazo completo de 4-20 mA a señales digitales. • Funciones de control, alarma, tendencia y otras funciones distribui-
das en los dispositivos de campo. • Interoperabilidad e intercambiabilidad. • Sistema abierto; la especificación está disponible sin necesidad de
acuerdo de licencia.
Los dispositivos Fieldbus dejaran de Ilamarse dispositivos inteli-gentes, ya que esto puede confundir al usuario por creer que los transmisores inteligentes existentes podrían hacer lo mismo. El Fieldbus es un sistema completo, con la función de control distribuido en el equipamiento de campo, que permite además la operación y la sintonía desde la sala de control usando comunicación digital. El Fieldbus reemplaza el tradicional 4-20 mA y los clásicos DCSs donde la función de control estaba centralizada en una o más "tarjetas de control".
Algunos fabricantes sostienen que sus DCSs han tenido Field-bus desde hace muchos años, pero ninguno de ello cumplen con los cuatro aspectos señalados anteriormente.
El Fieldbus es un protocolo multiproveedor interoperable, que comenzó como un trabajo de normalización en ISA, igual que la norma
13
4-20 mA. Se espera que el Fieldbus logre un reconocimiento a nivel mundial. Todos los fabricantes de instrumentos más importantes han manifestado su interés en una única norma de Fieldbus. El enfoque estuvo centrado en establecer Ia norma antes que aparezcan productos comerciales, como suele ocurrir con la mayoría de las normas, pero parece ser que en este caso no va a ser así.
Algunas ventajas de las comunicaciones digitales bidirecciona-les, con respecto a 4-20 mA, y otros aspectos positivos ya se conocen a partir de los protocolos de los transmisores inteligentes:
• Mayor exactitud y confiabilidad de datos. • Acceso multivariable. • Configuración y diagnósticos remotos. • Disminución del cableado. • Uso del "cableado analógico" existente.
La mayor exactitud puede estar atribuida a la comunicación
digital, ya que los microprocesadores, por ejemplo en un transmisor y un controlador, pueden hablar directamente, en lugar de pasar a través de conversiones D/A y A/D, de las cuales hay muchas en un lazo cerrado. El estado es enviado junto con los datos de medición y control. En consecuencia, es posible determinar si la información es confiable o no. Todos los datos son verificados y garantizados libres de distorsión debido al ruido o a algún desajuste de impedancia que en las señales analógicas no serian detectados.
El acceso multivariable significa que un transmisor de presión, por ejemplo, no está limitado a una sola salida para presión, sino que también informa la temperatura de proceso. Otro ejemplo es el acceso a la variable de setpoint y a la variable manipulada de un controlador en el mismo dispositivo, o los distintos canales de entrada en un transmisor de temperatura.
La comunicación digital permite modificar remotamente la configuración completa. La calibración se efectúa en funcionamiento sin tener que aplicar ninguna entrada o medir la salida. De manera similar se puede interrogar el estado de los autodiagnósticos.
La reducción de cableado y la simplificación se logran a través de la conexión de varios dispositivos sobre un solo par de cables
14
multidrop. La conexión es una tarea sencilla, ya que todo se encuentra en paralelo y el ni mero de terminales a utilizar es mínimo. Esto significa un bajo costo y un fácil reemplazo de viejos transmisores.
También es importante mencionar algunos de los problemas e inconvenientes de los protocolos existentes, en comparación con la tecnología 4-20 mA:
• La velocidad de comunicación es demasiado baja para control a lazo
cerrado. • Pobre o nula interoperabilidad entre dispositivos de distintos tipos
de diferentes fabricantes. • Los dispositivos deben ser rastreados por su estado. • Sin comunicación directa entre dispositivos de campo.
La opción más lenta del Fieldbus es 25 veces más rápida, y
mucho más eficiente, que el protocolo más común de transmisores
1.1. Sistema de Control Digital Directo (DDC). El primer sistema computarizado donde el control se encuentra centralizado en una única computadora en la sala de control,
15
inteligentes, asegurando así un control seguro a lazo cerrado. La versión de baja velocidad del Fieldbus fue diseñada para usar el mismo tipo de cableado que los transmisores analógicos e inteligentes, siendo capaz entonces de reemplazarlos fácilmente. Sin embargo, cabe señalar que a fin de aprovechar la característica de multidrop, los transmisores deben ser colocados en paralelo.
Muchos protocolos de transmisores inteligentes son propietarios y corresponden a un único fabricante. Para el usuario, la ausencia de una norma significa estar amarrado a un solo fabricante, si elige su sistema. Si ese fabricante no puede proveer un reemplazo urgente, o no dispone de un tipo particular de transmisor, la única alternativa del usuario es volver a 4-20 mA. El usuario depende de un solo proveedor que no puede brindarle lo último en tecnología y características. El proveedor se encuentra en una posición donde puede poner el precio que quiera.
Lo contrario ideal al sistema propietario es un sistema "abierto". Los sistemas abiertos se basan en normas que permiten que distintos proveedores puedan suministrar hardware y software interoperable.
La aptitud de los dispositivos 4-20 mA de reemplazar cualquier otro dispositivo del mismo tipo se denomina "interoperabilidad", lo que de un modo general significa compatible. El Fieldbus ofrece Ia
1.2. Sistema de Control Distribuido (DCS). El control se encuentra parcialmente distribuido en unas pocas tarjetas de control, todavía en la sala de control, donde cada una tiene varios lazos.
16
misma capacidad. Un transmisor de marca "Y" puede ser reemplazado por un transmisor de marca "X" del mismo tipo en todo momento, sin perdida de funcionalidad, y puede interconectarse a otro dispositivo de marca "Z".
El Fieldbus fuerza la interoperabilidad entre los dispositivos que están cumpliendo con esta norma, y también está disponible a todos los fabricantes y usuarios sin necesidad de acuerdos de licencia. Es "abierto", está totalmente expuesto, no hay "secretos". El usuario 0 un tercero pueden hacer sus propias configuraciones y software.
Los usuarios pueden seleccionar ahora un dispositivo en base al precio, performance, calidad y tiempo de entrega. Pueden mezclar y adaptar lo mejor de cada tipo, igual a como lo hacían con los 4-20 mA. Tampoco tienen que elegir un dispositivo fabricado por una cierta empresa por el solo motivo de adaptarse a otros dispositivos de la misma marca ya instalados (en este caso, sin el Fieldbus, los usuarios se hubieran visto obligados a desarrollar drivers especiales para comunicación).
Otro beneficio de la interoperabilidad es que ya no es necesario actualizar el software del sistema al introducir nuevos productos.
La ausencia de una norma significa no poder aprovechar las características de inteligencia de los dispositivos inteligentes de
1.3. Sistema Fieldbus. El control se encuentra totalmente distribuido en el campo con lazos en los dispositivos individuales.
17
campo ya existentes. La comunicación solo se usa para calibración. Por ejemplo, hay muy pocos sistemas existentes que han aprovechado la capacidad multidrop de los transmisores inteligentes existentes. Si bien los dispositivos inteligentes cuentan con autodiagnóstico, el estado solo es informado cuando se interroga un dispositivo. Esto es poco frecuente en la mayoría de [as aplicaciones puesto que la comunicación normalmente se efectúa solo durante la calibración. Uno debe sospechar e indagar por una falla antes de que descubra su ocurrencia.
Las ventajas del Fieldbus para los usuarios son tan obvias que, si fuera por ellos, el Fieldbus probablemente ya sería una norma internacional. Los usuarios finales han tenido muy poca información y muy pocas oportunidades para incidir en el desarrollo de la norma. Parecieran que ellos tan sólo se tienen que enfrentar a la alternativa de elegir entre una tecnología que ya está disponible en un grupo de fabricantes, y otra en proceso de desarrollo. Tal situación es muy similar a la decisión que los usuarios se veían obligados a tomar algunos años atrás sobre que tecnología de videograbación comprar para sus hogares. El miedo de los usuarios es elegir el protocolo "equivocado" de la misma manera que algunos de ellos podían elegir la tecnología de video "equivocada".
Muchos fabricantes, por su parte, también desean que el Fieldbus este listo. Los fabricantes que realmente se verán beneficia-dos con el Fieldbus serán aquellos que no tienen paquetes completos de sistemas de control, pero si un buen transmisor o una buena válvula. Estos fabricantes no tienen que aventurarse en el diseño de sistemas, desarrollando un DCS completo. Los fabricantes de dispo-sitivos de campo ya no tienen que ocuparse de las interfaces hombre máquina como ser software de configuración y supervisorio. Estos pueden ser escritos por empresas de software que son especialistas en este campo. Estos últimos también son relevados del desarrollo de nunca acabar de drivers de comunicación para cada nuevo protocolo que aparece en su camino.
Los fabricantes quieren que el Fieldbus este listo ya que saben que muchos usuarios detienen la compra de nuevos sistemas esperando el Fieldbus y tienen miedo de estar comprando el sistema "equivocado".
18
HART es un protocolo de transmisores inteligentes que ha alcanzado una aceptación casi universal, y está reforzando su posición cada aro que pasa sin que aparezca el Fieldbus. Si bien el HART cumple con el requerimiento de seguridad intrínseca y logra una cantidad aceptable de interoperabilidad (más de lo que la mayoría creen), su velocidad es la principal limitación.
Profibus y FIP son otros protocolos normalizados abiertos y rápidos, pero no son intrinsecamente seguros y el bus no puede proveer alimentación para los dispositivos, por lo que requieren cuatro cables.
1.2. Virando al Fieldbus
El impacto sobre el usuario, al adoptar el Fieldbus, será muy grande, con las siguientes ventajas a destacar:
• Operación con una confiabilidad aun mayor.
• Flexibilidad virtualmente ilimitada.
• Reducción en el costo del equipamiento.
• Reducción en el costo de instalación.
• Mayor flujo de información.
La velocidad con la cual el Fieldbus capturará el mercado depende fundamentalmente de cuan rápido son entrenados los usuarios. Uno no puede sentirse confiado en comprar algo si no entiende como trabaja.
La simplicidad de la tecnología analógica permite comprender fácilmente cual es la razón principal por la que la gente se siente tan confortable con ésta. Los dispositivos 4-20 mA pueden operarse usando solo un destornillador y probarse con el mas básico de los amperímetros. Casi cualquiera podría configurar tales dispositivos y localizar las fallas.
Los dispositivos de campo pueden informar fallas y problemas en forma inmediata, permitiendo que el personal de mantenimiento pueda detectar errores instantáneamente o incluso antes que estos puedan producir algún daño.
La capacidad multivariable del Fieldbus permite el control, totalización u otro procesamiento de señales en el campo. En consecuencia, ya no es necesario un controlador separado u otro equipamiento de acondicionamiento de señales. La host puede ser una simple PC "de estantería" con un software MMI.
El multidrop de varios dispositivos sobre un mismo cable puede reducir drásticamente la cantidad necesaria de cables. En muchas
industrias, un dispositivo puede encontrarse a un kilómetro y aun mas alejado de la sala de control. Cada lazo necesita al menos dos pares de alambres (uno para el transmisor y el otro para el actuador) y una refinería, por ejemplo, podría Ilegar a tener varios cientos de tales lazos. En definitiva, el ahorro en el cableado para una fábrica de mediana a grande es inmenso.
Los transmisores y los actuadores a veces se encuentran próximos unos a otros, pero lejos de la consola del operador, que es una situación ideal para multidrop. Si bien los precios de los disposi-tivos de Fieldbus pueden ser en un comienzo elevados, la reducción en el numero de dispositivos y cableado, teniendo en cuenta las bandejas y cajas de empalme asociadas, habrá de Ilevar sin lugar a dudas a un sistema de menor costo.
Los fabricantes ya no podrán basarse en una tecnología propie-taria para mantener altos sus precios. El Fieldbus habrá de Ilevar a una competencia abierta, que eventualmente se traduciría en una disminución de precios.
El acceso multivariable inundara la sala de control con información. Los registradores clásicos ya no podrán realizar su tarea, que ahora estará a cargo de los registradores sin papel y de las memorias de las computadoras, donde está información se utilizara para control estadístico y otras funciones de administración de procesos.
El Field bus cuenta, además, con bloques de función de software que reemplazan muchas de las funciones hoy día realizadas por
hardware. Esto provee una tremenda flexibilidad puesto que la estra-tegia de control puede editarse sin tener que recablear o cambiar ningún hardware. Una vez implementadas físicamente, se pueden cambiar las conexiones lógicas entre los bloques de función, se pueden agregar y quitar bloques de función, etc.
Los dispositivos más avanzados pueden ejecutar un número virtualmente ilimitado de bloques de función. En el caso de una ampliación o mejora de un sistema, la necesidad de hardware adicional se reduce a un mínimo, simplemente dejando que los dispositivos existentes ejecuten un mayor número de bloques.
1.3. Requerimientos del Fieldbus
El principal requerimiento para el Fieldbus es superar
los problemas de los protocolos de transmisores inteligentes, manteniendo las ventajas del estándar 4-20 mA (cuya principal ventaja es el control a lazo cerrado).
Al proveer distintas opciones para las velocidades de comunicación y alimentación de dispositivos, tanto los requerimientos de seguridad intrínseca como el retardo mínimo de [as comunicaciones se pueden cumplir fácilmente. Optimizando el use de la red, también se puede alcanzar un control estricto de lazo cerrado en caso de que se necesite seguridad intrínseca.
Con la tecnología 4-20 mA es posible construir un lazo de control conteniendo solo un transmisor, un controlador y un actuador. Los dispositivos Fieldbus también pueden ser capaces de hacerlo, como así también actuar en grandes sistemas de control.
El Fieldbus debe ser multipropósito y tan versátil como los 4-20 mA. En consecuencia, los dispositivos Fieldbus deben ser capaces de operar por si mismos con una simple interfaz de usuario a fin de ser económicos en sistemas pequeños.
El costo de una computadora host con software dedicado, y obviamente un DCS, no puede justificarse en el caso de un sistema pequeño, incluso si los costos Ilegaran a bajar. También habría un problema logístico para los usuarios como asimismo para los fabricantes si ellos se vieran obligados a seguir usando tecnología analógica en pequeños sistemas.
22
La posible complejidad de un sistema en donde pueden encon-trarse conectados tantos dispositivos (y donde cada dispositivo puede desempeñar la función de varios dispositivos convencionales) requie-re una interfaz amigable de usuario. El usuario debe estar liberado de la asignación manual de direcciones, tal como ocurre en los protocolos de transmisores inteligentes, y de la fatigosa tarea de rastrear bits, bytes, palabras y direcciones de memoria, tal como ocurre en los PLCs.
El modelo de bloques de función es la alternativa elegida por todas las propuestas de Fieldbus. El usuario puede relacionarse fácilmente con estos ya que los dispositivos están representados ahora por bloques, iguales a los bloques de los diagramas de control de ISA y SAMA. El cableado físico será entonces conexiones lógicas o enlaces "cableados por soft" entre los bloques. Si bien técnicamente son diferentes, estos parecen muy familiares y el usuario se sentirá bastante confortable con ellos. La dirección de dispositivos y los parámetros indexados son asignados automáticamente. Algunos sistemas y/o controladores están implementando una filosofía simi-lar.
La normalización asegura la interoperabilidad, pero si la misma es demasiado rígida, sus efectos sobre el usuario serán adversos. Debe haber lugar para una diferenciación entre fabricantes. Si la norma obliga al cumplimiento de cada detalle concebible, el usuario no tendrá nada para elegir, ya que los dispositivos de todos los fabricantes serán exactamente iguales. Si apareciera un fabricante con una gran idea, no estaría en condiciones de implementarla, o eventualmente se vería obligado a incluirla en la norma, con lo que todos sus competidores sabrían de la misma.
El Fieldbus especifica los requerimientos básicos de funcionali-dad, pero debe permitir que un fabricante pudiera adicionar características únicas a su dispositivo. Estas características benefician al usuario, y el fabricante podría usarlas como herramientas de marketing. Asimismo, si los nuevos modelos son diferentes de sus predecesores, los dispositivos que se comunican con ellos deberían saberlo. En pocas palabras, el Fieldbus no debe entorpecer el desarrollo y la mejora de productos. El Fieldbus provee un mecanismo que asegure que también se mantiene la interoperabilidad para las características específicas del fabricante.
23
El costo de Ia caída o parada de un sistema puede Ilegar a ser muy alto en términos de perdida de producción, surgiendo aquí otro requerimiento del Fieldbus que debe ser capaz de configurar el sistema estando en operación.
En este sentido, por ejemplo, los dispositivos Fieldbus de la Serie 302 de Smar son capaces de actuar como un maestro de la red y ser configurados localmente usando una herramienta magnética, con lo que se elimina la necesidad de un configurador portátil o una computadora en muchas aplicaciones básicas.
24
2. Cómo trabaja el Fieldbus
Hay dos partes principales en la arquitectura de un sistema Fieldbus: la interconexión y la aplicación.
La interconexión se refiere al pasaje de datos desde un disposi-tivo a otro, sean estos un dispositivo de campo, una consola de operador o un configurador. Esta es la parte de protocolo de comunicación del Fieldbus.
La aplicación es la función de automatización que realiza el sistema. Al estandarizar la aplicación, el Fieldbus ha ido más allá que cualquier otra norma de comunicación, asegurando la interoperabili-dad entre productos que conforman la norma.
2.1. Panorama general
La arquitectura de aplicación del Fieldbus soporta la distribución de tareas de automatización a los dispositivos en el campo que se hallan interconectados por una red. La mayoría de las funciones básicas desempeñadas por un dispositivo están modeladas como bloques. Los bloques cooperan y están interconectados uno con otro, soportando la propagación de los parámetros entre dispositivos, y el operador.
La arquitectura de interconexión del Fieldbus se basa en un subconjunto de tres niveles de la arquitectura proveniente del modelo de referencia OSI (Open Systems Interconnect) desarrollado por ISO (International Organization for Standardization). El sistema de administración y de aplicación del modelo OSI, como así también el modelo de arquitectura de aplicación Fieldbus, están basados en los conceptos de Programación Orientada a Objetos (OOP), Tanto OSI como OOP utilizan modelos para simplificar la comprensión de la funcionalidad. Ambos se describen brevemente a continuación. 2.2. Modelo OSI
El modelo de referencia OSI es una norma reconocida internacio-nalmente para arquitecturas de red sobre la cual se basa las redes abiertas. La norma está desarrollada como un modelo para telecomu-
25
nicaciones a todos los niveles. Todas las funciones (direccionamiento, verificación de errores y codificación/descodificación) de una red han sido agrupadas en conjuntos lógicos denominados niveles, en ni mero de siete. Los niveles están colocados uno encima de otro y juntos forman lo que se denomina el modelo jerárquico del protocolo. Un nivel solo se interconecta con los niveles inmediatamente encima o debajo del mismo en el modelo jerárquico. El modelo jerárquico se interconecta hacia arriba con la aplicación y hacia abajo con el medio de transmisión.
La aplicación realizada por el sistema que se efectúa en un dispositivo se denomina application process (AP). El AP consiste de dos partes, una porción del usuario, que es la funcionalidad, y una porción de comunicación. En el Fieldbus, la porción del usuario es la función real del dispositivo, como ser medición o control (bloques de función), o interface de usuario.
Cada nivel provee servicios para el nivel inmediatamente supe-rior, y se comunica con el nivel correspondiente en la arquitectura de la otra estación (su par), lo que se denomina comunicación peer-to-peer (entre pares). El conjunto de funciones proveídas por un nivel al nivel superior se denomina servicios.
Cuando se transmiten datos de una aplicación a otra, los datos son pasados desde arriba hacia abajo en la arquitectura, siendo procesados por cada nivel para obtener la trama del nivel físico. La trama que pasa por el medio es transmitida al otro extremo y cuando se recibe los datos son pasados de abajo hacia arriba en la arquitectura. El procesamiento realizado por los niveles en el extremo de transmisión es invertido por el nivel respectivo en el extremo de recepción, con lo cual se obtiene los datos de aplicación originales. Los niveles 3 a 6 no se usan ya que el Fieldbus (y la mayoría de las demas LANs) no tienen interconexión entre redes, que es el propósito de estos niveles. Esta simplificación permite que el Fieldbus sea más rápido y más fácil de implementar en dispositivos con procesadores de potencia limitada, como por ejemplo los instrumentos de campo. En consecuencia, los tres niveles contemplados en el Fieldbus, con sus características funcionales, son: 1. Nivel Físico (PhL). Es el medio independiente para la activación, mantenimiento y desactivación de los enlaces fisicos que permiten el pasaje en forma transparente de los bits para la comunicación; sólo reconoce bits individuales, y no caracteres o tramas multicaracter. La norma define tipos de medios y señales, velocidad y topología de transmisión incluyendo número de nodos, y alimentación de dispositivos (solamente en Fieldbus). 2. Nivel Enlace de Datos (DLL). Transfiere datos entre entidades de Ia red; activación, mantenimiento y desactivación de conexiones de enlace de datos, agrupamiento de bits en caracteres y tramas de mensaje, sincronización de caracteres y tramas, control de errores, control de acceso al medio y control de flujo (permitiendo que varios dispositivos puedan compartir la red). La norma define el tipo de control de acceso al medio, los formatos de la trama, verificación de errores y direccionamiento* de estaciones. *Nota: El direccionamiento es en realidad parte del Nivel de Red, que no está definido en el Fieldbus, pero que sí se hace en el Nivel Enlace de Datos. Parte de la funcionalidad de los niveles 3 a 6 se encuentra dentro del protocolo Fieldbus, implementados en el Nivel Aplicación.
27
3. Nivel Aplicación (APP). Da acceso a un conjunto de servicios locales y de comunicación para servir al sistema distribuido - interconexión entre los APs y el usuario. La norma define los formatos de mensaje y servicios disponibles para el AP.
El gerenciamiento de la red OSI es una extensión que cubre
todos los niveles: El gerenciamiento del sistema monitorea y controla el funcionamiento de los recursos de la red. Está dividido en área funcionales de gerenciamiento del sistema. Para el Fieldbus, el área funcional mas importante es la configuración de red. Se accede al gerenciamiento del sistema desde una estación a otra. Está modelado como un sistema gerencial (jugando el rol de gerente) y como un sistema gerenciado (que juega el rol de agente ) , que tiene una Base de Información de Gerenciamiento (MIB). La MIB es el lugar de almacenamiento lógico para la información y los recursos utilizados para soportar el gerenciamiento de la red.
El usuario final se ocupa fundamentalmente de la conexión física y de la aplicación. El nivel físico, tal como se menciono anteriormente, ya se encuentra normal izado y no cambiara. Seguramente se habrá de ampliar para incluir otros medios como ser radio, pero no cambiara. En consecuencia, ya que todos los protocolos propuestos de Fieldbus sugieren soluciones casi idénticas para la aplicación del usuario, el Fieldbus ya está "listo" en lo que al usuario se refiere.
Los usuarios pueden ahora avanzar y aprender los aspectos de instalación, aplicación y operación del Fieldbus sin preocuparse en que malgastan su tiempo. La incertidumbre reside en los niveles de aplicación y de enlace de datos, y en las funciones de gerenciamiento. Sin embargo, aquellos son transparentes para los usuarios, y solo son tema de los desarrolladores de producto.
2.3. OSI en Fieldbus
Sólo los niveles 1, 2 y 7 son utilizados por el Fieldbus, mientras la aplicación está funcionalmente provista por los bloques de función.
Un dispositivo Fieldbus tiene tres APs: la aplicación de los bloques de función, el gerenciamiento de la red y el gerenciamiento del sistema.
28
2.4. Nivel Físico del Fieldbus
Los lazos de control cerrado con una performance similar al sistema 4-20 mA, requieren una velocidad elevada de transmisión de datos. Puesto que una mayor velocidad significa un mayor consumo de energía, esto podría chocar con la necesidad de seguridad intrínseca en algunas aplicaciones. En consecuencia, se eligió una velocidad de comunicación moderadamente elevada, y otra más rápida pero que no es intrínsecamente segura, para cubrir así todas las aplicaciones. El sistema fue diseñado para tener un mínimo de sobrecarga de comunicación para satisfacer los requerimientos de control incluso con la opción de baja velocidad.
Hay varias combinaciones para el nivel físico, cada una con sus meritos relativos. Todos los dispositivos en un bus deben usar las mismas opciones en lo que hace a medios, conexión y velocidad de transmisión. Sin embargo, se pueden mezclar dispositivos alimentados o no por bus, como así también dispositivos intrínsecamente seguros o no.
Opciones de medios físicos: • Cable • Fibra óptica (pendiente) • Radiofrecuencia (pendiente)
Opciones de velocidades de transmisión: • 31,25 Kbit/s • 1 Mbit/s • 2,5 Mbit/s
Características comunes de los medios
Los datos son intercambiados como una señal serie sincrónica half-duplex. Un dispositivo transmite y recibe sobre el mismo medio, pero no simultáneamente. Las señales son sincronizadas usando la codificación Manchester (a.k.a. Biphase L). Puesto que Ia transmisión es sincrónica, no se requieren bits de arranque y de parada. En Ia codificación Manchester, eI reloj y los datos se combinan de manera
29
que un borde ascendente represente un dato 0 (cero) lógico, y un borde descendente represente un dato 1 (uno) lógico.
Cuando transmite, se comienza con el preámbulo, equivalente a la señal de Ilamada del teléfono, que se transmite primero para sincronizar los receptores de los otros dispositivos.
El comienzo y el final del mensaje son indicados por delimitadores de comienzo y fin, respectivamente. Los delimitadores no están codificados en Manchester, solo lo es el dato, y por lo tanto pueden ser identificados unívocamente. Los bits no codificados en los delimitadores se denominan N+ (non-data positive) y N- (non-data negative).
EI preámbulo y los delimitadores adicionados por el nivel físico en el dispositivo de transmisión, son separados por el nivel físico del dispositivo receptor.
Se puede alcanzar redundancia duplicando el nivel físico y el medio. El sistema dispone de controles para determinar cuales de los dos medios esto usando un dispositivo.
Características del cable utilizado como medio
El cable usa señales eléctricas sobre un par retorcido normal, y
ya está aprobado como norma IEC/ISA desde 1992.
La máxima distancia permitida entre dos dispositivos sobre el medio cable depende de la velocidad de transmisión elegida:
• 31,25 Kbit/s: 1.900 m • 1 Mbit/s: 750 m • 2,5 Mbit/s: 500 m
Los dispositivos deben aislar el hardware de comunicación de
la tierra para evitar la formación de lazos de tierra cuando los dispositivos están instalados en un esquema multidrop.
Aceptan topología bus (figura 2.4), topología árbol (figura 2.5) y topologías punto a punto.
La topología árbol sólo es soportada por la versión de baja velocidad.
La topología bus tiene un cable troncal (trunck) con dos termina-dores. Los dispositivos se encuentran conectados al trunck vía spurs (ramas). Los spurs pueden estar integrados en el dispositivo, lo que da una longitud de spur igual a cero. Un spur puede conectar más de un dispositivo, lo cual depende de la longitud. Se pueden usar acopladores activos para extender la longitud del spur. También se pueden usar repetidores activos para extender la longitud del trunck.
Los terminadores están diseñados para tener una impedancia de 100 ohms cada uno a la frecuencia de transmisión. Los dispositivos transmiten mediante una corriente modulada por la red de acuerdo a la serial codificada Manchester. Los dispositivos receptores detectan la caída de tensión generada sobre los dos terminadores cuando la corriente ha sido modulada. La corriente modulada es 15 a 20 mA pico a pico para la versión de baja velocidad, con una sensibilidad de receptor de 150 mV.
Características del medio cable de 31,25 Kbit/s
La opción de medio cable con menor velocidad, 31,25 Kbit/s, es la mas versátil y se espera que sea el tipo de medio mas ampliamente utilizado. Ofrece versiones para seguridad intrínseca y alimentación de dispositivos por bus. El ni mero de dispositivos está limitado por las siguientes posibilidades: • intrínsecamente seguro / no intrínsecamente seguro • Alimentado por bus / alimentado en forma separada
El número máximo de dispositivos es 32. En sistemas intrínsecamente seguros, la barrera de
seguridad debe colocarse entre la fuente de alimentación y el terminador final de la fuente de alimentación.
Los dispositivos pueden ser alimentados por el bus, donde solo se requieren dos cables para alimentación y comunicación. Una sola fuente de alimentación, común a todos los dispositivos, se halla conectada a la red en cada uno de los extremos del trunck. La tensión puede estar en el orden de 9-32 V CC.
La impedancia de la fuente de alimentación debe tener un mínimo de 3 Kohm a la frecuencia de transmisión a fin de no cortocircuitar la señal de comunicación.
Una señal codificada Manchester tiene un ciclo de carga de exactamente 50% y puede ser vista como una señal CA. En consecuen-cia, el consumo de energía eléctrica de corriente continua de un dispositivo es constante.
2.5. Nivel de Enlace de Datos Fieldbus (FDL)
El Nivel de Enlace de Datos Fieldbus consiste de dos subniveles: la parte inferior es el Control de Acceso al Medio Fieldbus (FMAC) y la parte superior es el Control de Enlace de Datos Fieldbus (FDLC).
Un dispositivo conectado en Ia red Fieldbus puede trabajar como dos tipos de estaciones diferentes:
• Estación maestro • Estación esclavo
Una estación maestra tiene el derecho de acceder al medio (iniciar comunicación). Los esclavos solo tienen el derecho de respon-der a una solicitud enviada por la estación maestra.
Control de acceso al medio de transmisión Fleldbus
El acceso al medio Fieldbus es una combinación de los principios de token-passing y polling. Varios de los dispositivos de una red pueden ser estaciones maestras. Solo a la estación que tiene el token le es permitido iniciar la comunicación.
La estación maestra puede escrutar (solicitudes de estaciones maestras, respuestas de estaciones esclavos) los dispositivos escla-vos mientras tiene el token.
El token es enviado a la siguiente estación maestra en un formato de mensaje especial.
Los dispositivos tienen otorgadas direcciones de estación individuales. Todos los formatos de mensaje contienen la dirección del destino (DA) y la dirección de la fuente (SA) para el mensaje.
El Fieldbus tiene servicios que liberan al usuario de la responsa-bilidad de asignar y conservar un registro de las direcciones.
Una exigencia básica para lograr un control confiable es tener datos confiables. Se calcula un Frame Check Sequence (FCS) de dos bytes en base a todos los datos del formato de mensaje usando un polinomio en el dispositivo transmisor, y se lo agrega al mismo. El dispositivo receptor efectúa el mismo cálculo y compara el resultado con la FCS, detectando entonces cualquier error. La FCS es equivalen
35
te a los bits de paridad y a los Cyclic Redundancy Checks de los protocolos asincrónicos.
Cuando el nivel de arriba le solicita al FDL pasar un mensaje, la prioridad del mensaje se envía junto con el mismo. Hay dos prioridades: alta, por ejemplo alarmas, y baja, por ejemplo datos de configuración y diagnósticos. El FDL transmite primero los mensajes de prioridad alta.
Control de Enlace de Datos Fieldbus
El FDLC provee distintas posibilidades para el nivel de aplicación de enviar datos a otras estaciones.
Existen dos tipos de mensajes que pueden identificarse en un sistema Fieldbus:
• Operacional • De fondo
El tráfico operacional son los datos transferidos entre dispositi-
vos como parte de la estrategia de control, por ejemplo variables de proceso. Se caracteriza por su bajo volumen, tiempos critico y es cíclico. El tráfico de fondo son los datos transferidos entre un dispositivo y la interface de operador, por ejemplo configuración y diagnósticos. Tiene las características opuestas al tráfico operacional: gran volumen, posee tiempo fijo y es acíclico (esporádico).
2.6. Modelo Orientado a Objetos
Una de las técnicas utilizadas para diseñar el nivel de aplicación y
el proceso de aplicación de bloques de función es la OOD (Modelo Orientado a Objetos).
Hay muchas "palabras clave" en OOD. Sin embargo, para el estudio del Fieldbus, es suficiente con Objeto y Clase. Los objetos son entidades con un comportamiento bien definido. Los sistemas pueden ser descompuestos en objetos que pueden ser considerados como "partes del" sistema. En OOD, el software se basa en objetos que hacen cosas o cambian cuando uno les envía mensajes u opera sobre
36
ellos. En consecuencia, OOD no se basa en algoritmos (pasos de ejecución).
Los objetos representan con frecuencia entidades del mundo real, por ejemplo un archivo. Los objetos pueden clasificarse de acuerdo a su función y otras propiedades que ellos tienen en común.
Una clase define varios tipos de objetos. Las propiedades únicas de un objeto definen una instancia de la clase.
Para organizar o clasificar abstracciones, tanto los objetos como las clases se organizan en una jerarquía (niveles de abstracción o complejidad). Al ser construidos uno encima del otro, cada nivel es entendible por si mismo.
La herencia es una jerarquía de clases - una subclase (clase inferior) comparte la estructura y el comportamiento de una superclase (clase superior). Es posible, y es bastante común, una herencia múltiple.
La agregación es una jerarquía de objetos: los objetos se construyen a partir de subobjetos.
En un sistema de control grande puede haber un sistema de gerenciamiento, un sistema supervisorio y equipamiento de campo; todos son partes del sistema de control. Un dispositivo de campo puede tener subpartes tales como sensor, electrónica y caja. Por ejemplo, un Smar LD302 es un tipo de transmisor de presión que a su vez es un tipo de equipamiento de campo. El LD302 hereda las propiedades y el comportamiento de la clase de transmisores de presión. En consecuencia, un operador familiarizado con transmisores de presión puede operar el LD302 en cuestión de minutos, ya que solo tiene que aprender sus propiedades únicas.
OOD puede trabajar con sistemas más pequeños a través de este reuso de mecanismos comunes, la agregación y la herencia.
Los modelos son utilizados extensivamente en el Fieldbus y en toda la ingeniería ya que facilita Ia abstracción, la descomposición y el ordenamiento jerárquico.
OOD en el Fieldbus
El sistema de control Fieldbus ha sido descompuesto en las así
Ilamadas variables simples que constituyen un nivel adecuado de
37
abstracción. Como ejemplo podemos mencionar variables flotantes, enteras y seriadas. Las variables simples se usan por si mismas pero también como partes de estructuras de datos tales como parámetros de E/S de bloques de función y enlaces de bloques de función. Una vez mas, estas estructuras de datos son parte del tipo de datos de los bloques de función que también es una estructura de datos.
Los bloques de función son parte del proceso de aplicación con bloques de función, que es parte del dispositivo de campo que a su vez es parte del sistema.
Las variables pueden clasificarse de muchas maneras:
• Flotantes, enteras o seriadas; • Estáticas o dinámicas; • De lectura o de escritura, etc.
Las variables son sólo uno de los muchos tipos de objetos, pero es la más importante y está definida en el Fieldbus. Se encuentran en el AP y se las denomina Application Process Objets (APO).
2.7. Nivel de Aplicación Fieldbus
Los procesos de aplicación distribuidos en el sistema necesitan comunicarse. El Fieldbus provee los caminos (canales) lógicos de comunicación entre los procesos de comunicación. Se dispone de varios tipos de conexiones con distintas combinaciones de características para satisfacer las distintas necesidades de comunicación. Pueden existir simultáneamente varias conexiones, lo que permite un acceso multivariable.
Las conexiones Fieldbus se pueden modelar de dos maneras:
• Modelo cliente-servidor • Modelo editor/suscriptor
El modelo cliente-servidor se usa para describir la transferencia de datos acíclicos. Desde el punto de vista de la comunicación, un cliente es un AP que está usando una funcionalidad de AP remoto. El AP remoto se denomina el servidor. Por ejemplo, si la consola del
38
operador desea leer un parámetro de sintonía en un controlador en el campo, el AP en la consola es el cliente, mientras el AP en el controlador es el servidor.
El modelo editor-suscriptor se usa para describir transferencia de datos cíclicos. Desde el punto de vista de la comunicación, un suscriptores un AP que está usando una funcionalidad de AP remoto.
El AP remoto se denomina el editor. El editor en realidad está produciendo (publicando) datos, mientras un suscriptor está consumiento esos datos (suscripto a). Por ejemplo, un transmisor está publicando una variable de proceso que es consumida por un controlador. El controlador está publicando una salida que es consumida por un actuador. La transmisión es controlada por un tercero, el solicitante, que emite un pedido al editor para que publique sus datos. Cabe señalar que el modelo editor-suscriptor está derivado del modelo productor-consumidor elemental.
Tal como se mencionó anteriormente, un sistema Fieldbus se puede descomponer en variables. Hay un conjunto de servicios que hace que un AP use la funcionalidad de un AP en otro dispositivo, por ejemplo dejar que el valor de una variable manipule el objeto.
La intención básica del Fieldbus es construir la aplicación usando bloques de función. Esto se haría en los FBAPs. Sin embargo, dentro de un dispositivo Fieldbus es posible tener otros tipos de APs, por ejemplo lógica escalera o texto estructurado, si bien todavía no hay una definición al respecto.
Desde el punto de vista del Fieldbus, un dispositivo no es parte del hardware como lo es para los seres humanos. Por ejemplo, un transmisor de presión no es un conjunto de sensor de presión, electrónica y caja, sino un nodo de red que contiene parámetros. Esta visión de la red se denomina Dispositivo do Campo Virtual (VFD). Un dispositivo (estación) contiene un solo FBAP. El FBAP puede contener varios VFDs que le permiten dividir la aplicación del dispositivo en lazos individuales, con lo que le facilita al operador tener una visión general del sistema.
El VFD es la interface entre la arquitectura del protocolo y el bloque de función AP. El VFD es la parte de la aplicación real que es visible y accesible a través de la red, los objetos de comunicación como ser variables y bloques, etc.
39
Antes de que un dispositivo pueda acceder a los objetos de comunicación (por ejemplo variables) en otro dispositivo, primero tiene que saber que objetos se encuentran disponibles, y su estructura. Conocer la estructura es importante ya que no tiene sentido alguno preguntar por una variable si no se sabe como interpretar la respuesta, por ejemplo si ella es flotante o entera. Esta información puede ser preconfigurada u obtenida del compañero de la comunicación. Hay dos tipos de tales servicios: servicios operacionales para manipular objetos y servicios para la manipulación de sus atributos descriptivos.
Todos los objetos (variables, etc.) tienen un índice que permite su fácil referencia. Cada parámetro en el sistema está unívocamente identificado por su índice más la conexión. Este el método que se usa para solicitar datos una vez que el sistema Fieldbus se encuentra instalado y funcionando. El usuario no debe preocuparse en seguir índices y direcciones. Esto es realizado por la red y puede ser totalmente transparente para el usuario, de acuerdo al tipo de interface de usuario.
Una interface hombre maquina, como ser una terminal de mano, necesita mas información acerca del objeto de lo que hace falta para comunicación. Debe saber cómo presentar la información al usuario (por ejemplo en un menú), cuando se la debe actualizar dinámicamente, si hay implicado un cierto procedimiento antes de escribir la variable, etc. Esta información puede ser almacenada en el dispositivo, o suministrada separadamente, por ejemplo en un medio magnético.
Ejemplos de servicios: • Conectar dispositivo a la red • Leer estado del dispositivo • Leer fabricante, tipo y versión del dispositivo • Leer el total o parte de la configuración • Leer variable • Escribir variable • Notificar un evento • Generar un bloque • Buscar índice OD para un parámetro • Borrar bloque
40
2.8. Gerenciamiento del sistema y de la red El propósito del gerenciamiento de la red es proveer
servicios para la configuración y control central de la arquitectura del protocolo de red, como ser el mantenimiento y la puesta en marcha del sistema Fieldbus. Por ejemplo, el gerenciamiento de red administra las conexiones.
El gerenciamiento del sistema se divide en dos partes: un kernel (núcleo) que provee la funcionalidad básica sobre la cual se puede construir una aplicación de control, y una parte que provee la optimización de la operación y los diagnósticos de los problemas. También coordina funciones en todos los niveles y controla la operación global de los dispositivos y su puesta en marcha.
El propósito de un kernel de gerenciamiento de sistema es proveer funciones para:
• Asignación de tags a dispositivos • Asignacion de direcciones de estaciones • Sincronización de reloj • Programación de APs distribuidos • Vincular bloques de función
En un sistema, cada una de las funciones mencionadas
anteriormente solo pueden ser administradas por un solo dispositivo (aunque un dispositivo puede manejar muchas de ellas), mientras las otras actúan como agentes. En caso de que falle un administrador, uno de los agentes asumirá el rol de administrador.
Para que el gerenciamiento de sistema pueda realizar su tarea, debe cooperar con el gerenciamiento de sistema de las restantes estaciones en la red. Un simple dispositivo puede implementar solo una parte de las funciones de gerenciamiento de sistema.
Asignación de tag a dispositivo físico Antes de poner un dispositivo en la red, el usuario primero debe asignarle un tag al dispositivo físico (esto se hace off-line). El tag puede tener hasta 16 caracteres, por lo general de acuerdo a las prácticas normales de instrumentación, por ejemplo PT-10270.
41
Asignación de dirección de estación Se asigna y se asegura automáticamente que cads dispositivo en la red
tenga una única dirección. Un dispositivo "no iniciado" tiene una dirección de "default". Los dispositivos de configuración detectan nuevos dispositivos y les asignan una dirección de estación, después de verificar la duplicación de tags, Ilevando entonces el dispositivo al estado de "standby". Un dispositivo temporario como ser un configu-rador de mano selecciona su propia dirección si no hay tráfico en la red. Vinculación de bloques de función La red encuentra automáticamente el dispositivo (dirección de
estación) para un bloque de función dado. Luego verifica si no hay múltiples tags. Esta función se usa cuando se resuelven enlaces entre las salidas y las entradas del bloque (identificadas por el tag del bloque y el nombre del parámetro) con la dirección abreviada y la referencia del índice. Sincronización de reloj Para que el sistema Fieldbus pueda realizar la programación y otras
funciones temporales como ser la marcación de tiempo de alarmas y eventos, se dispone en cada dispositivo de una base de tiempo distribuida (reloj), lo que aporta un sentido común del tiempo entre todos los dispositivos - "tiempo de sistema". El gerenciamiento del sistema provee un mecanismo para la sincronización del tiempo en cada dispositivo. Esto se efectúa a partir del "reloj maestro" que provee el tiempo correcto. Programación El propósito de Ia programación es minimizar retardos debido a la
comunicación. Tales retardos son tiempo muerto puro que dificultan el control. La programación también asegura que el muestreo de las variables y la ejecución de los bloques de función se realicen sobre una base periódica precisa, con lo que el retardo es constante. Un retardo constante es obligatorio, ya que un cambio en el retardo requeriría resintonía. De esta manera se logra un control estricto de lazo cerrado dejando tiempo para el tráfico de fondo. La programación también asegura una tendencia exacta y una detección predecible de alarmas.
42
Hay tres funciones programadas:
• Tráfico de Fondo • Tráfico Operacional • Ejecución de Bloques de Función
La sincronización se basa en el tiempo de sistema. Un
macrociclo es un periodo de ejecución de bloques que se divide en un número entero de fases - unidades de reloj. Durante el macrociclo se transmite el trafico operacional completo y se ejecutan todos los bloques de función (ver figura 2.7).
La Ejecución de Bloques de Función comienza ejecutando los bloques de función al inicio de una fase informando al FBAP en el momento apropiado. Cabe señalar que los bloques de transductor no están incluidos en la programación, esto es para implementar técnicas
de sensado especiales o medición cuando la muestra está disponible. El usuario puede determinar en que orden deben ser ejecutados los bloques a fin de minimizar los retardos debidos a la propagación de parámetros.
El Tráfico de Fondo está programado para pasar durante las fases en que no se usan para la Ejecución de Bloques de Función o el Trafico Operacional.
En el ejemplo de la figura 2.7 se muestra un lazo de control simple que consiste de un bloque de entrada (Al), un bloque de control (PID) y un bloque de salida (AO), con el Al y el PID en el mismo dispositivo físico. No se necesita ningún tipo de conexión entre dispositivos para la variable de proceso. En este ejemplo, el periodo de ejecución para el bloque AO es mas corto a fin de mostrar que ese tiempo de ejecución de bloque depende del bloque.
La comunicación se programa en un dispositivo maestro que controla el tráfico y la solicitud de comunicación. Los bloques de función se programan en los dispositivos individuales.
El FBAP es donde el usuario configura su aplicación de medición
y control. Partes del mismo se encuentran distribuidas en varios dispositivos en el campo. No es ejecutado en una sola tarjeta de control como si ocurre en un DCS.
La funcionalidad de un dispositivo Fieldbus está modelada como objetos. El objeto bloque tiene tres clases que a su vez tienen subclases en las cuales están agrupados distintos bloques:
• Objeto bloque
- Objeto bloque de función - Bloque de función de entrada - Bloque de función de salida - Bloque de función de control - Bloque de función de cálculo
- Objeto bloque transductor - Bloque transductor de entrada - Bloque transductor de salida - Bloque transductor de display
- Objeto bloque físico
44
• Objeto alarma • Objeto evento • Objeto tendencia • Lista de displays
La parte del FBAP que está normalizada por el Fieldbus se
denomina capa de usuario o de bloque de función. Por ejemplo, los algoritmos del bloque no están normalizados. Para cada bloque hay un conjunto de parámetros que, en cierta medida, define que funcionali-dad mínima tendrá un bloque.
Sin embargo, el fabricante puede implementar tal bloque a su manera. Por ejemplo, en el bloque de control PID debe haber un parámetro de Ganancia y, por lo tanto, el fabricante puede usar este parámetro como ganancia o como banda proporcional.
2.9. Bloques de función
Los bloques modelan la parte de toda la aplicación configurable
por el usuario. Normalmente, estas funcionalidades se encontraban disponibles anteriormente en los dispositivos físicos individuales. Hoy día, varios de ellos se encuentran incluidos en la forma de bloques de software en un solo dispositivo.
Junto a un sistema Fieldbus, los distintos tipos de bloques de función proveen toda la funcionalidad necesaria para la mayoría de los sistemas de control. El usuario puede construir estrategias de control adecuadas para su aplicación acoplando estos bloques de función.
Generalmente hablando, se puede decir que los bloques de función usan algoritmos y parámetros contenidos a fin de procesar parámetros de entrada para producir como resultado parámetros de salida. De nuevo, el bloque es justamente una abstracción de software y datos. No hay ningún tipo de bloque que pueda verse dentro de un dispositivo.
El concepto de bloque de función fue diseñado en base al bloque PID puesto que este es el bloque más complejo. El concepto de setpoint local/remoto, salida automática/manual, cascada (setpoint remoto) y el algoritmo han sido Ilevados a los otros bloques, lo cual podría parecer extraño al comienzo.
45
Una selección particular de setpoint y salida se denomina el modo del bloque. El algoritmo no se refiere al algoritmo PID solo en el bloque PID, sino en general a la funcion de procesamiento de todos los bloques.
Cada bloque está identificado en el sistema por un tag asignado por el usuario. Este tag debe ser único en el sistema Fieldbus. Cada parámetro en un bloque tiene un nombre que no puede ser modificado. Todos los parámetros en el sistema están unívocamente definidos por el tag del bloque más el nombre del parámetro.
Las entradas desde otros bloques Ilegan asincrónicamente. En consecuencia, cuando se ejecuta un bloque se toma una instantánea
de las entradas. Esto también impide que cambien los datos durante la ejecución del bloque. Después de ejecutar el algoritmo del bloque, sus salidas son actualizadas y emitidas sobre la red y leídas por las entradas de los bloques usando esta información. De esta manera, la salida se ha de comunicar solo una vez, aun cuando se halla conectada a muchas entradas.
La configuración consiste básicamente en la asignación de tags y la construcción de la estrategia de control mediante la elección de los bloques (instalación), acoplándolos y ajustando los parámetros conte-nidos para obtener así la operación deseada. Todas estas operaciones pueden ser implementadas con un simple configurados de mano o a través del use de una computadora con una interfaz gráfica de usuario, lo que le permite a los usuarios trazar la configuración como un diagrama de control. La configuración puede hacerse antes o durante la operación.
Algunos bloques que podemos mencionar para mostrar su
arquitectura son:
Bloque de entrada analógica Provee la funcionalidad de lo que se conoce como transmisor. Pone a disposición del sistema Fieldbus la medición realizada por un disposi-tivo. También en forma opcional aplica calibración, atenuación y una
función de transferencia como ser raíz cuadrada de una presión diferencial medida, haciendo posible inferir mediciones como ser caudal (en este caso) en un transmisor de presión diferencial. También provee alarma para la variable de proceso.
Bloque de control PID Provee la funcionalidad del controlador PID. Esto permite que un dispositivo pueda operar como un controlador distribuido al campo en un transmisor o una válvula, normalmente para la presión, caudal o nivel que mida o sobre el cual actúe. También provee alarma para la variable de proceso y de desviación, estación L/R y A/M, etc. Se puede implementar para control por realimentación, avanacción o rango partido entre otros.
Bloque de salida analógica Provee la funcionalidad de lo que se conoce como un actuador. Pone a disposición del hardware del actuador la salida de control calculada. También en forma opcional aplica inversión de señal y realimentación de posición real.
Bloque aritmético Provee la funcionalidad para la realización de diferentes algoritmos ya predefinidos o a definir por el usuario. Está constituido por cuatro entradas independientes y una salida para la interconexión con otros bloques de función, siendo posible conectar esta salida a más de un bloque. Entre los cálculos que se pueden realizar con este bloque podemos mencionar la compensación de caudal por AGA 3, compensación de líquidos y gases, calculo de caudal en canales abiertos, poder calorífico, promedios, ecuación polinómica de cuarto orden, medición de nivel por HTG.
Bloque de función avanzado Este bloque podrá realizar las siguientes funciones: selector de señal de salida, divisor, tiempo muerto, anticipo/retardo, salida analógica compleja, salida digital compleja, control de dispositivos, alarma analógica, entrada de pulsos, interfaz binaria, generador de setpoint, integrador, caracterización, control por pasos.
48
Enlaces de bloques de función
Acoplando las salidas de los bloques de función a las entradas de otros bloques de función, se pueden construir estrategias de control. Cuando se produce tal enlace, Ia entrada "arrastra el valor de la salida, obteniendo de ésta forma su valor. Se pueden establecer enlaces entre bloques de función en el mismo dispositivo o en diferentes dispositivos (ver figura 2.10). Una salida puede ser conectada a muchas entradas. Estos enlaces son puramente software, y básicamente no hay limitación alguna a como puedan trasladarse los distintos enlaces a lo largo del cable físico.
No se pueden establecer enlaces con las variables contenidas. Los valores analógicos son pasados como punto flotante en unidades de ingeniería, pero son escalados en porcentaje (por ejemplo, en el bloque de control PID) para permitir una sintonía adimensional de los parámetros. Los valores digitales son pasados como booleanos, 0 o 225. La información del escalado analógico también puede ser usada en la interfaz de operador para brindar una lectura de grafico de barra. Un valor de salida siempre es acompañado por un estado que informa si, por ejemplo, un valor recibido de un sensor es adecuado
para control, o como Ia realimentación (camino regresivo) que informa si, por ejemplo, la salida no ha movido el elemento final de control. El estado está determinado por la fuente. Obsérvese que el sistema de arrastre es utilizado también para los caminos regresivos. De esta manera, el bloque de función receptor puede tomar una acción apropiada.
Los enlaces están unívocamente definidos por el nombre del parámetro de salida y el tag del bloque de función del cual procede. Por lo tanto, les es muy fácil a los usuarios indentificar enlaces. El gerenciamiento del sistema resuelve la construcción del tag del bloque + nombre del parámetro dentro de una corta referencia de dirección + índice para acelerar la comunicación. Los enlaces también pueden ser configurados directamente usando dirección e índice. Cuando se lo enciende, el administrador del enlace establece automáticamente las conexiones.
Todos los enlaces de los bloques de función representan conexiones editor/suscriptor. Los bloques de función están definidos para tomar acción si se pierde comunicación (por ejemplo, falla el gerente de edición).
2.10. Bloques transductor
Los bloques transductor son responsables de la interfaz
entre los bloques de función y el hardware de E/S de los dispositivos. Hay un bloque transductor para cada punto de hardware, como ser sensor, terminal de E/S o display. La norma en sí no especifica ningún parámetro para los bloques transductor, pero el grupo de usuarios tiene un parámetro identificado para varios tipos de dispositivos.
Los bloques transductor no están programados. En consecuen-cia, el fabricante puede controlar la ejecución del bloque transductor para, por ejemplo, seguir su técnica de sensado, muchas veces más rápida que la ejecución de los bloques de función. La interfaz con los bloques de función (clase de entrada o salida) es independiente del dispositivo gracias a los bloques transductor.
Los bloques transductor no pueden acoplarse usando los enla-ces de bloques de función, ya que todos sus parámetros se encuentran contenidos dentro de los mismos. Ellos se conectan con los bloques
50
de función a través de canales de hardware enumerados, y solo con bloques en el mismo dispositivo físico. El correspondiente bloque de función especifica el canal de hardware.
Bloque transductor de entrada Responsable del procesamiento de la señal del sensor como ser caracterización de temperatura y ajuste.
Bloque transductor de salida Responsable del procesamiento del actuador y de la señal de realimentación como ajuste.
Bloque transductor de display Responsable del display local y teclado o equivalente.
2.11. Bloque físico
Hay un solo bloque físico en un dispositivo. Es responsable del monitoreo de la operación de todo el dispositivo, como ser autodiagnósticos. También contiene información del dispositivo como ser el número final de ensamblado y materiales.
El bloque físico no puede ser acoplado usando enlaces de bloques de función, ya que todos sus parámetros están contenidos
dentro del mismo. El bloque físico también puede contener parámetros que son "globales" y que pueden ser utilizados por cualquier bloque en el dispositivo. Por ejemplo, un único conjunto de datos de linealiza-ción puede ser utilizado para varios bloques de entrada analógica.
El bloque de función no está programado. El fabricante puede controlar la ejecución para responder a las necesidades del dispositivo.
2.12. Parámetros de los bloques
Tal como se mencionó en la sección OOD, la arquitectura se puede descomponer en simples variables. Para las variables hay dos metatipos:
• Variable simple • Registro (estructura de datos)
Para cada metatipo hay muchos subtipos. Por ejemplo, una
variable simple puede ser flotante, entera o seriada. Las estructuras de datos son agrupaciones lógicas de
parámetros relacionados de variables simples. Por ejemplo, la estructura de datos de modo es una colección de los modos target, actual y normal. Una estructura de datos de alarma es una colección de estado/ prioridad, causa, valor causante y marca de tiempo. También el bloque es un tipo de estructura de datos.
Las variables simples pueden usarse por si mismas o como elementos de estructuras de datos. La ventaja de las estructuras de datos es que los parámetros que se necesitan juntos pueden ser accedidos con una simple solicitud, en lugar detener que solicitar cada elemento repetidas veces.
Hay muchas clasificaciones de los parámetros que se usan en los bloques. Un parámetro puede pertenecer a más de una clasifica-ción:
• Uso • Almacenamiento • Jerarquía • Acceso
52
Hay tres clasificaciones que dependen del use del parámetro en un bloque:
• Entrada. Puede ser acoplada a una salida de bloque de función para recibir ese valor. Por ejemplo, la variable de proceso de un bloque PID. Una entrada puede ser ajustada por el operador si no está acoplada. Los parámetros de entrada consisten de un valor y un estado.
• Salidas. Pueden ser acopladas a la entrada de un bloque de función
para propagar el valor. Es calculada por el bloque o puede ser ajustada por el operador en ciertos modos. Por ejemplo, la variable manipulada (salida) del bloque PID. Los parámetros de salida consisten de un valor y un estado.
• Contenida. Puede no estar acoplada pero está disponible para la
interfaz de usuario como ser configuración, operación y diagnósticos. Los parámetros contenidos controlan la operación del bloque. Depen-diendo del modo de bloque, puede ser calculada por el bloque o bien ajustada por el operador. Por ejemplo, los parámetros de sintonía del bloque PID.
El bloque transductor y el bloque físico solo pueden tener
parámetros contenidos.
Hay tres clasificaciones que dependen de como está almacena-do el parámetro:
• Estática. Escribir a esta variable incrementa el contador de revisión estático. El valor es recordado durante un ciclo de operación. Por ejemplo, un límite de alarma.
• No volátil. Escribir a esta variable no incrementa el contador de revisión estático. El valor es recordado durante un ciclo de operación. Por ejemplo, el setpoint de un bloque PID.
• Dinámica. El valor es calculado por el bloque de función o recibido como una entrada de bloque. El usuario no escribe esta variable.
53
El valor no incrementa el contador de revisión estático y no es recordado a través de un ciclo de operación. Por ejemplo, entradas y salidas de bloques.
Hay dos clasificaciones que dependen de como se puede acceder al parámetro:
• Escritura. La variable puede ser leída y escrita.
• Sólo lectura. La variable puede ser leída pero no escrita.
Hay cuatro clasificaciones que dependen del nivel jerárquico del parámetro:
• Universal. Obligatoria en todos los bloques de función. Por ejemplo, todos los bloques tienen un parámetro de tag y de modo.
• Función. Obligatoria en ciertos bloques de función según lo define la norma. Por ejemplo, un bloque de entrada analógica debe tener atenuación, y un bloque de control PID debe tener un setpoint.
• Dispositivo. Obligatoria en cierto tipo de dispositivos de acuerdo al
grupo de usuarios. Por ejemplo, todos los transmisores de presión deben tener un parámetro para la conexión de proceso, y todos los transmisores de temperatura deben tener un parámetro para el tipo de sensor.
• Fabricante. Opcional y específico para el dispositivo según lo define el fabricante. Le permite al fabricante incorporar parámetros adicionales para cubrir características únicas de su dispositivo. Por ejemplo, corte ajustable de raíz cuadrada.
La herencia de parámetros juega un rol importante para la interoperabilidad. Un dispositivo conformante tendrá como mínimo los parámetros y la funcionalidad asociada definidos como parámetros de dispositivo.
2.13. Objeto alerta
Muchos de los bloques de función tienen incorporada una función de alarma para detectar alarmas de variables de proceso alta y baja y alarmas de desviación.
Cuando se produce una alarma y otros eventos críticos, un objeto alarma le notifica automáticamente al usuario. De esta forma, la interfaz de operador no tiene que realizar una interrogación periódica para determinar si hay una condición de alarma.
Los bloques físico y transductor detectan fallas en el hardware y el estado global de la operación. El objeto alarma le saca a los bloques la tarea de manejar alertas de modo que su ejecución no es afectada en lo más mínimo. El objeto alarma también provee un mecanismo de reconocimiento para saber que el operador ha sido informado. Si la respuesta no es recibida dentro de un tiempo especificado, se repite la notificación de la alerta. El usuario también
55
es informado del momento cuando desaparece una condición de alarma.
Ejemplos de eventos:
• El modo está siendo forzado por alguna razón. • El tag del bloque ha sido modificado. • Salida enclavada / condiciones de seguridad ante fallas. • La realimentación no ha logrado la salida deseada.
Para las alarmas, el usuario puede configurar el nivel de disparo
y el nivel de prioridad y banda muerta. La notificación de alerta a la consola incluye: marca de tiempo, razón, prioridad, estado actua a alarma puede ya haber desaparecido) y el valor de disparo.
Si se produce un cambio en la configuración, se emite una notificación de alerta conteniendo prioridad, nivel de revisión de configuración, parámetros cambiados y marca de tiempo.
Todas las alertas informaran asimismo cual dispositivo y bloque es la fuente de la alarma, la clave de la alerta para Ia división de planta y un código de tipo que identifica los mensajes enumerados para el operador. Los mensajes pueden ser mensajes estándar u otros especificados por el fabricante.
Para cada bloque hay también un resumen de alarmas de hasta 16 alertas, que resumen: estado actual, si la alarma ya ha sido reconocida, si no ha sido informada correctamente al operador, o si no está habilitada.
2.14. Objeto tendencia
La tendencia puede ser realizada por el propio dispositivo
usando el objeto tendencia. De esta manera, ya no es necesario una comunicación periódica de tiempo crítico. Los datos son recolectados desde 20 muestras y son accedidos en una sola comunicación. Esto reduce la carga de comunicación y de red, dejando más tiempo para las transferencias de tiempo crítico.
56
2.15. Objeto displays
Las interfaces remotas de operador proveen monitoreo y actuación de variables, como ser variables de proceso y setpoints. Tales interfaces necesitan un acceso para configuración y diagnosticos.
Estas variables han sido agrupadas en cuatro grupos, que dependen del uso, y que pueden accederse en una sofa comunicación en lugar de varias individuales. Esto reduce el nimero de accesos y, en consecuencia, la carga de red. Todos los datos de la interfaz de operador están programados como trafico de fondo. • Datos de operación dinámica. Por ejemplo, variable de proceso. • Datos de operación estática. Por ejemplo, modo permitido. • Todos los datos dinámicos. Todas las entradas y salidas. • Otros datos estáticos. Por ejemplo, toda la configuración de alarma.
2.16. Acceso a parámetros
El operador en la consola tiene la posibilidad de otorgar o denegar el acceso a cuatro conjuntos de parámetros en un bloque para una interface local o un dispositivo de mayor nivel, como ser un programa batch. Para el bloque de función, los ajustes hechos desde la consola, localmente o por medio de un programa batch, parecerán iguales. Los cuatro grupos son: • Para un dispositivo de mayor nivel: - Programa. Modo, setpoint y salida. - - Sintonía. Parámetros de sintonía. - - -- Alarma. Parámetros de alarma. • Para una terminal de mano o interfaz local: - Local. Modo, setpoint y salida.
57
2.17. Optimización
La versión de baja velocidad del Fieldbus se eligió para satisfacer [as restricciones sobre la capacidad de procesamiento impuestas por la necesidad de cumplir con los requerimientos de seguridad intrínseca.
Por su parte, para poder cumplir con la necesidad de un control de lazo cerrado estricto restringido por el bajo ancho de banda de comunicación, se ha optimizado el use de la red de las maneras que se describen en forma resumida a continuación:
• Programación • Breves referencias • Definición de parámetros estándar • Alerta de cambio de configuración • Objeto displays • Objeto alerta • Objeto tendencia
La programación asegura que la red nunca estará ociosa,
esperando que Ileguen algunos parámetros. Los tags de los bloques y los nombres de los parámetros son convertidos a una dirección y un índice. Los parámetros están normalizados y no tienen que ser "decodificados" de muchas maneras diferentes.
Cuando se produce un cambio en un dispositivo de campo, la host es informada automáticamente donde se ha producido el cambio, necesitándose actualizar solo el parámetro. No es necesario efectuar verificaciones continuas para ver si la configuración ha cambiado.
El objeto tendencia y el objeto displays reducen el numero de comunicaciones necesarias para el acceso de datos. En consecuen-cia, queda mucho mss tiempo para las tareas de tiempo crítico.
El objeto alerta asegura que la host no tiene que cargar la red con interrogaciones frecuentes sobre el estado de las alarmas; el cambio de estado de una alarma es notificado en forma automática.
58
3. Usando el Fieldbus Para el usuario, lo más importante es comprender el
comportamiento de los bloques de función. Un lazo de control, por ejemplo el de la figura 2.10, contiene normalmente por lo menos un bloque Al (transmisor), un bloque PID (controlador) y un bloque AO (válvula). El hecho de que estos puedan estar en tres dispositivos separados plantea numerosos requerimientos para la interoperación entre estos bloques. Por ejemplo, si el operador asume el control de la válvula, el controlador debe estar informado para que no se desvanezca (-windup-) y para ser capaz de implementar una transferencia suave cuando el operador devuelve el control a la válvula. De la misma manera, el controlador debe detener la integración si la medición desde el transmisor es mala o no existe.
3.1. Modos
El modo tiene dos funciones: selección de setpoints y selección
de salidas. Esto se puede comparar con los clásicos modos de control: Local/Remoto y Automático/Manual, respectivamente. También hay modos para «fuera de servicio» y «relevo local» (seguridad). El nÚmero de modos implementados en un dispositivo varÍa de bloque a bloque.
El bloque genérico de la figura 3.1 también muestra que los bloques de entrada no tienen selección de setpoints y que los bloques de salida no tienen selección de salidas.
• Selección de salidas
Automático. El algoritmo del bloque calcula la salida usando sus entradas. Es el único modo en el grupo de selección de salidas donde se usa un setpoint.
Manual. La salida es ajustada por el operador.
Relevo local. La salida sigue un parámetro de seguimiento provisto por otro bloque, por ejemplo un valor de seguridad. Este modo sólo puede ser ajustado por una entrada de bloque especial.
59
Inicialización. El bloque va balanceando su salida, lo que significa que sigue un valor de realimentación provisto por un bloque corriente abajo.
Salida remota. La salida del bloque es calculada y provista por una computadora.
• Selección de setpoints
Local. El bloque calcula la salida usando sus entradas y el setpoint desde el operador.
Cascada. El bloque calcula la salida usando sus entradas y el setpoint desde un bloque remoto.
Cascada remota. El setpoint es calculado y provisto por una compu-tadora host. La salida es calculada por el propio bloque.
Seguimiento de setpoint. Esto solo es válido con selección de salidas manual. El setpoint está siguiendo la variable de proceso.
En un bloque hay distintos parámetros de modos, cada uno con
una función particular: Modo target. Es el modo solicitado por el operador. Sólo pueden seleccionarse los modos admitidos por el modo Permitido. El bloque tratará de alcanzar este modo y puede o no lograrlo, lo cual depende de las distintas condiciones de los bloques y dispositivos.
Modo actual. Es el modo predominante del bloque. De acuerdo a las condiciones vigentes, puede o no ser el mismo que el modo target. Puede cambiar no sólo a pedido del usuario, sino también debido a otros eventos.
Permitido. Define los modos que están a disposición del operador. Está configurado por el ingeniero de proceso antes de la operación.
Cuando se inicia un bloque y luego es Ilevado a la operación, el
modo inicial será «fuera de servicio». Una vez en operación, el último modo permanecerá durante un ciclo de operación.
Cuando es ejecutado un bloque, el modo se determina primero a partir de los bits de estado de las distintas fuentes de setpoints, salidas y de realimentación, y el estado global de los dispositivos.
61
3.2. Bits de estado
El equipamiento basado en microprocesador es capaz de detectar errores en su hardware. Esta información es utilizada para informar la calidad de las variables enviadas a fin de impedir un desvanecimiento integral en los bloques de control, y de proveer un mecanismo para que los bloques puedan mudarse a modos de seguridad.
Todas las entradas y las salidas de los bloques de función están acompañadas por estados. Por ejemplo:
• Calidad: buena, dudosa, mala o fuera de servicio; la calidad
mala puede deberse a ausencia de comunicación, falla de hardware, etc.
• Pedido de inicializar: fuerza a un bloque corriente arriba a inicializar para proveer una transferencia suave.
• Alta limitada, por un limitador en un bloque corriente abajo. • Baja limitada, por un limitador en un bloque corriente abajo.
Los estados recibidos con las entradas provenientes de otros bloques que indican discontinuidades en el control pueden hacer que el bloque cambie automáticamente su modo. Cuando la condición que provocaba el cambio desaparece, el modo normalmente vuelve al modo anterior. El usuario puede configurar el modo al cual le es permitido al bloque cambiarse.
El estado de las variables de salida de un bloque depende del modo del bloque. Una falla en uno de los bloques puede entonces Ilevar a una reacción en cadena en el cambio de modos para asegurar que todos los bloques se encuentren en el modo apropiado.
3.3. Estructura en cascada
La estructura en cascada es un concepto importante en la construcción de estrategias de control. En un sentido más amplio, la estructura en cascada se refiere a que la salida de uno de los bloques, normalmente un bloque PID, está acoplada al setpoint de cascada de otro bloque, no necesariamente un bloque PID sino por lo general un bloque de salida.
El bloque que provee la salida se dice estar ubicado «corriente arriba» en el camino de la señal, mientras el bloque que recibe el setpoint de cascada se dice estar «corriente abajo». En consecuencia, el setpoint de cascada proviene, en un sentido más amplio, de un bloque corriente arriba, mientras el bloque receptor manipula su salida acordemente.
En una estructura en cascada también se provee un camino de realimentación. El bloque corriente abajo en la estructura en cascada no siempre es capaz de aceptar el setpoint de cascada proveniente del bloque corriente arriba. Por ejemplo, si el setpoint de cascada no se
usa a causa del modo del bloque, o por estar más allá de los límites correspondientes, o el bloque no es capaz de mover el actuador. Si el bloque corriente arriba no es informado que ya no puede mover su salida, la acción integradora del controlador PID puede desvanecerse, o en el caso de otros bloques, podría pensar que está actuando cuando en realidad no lo hace. El estado del valor de realimentación le permite al bloque corriente abajo informar al bloque corriente arriba de lo que está pasando. El bloque PID también puede usar el valor de realimentación para balancear su salida. 3.4. Aplicaciones Han quedado definidos muchos bloques de función. Ellos pueden combinarse para producir la mas simple de las mediciones usando solo un simple bloque de entrada analógica, y para construir estrategias de control clásicas como ser simple lazo, cascada, relación, limite cruzado, etc., e incluso esquemas de control aun mas complejos de los cuales algunos se muestran en las figuras 3.2, 3.3 y 3.4. Los parámetros básicos de entrada y salida se explican a continuación: IN. Entrada de variable de proceso.
OUT. Salida básica del bloque.
CAS-IN. Entrada para setpoint remoto desde otro bloque, setpoint cascada. BKCAL_IN. Entrada de realimentación desde el bloque corriente abajo. Valor usado para inicialización, balance, de la salida del bloque para asegurar una transferencia suave de setpoint en el bloque corriente abajo cuando este retorna al modo local. BKCAL_OUT. Copia del setpoint seleccionado a ser usado por el bloque coriente arriba para la inicialización de su salida.
64
RCAS_IN. Entrada para setpoint desde una host, seleccionado en modo de cascada remota. RCAS OUT. Copia del setpoint seleccionado, valor idéntico a BKCAL OUT pero el estado está basado en una comunicación RCAS_IN. ROUT-IN. Entrada para salida remota desde host, seleccionada en el modo de salida remota. ROUT OUT. Copia de la salida seleccionada, OUT, pero con el estado basado en una comunicación ROUT IN. SP (contenido). Setpoint ajustado por el operador en el modo local, o el setpoint después de la limitación de setpoint recibida de otro bloque o de una host.
65
4. Aplicación del Fieldbus
4.1. Sistema de medición hidrostática de parque de tanques
Esta es una de las aplicaciones donde se puede apreciar
claramente la ventaja de utilizar la tecnología del Fieldbus en un parque de tanques.
El manejo de inventarios, el control de perdidas y las aplicaciones de transferencia de productos entre terceros (transferencia en custodia) requieren la medición de masa con una muy buena exactitud, lo cual se puede lograr con un sistema de medición hidrostática HTG (Hydrostatic Tank Gauging).
El sistema consiste en utilizar uno o más transmisores de presión y un transmisor de temperatura, que transmiten sus valores a un procesador de tanque colocado al pie del mismo o a una computadora donde se realizan los cálculos de masa total, nivel, volumen total, densidad, etc.
Este tipo de aplicaciones, además de requerir transmisores de elevada exactitud, plantean el inconveniente de las grandes distancias que separan un tanque de otro y de la sala de control.
Se debe utilizar un procesador de campo o una remota para cada tanque, donde el costo de este dispositivo mas el de sus drivers son elevados. También se debe incorporar un software dedicado para correr en la computadora que permita que la misma sea la interface hombre/maquina con el proceso.
Y aquí es donde aparece la tecnología de Fieldbus, que permite obtener importantes ventajas:
• Los transmisores Fieldbus no poseen convertidores analógicos/
digitales que empeoran la exactitud. • La comunicación entre cada dispositivo es digital y bidireccional. • Los cálculos necesarios para Ia determinación de masa y volumen se
realizan en los bloques de función de los dispositivos Fieldbus, sin necesidad de utilizar los procesadores de campo al pie de
cada tanque. • Dado que se conectan a un medio físico único (par de cables), se
66
consigue una instalación más económica y sencilla. • Al no necesitar de procesadores de campo para cada
tanque, no se exige ningún software y/o driver especial para la estación supervisora, con lo que se puede utilizar el software estándar que tenga cada planta como ser Aimax, Factory Link, Wizcon, Fix, etc.
• Dada la intercambiabilidad e interoperabilidad de los dispositivos de campo Fieldbus de distintos fabricantes, el usuario no se encuentra atrapado en la necesidad de comprar los mismos productos del fabricante inicial en el caso de ampliar el parque de tanques.
Dado que los dispositivos cuentan entre sus bloques de
función con bloques de entrada analógica, cálculos aritméticos, linealización, caracterización, control PI D, totalización, selector de máximo/mínimo, etc., todos los cálculos necesarios en un parque de tanques se pueden efectuar dentro de dichos dispositivos.
En esta aplicación de HTG (figura 4.1.), solo se utilizaran
bloques de entrada analógica, bloques de linealización y aritméticos.
Suponiendo un tanque vertical, el detalle de la configuración implementada con dispositivos Fieldbus se muestra en la figura 4.2. A partir de dos presiones diferenciales leídas por los bloques LT-A1 y DT-AI, se obtiene, mediante la utilización del bloque DT-ARTH, el valor de la densidad del líquido contenido en el tanque.
Utilizando la presión diferencial leída por el bloque LT-Al, la densidad obtenida del bloque DT-ARTH y considerando además el valor de la presión a la cual se encuentra presurizado el tanque (valor leído en el bloque PT-Al), se puede determinar el nivel del líquido en el bloque PT-ARTH.
La salida del bloque PT-ARTH es transferida al bloque LT-CHAR que tiene almacenada una curva que relaciona nivel con volumen, permitiendo así la obtención del volumen de dicho bloque.
La salida del bloque DT-ARTH y la salida del bloque LT-CHAR se ingresan al bloque LT-ARTH donde se obtiene el valor de la masa contenida en el tanque.
Como la temperatura interfiere indirectamente en la medición del volumen almacenado en el tanque, una función del transmisor de temperatura es verificar instantáneamente este valor para encontrar la densidad estándar y el volumen estándar, lo cual se realiza transfiriendo el valor leído por el bloque TT-Al al bloque TT-CHAR donde se tiene almacenada una curva que relaciona temperatura con densidad, permitiendo así la obtención de la densidad estándar.
Considerando las salidas de los bloques LT-ARTH y TT-CHAR como entradas del bloque TT-ARTH, se obtiene el volumen estándar.
De esta forma quedan implementados todos los cálculos necesarios en los dispositivos Fieldbus, quedándole a la computadora solo la tarea de almacenar dichos cálculos; utilizando un software comercial (no esencial para HTG), se pueden obtener reportes, tendencias y la vista del proceso en una pantalla.
Como se puede apreciar en la figura 4.2., para realizar esta implementación se utilizaron solamente 10 bloques de función. Las señales de proceso entran por los bloques de entrada analógicos (Al), mientras que los cálculos de densidad, nivel, masa y volumen estándar se obtienen en los bloques aritméticos (ARTH). A través de un bloque de caracterización (CHAR) se obtiene el volumen del líquido contenido en el tanque.
68
Cabe señalar que por la capacidad que poseen los transmisores Fieldbus, muchas de las transferencias de datos entre bloques se realizan internamente en un dispositivo, con lo cual son muy pocas las comunicaciones que se efectúan por el Fieldbus entre diferentes dispositivos.
Esta aplicación se implementó en la practica con los transmiso-res de presión diferencial y de temperatura de la Serie 302 de Smar.
70
71