Informe Redes Industriales LC1 - Laboratorio calificado 01 PDF

Preview

Summary

REDES INDUSTRIALESLABORATORIO CALIFICADO N° 1PROFESOR: Osniel Pozo MederosALUMNOS:TEMA: Informe herramientas ModbusLima, Peru 2020ÍndiceIntroducción.............................................................................................................................Protocolo de comunicación.....

Description

REDES INDUSTRIALES LABORATORIO CALIFICADO N° 1

PROFESOR:

Osniel Pozo Mederos

ALUMNOS:

TEMA:

Informe herramientas Modbus

Lima, Peru 2020

Índice Introducción.............................................................................................................................3 Protocolo de comunicación......................................................................................................3 Protocolo Modbus....................................................................................................................3 El Ciclo de Solicitud-Respuesta.................................................................................................3 Los beneficios del protocolo Modbus.......................................................................................4 Limitaciones del protocolo Modbus.........................................................................................5 Laboratorio...............................................................................................................................6 Reconocimiento de Tramas..................................................................................................6 Experimentación..................................................................................................................7 Observaciones........................................................................................................................10 Conclusiones..........................................................................................................................11 Bibliografía.............................................................................................................................12

Introducción En el presente informe se explicará que es un protocolo Modbus, cuando y quienes desarrollaron este protocolo. Además de resaltar la diferencias entre utilizar este protocolo con respecto a otros.

Protocolo de comunicación Cuando los humanos empezaron a utilizar el lenguaje como medio de comunicación entre personas. Era indispensable el establecimiento de reglas de comunicacón, de como estruturar las oraciones, para que al expresarselo a otro individuo, este sepa identificar la información. El mismo caso ocurrio cuando se intento comunicar entre las computadoras, microcontroladores, sensores, etc. Para que cuando una computadora reciba señales de un sensor sepa difereniar entre información y ruido, siempre y cuando el sensor siga las reglas de comunicación establecidadas entre la PC y el sensor, a esto se le denomida protocolo de comunicación

Protocolo Modbus El protocolo industrial Modbus fue desarrollado en 1979 para permitir la comunicación entre dispositivos de automatización. Originalmente implementado como un protocolo a nivel de la aplicación para transferir datos en una capa serial, el protocolo se ha expandido para incluir implementaciones a través de protocolo serial, TCP/IP y UDP (User Datagram Protocol). Hoy en día, es un protocolo común usado por innumerables dispositivos para comunicación simple, confiable y eficiente en una variedad de redes modernas. Modbus es usado generalmente para comunicación en red tipo SCADA entre dispositivos. Por ejemplo, un servidor grande puede ser usado para manejar un controlador lógico programable (PLC) o un controlador de automatización programable (PAC), y el PLC o PAC puede a su vez manejar un sensor, válvula, motor o cualquier otro dispositivo embebido. Para cumplir estas necesidades, Modbus fue diseñado como un protocolo de solicitud y respuesta con un modelo flexible de datos y funciones; características que son parte de la razón por la que hoy en día aún sigue en uso.

El Ciclo de Solicitud-Respuesta El protocolo Modbus sigue una arquitectura de maestro y esclavo, en la que un maestro transmite una solicitud a un esclavo y espera la respuesta. Esta arquitectura brinda al maestro control completo sobre el flujo de información, lo cual tiene

beneficios en redes seriales multipunto más viejas. Aún en redes TCP/IP modernas, le da al maestro un alto grado de control en el comportamiento del esclavo, lo cual es útil en algunos diseños.

Figura 1. La Relación de Solicitud-Respuesta y Maestro-Esclavo de los Dispositivos Modbus

En Modbus, esta solicitud es un conjunto de datos en capas. La primera capa es la unidad de datos de la aplicación (ADU), la cual es lo que la mayoría de las personas consideran que es el "tipo" de Modbus usado. Existen tres ADUs: ASCII, unidad de terminal remota (RTU) y TCP/IP. TCP es un formato moderno que permite un manejo eficiente de las solicitudes y respuestas Modbus en software, así como un sistema de red más eficiente a través del uso de conexiones e identificadores dedicados para cada solicitud. RTU y ASCII son formatos de ADU seriales antiguos y la principal diferencia entre los dos es que RTU utiliza una representación binaria compacta, mientras que ASCII envía todas las solicitudes como cadenas de caracteres ASCII. Para la mayoría de las aplicaciones, el ADU preferido depende de la red física deseada (Ethernet, serial o alguna otra), el número de dispositivos en la red y los ADUs soportados por los dispositivos maestros y esclavos en la red. Desde el punto de vista de la aplicación usando Modbus, los datos deben ser expuestos simplemente como si el ADU no existiera. En cada ADU, existe una unidad de datos de protocolo (PDU) que es el núcleo del protocolo Modbus. Cada PDU contiene un código de función y datos asociados. Cada código de función tiene una respuesta bien definida y usted puede pensar en este código de función como el comando que ha sido enviado al esclavo. En algunos casos, pueden ocurrir errores. Modbus define un PDU específico para excepciones, lo cual permite al maestro saber lo que pasó. La mayoría de los controladores convierten esto en una forma que tenga sentido para el lenguaje o la aplicación en uso.

Los beneficios del protocolo Modbus 

De codigo abierto, no se requiere pagar por licencia.

    

Ampliamente soportado por HMIs o softwares SCADA Facil de usar Se pueden integrar varios equipos facilmente Bajo costo de desarrollo Conocido apliamente en la industria

Limitaciones del protocolo Modbus 











Dado que Modbus fue diseñado a finales de los setenta para comunicarse con controladores lógicos programables, el número de tipos de datos se limita a aquellos entendidos por los PLC en ese momento. Los objetos binarios grandes no son compatibles No existe una forma estándar para que un nodo encuentre la descripción de un objeto de datos, por ejemplo, para determinar si un valor de registro representa una temperatura entre 30 y 175 grados. Dado que Modbus es un protocolo maestro / esclavo, no es posible que un dispositivo de campo "informe por excepción" (excepto a través de Ethernet TCP / IP, llamado open-mbus) - el nodo maestro debe rutinariamente encuestar cada dispositivo de campo y buscar cambios en los datos. Esto consume ancho de banda y tiempo de red en aplicaciones en las que el ancho de banda puede ser costoso, como por ejemplo un enlace de radio de baja velocidad binaria. Modbus está restringido al direccionamiento de 254 dispositivos en un enlace de datos, lo que limita el número de dispositivos de campo que pueden conectarse a una estación maestra (una vez más, Ethernet TCP/IP es una excepción). Las transmisiones Modbus deben ser contiguas, lo que limita los tipos de dispositivos de comunicaciones remotas a aquellos que pueden almacenar datos para evitar lagunas en la transmisión. El protocolo Modbus no ofrece seguridad contra órdenes no autorizadas o interceptación de datos.

Figura 2. Representación del sistema Modbus

Laboratorio Reconocimiento de Tramas Para el reconocimiento de las tramas en el protocolo Modbus se tiene que tomar en cuenta que tipo de formato se usará, ya que esto determina la distribución de la información dentro de una trama.

Nombre Inicio Direcció n

Longitud (bits) 28

Función

8

Datos

n×8

CRC Fin

16 28

Nombre Inicio Direcció n Función Datos LRC Fin

8

Formato de trama Modbus RTU Función Al menos 3 1⁄2 Tiempos de silencio Station address Indica el código de función; Por ejemplo, leer los registros de bobinas/retención Datos + La longitud se rellenará dependiendo del tipo de mensaje Verificación de redundancia cíclica (CRC) Al menos 3 1⁄2 Tiempos de silencio entre tramas

Formato de trama Modbus ASCII Función Longitud (Bytes) 1 Comienza con dos puntos : (El valor hex ASCII es 3A) 2 Dirección de la estación 2 n×2 2 2

Nombre Identificador de la transacción Identificador del protocolo Campo de longitud Identificador de unidad Código de función Bytes de datos

Indica los códigos de función como leer bobinas / entradas Datos + La longitud se rellenará dependiendo del tipo de mensaje Verificación de redundancia longitudinal (LCR) Par retorno de carro/avance de línea (CR/LF) (Valores ASCII de 0D, 0A)

Formato de trama Modbus TCP Longitud (Bytes) Función 2 Para la sincronización entre mensajes de servidor y cliente 2 0 para Modbus/TCP 2 1 1 nx2

Número de bytes en esta trama Dirección del esclavo (255 si no se usa) Códigos de función como en otras variantes Datos como respuesta o comandos

Experimentación Para poder entender la que era lo que se recibía en cada trama del protocolo de comunicación Modbus TCP/IP, realice previas pruebas con valores simples, y así comprender poco a poco que era lo que se estaban comunicando el maestro y esclavo (Simulado por el Modsim y el Modscan). La primera prueba:

Empecé a solo enviar un valor constate de 500 y esto fue lo que recepcionó durante los primeros segundos: XMT: [002][000][000][000][000][006][001][003][000][099][000][001] RCV: [002][000][000][000][000][005][001][003][002][001][116] XMT: [003][000][000][000][000][006][001][003][000][099][000][001] RCV: [003][000][000][000][000][005][001][003][002][001][116] XMT: [004][000][000][000][000][006][001][003][000][099][000][001] RCV: [004][000][000][000][000][005][001][003][002][001][116] Y estas fueron las tramas luego de los 3 minutos de prueba: XMT: [012][001][000][000][000][006][001][003][000][099][000][001] RCV: [012][001][000][000][000][005][001][003][002][001][116] XMT: [013][001][000][000][000][006][001][003][000][099][000][001] RCV: [013][001][000][000][000][003][001][003][002] XMT: [014][001][000][000][000][006][001][003][000][099][000][001] RCV: [014][001][000][000][000][003][001][003][002]

Aún no tenia muy claro lo que significaban cada fila de números; entonces realice una segunda prueba:

Esta vez envié un valor constate de 500 y un valor que se incrementadaba cada 2 segundo, desde 0 a 10.

XMT: [078][000][000][000][000][006][001][003][000][099][000][002] RCV: [078][000][000][000][000][007][001][003][004][001][116][000][002] XMT: [079][000][000][000][000][006][001][003][000][099][000][002] RCV: [079][000][000][000][000][007][001][003][004][001][116][000][002] XMT: [080][000][000][000][000][006][001][003][000][099][000][002] RCV: [080][000][000][000][000][007][001][003][004][001][116][000][003]

Y estos fueron las ultimas tramas.

XMT: [080][001][000][000][000][006][001][003][000][099][000][002] RCV: [080][001][000][000][000][007][001][003][004][001][116][000][010] XMT: [081][001][000][000][000][006][001][003][000][099][000][002] RCV: [081][001][000][000][000][003][001][003][002] XMT: [082][001][000][000][000][006][001][003][000][099][000][002] RCV: [082][001][000][000][000][003][001][003][002] Con las primeras dos pruebas pude entender que: -

XMT es la nomenclatura de transmisor y RCV de receptor.

-

Los datos que se envian dentro de la trama, van ordenadas de izquierda a derecha. Empezando desde la dirección 0 hasta la final. Aunque la simulacipon se halla terminado, el receptor y transmisor nunca dejan de enviar tramas.

Luego de realizar un reconocimeinto de la información que se obtenía, procedí a realizar el laboratorio respectivo, con los valroes que son requeridos:

XMT: [026][000][000][000][000][006][001][003][001][043][000][010] RCV: [026][000][000][000][000][023][001][003][020][000][087][000][105][001][036][000][060] [018][016][002][099][004][125][000][015][001][107][000][092] Glosario de las partes de la trama: Este par de bytes representan el identificador de la transición, se usa para sincronizar los mensajes entre cliente/servidor. En este caso, se ha realizado la transición numero 26 Este par de bytes representan el protocolo de la comunicación, como en este laboratorio estamos usando el modelo TCP/IP, el valor 0 indica ello Este par de bytes representan la cantidad de número de bytes entra la trama a partir de aquí. En este caso habrá 23 bytes de aquí en adelante.

Este byte indica el identificador de la unidad/dispositivo, en este caso es el 1

Ente byte indica en que código de función nos estamos comunicando. Como en el laboratorio se requiere que el maestro y esclavo envíen código de Holding Registers

En todos estos bytes se mandan la información, están agrupados de a dos y ordenados de izquierda a derecha, empezando desde la dirección 0 hasta la 9

Ubicación del protocolo Modbus:

Basandonos en la la definicion de cada uno de los niveles de la pirámide, el protocolo Modbus se ubica en el nivel 1 o de campo.

Observaciones -

-

Se deben determinar para el Modsim y para el Modscan las mismas direcciones y tamaño de los registros, para que no halla perdida de datos. Para poder entender el funcionamiento de un protocolo, es importante que primero se hagan pruebas con datos pequeños y predecibles, para que luego al recibir o enviar tramas enormes, se sepa el significado de lo que se está enviando o recibiendo. Aunque la transmision/recepción de los datos ya haya acabado, el sistema aun sigue enviando tramas, para idicar que aun existe comunicación, aunque aun no halla que comunicar.

Conclusiones Luego de experimentar con las tramas del Modbus TCP/IP, se puede concluir lo importante de tener documentación que te determine que significa cada bit/byte dentro de una trama para que luego al ser interpretada, los datos no pierdan sentido. Este protocolo se usa en la industria para comunicar sistemas Maestros-Esclavos, por ejemplo si usamos un PLC con altas prestaciones como maestro y PLC de baja categorias como esclavos, y es necesario la comunicación entre estos para la realización de un proceso, se tiende a utilizar este protocolo por su simplicidad y confiabilidad de transmisión. Tambien se puden utilizar nos solo para los PLCs, sino para microprocesadores (como un rasberry pi).

Bibliografía Guia de protocolo Modbus (https://bit.ly/3kgkTEB) ¿Que es Modbus? (https://bit.ly/2FC3hUy) Introducción a Modbus (https://bit.ly/3iIkieN)

Introducción a las Comunicaciones Industriales ( https://bit.ly/33Ot4kR )...