PDF de programación - Entrega 26 - Curso sobre Controladores Lógicos Programables (PLC)

Curso sobre Controladores Lógicos
Programables (PLC).

Por Ing. Norberto Molinari.

Entrega Nº 26.

Capitulo 5.

Redes Digitales de Datos en Sistemas de
Control de Procesos.

5.10. Ejemplos de protocolos, Parte 2

Definiremos como protocolos de transferencia de datos en tiempo real a aquellos que
permitan la transferencia de valores o estados asociados a variables de proceso, y el
intercambio de datos entre aplicaciones corriendo en distintos equipos digitales, dentro
de tiempos cortos cuya definición depende de la aplicación.

Son numerosos los protocolos que existen para resolver este problema, la mayor parte
de ellos definidos por distintos fabricantes. Podemos mencionar algunos, como
MODBUS (de Modicon), Allen Bradley; y numerosos protocolos cuyos nombres están
asociados a los equipos a los que sirven.

La mayor parte de estos protocolos responden a la descripción dada en la sección 5.1
de] esquema maestro-esclavo. Estos protocolos suelen utilizar RS-232 ó RS-485,
mientras que los demás niveles son un desarrollo particular de cada fabricante. Estas
aplicaciones suelen estar limitadas a velocidades de 9600 bps.

En la última década se han empezado a difundir aplicaciones que utilizan redes LAN,
sobre las cuales se implementan protocolos de los fabricantes. Un caso es el de los
sistemas de control basados en PC.

Estos sistemas suelen implementarse sobre redes cuyas capas 1 a 5 corresponden a redes
como las descriptas, siendo usual que la interfase a la capa de sesión se realice según
NetBIOS. Algunos ejemplos son Gen-Net (Software Genesis, de Iconics) o FMMS
(software DMACS, de Initellution). Otro caso similar es el de integración de sistemas
de control, con redes informáticas.
El uso de un software apropiado permite el acceso a los datos del sistema a lo
largo de toda la red.

Un ejemplo de esta aplicación es la red AISNet (del sistema I/A Series de Foxboro), que
cubre los niveles 5, 6 y 7, apoyándose en redes como TCP/IP o Novell (IPXISPX).

Se han realizado muchos esfuerzos para lograr la normalización de estas redes.
En estos esfuerzos se vio que el problema tiene dos facetas (Fig. 5.36).

(cid:137) El manejo de información asociada al proceso en redes de control asociadas al nivel

de supervisión, o en la red administrativa la planta.

(cid:137) La integración de datos de diversos equipos de control, a nivel de campo.

En 1980 General Motors inicia el desarrollo de] protocolo MAP, que apunta a resolver
el primer problema. Como se describirá en la próxima sección, el desarrollo de MAP ha
perdido mucho impulso desde 1987.

Por otra parte, desde 1989 se ha aumentado la actividad para la concreción de una
norma de bus de campo (FieldBus), que apuntaría a resolver el problema de integración
de los equipos de campo. Puesto que los distintos desarrollos de FieldBus incluyen a
MMS (servicio incluido en la capa de aplicación de MAP) en su arquitectura, es posible
pensar que éste pueda satisfacer también las necesidades de las redes de planta.

Describiremos a continuación ambos protocolos, dedicándonos en primer lugar a MAP,
por ser cronológicamente anterior al FieldBus.

5.10.1 Manufacturing Automation Protocol

Es un conjunto de protocolos cuyo desarrollo fue iniciado en 1980 por General Motors.
Puesto que el objetivo de MAP fue lograr que dos estaciones que conforman MAP
puedan comunicarse sin necesidad de definir más detalles de implementación, MAP
comprende una especificación detallada de todas las capas de] modelo ISO / IOSI.

A su vez, refiere en las distintas capas a diversas normas. Muchas de estas normas
fueron consensuadas con el grupo TOP liderado por la Boeing, utilizándose los mismos
protocolos en MAP y en TOP. De esta forma, se define exactamente como los
dispositivos y programas de aplicación se comunican entre sí.

La Fig. 5.37 muestra la pila de protocolos de MAP. La capa de aplicación comprende
principalmente a la Especificación de Mensajes de Fabricación (Manufacturing
Message Specification, MMS), que incluye más de 80 servicios para el intercambio de
mensajes en plantas de manofactura. La importancia de la especificación deMMS radica
en que es utilizada en los principales proyectos de fieldbus que se describirán en la
próxima sección. Otro servicio incluido en la capa de aplicación es la Transferencia y
Administración de Archivos (File Transfer, Access and Management, FTAM).

El comité MAP presentó a su protocolo en diversas exposiciones. Robert Waterbury,
editor de la revista Intech, reflejó así el esfuerzo realizado por diez proveedores en una
demostración realizada en ISA/91 [Ref.51] (Fig. 5.38):

"Una de las demostraciones más notables de comunicaciones abiertas fue realizada
con MMS.
MMS corresponde al nivel 7 del modelo ISO / IOSI, pudiendo ser implementado
en otras redes que no respetan este modelo. Consiste en mensajes con un formato
específico que es comprendido por dispositivos MMS compatibles. Actualmente
hay disponibles 84 servicios para acceso a archivos, reportes, registro de eventos y
control”.

“MMS es soportado por más de 40 compañías, 10 de las cuales participaron de la
demostración: Siemens, US Data, Hewlett Packard, IBM, GE Fanuc, DEC, AEG
Modicon, Computrol, Aimco y Allen Bradley.”

“La demostración mostró la comunicación entre PLCs, PCs, monitores y
software a través de redes IEEE 802.3 y 802.4, con protocolo MMS.
El objetivo de la demostración fue promover la aceptación de MMS por parte de la
industria como el protocolo de integración de aplicaciones industriales".

MAP no alcanzó la difusión esperada, en parte por los altos costos que implica. George
Blickley, editor de Control Engínering, opinaba ya en 1987 que MAP había perdido
impulso en la medida en que se tomaba conciencia de los costos implícitos, incluyendo
hardware, software, planificación, instalación, pruebas y correcciones (debugging) [Ref.
101]. Este alto costo está asociado al diseño de las capas física, de enlace y de
transporte.

MAP comprende también una serie de arquitecturas adicionales, como MAP/EPA
(Enhanced Protocol Architecture), MAP/PROWAY y MiniMAP. Estas arquitecturas
adicionales buscan tener un menor costo para determinadas aplicaciones.

Uno de los puntos usualmente requeridos en redes de integración de equipos digitales de
control de procesos, es la redundancia. Este requerimiento no es satisfecho por MAP, en
ninguna de sus arquitecturas.

5.10.2 FieldBus

La inclusión de microprocesadores en numerosos equipos de campo permitió su
integración en redes, con importantes ventajas como la mayor precisión derivada de la
integración digital de las mediciones, el ahorro en el tendido de cables, diagnóstico
remoto de componentes, disminución del tamaño de la sala de control, etc. Estos
conceptos resultaron aplicables a controladores unilazo, módulos remotos de E/S,
transmisores inteligentes, PLCs y otros equipos digitales de campo. Dado que no
existían normas para la integración digital de estos equipos, cada proveedor desarrolló
un protocolo propio, por lo que estas ventajas estuvieron limitadas a algunos equipos de
un mismo proveedor.

Varios grupos han intentado generar e imponer una norma que permita la integración de
equipos de distintos proveedores.

Podemos identificar dos corrientes en este sentido. En los Estados Unidos, la
introducción en 1982 de los primeros transmisores inteligentes por parte de la firma
Honeywell, seguida por otras compañías como Foxboro y Rosemount, incentivo a la
Sociedad Americana de Instrumentos (Instrument Society of America, ISA), a formar el
comité SP50, cuyo objetivo es el diseño de un protocolo normalizado para la
integración de transmisores inteligentes.

En Europa, firmas como Siemens, Telemecanique, AEG, Klockner Moeller, y otras,
concentraron sus esfuerzos en la creación de un bus digital para la integración de PLCs.
Dos grupos se impusieron: la norma alemana Profibus, y la norma francesa FIP.

Puesto que el esfuerzo de los tres grupos está dirigido a desarrollar e imponer un bus de
datos que permita la integración de equipos digitales de campo, se lo denominó,
genéricamente FieldBus.

El desarrollo de esta norma emergente no ha estado exento de marchas, contramarchas,
e incluso una fuerte presión de proveedores que ya habían diseñado un FieldBus, y
deseaban disminuir sus futuros costos de diseño imponiéndolo. Tampoco se quedaron
atrás distintos entes normalizadores nacionales.

Repasemos algunas frases que se dijeron en los últimos años:

1. "Dado que hay mucha presión para desarrollar una norma internacional
de FieldBus durante 1990, podemos esperar un rápido progreso.”

Robert Stockdale, Control Engineering, Octubre 1989.

2. "La ausencia de una norma de comunicación disminuye el progreso de los
transmisores de proceso.”

Robert Stockdale, Control Engineering, Septiembre 1990.

3. “El desarrollo de una norma para FieldBus está progresando rápidamente en todos los
niveles”.

Robert Waterbury, Intech, Agosto 1991.

4. "La ausencia de una norma de comunicaciones está disminuyendo la adopción de
transmisores inteligentes en varias industrias.”

Robert Stockdale, Control Engineering, Septiembre 1991.

5. "Finalmente, el FieldBus puede ver la luz del día".

6. “En septiembre de 1991, tres grandes compañías: Rosemount, Honeywell y Ronan
Engineering anunciaron su compromiso para el desarrollo del silicón para los dos
primeros niveles del FieldBus. "

Michael Badd, Control Engeneering, Octubre 1991.

7. “Una norma de comunicación está en contra de los intereses que dominan el mercado
de controladores de campo, por lo que Allen Bradley, Rosemount y Texas
Instruments demorarán todo lo posible el desarrollo de SP50. “

Peter Jacobs,Director del Grupo de Usuarios de Profibus, Alemania, Chemical ,
Engeneering de 1992.

8. "El FieldBus francés FIP puede manejar funciones de control dentro de tiempos
críticos que no pueden ser manejados por Profibus".

Patrick Chatalet, Gerente de Desarrollo, Cegelec SA,