CONSEJO DIRECTIVO

AADECA 94-96

Presidente: Ing. Jonas Paiuk

Vicepresidente 1 ro: 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 20 0 (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 2 4 5 . 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 a g e n t e ) , 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