Tp 3 - Facultad de Ingeniería

UNIVERSIDAD DE BUENOS AIRES
FACULTAD DE INGENIERÍA
DEPARTAMENTO DE ELECTRÓNICA
LABORATORIO 6: REDES INDUSTRIALES
66.48 – SEMINARIO DE REDES
ALUMNOS
Grupo:
• Orlandi, Guido 78602
• Veira Tassara, Alejandro Agustín 79458
2° CUATRIMESTRE 2005
Índice
Objetivos
Definiciones
Fieldbus (bus de campo)
Mecanismo de Schedulling
Bus AS-I
CAN (Control Area Network)
DeviceNet
Modbus
Profibus
Anexo
RS 422
RS 485
RS 232
Objetivos
El objeto del siguiente trabajo es presentar una breve descripción de las redes utilizadas
en el ambiente industrial. En comparación con la amplia difusión del estándar
802.3/Ethernet-TCP/IP, no existe en el ambiente industrial un estándar ni una solución
de amplia difusión. La respuesta a las necesidades consiste en un conjunto de diversas
soluciones propietarias que aplican distintos métodos de acceso al medio, etc.
Surgen dos preguntas intuitivas: que requiere una Red Industrial (a diferencia de una red
de datos) y por que los estándares de redes de datos no son apropiados.
A continuación intentaremos encontrar un conjunto de respuestas satisfactorias a las
preguntas anteriores.
Los buses que vamos a describir son solo algunos de los existentes, pero dado a que no
existe un estándar, sino que se trata en general de protocolos propietarios, elegimos
estos debido a su amplia utilización en el mercado, a nuestro entender. Existen también
otras redes muy conocidas.
Definiciones
Una Red Industrial es utilizada en un sistema de producción, se encarga de conectar
distintos procesos de aplicación con el propósito de asegurar la explotación de la
instalación. La red debe cumplir las siguientes condiciones:
•
•
•
Red de tiempo real: la información debe poder se enviada en el momento que
se genera e idealmente debe llegar en el mismo momento que se genera. Aunque
esto último no se cumple exactamente, si se puede pedir a una red industrial una
demora en la emisión y arribo de los datos mucho mayor que a una red
convencional para datos.
Provee servicio bajo restricciones temporales: lo cual implica que un dato,
dependiendo de su prioridad puede tener que ser entregado en un tiempo
determinado, fijo (algo que no puede darse en una red Ethernet).
Identificación de prioridades: Para priorizar la entrega de determinados datos
sobre otros.
A diferencia de una red convencional de datos, en la Red Industrial los recursos son
utilizados por procesos cuyo servicio ya está definido y en muchos casos tiene un
tiempo de respuesta crítico. En vista esto, la red debe proveer un sistema de distribución
de tráfico determinístico.
Si se piensa en el método tradicional de entrega de datos de Ethernet, el CSMA-CD, se
comprende que ante la posibilidad de que otro usuario este utilizando el medio, habrá
que “esperar” que este termine, para agravar las cosas este tiempo de espera no esta
definido, sino que depende de las necesidades del usuario y de la aplicación, además en
caso de que dos terminales transmitan a la vez y haya colisión, deberá retransmitirse
pasado un cierto tiempo, no determinado, pudiendo darse el caso inclusive de que
alguno de los terminales “desista” de enviar sus datos. Esto es lo que se conoce como
método de acceso al medio aleatorio.
En contraposición un medio de acceso determinístico asegura a cada proceso un instante
de acceso y un intervalo de tiempo durante el cual puede transmitir determinado, y
además garantiza una demora acotada en el tiempo de acceso al medio. Todos estos
parámetros se fijan de acuerdo a la prioridad y las necesidades del proceso.
Según nuestra consideración de Red Industrial hay que decir que además de interactuar
con los distintos procesos, además esta conectada con redes de datos, permitiendo
acceder a la información del control de la industria desde terminales conectados a la
Internet o a una red IP-Privada. El siguiente gráfico muestra como se da esa interacción.
Para conectar la FAN con la LAN se colocan un gateway capaz de “traducir” los
protocolos de las distintas redes. Cabe aclara que, en la mayoría de los casos, más allá
de la red de supervisión no se puede actuar sobre ningún parámetro de la red industrial,
simplemente esta para ser consultado a modo informativo.
La conexión de la LAN con la WAN se realiza en general a través de más de un firewall
para garantizar la seguridad y confidencialidad de los datos industriales.
En lo que sigue nos concentraremos en las partes más baja de la imagen, la Red de
Campo y la Red de Control de Procesos.
Fieldbus (bus de campo)
La primera red que se ve de abajo hacia arriba es la red que se encarga de conectar los
que se conoce como dispositivos de campo (PLCs, controladores, sensores,
actuadores, etc.) distantes entre si. Esto es un bus de campo, el objetivo de un bus de
campo es sustituir las conexiones punto a punto, utilizadas en tiempos pasados, entre los
elementos de campo y el equipo de control, hoy reemplazadas típicamente con redes
digitales, bidireccionales, multipunto, montadas sobre un bus serie.
Solución centralizada tradicional
Solución distribuida con bus de campo con salida a redes de datos
Los buses de campo tienen ventajas frente a las soluciones centralizada en cuanto al
costo y las facilidades del diseño, la instalación y la futura ampliación. Además mucho
de los procesos de control y señalización de la comunicación que antes debían estar
incluidos en los controladores hoy pueden distribuirse en los diversos dispositivos de
campo, simplificando tareas. Por otro lado si un dispositivo de campo requiere algún
dato de otro D.C. puede pedírselo directamente, sin necesidad de pedírselo al
controlador, ya que están conectados sobre el mismo bus.
Aquí surgen otra vez los conceptos analizados antes, de tiempo de respuesta
determinístico por parte de la red o el bus de campo. En lo que resta del trabajo nos
encargaremos de analizar los diversos estándares y protocolos de acceso al medio en
buses de campo, en orden creciente de complejidad.
Requisitos de un fieldbus (bus de campo):
1. Transportar pequeños paquetes de datos en un tiempo acotado, el tamaño de
los datos es corto para ocupara lo menos posible la red (Ethernet no cumple este
requisito).
2. Transmitir datos periódicos antes de que vuelvan a ser muestreados, los
componentes en régimen toman datos de manera periódica y deben transmitirlos
antes de renovar dichos datos.
3. Transmitir datos aperiódicos en un tiempo acotado.
4. Indicar la si la frecuencia con que se muestrea un dato está acorde a la
importancia de ese dato (consistencia temporal), es de vital importancia
controlar este parámetro y poder ajustar la red para cumplir los requisitos de
consistencia temporal.
5. Poseer medios para determinar el orden en el que se produjeron los datos
esporádicos.
6. Soportar transmisiones punto a punto y multipunto.
7. Soportar los ambientes industriales, en general las redes de datos no tienen los
medios físicos (cables, conectores, etc. que puedan ser utilizados en ambientes
industriales).
Ethernet-TCP/IP como bus de campo
Como dijimos antes gracias a la gran difusión de Ethernet junto a TCP/IP, a lo largo del
tiempo han intentado utilizar esto protocolos en ambientes industriales. Hace más de 20
años aparecieron soluciones como MAP, FACTOR entre otras; todas ellas fueron
descartadas por el factor de aleatoriedad que introducía ethernet con TCP/IP.
Hoy gracias a la aparición de Switchs que limitan los dominios de colisión, el aumento
de las velocidades y la posibilidad de introducir mecanismo de priorización se volvió a
pensar en utilizarlas.
La siguiente tabla muestra las contras y las soluciones de la utilización de Ethernet con
TCP/IP en relación a los requerimientos de un bus de campo.
Contras
Tamaño mínimo de la trama de 64bytes
Método de acceso CSMA-CD
Poca capacidad para detallar prioridades
Demasiado delay al detectar-corregirretransmitir ante eventuales errores
(puesto que es el nivel de enlace el que se
Soluciones
No es grave a altas velocidades
La red se puede subdividir en dominios de
colisión colocando switchs y minimizar
los problemas ocasionados por el acceso
el medio
encarga de esto, genera mucho tiempo de
procesamiento).
Muestreo periódico de datos, requiere
mucha complejidad y demora mucho
Se puede hacer implementando algoritmos
de sincronización a nivel de procesos.
Se puede agregar un timestamp para
verificar coherencia temporal.
No se puede saber el orden relativo de los
eventos esporádicos
Los cables y conectores estándar no
soportan la condiciones industriales
Ethernet usa topología de árbol que resulta
mas compleja que la utilizada por otros
buses
Se requiere mayor complejidad
computacional para implementar TCP que
para otros buses industriales
Se debe cablear por separado la
alimentación de los equipos
Se puede transmitir en modo broadcast
Están apareciendo cables y conectores
especiales para dicho tipo de ambientes
Se ve que sigue comportándose de manera aleatoria la red, además no se puede
garantizar la consistencia temporal (solo verificarla), no se puede saber el orden de los
eventos, no hay un mecanismo rápido de retransmisión, no hay cableado para
alimentación, y además el cableado especial para ambientes industriales es mas caro y
complejo que el convencional.
Aún hoy utilizar Ethernet con TCP/IP como bus de campo presenta muchos
inconvenientes. Queda limitada su funcionalidad a otras partes dentro de la red
industrial.
Después de ver el estándar de Ethernet y sus múltiples fallas como bus de campo se ve
que es necesario definir nuevas tecnología para que puedan cumplir los requisitos
necesarios, las siguientes son algunas soluciones desarrolladas con este fin. Las
soluciones propuestas utilizan Mecanismos de Schedulling, Redes tipo token-ring, y
mecanismos de acceso al medio que definen prioridades.
Mecanismo de Schedulling
Un mecanismo desarrollado para cumplir las condiciones de bus de campo antes
mencionadas es el Schedulling. Este mecanismo, en contraposición con el de CSMACD, consiste en dividir el tiempo en slots y asignar un tiempo de inicio u offset para que
cada tarea transmita sus datos dentro de su slot comenzando en su tiempo asignado, así
la red presenta un comportamiento determinístico. Además se deja un slot destinado a
comunicaciones no programadas dentro del cual puede transmitir cualquier proceso que
lo necesite, dentro de ese slot la red presenta un comportamiento aleatorio. Este
mecanismo requiere de una sincronización de los procesos, además de un gestor de red
que asigne los recursos que le corresponde a cada uno.
La siguiente figura ilustra la implementación del mecanismo.
El éxito en la implementación de este mecanismo en un bus de campo depende del
control de acceso al medio y la velocidad de transferencia.
Bus AS-I (ACTUATOR SENSOR INTERFACE)
El estándar AS-I comprende la capa física y de acceso al medio. Utiliza un modelo
Master-Slave en contraposición con el modelo Cliente-Servidor. En este modelo el
Maestro realiza un ciclo de polling obligando a cada esclavo a enviarle sus datos, de a
uno por vez, cada esclavo puede tener conectados de uno a cuatro dispositivos. El ciclo
entero de polling esta dentro del orden los 5ms, esto impone una restricción a la
cantidad de esclavos que se pueden manejar por Maestro y la cantidad de información
que cada esclavo puede transferir.
El sistema completo consta de:
•
Maestro que soporta hasta 31 esclavos a una distancia de 300 metros (con
repetidoras cada 100m)
El maestro puede ser un PLC, en este caso se controla directamente la planta
programando el PLC; o puede colocarse Gateway (AS-I), a través del cual se
envían los datos I/O tomados del bus de campo a protocolos de capa superior
como Profibus, DeviceNet, etc.
•
Esclavos que pueden ser: Unidades I/O con 4 entradas/salidas digitales para
conectar sensores, actuadores, etc.; o dispositivos con chip AS-I integrados.
•
Fuente de alimentación
•
Cableado especialmente diseñado para ambientes industriales, en el mismo
cable se transportan los datos y la alimentación para los esclavos y los sensores.
El bus AS-I soporta configuraciones en red, en línea, en rama y en árbol.
CAN (Controller Area Network)
CAN es un protocolo definido por las normas ISO11898 e ISO16845 que garantizan el
correcto intercambio de datos.
CAN se basa en un mecanismo de broadcast con un protocolo orientado a mensajes.
Cada mensaje tiene un identificador que es único dentro de la red. El identificador lleva
asociada una prioridad que es fundamental en el arbitraje del medio.
Método de acceso al medio – Transmisión en tiempo real
En la transmisión en tiempo real, los mensajes que se transmite llevan distintos datos
que dependiendo del tipo que sea deben ser entregados con mayor frecuencia y/o menor
delay que otros. De alguna manera es necesario comparar los mensaje y determinar cual
es de mayor prioridad. Esto se lleva a cabo utilizando una técnica conocida como
CSMA-APM que se encarga de arbitra el medio de la siguiente manera:
Igual que en el caso de Ethernet los nodos que desean transmitir sus mensajes sensan el
medio y si no está ocupado pueden transmitir. A diferencia de Ethernet las tramas de
CAN no poseen direcciones origen y destino sino que tienen un campo de arbitraje (y
se difunden en modo broadcast a todas las otras terminales).
En el supuesto que dos o más nodos transmitan simultáneamente, se producirá una
colisión, en este caso el medio determina en base al campo de arbitraje cual de los
nodos que transmitió simultáneamente tiene derecho a ganar el medio. Esto se
determina en función de la prioridad de cada nodo, que viene determinado por el
identificador que lleva el mensaje.
El bus CAN se comporta como una compuerta AND donde cada entrada lleva
conectada un nodo, dependiendo del resultado de la operación lógica entre los campos
de arbitraje de todos los nodos que trasmiten simultáneamente es que se determina
quien gana el medio y tiene la mas alta prioridad.
La siguiente figura muestra como se arbitra el medio mediante CSMA-AMP
El que tiene el identificador menor es el que tiene la mayor prioridad y por ende gana el
medio.
La siguiente figura muestra la trama que utiliza CAN
Los campos tienen las siguientes funcionalidades:
•
•
•
•
•
•
•
Identificador: Identifica el mensaje y su prioridad. En “CAN base frame” este
campo tiene 11bits y permite un total de 2048 mensajes distintos, en “CAN
extended” tiene 29bits y permite un total de 500 millones de mensajes.
Start of Frame: indicando el comienzo de la trama.
RTR (remote erminal ct request): Identifica si es un dato enviado o un
pedido de datos (se ve que el pedido de un dato es de menor prioridad que un
dato enviado). El RTR + Identificador forman el campo de arbitraje.
IDE: Utilizado para distinguir entre CAN base o extended.
Data length code (DLC): Utilizado para saber la longitud de los datos enviados
o la cantidad de datos solicitados dependiendo del RTR.
Data: Campo conteniendo los datos enviados.
CRC: Es un control de errores de la trama.
•
ACK: Lo utilizan los nodos que reciben la información correctamente para
confirmarla. Utilizan el ACK de la misma trama que reciben y lo cambia de
estado.
•
•
EOF: Maraca el final de la trama.
IFS: Debe llevar como mínimo un número de bits definidos como el mínimo
“espacio” entre tramas.
En CAN base la longitud de las tramas debe ser:
44 bits < long. De trama < 111 bits
(Esto da un troughtput del 58% del bitrate, además cumple la condición de generar
paquetes pequeños de datos en el bus de campo)
Control de errores:
CAN implementa 3 mecanismos para detectar errores:
1. Un código de redundancia cíclico (CRC), para verificar la integridad de las
tramas.
2. Chequeo de las tramas, comprándolas con el tipo y la longitud que deben tener.
3. Control por parte del receptor del ACK.
4. Monitoreo del bus, las estaciones que transmiten saben si lo que se inserta en el
medio es el dato que se desea transmitir y en caso de no coincidir avisan del
error.
5. Utilización de bit stuffing.
En caso de encontrar uno mas de estos errores, se genera una trama de error avisando al
resto de las terminales que se difundió en el medio una trama con error, previniendo a
los otros nodos de no aceptar mensajes “fallados”. Luego de esto el nodo que emitió los
datos debe retransmitir.
En el caso de que una estación detecte localmente que está generando gran cantidad de
errores, tiene la capacidad de desconectarse del bus si que esto afecte a los otros nodos.
La detección es posible gracias a que CAN permite detectar los errores esporádicos y
también los permanentes.
Definiciones del protocolo CAN
•
Dentro del modelo OSI ocupa las capas Data Link Layer y Phisical Layer.
•
CAN utiliza codificación NRZ junto con bit stuffing.
•
CAN utiliza un sistema sincrónico bit a bit. Puesto que el único delimitador de
para sincronismo se encuentra al principio de la trama es necesario a lo largo de
esta resincronizar. Para esto se agrega dentro del tiempo de bit una buffer antes
y uno después del intervalo de muestreo además de segmento de sincronismo y
un delay, como se ve a continuación.
Se pueden distinguir entonces 2 sincronizaciones, una en el comienzo de la
trama y una resincronización a lo largo de la misma.
•
Las velocidades van desde los 20kbit/s hasta 1Mbit/s, dependiendo de la
longitud del bus.
•
Existen bridges y repetidores para aumentar la longitud de bus.
•
Se utilizan gateways para interactuar con protocolos de nivel superior.
Aplicaciones
CAN originalmente se diseño para el control dentro de automóviles, hoy además se
utiliza control de aviones y barcos, en la automatización de industrias y en
equipamiento médico entre otras.
DeviceNet
DeviceNet es un estándar estable para redes industriales que utiliza CAN para su Data
Link Layer y CIP (common industrial protocols) para sus capas de nivel superior.
Sigue igual que CAN un estándar de productor-consumidor montado sobre una red
digital que permite priorización de los mensajes. Además brinda una cualidad única
como ser incluir en el cableado de red la tensión de alimentación, pudiendo alimentarse
los distintos dispositivos de ahí mismo.
Capa Física
D.N. utiliza una topología de bus en línea de la cual se pueden derivar otras líneas con
nodos.
También define un conjunto de velocidades acorde al tipo de cable y las distancias
(junto con conectores de uso industrial), que se puede ver en la siguiente tabla.
Network Size
125 KBPS
250 KBPS
500 KBPS
er Trunk Length
Thin Trunk Length
Flat Trunk Length
Maximum Drop Length
Cumulative Drop Length
500
100
420
6m
156
250 m (820 ft)
100 m (328 ft)
200 m (656 ft)
6 m (20 ft)
78 m (256 ft)
100 m (328 ft)
100 m (328 ft)
75 m (246 ft)
6 m (20 ft)
39 m (128 ft)
m (1,640 ft)
m (328 ft)
m (1,378 ft)
(20 ft)
m (512 ft)
Table 2: The end-to-end network distance varies
with data rate and cable thickness.
Data link layer
Como ya dijimos antes, utiliza CAN en esta capa.
Capas de red y transporte
D.N. requiere que se establezca primero una conexión entre los dispositivos que van
a intercambiar información. Para eso se usan los mensajes UCMM o UP. Una vez
establecida la conexión, esta es utilizada para transferir información entre nodos. Una
vez que se ha establecido la conexión, el protocolo de D.N. se transporta dentro de los
11bit del campo identificación de CAN, esto es una ventaja porque no ocupa lugar en el
campo de datos CAN. A continuación mostramos el formato D.N. encapsulado dentro
de CAN.
El campo de identificación esta dividido en: un MAC ID que identifica la conexión y un
Message ID que identifica el mensaje (junto con su prioridad) dentro de la conexión.
Los distintos dispositivos pueden ser clientes, servidores o ambos y a su vez cualquiera
puede ser productor y/o consumidor.
Cada nodo se su vez es el responsable manejar sus identificaciones (MAC ID) y la
identificación de sus mensajes. La ventaja de esto es que no se requiere de un registro
centralizado de nodos, los cuales a su vez pueden ser agregados o descartados sin
necesidad de actualizaciones. Además existe un algoritmo encargado de controlar que
no existan MAC´s ID repetidas.
Capas superiores – CIP
CIP ocupa las capas de sesión, presentación y aplicación en DeviceNet.
Es un protocolo de mensajeria (intercambio de mensajes), orientado a conexión donde a
cada conexión se le asigna una identificación (CID), en el caso de ser unidireccional, o
dos identificaciones en el caso de ser bidireccional.
Cada nodo se modela como una colección de objetos. Cada objeto pertenece a una clase
(Ej. Drivers, Sensores de temperatura, etc) y se identifica cada uno por su instancia
dentro de la clase. Un objeto/instancia o toda una clase poseen atributos o variables que
los describen; servicios o comandos y conductas o reacciones que se especifican ante
determinados eventos.
Además de la gestión de las conexiones, CIP se encarga de intercambiar mensajes entre
los diversos objetos. Los mensajes pueden ser:
• Implícitos: entre una o más aplicaciones consumidoras y un productor
(unidireccional). Está especialmente pensado para datos de control cuyos
tiempos son críticos.
• Explícitos: provee una conexión punto a punto, bidireccional. Es más lenta que
la anterior, un extremo debe solicitarle al otro los datos que necesita.
CIP en la capa de aplicación:
Le presenta al usuario una lista de los nodos, con sus objetos y a su vez la clase, los
servicios, los atributos y las distintas reacciones de estos últimos.
CIP en la capa de presentación:
Se encarga de “traducir” los datos ingresados por el usuario en datos que pueda entender
la capa inferior.
CIP en la capa de sesión:
Lleva un control de las conexiones abiertas, además se encarga de rutear los datos. En
esta capa se colocan la MAC ID del nodo en el que se encuentra el objeto, el número de
clase e instancia y el servicio requerido, de modo que la capa inferior (capa de
transporte) pueda realizar el ruteo.
Aunque estudiamos CIP como protocolo adicional de DeviceNet, también se
implementa sobre Ethernet-TCP/IP. Desde ya que siguen siendo válidas todos los
inconvenientes que presenta esta tecnología en el control industrial. No obstante lo cual
nos muestra lo similares que resultan ser las dos redes.
Modalidad Maestro-Esclavo
Además de la modalidad peer-to-peer o modelo de cooperación ya estudiada. D.N.
permite la modalidad Maestro-Esclavo similar a la del Bus AS-I. Esto es útil cuando se
sabe de antemano la frecuencia con la que va a transmitir un dispositivo.
Esta modalidad soporta 3 tipos de operación:
1. Polled: Cada esclavo espera recibir el “output data” del maestro y devolverle los
datos (en unicast o multicast), en una secuencia de tiempo específica. Así la red
presenta un comportamiento determinístico.
2. Cíclico: Cada dispositivo produce y envía de manera periódica sus datos.
3. Change-of-State: Los dispositivo envía datos ante un cambió de estado.
Comparación DeviceNet vs. Ethernet
DeviceNet
Ethernet
Tamaño de trama pequeña acorde a los
requisitos de un bus de campo.
Implementa un sistema de priorización
rápido y sofisticado que arbitra el medio.
Tamaño de trama grande para el estándar
de buses de campo.
Implementa un sistema de priorización
que introduce mayor delay y no resuelve
quien gana el medio.
Requiere planeamiento y management de
la red para agregar o quitar dispositivos.
Simplemente configura y toma los datos
de la red.
Puede cubrir toda una industria.
No hay límites de distancia pudiendo
utilizarse diversos medios de transporte
(satélite, ATM).
Lo tráficos que no corresponden a
procesos productivos deben ser filtrados
para que no interfieran.
Costos bajos por la gran popularidad de
Ethernet.
Solo datos, pero a mayor velocidad.
Simplemente se agregan o quitan los
dispositivos de la red.
Provee diagnostico de los dispositivos.
Abarca un área “reducida” de trabajo.
La distancia queda limitada por la
velocidad y por la potencia.
No se requiere filtrar distintos tipos de
tráfico, puesto que solo acepta lo que es
DeviceNet.
Costos bajos de tecnología CAN
El cable lleva datos y alimentación.
MODBUS
En su definición inicial Modbus era una especificación de tramas, mensajes y funciones
utilizada para la comunicación con los PLCs Modicon. Modbus puede implementarse
sobre cualquier línea de comunicación serie y permite la comunicación por medio de
tramas binarias o ASCII con un proceso interrogación-respuesta simple. Debido a que
fue incluido en los PLCs de la prestigiosa firma Modicon en 1979, ha resultado un
estándar de facto para el enlace serie entre dispositivos industriales.
Modbus Plus define un completo bus de campo basado en técnica de paso de testigo. Se
utiliza como soporte físico el par-trenzado o fibra óptica.
Es un protocolo utilizado en comunicaciones vía módem-radio, para cubrir grandes
distancia a los dispositivos de medición y control, como el caso de pozos de petróleo,
gas y agua. Velocidad a 1200 baudios por radio y mayores por cable.
Estructura de la red
Medio Físico
El medio físico de conexión puede ser un bus semidúplex (half duplex) (RS-485 o fibra
óptica) o dúplex (full duplex) (RS-422, BC 0-20mA o fibra óptica). (Ver Anexo)
La comunicación es asíncrona y las velocidades de transmisión previstas van desde los
75 baudios a 19.200 baudios. La máxima distancia entre estaciones depende del nivel
físico, pudiendo alcanzar hasta 1200 m sin repetidores.
Acceso al Medio
La estructura lógica es del tipo maestro-esclavo, con acceso al medio controlado por el
maestro. El número máximo de estaciones previsto es de 63 esclavos más una estación
maestra.
Los intercambios de mensajes pueden ser de dos tipos:
• Intercambios punto a punto, que comportan siempre dos mensajes: una demanda
del maestro y una respuesta del esclavo (puede ser simplemente un reconocimiento
(«acknowledge»))
.
• Mensajes difundidos. Estos consisten en una comunicación unidireccional del
maestro a todos los esclavos. Este tipo de mensajes no tiene respuesta por parte
de los esclavos y se suelen emplear para mandar datos comunes de configuración,
reset, etc.
PROTOCOLO
La codificación de datos dentro de la trama puede hacerse en modo ASCII o puramente
binario, según el estándar RTU (Remote erminal ct Unit). En cualquiera de los dos
casos, cada mensaje obedece a una trama que contiene cuatro campos principales, según
se muestra en la figura 1. La única diferencia estriba en que la trama ASCII incluye un
carácter de encabezamiento («:»=3AH) y los caracteres CR y LF al final del mensaje.
Pueden existir también diferencias en la forma de calcular el CRC, puesto que el
formato RTU emplea una fórmula polinómica en vez de la simple suma en módulo 16.
Con independencia de estos pequeños detalles, a continuación se da una breve
descripción de cada uno de los campos del mensaje:
Número de esclavo (1 byte):
Permite erminal ct un máximo de 63 esclavos con direcciones que van del 01H hasta
3FH. El número 00H se reserva para los mensajes difundidos.
Código de operación o función (1 byte):
Cada función permite transmitir datos u órdenes al esclavo. Existen dos tipos básicos de
órdenes:
• Ordenes de lectura/escritura de datos en los registros o en la memoria del esclavo.
• Ordenes de control del esclavo y el propio sistema de comunicaciones (RUN/STOP,
carga y descarga de programas, verificación de contadores de intercambio, etc.)
Campo de subfunciones/datos (n bytes):
Este campo suele contener, en primer lugar, los parámetros necesarios para ejecutar la
función indicada por el byte anterior. Estos parámetros podrán ser códigos de
subfunciones en el caso de órdenes de control (función 00H) o direcciones del primer
bit o byte, número de bits o palabras a leer o escribir, valor del bit o palabra en caso de
escritura, etc.
Palabra de control de errores (2 bytes):
En código ASCII, esta palabra es simplemente la suma de comprobación (‘checksum’)
del mensaje en módulo 16 expresado en ASCII. En el caso de codificación RTU el CRC
se calcula con una fórmula polinómica según el algoritmo mostrado en la figura 2.
En la capa 7 del modelo OSI que provee comunicación cliente servidor entre
dispositivos conectados en distintos tipos de buses o redes.
La comunidad e Internet puede acceder a Modbus mediante el puerto reservado TCP/IP
502.
Es actualmente utilizado usando:
•
•
•
TCP/IP over Ethernet
Transmisión serial asincrónica sobre distintos tipos de medios (cable
, fibra, radio)
MODBUS PLUS, una red de alta velocidad con token.
Referencias: RFC 791, Internet Protocol, Sep81 DARPA
Abreviaturas
ADU
BSD
HDLC
HMI
IETF
I/O
IP
MAC
MB
MBAP
MSL
PDU
PLC
TCP
Application Data Unit
Berkeley Software Distribution
High level Data Link Control
Human Machine Interface
Internet Engineering Task Force
Input/Output
Internet Protocol
Medium Access Control
MODBUS Protocol
MODBUS Application Protocol
Maximum Segment Lifetime
Protocol Data Unit
Programmable Logic Controller
Transport Control Protocol
Contexto
El Protocolo Modbus permite la fácil comunicación entre todo tipo de arquitecturas de
red.
Todo tipo de dispositivos (PLC, HMI, Panel de Control, Controlador, control de
Movimiento, I/O Device…) pueden usar Modbus para iniciar una operación remota.
La misma comunicación puede ser tanto en línea serial como en redes Ethernet TCP/IP.
Los gateways permiten la comunicación entre varios tipos de buses o redes usando el
protocolo Modbus.
Descripción General
Se define una unidad de datos de protocolo (PDU) independiente de las capas de
comunicación inferiores. Se pueden incluir en distintos buses algunos campos
adicionales en la unidad de datos de aplicación (ADU)
La ADU es creada por el cliente que inicia la transacción Modbus. La función indica al
servidor que tipo de acción tomar. El Modbus aplication protocol establece el formato
de un request iniciado por un cliente.
El campo de función de una unidad de datos Modbus esta codificado en 1 byte. Los
códigos validos van del 1 al 255 decimal (128-255 reservados para excepciones).
Cuando un mensaje es enviado desde un Servidor a un Cliente la el campo de función
de código le indica que acción debe tomar. (0 no es valido).
También se pueden agregar subfunciones para definir múltiples acciones.
El campo de datos de los mensajes enviados de cliente a servidor contiene información
adicional que el servidor usa para tomar la acción definida en el código de función.
El campo de datos puede ser 0 de largo en algunos tipos de respuestas.
El tamaño del PDU esta limitado por el tamaño limite proveniente de la primera
implementación en Serial Line network (máx. RS485 ADU =256 bytes)
PDU serial line communication = 256 – Server address (1 byte) – CRC (2 bytes) =
253 bytes.
Entonces:
RS232 / RS485 ADU = 253 bytes + Server address (1 byte) + CRC (2 bytes) = 256
bytes.
TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.
Se definen 3 paquetes:
•
•
•
MODBUS Request PDU
MODBUS Response PDU
MODBUS Exception Response PDU
Codificación de datos
Se usa una “big-Endian” representación para direcciones y datos. Esto quiere decir que
cuando una cantidad numérica más larga que un simple byte es transmitida, el byte más
significativo se manda primero.
Modelo de Direcciones
En un PDU cada dato es
erminal cta de 0 a 65535
Transacción
Una vez que el request fue procesado por el servidor, una respuesta es construida
Según el resultado del proceso se construyen dos tipos de respuestas:
• Una respuesta positiva:
ƒ El código de función de respuesta = código de función de request
• Una respuesta negativa
ƒ El objetivo es proveer al cliente información relevante
concerniente al error detectado durante el proceso
ƒ El código de función de respuesta = código de función de request
+ 0x80
ƒ El código de excepción es provisto para indicar el motivo del
error
Respuestas de Excepciones
Si un cliente envía un request a un Server espera una respuesta normal. Una de los
cuatro posibles eventos puede ocurrir:
•
•
•
•
Si el servidor recibe un request sin error de comunicación y puede
manejar la consulta normalmente devuelve una respuesta normal.
Si el servidor no recibe un request debido a un error de comunicación
no devuelve ninguna respuesta. El cliente procesara el timeout del
request
Si el servidor recibe un request, pero detecta un error de
comunicación (parity, LRC, CRC,…), no devuelve respuesta. El
cliente procesara el timeout del request
Si el servidor recibe un request sin error de comunicación, pero no
puede manejarlo (ej. Si el request es leer una salida existente o
registro), el servidor va a devolver una respuesta de excepción para
informar al cliente de la naturaleza del error.
El mensaje de respuesta de excepción tiene dos campos que lo diferencian de la
respuesta normal:
Campo de código de función: En una respuesta normal, el servidor responde el código
de función del request original. Todos los códigos de función tienen un bit mas
significativo en 0 (los valores están todos debajo del 80 hexadecimal). En una respuesta
de excepción, el servidor setea este bit en 1. Por lo que la respuesta será el número de
función más 80.
Con el MSB seteado, el programa de aplicación del cliente puede reconocer la respuesta
de excepción y examinar el campo de datos del código de excepción.
Campo de Datos: En una respuesta normal, el servidor debe retornar datos o estadísticas
en el campo (cualquier información que haya sido pedida). En una excepción, el
servidor devuelve un código de excepción en el campo de datos.
MODBUS Mensajes de Excepción
Code Name
Meaning
01
ILLEGAL FUNCTION
El código de función recibido en la consulta
no es una acción posible para el servidor. O
porque el código de función es solo aplicable
en los dispositivos mas nuevos y no esta
implementado en el dispositivo elegido, o
bien puede indicar que el servidor esta en el
estado incorrecto como para procesar un
request de este tipo.
02
ILLEGAL DATA ADDRESS
La dirección de datos recibida en la consulta
no es permitida para el servidor.
03
ILLEGAL DATA VALUE
Un valor contenido en la consulta del campo
de datos no contiene un valor possible para el
servidor. Ej, el largo
04
SLAVE DEVICE FAILURE
Se produjo un error irreparable cuando el
servidor trataba de realizar el request.
05
ACKNOWLEDGE
Completa el mensaje para saber si el proceso
fue finalizado.
O para saber si se recibió un request.
06
SLAVE DEVICE BUSY
El dispositivo esta
retransmitir mas tarde
08
MEMORY PARITY ERROR
Al tratar de leer o escribir en memoria se
detecta un error de paridad.
0A
GATEWAY
UNAVAILABLE
0B
GATEWAY
TARGET Indica que no se obtuvo respuesta del
DEVICE
dispositivo que se quiere alcanzar.
FAILED TO RESPOND
Generalmente quiere decir que el dispositivo
no esta presente en la red.
ocupado
se
debe
PATH Indica que el gateway no fue capaz de
encontrar un camino para el ermin de
entrada al ermin de salida requerido.
Esto quiere decir generalmente que esta
desconfigurado o sobrecargado.
MODBUS EN TCP/IP
Es una variante o extensión del protocolo Modbus que permite utilizarlo sobre la capa
de transporte TCP/IP. De este modo, Modbus-TCP se puede utilizar en Internet, de
hecho, este fue uno de los objetivos que motivó su desarrollo (la especificación del
protocolo se ha remitido a la IETF=Internet Engineering Task Force).
En la práctica, un dispositivo instalado en Europa podría ser
EEUU
o cualquier otra parte del mundo.
erminal cta desde
Las ventajas para los instaladores o empresas de automatización son innumerables:
• Realizar reparaciones o mantenimiento remoto desde la oficina utilizando un PC,
reduciendo así los costes y mejorando el servicio al cliente.
• El ingeniero de mantenimiento puede entrar al sistema de control de la planta desde
su casa, evitando desplazamientos.
• Permite realizar la gestión de sistemas distribuidos geográficamente mediante el
empleo de las tecnologías de Internet/Intranet actualmente disponibles.
Modbus/TCP simplemente encapsula una trama Modbus en un segmento TCP.
TCP proporciona un servicio orientado a conexión fiable, lo que significa que toda
consulta espera una respuesta.
El servicio de mensajes Modbus provee
dispositivos en una red Ethernet TCP/IP
una comunicación Cliente/Servidor entre
Este modelo cliente/servidor esta basado en cuatro tipo de mensajes:
• MODBUS Request,
• MODBUS Confirmation,
• MODBUS Indication,
• MODBUS Response
MODBUS Request es el mensaje enviado en la red por el cliente para iniciar una
transacción.
MODBUS Indication es el mensaje request recibido en el lado del Servidor.
MODBUS Response es el mensaje request enviado por el Servidor.
MODBUS Confirmation es el mensaje request recibido en el lado del Cliente.
Este servicio es usado para el intercambio en tiempo real:
• Entre dos aplicaciones de dispositivos.
• Entre una aplicación de un dispositivo y otro dispositivo.
• Entre aplicaciones HMI/SCADA y otros dispositivos.
• Entre una PC y un programa de un dispositivo que da servicios online.
Documentos de referencia
RFC 1122 Requirements for Internet Hosts – Communication Layers
Descripción del Protocolo
Un sistema de comunicación Modbus TCP/IP debe incluir diferentes tipos de
dispositivos:
•
•
Un Cliente y un Servidor Modbus TCP/IP conectados a una red TCP/IP
La interconexión entre dispositivos como bridge, router o gateway para
interconexión entre la red TCP/IP y una sub red de línea serial que permita
conexiones del Cliente y Servidor Modbus Serial Line.
Recordando el PDU de Modbus
Unidad de datos de aplicación Modbus en TCP/IP
Ahora veremos el encapsulado de una respuesta o request Modbus cuando es
transportado en una red Modbus TCP/IP.
Un header dedicado es usado en TCP/IP para identificar el Unidad de datos de
aplicación Modbus. Es llamado header MBAP (MODBUS Application Protocol
header).
El header posee algunas diferencias comparado con la unidad de datos de aplicación
RTU Modbus usado en línea serial:
•
•
•
El campo “slave address” usualmente usado en línea serial es reemplazado por
un byte “Unit identifier” dentro del MBAP header. Este campo es usado para
comunicar vía dispositivos como bridges, routers y gateways que usan una
dirección IP para soportar múltiples unidades Modbus independientes
Todos los request y respuestas están diseñadas de manera tal que el receptor
pueda verificar que el mensaje termino. Para códigos de función donde Modbus
PDU tiene un largo fijo, el código de función solo es suficiente. Para códigos de
función que lleven una cantidad de datos variables en el request o en la
respuesta, el campo de datos incluye un byte de conteo.
Cuando es transportado en TCP, se lleva información adicional del largo en el
header MBAP para permitir al receptor reconocer los límites del mensaje aunque
este haya sido dividido en múltiples paquetes para la transmisión. La existencia
de reglas de largo implícitas y explicitas y el uso del código de chequeo de error
CRC-32 (en Ethernet) resultan en una chance infinitesimal de detectar mensajes
con error.
Descripción del Header
Campos
Identificador
de transacción
Largo
2 bytes
Identificador
de Protocolo
2 Bytes
Largo
2 Bytes
Identificador
de Unidad
1 Byte
Descripción
Identifica
la
transacción de
respuesta
o
request
0= Protocolo
Modbus
Cliente
Servidor
Inicializado por Recopiado por
el cliente
el servidor del
request
recibido
Inicializado por Recopiado por
el cliente
el servidor del
request
recibido
Numero de los Inicializado por Inicializado por
siguientes
el
el
servidor
Bytes
cliente(request) (response)
Identificación
Inicializado por Recopiado por
de un esclavo
el cliente
el servidor del
remoto
request
conectado en
recibido
una línea serial
o en otros
buses
Modelo de la arquitectura
•
•
Communication Application LayerTCP Management Layer- Administra el establecimiento y el fin de la conexión
y administra el flujo de la información en conexiones TCP establecidas
o Connection Management – se encarga de administrar globalmente los
mensajes de las conexiones TCP.
La aplicación de usuario administra las conexiones TCP por si mismo o
la administración de la conexión es totalmente realizada por este modulo
y entonces es transparente a nivel de aplicación de usuario.
o Access Control Module- En algunos contextos, la accesibilidad a datos
internos de los dispositivos debe ser prohibida para algunos hosts. Es por
eso que se necesita un modo de seguridad.
• TCP/IP Stack Layer – Puede ser parametrizado para adaptar el control de flujo
de datos, la administración de direcciones y la administración de conexiones de
a distintos limites específicos para un producto o un sistema. Generalmente se
usa el socket BSD para administrar las conexiones TCP.
• Resource management and Data Flor Control- Para equilibrar el flujo de
mensajes de datos de entradas con las salidas entre el cliente y el servidor, el
mecanismo de data erm control es implementado en todas las capas.
Esta basado básicamente en el control de flujo de TCP con el agregado de un
control de flujo de datos en la capa de link y también en la capa de aplicación de
usuario.
TCP CONECTION MANAGEMENT
La comunicación Modbus requiere el establecimiento de una conexión TCP entre
Cliente y Servidor.
Esta puede ser activada explícitamente por el modulo de aplicación de usuario o
automáticamente por el modulo de administración de conexión TCP.
En el primer caso una interfaz de programa de aplicación debe ser provisto en el
modulo de aplicación de usuario para manejar completamente la conexión. Esto le
da flexibilidad pero requiere un buen manejo de TCP/IP.
En el segundo caso es completamente invisible para la aplicación de usuario. El
modulo de administración de conexión de TCP es el que se encarga de establecer
una nueva conexión TCP cuando esta es requerida.
Si el numero de conexiones llega al máximo para abrir una conexión nueva se cierra
las mas antigua.
Para terminar una conexión el cliente debe iniciar el procedimiento de cerrado de
conexión.
PROFIBUS
En el año 1987, las firmas alemanas Bosch, Klöckner Möeller y Siemens iniciaron un
proyecto de desarrollo de una arquitectura de comunicaciones industriales que
permitiera la interconexión de equipos de distintos fabricantes. Esta fue la base de un
grupo de trabajo al que se integraron otras grandes empresas tales como ABB, AEG,
Landis&Gir, etc., algunas universidades y organizaciones técnicas estatales, entre ellas
la propia VDE y el Ministerio Federal de Investigación Alemán. Se formaron varios
grupos de trabajo en distintas áreas, cuya tarea esencial fue la de desarrollar un sistema
abierto de comunicaciones apto para integrar desde los sencillos transductores y
elementos de campo, pasando por los autómatas y controles numéricos hasta llegar al
nivel de los mini ordenadores para diseño y gestión de la producción. El primer objetivo
fue sólo el diseño de un bus de campo con una estructura abierta y un protocolo
compatible que permitiera enlazar con una red adoptada como base en los niveles
superiores (MAP), con lo que resultó el proyecto de normas y protocolos que se
estudiarán con más profundidad en apartados posteriores. A partir del año 1990 se abrió
la posibilidad para cualquier usuario o empresa de integrarse en un consorcio
denominado PROFIBUS Nutzerorganisation, que a través de diversos comités sigue
desarrollando y dando soporte al nivel de aplicación y certificación de productos.
PROFIBUS es actualmente el líder de los sistemas basados en buses de campo en
Europa y goza de una aceptación mundial. Sus áreas de aplicación incluyen
manufacturación, automatización y generación de procesos. PROFIBUS es un bus de
campo normalizado internacional que fue estandarizado bajo la norma EN 50 170. Esto
asegura una protección óptima tanto a los clientes como a los vendedores y asegura la
independencia de estos últimos. Hoy en día, todos los fabricantes líderes de tecnología
de automatización ofrecen interfaces PROFIBUS para sus dispositivos. La variedad de
productos existentes incluye más de 1500 elementos y servicios, de los cuales 400 están
certificados, asegurando un funcionamiento sencillo y correcto incluso en redes de
diferentes fabricantes. PROFIBUS ha sido usado satisfactoriamente en alrededor de
200.000 aplicaciones en todo el mundo y se han instalado más de 2.000.000
dispositivos.
Contexto
PROFIBUS es un bus de campo erminal que acoge un amplio rango de aplicaciones
en fabricación, procesado y automatización. La independencia y franqueza de los
vendedores está garantizada por la norma EN 50 170. Con PROFIBUS los componentes
de distintos fabricantes pueden comunicarse sin necesidad de ajustes especiales de
interfaces. PROFIBUS puede ser usado para transmisión crítica en el tiempo de datos a
alta velocidad y para tareas de comunicación extensas y complejas. Esta versatilidad
viene dada por las tres versiones compatibles que componen la familia PROFIBUS:
PROFIBUS define toda una red de Comunicación industrial, desde el nivel físico hasta
el de aplicación, integrando al máximo las técnicas de comunicación previamente
definidas y consolidadas.
Todos los grupos de usuarios se unen bajo la Organización PROFIBUS erminal ctar
(PI), que con más de 750 miembros es la organización de buses de campo más grande
del mundo.
PROFIBUS emplea un protocolo implementado en la capa 2 del modelo OSI. El
control de acceso al medio o MAC se basa en el principio de comunicación Maestro –
Esclavo (estación activa – estación pasiva), y entre Maestros mediante Token passing,
siendo el Maestro clase l un controlador (típicamente, un PLC), el clase 2 un sistema de
monitoreo o configuración (PC o panel HMI). Un esclavo DP es un dispositivo
periférico que se encarga de reunir la información de entrada y enviar dicha información
como salida al controlador (maestro clase 1) ante su pedido; pueden ser tanto señales
simples como dispositivos inteligentes.
De este modo, podríamos pensar en una red PROFIBUS DP en la cual un PLC es uno
de los maestros, mientras que otro puede ser una PC en la cual corre una aplicación
SCADA. Los esclavos pueden ser instrumentos de campo, estaciones remotas, islas de
válvulas, posicionadores, PLCs, switchgears, drives, transmisores HART, etc. El
controlador central (maestro) puede leer cíclicamente la información de entrada de sus
esclavos, y escribir también en forma cíclica la información de los campos de salida de
los mismos. El tiempo de ciclo de bus en una configuración extensa de 512 bits de
señales de input/output promedia 1ms en 12Mbit/seg de velocidad de transferencia. Las
funciones de diagnóstico garantizan que aun a 12Mbits/segundo haya un constante
monitoreo y seguridad de la información transmitida.
• PROFIBUS PA (Process Automation).
Para control de proceso y cumpliendo normas especiales de seguridad para la
industria química (IEC 1 1 15 8-2, seguridad intrínseca). Apta para la conexión de
instrumentación de campo y actuadores en entornos normales y EX.
• Diseñado para automatización de procesos.
• Permite la conexión de sensores y actuadores a una línea de bus común
incluso en áreas especialmente protegidas.
• Permite la comunicación de datos y energía en el bus mediante el uso
de 2 tecnologías (norma IEC1158-2).
• PROFIBUS DP (Decentralized Periphery/Periferia Distribuida)
Para la descentralización de señales y controladores. Orientado a
sensores/actuadores enlazados a procesadores (PLCS) o terminales.
• Optimizado para alta velocidad.
• Conexiones sencillas y baratas.
• Diseñada especialmente para la comunicación entre los sistemas de
control de automatismos y las entradas/salidas distribuidas.
• PROFIBUS FMS (Fieldbus Message Specification).
Para comunicación entre células de proceso o equipos de automatización. La
evolución de Profibus hacia la utilización de protocolos TCP/IP para enlace al nivel
de proceso hace que este perfil esté perdiendo importancia.
• Solución general para tareas de comunicación a nivel de célula.
• Gran rango de aplicaciones y flexibilidad.
• Posibilidad de uso en tareas de comunicación complejas y extensas.
Medio Físico
La tecnología de transmisión más usada es la RS 485, conocida habitualmente como
H2. Su área de aplicación comprende aquellas aplicaciones donde prima su simplicidad,
la velocidad de transmisión y lo barato de la instalación. Se usa un par diferencial con
cable trenzado, previsto para comunicación semi-duplex, aunque también puede
implementarse con fibra óptica y enlaces con estaciones remotas vía módem o vía radio.
La velocidad de transmisión varía entre 9.6Kbits/s y 12Mbits/s.
Al conectar varias estaciones, hay que comprobar que el cable de las líneas de datos no
sea trenzado. El uso de líneas apantalladas es absolutamente esencial para el logro de
una alta inmunidad del sistema en ambientes con emisiones altas de electromagnetismo
(como en la fabricación de automóviles). El apantallamiento se usa para mejorar la
compatibilidad electromagnética (CEM).
Bus
El elemento esencial del bus es el nodo. PROFIBUS prevé la existencia de dos tipos de
nodos:
• Activos: son nodos que pueden actuar como maestro del bus, tomando enteramente el
control del bus.
• Pasivos: son nodos que únicamente pueden actuar como esclavos y, por tanto, no
tienen capacidad para controlar el bus. Estos nodos pueden dialogar con los nodos
activos mediante un simple mecanismo de pregunta-respuesta, pero no pueden dialogar
directamente entre sí.
Aparte de estos dos tipos de nodos, existen otros dos bloques esenciales en la
arquitectura del bus:
• Expansiones E/S: este tipo de bloques constituyen la interfaz con las señales
de proceso y pueden estar integrados tanto en un nodo activo como en un nodo
pasivo.
• Repetidores: los repetidores ejecutan el papel de simples transceptores
bidireccionables para regenerar la señal. Su diferencia esencial con los
estudiados en el caso del BITBUS es que no se requieren señales de control
(RTS+, RTS-) para conmutar el sentido de la línea de datos, ya que el sistema de
codificación en PROFIBUS es del tipo NRZ (por niveles) y las velocidades son
más bajas.
Características de las redes PROFIBUS
• La misma topología, protocolo y estructura de red.
• Adaptación a diferentes baudrates, desde 9,6Kbits/seg hasta 12Mbits/seg, permiten
adaptar la comunicación a cada requisito tecnológico.
• Enorme capacidad de procesamiento de diagnóstico.
• Adaptación a diferentes medios como fibra óptica (para largas distancias o ambientes
con perturbaciones), cable de cobre en RS485 o para entornos Ex (con riesgos de
explosión) donde se requiere enviar la energía por el mismo cable de señal.
• Reconfiguración online sin caída del maestro y reemplazo con energía.
• Independiente de marca: cualquier componente de cualquier marca puede hablar con
otro que adhiera al estándar PROFIBUS.
Conclusiones:
Aunque a lo largo del trabajo se dio la impresión de que los estándares industriales
compiten comercialmente con los estándares de datos, esto no es del todo cierto. Si bien
es cierto que por simplicidad y difusión tecnológica se está tratando de aplicar
estándares de datos en el control industrial, lo cierto es que tanto los actuales estándares
industriales como los de datos encuentran su lugar en las redes industriales. No toda la
información es utilizada siempre para el control de la planta sino que muchas veces se
utiliza a título informativo, es en esos caso cuando se puede aplicar perfectamente los
estándares de datos y es por eso que existen muchas soluciones tecnológicas para lograr
la interacción de las redes industriales con las redes de datos.
Cuando uno piensa en redes de datos suele pensar en 2 o tres estándares muy difundidos
y en pos de eso suele quitarle importancia a otras tecnologías ya en desuso (Token Ring,
TDMA). El error radica en pensar exclusivamente las redes en función del transporte
de datos digamos triviales en comparación con lo visto en este trabajo.
En cuanto a la gran diversidad de protocolos y estándares industriales, se puede decir
que buscan alcanzar una meta inalcanzable. Como en todas las soluciones de ingeniería
siempre está el compromiso de fondo es necesario buscarlo, teniendo en cuanta que en
este ambiente las fallas pueden tener repercusiones muy severas.
Anexo
RS-422
El RS-422 conocido originalmente como EIA-422 es un interfaz o sistema de
comunicación serie que consiste en 4 hilos con transmisión full-duplex y línea
diferencial. Permite conectar más de un dispositivo a la línea de transmisión. La
comunicación diferencial permite una mayor velocidad que el RS-232 permitiendo hasta
10Mbits/seg.
Cuando solo se usan 2 hilos en half-duplex line se denomina EIA-485 o RS-485.
La longitud máxima del cable son 1200 metros. No puede implementar una autentica
red multipunto, como si hace el RS-485 pero sí permite que un ordenador controle por
el mismo bus hasta 10 dispositivos.
RS-485
El Estándar RS-485
La norma RS-485 está siendo la aplicación fundamental para conexiones multipunto en
la industria.
La RS-485 es la única que permite una red de nodos múltiples con comunicación
bidireccional con un solo par de cables trenzados, no todos los estándares combinan esta
capacidad con el buen rechazo al ruido, con excelente velocidad de transmisión de
datos, con gran longitud del cable de interconexión, y la robustez general del estándar.
Por estas razones, existe una gran variedad de uso de las aplicaciones con RS-485 para
la transmisión de datos entre aparatos en sectores como:
•
•
•
•
•
•
•
Automoción
Informática
Robótica
Repetidores celulares
Fabricantes de PLCs
Fabricantes de Sinópticos
Etc.
Aunque la RS-485 es sumamente popular, los fabricantes de productos que quieren
incorporar esta norma, deben aprender y comprender los problemas de la interconexión
con la RS-485.
La RS-485 es de bajo coste, bidireccional, multi-punto, interconexión con fuerte
rechazo del ruido, buena tasa y rapidez de transmisión de datos, alta velocidad en la
transmisión de datos y un rango del modo común ancho.
La norma especifica las características eléctricas de transmisores y receptores para la
transmisión diferencial multi-punto de datos, no hace referencia ni especifica el
protocolo, si el código, las características mecánicas del conector y las conexiones de
los pines (pinout).
La EIA (Electronic Industries Association) Technical Recommendation ermin TR30,
especificó la norma RS-485 en el año 1983. La Telecommunitcations Industry
Association (TIA) es ahora la responsable para las revisiones futuras. La RS-485 se está
revisando actualmente, en su revisión y después de una votación la norma revisada
pasará ha llamarse “ANSI TIA/EIA-485-A”.
Conceptos técnicos
Existen, por lo menos, 10 conceptos técnicos que se deben repasar antes de aplicar la
norma, que son:
•
•
•
•
•
•
•
•
•
•
La forma de los nodos
Las configuraciones
La media de erminal ctares
Velocidad de los datos y la longitud del cable
Terminales y adaptadores
Diferencial único y parámetros de RS-485
Blindajes y tierras
Modo de protección
Especial-función transmisor-receptor
Relación fallo-seguridad
La forma de los Nodos
El estándar RS-485 permite su uso en redes múltiples de gran velocidad si tenemos en
cuenta las siguientes recomendaciones:
1. Cada bus o red no debe tener más de 32 cargas.
2. El control direccional de los repetidores es complejo, pero se puede solucionar
por hardware, por consiguiente, una estimación algo conservadora es que, sin
usar los transceptores especiales, una red puede incluir 32 transceptores.
Datos Técnicos
ESPECIFICACIONES
Modo de trabajo
Número Total de Emisores y Receptores en Una Línea
Máxima Longitud del Cable
Velocidad Máxima de transmisión de Datos
Tensiones Máximas de Salida
Nivel de la Señal de Salida (Carga Min.) Con Carga
Nivel de la Señal de Salida (Carga Max.) Con Carga
Resistencia de Carga (Ohms)
Max. Corriente en Estado Z Alto Alimentación conectada
Max. Corriente en Estado Z Alto Alimentación
desconectada
RS-485
Diferencial
1 EMISOR 32 RECEPTORES
4000 FT. (1.200 m.)
10 Mb/s
-7V a +12V
+/-1.5V
+/-6V
54
+/-100µA
+/-100µA
Velocidad de Cambio (Max.)
Tensiones de entrada del Receptor
Sensibilidad de entrada del Receptor
Resistencia de entrada del Receptor (Ohms)
N/A
-7V a +12V
+/-200mV
>=12k min.
Instalación y Conexionado
Para la instalación del bus RS-485 debemos tener en cuenta las siguientes consideraciones:
•
Longitud máxima del bus RS485: 1200 m aprox. (sin amplificadores).
Para mas distancias, es posible utilizar amplificador, que regenera y amplifica la señal.
•
Cable a utilizar: Se pueden instalar buses RS-485 usando cable de pares trenzados.
La impedancia característica del cable puede variar entre 100 o 120ohm.
Es recomendable la utilización de cable UTP cat.5 o superior.
•
Evitar el paso del bus cerca de cables y equipos de potencia, ya que estos producen
inducciones electromagnéticas que pueden provocar mal funcionamiento en el sistema
y en algunos casos incluso la avería de los equipos.
•
El bus RS-485 es un bus serie, nunca instale los equipos en estrella o anillo.
El estándar RS-485 es el único que permite que múltiples nodos se comuniquen
bidireccionalmente sobre un único par de cables. Ningún otro estándar combina esta capacidad
con un equivalente rechazo de ruido, longitud de cable y, en general, robustez.
Es necesaria una buena interconexión de los equipos como indica el siguiente esquema:
Norma de comunicación TIA/EIA-232-E
Norma RS-232
El estándar RS-232 es una de las normas de comunicación serie asíncrona más popular
y es ampliamente aceptada en la industria. Esta norma es utilizada para la comunicación
entre modems, impresoras, ordenadores, etc. Fue definida como estándar por la
Asociación de Industrias Electrónicas (EIA) y la letra final de su denominación indica la
versión.
La RS-232 toma en cuenta las características mecánicas, eléctricas, funcionales y de
procedimientos típicos de un protocolo orientado al enlace físico punto a punto. Este
estándar se basa en comunicación asíncrona, es decir, los datos pueden ser transmitidos en cualquier momento, por lo que deben tomarse precauciones para sincronizar
la transmisión con la recepción.
La Transmisión
En la transmisión bit a bit la línea se mantiene en estado latente (no transmisión) y el
envío de la información se realiza enviando un bit de inicio (siempre en nivel bajo),
seguido de 5,6,7,u 8 bits de datos, un bit adicional de paridad y 1, 1.5 o 2 bits de parada.
Esta secuencia permite reconocer el inicio de la transmisión, los datos, así como la
integridad de la misma y la finalización del envío.
Para que dos dispositivos puedan hacer efectivo el intercambio de información se
requiere, además, que cada una de ellos utilice las mismas características de
transmisión, entre estas características están la velocidad que pueden ser de:
110 bps, 300 bps, 600 bps, 900 bps, 1200 bps, 2400 bps, 4800 bps, 9600 bps, 19200
bps. Estas velocidades han sido ampliadas en la versión RS-232-E.
El Puerto RS-232
El estándar establece además las características físicas y mecánicas del conector, el tipo
de dispositivo (emisor o receptor), las características eléctricas de la conexión y los
mecanismos de sincronización de la comunicación. El conector es un DB25 (conector
de 25 contactos), aunque en la práctica se suele utilizar un DB9, en los que están
definidos cada uno de los contactos dependiendo del tipo de dispositivo. El DTE
(Equipo erminal de Datos) lleva instalado el conector macho y el DCE (Equipo de
Comunicación de Datos) dispone del conector hembra.
Subir
Referencias:
•
•
•
•
•
www.CAN-CIA.org
www.profibus.org
www.automatas.org
Modbus Application Protocol - www.modbus-IDA.org
Modbus Messaging Implementation Guide V1.0a -www.modbusIDA.org
• Comunicaciones Industriales, Profesor Manuel Jiménez
Buendía, Universidad Politécnica de Cartagena, Dpto. de
Tecnología Electrónica
• Tema 9: REDES LOCALES EN ENTORNOS INDUSTRIALES.
BUSES DE CAMPO- Ingeniería de Sistemas y Automática,
Universidad de Oviedo
• ANALISIS DEL ESTADO DEL ARTE DE LOS BUSES DE
CAMPO APLICADOS AL CONTROL DE PROCESOS
INDUSTRIALES,Dr. Ing. Héctor Kaschel C. e Ing. Ernesto
Pinto L., Fac. de Ingeniería, Depto. de Ingeniería Eléctrica
,Universidad de Santiago de Chile
E-mail: hkaschel@lauca.usach.cl e.pinto@ieee.org