Modbus

La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la versión revisada el 17 de marzo de 2020; las comprobaciones requieren 44 ediciones .

Modbus  es un protocolo de comunicación abierto basado en la arquitectura maestro-esclavo ( en inglés master -  slave ; los términos cliente-servidor se utilizan en el estándar Modbus ). Es ampliamente utilizado en la industria para organizar la comunicación entre dispositivos electrónicos . Se puede utilizar para la transmisión de datos a través de líneas de comunicación serie RS-485 , RS-422 , RS-232 y redes TCP/IP (Modbus TCP). También hay implementaciones no estándar que utilizan UDP [1] [2] .

No confunda "Modbus" y "Modbus Plus". Modbus Plus es un protocolo propietario propiedad de Schneider Electric . La capa física de Modbus Plus es única, similar a Ethernet 10BASE-T , medio dúplex sobre un par trenzado , velocidad de 2 Mbps. El protocolo de transporte de Modbus Plus es HDLC , sobre el cual se especifica una extensión para la transmisión de Modbus PDU.

JBUS es un subconjunto del protocolo Modbus RTU con ligeras diferencias en el método de direccionamiento [3] .

Historia

Modbus fue desarrollado por Modicon (ahora propiedad de Schneider Electric ) para su uso en sus controladores lógicos programables . La especificación del protocolo se publicó por primera vez en 1979 [4] . Era un estándar abierto que describía el formato de los mensajes y cómo se transmitían a través de una red de varios dispositivos electrónicos.

Inicialmente, los controladores MODICON usaban la interfaz serial RS-232 [4] . Más tarde, se comenzó a utilizar la interfaz RS-485, ya que brinda mayor confiabilidad, le permite usar líneas de comunicación más largas y conectar varios dispositivos a una línea.

Muchos fabricantes de equipos electrónicos han respaldado el estándar, cientos de productos que lo utilizan han aparecido en el mercado.

Modbus estándar

Modbus está siendo desarrollado actualmente por la organización sin fines de lucro Modbus-IDA [5] .

Terminología específica

• PDU ( Unidad de datos de protocolo ) es una parte del paquete Modbus común a todos los niveles físicos. Incluye código de función y datos del paquete.
• ADU ( Unidad de datos de aplicación ) es un paquete Modbus completo. Incluye la parte específica de la capa física del paquete y la PDU.

Modbus especifica 4 tipos de datos:

• Las entradas discretas  son del tipo de solo lectura de un bit.
• Coils  es un tipo de un bit, disponible para lectura y escritura.
• Registros de entrada  : tipo de 16 bits con o sin signo, solo lectura.
• Registros de retención  : tipo de 16 bits con o sin signo, disponible para lectura y escritura.

Composición de la norma

Los estándares Modbus constan de 3 partes:

• El documento del protocolo de aplicación Modbus contiene la especificación para la capa de aplicación del modelo de red OSI :
  • Un paquete de protocolo elemental, el llamado PDU ( Protocol Data Unit ), es el mismo para todas las capas físicas. La PDU está empaquetada en una unidad de datos de aplicación ( ADU ) específica del transporte.
  • Códigos de función y contenido de PDU para cada código.
• El documento Modbus sobre línea serie contiene la especificación del enlace y las capas físicas del modelo de red OSI para las capas físicas RS-485 y RS-232. En principio, se puede utilizar cualquier capa física basada en un transceptor asíncrono .
• El documento Guía de implementación de mensajería Modbus en TCP/IP contiene la especificación ADU para el transporte a través de la pila TCP/IP.

Ventajas de la norma

Las principales ventajas del estándar son la apertura y el carácter masivo. La industria ahora (2014) produce muchos tipos y modelos de sensores, actuadores, módulos de normalización y procesamiento de señales, etc. Casi todos los sistemas de control y monitoreo industrial tienen controladores de software para trabajar con redes Modbus.

Desventajas de la norma

El estándar se desarrolló básicamente en 1979, teniendo en cuenta las necesidades y las capacidades informáticas de esa época, y no se tuvieron en cuenta muchos aspectos relevantes para las redes industriales modernas [6] . La ausencia de estas características es consecuencia de la sencillez del protocolo, lo que facilita su estudio y agiliza la implementación.

• El estándar especifica un método para transferir solo dos tipos de datos [7] . La falta de una indicación clara en el estándar condujo al hecho de que los fabricantes de soluciones Modbus de terceros actuaron a su propia discreción con otros tipos de datos. La diferencia de opiniones de los fabricantes de equipos sobre este tema no permitió aclaraciones posteriores en el documento oficial: esto provocaría una oleada de descontento entre los fabricantes que no están de acuerdo con las modificaciones propuestas a la norma y una posible guerra de formatos.
• La norma no regula la inicialización inicial del sistema. La asignación de direcciones de red y el registro de los parámetros de cada dispositivo específico en el sistema se realizan manualmente en la etapa de adaptación y programación del sistema.
• No prevé la transmisión de mensajes iniciados por el dispositivo esclavo (interrupciones) [7] . El maestro debe sondear periódicamente a los esclavos.
• La duración de la solicitud es limitada y solo se pueden solicitar datos de registros consecutivos. Esto aumenta la latencia y la sobrecarga al usar la red, ya que para obtener datos de registros ubicados lejos unos de otros en el espacio de direcciones, el maestro debe solicitar datos innecesarios o usar múltiples solicitudes [7] .
• No hay forma de que un esclavo detecte una pérdida de comunicación con el maestro [7] .

Introducción

Los controladores en el bus Modbus se comunican utilizando un modelo maestro-esclavo basado en transacciones que consisten en una solicitud y una respuesta.

Por lo general, solo hay un dispositivo maestro ( ing.  cliente , según la antigua terminología maestro ) en la red, y varios dispositivos esclavos ( ing.  servidor , según la antigua terminología esclavo ). El maestro inicia transacciones (transmite solicitudes). El maestro puede dirigir la solicitud individualmente a cualquier esclavo o iniciar un mensaje de difusión a todos los esclavos. El dispositivo esclavo, habiendo reconocido su dirección, responde a una solicitud dirigida específicamente a él. Cuando se recibe una solicitud de difusión, los dispositivos esclavos no generan una respuesta.

La especificación Modbus describe la estructura de solicitudes y respuestas. Su base es un paquete de protocolo elemental, el llamado PDU ( Protocol Data Unit ). La estructura de la PDU es independiente del tipo de enlace e incluye un código de función y un campo de datos. El código de función está codificado como un campo de un byte y puede tomar valores en el rango de 1…127. El rango de valores 128…255 está reservado para códigos de error. El campo de datos puede ser de longitud variable. El tamaño del paquete PDU está limitado a 253 bytes.

PDU Modbus

Código de función	datos
1 byte	N ≤ 252 (byte)

Para transmitir un paquete a través de líneas de comunicación físicas , la PDU se coloca en otro paquete que contiene campos adicionales. Este paquete se denomina ADU ( Unidad de datos de aplicación ). El formato ADU depende del tipo de enlace. Hay tres variantes de la ADU, dos para la transmisión de datos sobre una interfaz asíncrona y una sobre redes TCP/IP:

• Modbus ASCII: solo se utilizan caracteres ASCII para el intercambio. Se utiliza una suma de comprobación de un solo byte para comprobar la integridad . El principio y el final del mensaje están marcados con caracteres especiales (el principio del mensaje es ":", el final del mensaje es CR/LF ).
• Modbus RTU es una opción binaria compacta. Los mensajes están separados por una pausa en la línea. El mensaje debe comenzar y terminar con un intervalo de silencio de al menos 3,5 caracteres a una velocidad de transmisión determinada. Durante la transmisión del mensaje, no debe haber pausas de más de 1,5 caracteres. Para velocidades superiores a 19200 baudios, se permiten intervalos de 1,75 y 0,75 ms, respectivamente. La comprobación de integridad se realiza mediante CRC .
• Modbus TCP: para la transferencia de datos a través de una conexión TCP/IP .

La estructura general de una ADU es la siguiente (dependiendo de la implementación, pueden faltar algunos de los campos):

dirección del dispositivo esclavo (esclavo)	Código de función	datos	bloque de detección de errores

dónde

• dirección del dispositivo esclavo  : dirección del dispositivo esclavo al que se dirige la solicitud. Los esclavos responden solo a las solicitudes que se les dirigen. La respuesta también comienza con la dirección del esclavo que responde, que puede variar de 1 a 247. La dirección 0 se usa para la transmisión y es reconocida por todos los dispositivos, las direcciones en el rango 248…255 están reservadas;
• el código de función  es el siguiente campo de un byte de la trama. Le dice al esclavo qué datos o qué acción requiere el maestro;
• datos  : el campo contiene información necesaria para que el dispositivo esclavo realice la función especificada por el maestro o contiene datos transmitidos por el dispositivo esclavo en respuesta a una solicitud del maestro. La longitud y el formato del campo dependen del número de función, el campo de datos también puede contener el detalle del código de función;
• bloque de detección de errores  : suma de verificación para verificar la ausencia de errores en el marco.

El tamaño máximo de ADU para redes serie RS232/RS485 es de 256 bytes, para redes TCP es de 260 bytes.

Para Modbus TCP ADU se ve así:

ID de transacción	ID de protocolo	longitud del paquete	dirección esclava	Código de función	datos

dónde

• ID de transacción  : dos bytes, generalmente ceros
• ID de protocolo  : dos bytes, ceros
• longitud del paquete  : dos bytes, alto, luego bajo, longitud de la parte del paquete que sigue a este campo
• dirección del dispositivo esclavo  : dirección del dispositivo esclavo al que se dirige la solicitud. Por lo general, se ignora si ya se ha establecido una conexión con un dispositivo específico o si solo hay un dispositivo en el sistema. Se puede usar si la conexión se establece a un puente que está conectado físicamente, como una red RS-485.

Cabe señalar que no existe un campo de control de errores en Modbus TCP, ya que la integridad de los datos está asegurada por la pila TCP/IP.

Categorías de códigos de función

La especificación del protocolo actual define tres categorías de códigos de función:

Comandos estándar Su descripción debe ser publicada y aprobada por Modbus-IDA. Esta categoría incluye códigos ya definidos y no utilizados actualmente. Comandos personalizados Dos rangos de códigos (65 a 72 y 100 a 110) a los que el usuario puede asignar una función arbitraria. Sin embargo, no se garantiza que algún otro dispositivo no utilice el mismo código para realizar una función diferente. reservado Esta categoría incluye códigos de función que no son estándar, pero que ya se utilizan en dispositivos fabricados por varias empresas. Estos son los códigos 9, 10, 13, 14, 41, 42, 90, 91, 125, 126 y 127.

Modelo de datos

Uno de los usos típicos del protocolo es leer y escribir datos en los registros del controlador. La especificación del protocolo define cuatro tablas de datos:

Mesa	Tipo de artículo	Tipo de acceso
Registros de banderas ( Bobinas )	un bit	Lee y escribe
Entradas discretas _	un bit	solo leyendo
Registros de entrada _	palabra de 16 bits	solo leyendo
Registros de tenencia _	palabra de 16 bits	Lee y escribe

Se accede a los elementos de cada tabla mediante una dirección de 16 bits, la primera celda es la dirección 0. Así, cada tabla puede contener hasta 65536 elementos. La especificación no define cuáles deben ser físicamente los elementos de la tabla y en qué direcciones de dispositivos internos deben estar disponibles. Por ejemplo, es aceptable organizar tablas superpuestas. En este caso, las instrucciones que funcionan con datos discretos y con registros de 16 bits accederán realmente a los mismos datos.

Cierta confusión está asociada con la forma en que se abordan los datos. Modbus se desarrolló originalmente para controladores Modicon. En estos controladores se utilizó una numeración especial para cada una de las tablas. Por ejemplo, el primer registro de entrada fue el número de ubicación 30001 y el primer registro de retención fue el 40001. Por lo tanto, la dirección del registro de retención 107 en el comando Modbus fue el número de registro 40108 del controlador. Aunque dicha coincidencia de direcciones ya no forma parte del estándar, algunos paquetes de software pueden "corregir" automáticamente las direcciones ingresadas por el usuario, por ejemplo, restando 40001 de la dirección del registro de almacenamiento. Manual de referencia de 1996 https://modbus.org/docs/PI_MBUS_300.pdf , donde se adoptó implícitamente un direccionamiento similar, marcado como obsoleto ("obsoleto" y "SOLO PARA APLICACIONES LEGADA"), especificación de protocolo actual https:// modbus. org/docs/Modbus_Application_Protocol_V1_1b3.pdf solo usa direccionamiento absoluto - 01 (0x01) Leer bobinas 0x0000 a 0xFFFF, 03 (0x03) Leer registros de retención 0x0000 a 0xFFFF.

Funciones estándar del protocolo Modbus

Acceso a datos

Lectura de datos

Para leer valores de las tablas de datos enumeradas anteriormente, use los códigos de función 1-4 ( valores hexadecimales 0x01-0x04):

• 1 (0x01)  - lectura de valores de varios registros de bandera (Read Coil Status) .
• 2 (0x02)  - lectura de valores de varias entradas discretas (Read Discrete Inputs) .
• 3 (0x03)  - Lectura de valores de varios registros de retención (Read Holding Registers) .
• 4 (0x04)  - Lectura de valores de varios registros de entrada (Read Input Registers) .

La consulta consta de la dirección del primer elemento de la tabla cuyo valor se va a leer y el número de elementos a leer. La dirección y la cantidad de datos se dan como números de 16 bits, el byte más significativo de cada uno se transmite primero.

Los datos solicitados se envían en la respuesta. El número de bytes de datos depende del número de elementos solicitados. Antes de los datos, se transmite un byte, cuyo valor es igual al número de bytes de datos.

Los valores de los registros de almacenamiento y los registros de entrada se transfieren a partir de la dirección especificada, dos bytes por registro, el byte alto de cada registro se transfiere primero:

byte 1	byte 2	byte 3	byte 4	…	byte N-1	byte N
RA ,1	RA ,0	RA +1.1	R A+1.0	…	R A+Q-1.1	R A+Q-1.0

Los valores de banderas y entradas digitales se transmiten en forma empaquetada: un bit por bandera. Uno significa encendido, cero significa apagado. Los valores de las banderas solicitadas llenan primero el primer byte, comenzando con el bit menos significativo, luego los siguientes bytes, también desde el bit menos significativo hasta los más significativos. El bit menos significativo del primer byte de datos contiene el valor de la bandera especificada en el campo "dirección". Si el número solicitado de banderas no es un múltiplo de ocho, entonces los valores de los bits adicionales se llenan con ceros:

byte 1								…	byte N
FA +7	FA +6	FA +5	FA +4	FA +3	FA +2	FA +1	FA _	…	0	…	0	FA +Q-1	FA +Q-2	…

Registro de un valor único

• 5 (0x05)  - escriba el valor de una bandera (Forzar bobina simple) .
• 6 (0x06)  : escribe el valor en un registro de almacenamiento (registro único preestablecido) .

El comando consta de la dirección del elemento (2 bytes) y el valor establecido (2 bytes).

Para un registro de retención, el valor es simplemente una palabra de 16 bits.

Para banderas, el valor 0xFF00 significa encendido, 0x0000 significa apagado, otros valores no son válidos.

Si el comando tiene éxito, el esclavo devuelve una copia de la solicitud.

Registro de valores múltiples

• 15 (0x0F)  - Escribir valores en múltiples registros de bandera (Forzar bobinas múltiples)
• 16 (0x10)  - escribe valores en varios registros de almacenamiento (Preset Multiple Registers)

El comando consta de la dirección del elemento, la cantidad de elementos a cambiar, la cantidad de bytes de los valores establecidos que se transmitirán y los valores establecidos en sí. Los datos se empaquetan de la misma manera que en los comandos de lectura de datos.

La respuesta consiste en la dirección inicial y el número de elementos modificados.

Cambio de registros

• 22 (0x16): escritura en un registro de almacenamiento utilizando la máscara "Y" y la máscara "O" (registro de escritura de máscara) .

El comando consiste en la dirección de un registro y dos números de 16 bits que se usan como máscaras que se pueden usar para restablecer o configurar individualmente bits individuales en el registro. El resultado final está determinado por la fórmula:

Resultado = ( Valor_actual Y Máscara_Y ) O ( Máscara_O Y (NO Máscara_Y ))

Lectura con escritura

• 23 (0x17)  - lectura/escritura de registros múltiples ( lectura/escritura de registros múltiples )

Este código de función realiza una combinación de una operación de lectura y una operación de escritura en una transacción Modbus.

Colas de datos

• 24 (0x18) - lectura de datos de la cola (Read FIFO Queue)

La función está diseñada para recibir palabras de 16 bits de una cola FIFO (primero en entrar, primero en salir ).

Acceso a archivos

• 20 (0x14) - lectura de un archivo (Read File Record)
• 21 (0x15) - escribir en un archivo (Escribir registro de archivo)

Estas funciones se utilizan para acceder a registros de 16 bits organizados en archivos de registros de longitud arbitraria. El comando especifica el número de archivo, el número de registro y la longitud del registro en palabras de 16 bits. Con un solo comando, puede escribir o leer varios registros, no necesariamente adyacentes.

Además, el comando contiene un código de un byte para indicar el tipo de referencia de datos. La versión actual del estándar define solo un tipo (descrito anteriormente) con el código 0x06.

Diagnósticos

Las funciones enumeradas a continuación son para dispositivos en líneas serie (Modbus RTU y Modbus ASCII).

• 7 (0x07) - señales de estado de lectura (Estado de excepción de lectura)

La función está destinada a obtener información sobre los indicadores de estado en un dispositivo remoto. La función devuelve un byte, cada uno de los cuales corresponde al estado de un indicador.

• 8 (0x08) - diagnóstico (Diagnóstico)
• 11 (0x0B) - leyendo el contador de eventos (Get Com Event Counter)
• 12 (0x0C) - leyendo el registro de eventos (Get Com Event Log)

Estas funciones están diseñadas para probar la funcionalidad del enlace serial.

• 17 (0x11) - leer información del dispositivo (ID del servidor de informes)

La función está destinada a obtener información sobre el tipo de dispositivo y su estado. El formato de la respuesta depende del dispositivo.

Otros

• 43 (0x2B) - Transporte de interfaz encapsulada

La función está diseñada para transferir datos en formatos arbitrarios (definidos por otros estándares) desde el maestro (cliente) al esclavo (servidor) y viceversa.

El tipo de datos transmitidos está determinado por un código adicional (MEI - Interfaz Modbus Encapsulada) transmitido después del número de función. El estándar define MEI 13 (0x0D), destinado a encapsular el protocolo CANopen . MEI 14 (0x0E) se usa para obtener información del dispositivo y los MEI en los rangos 0-12 y 15-255 están reservados.

Manejo de errores

Pueden ocurrir dos tipos de errores durante la comunicación:

• errores asociados con distorsiones en la transmisión de datos;
• errores lógicos (solicitud aceptada sin distorsión, pero no se puede ejecutar)

Cuando se transmite a través de líneas de comunicación asíncronas, los errores del primer tipo se detectan al verificar el cumplimiento de la solicitud recibida con el formato ADU establecido y al calcular la suma de verificación. Además, se puede usar un bit de paridad para verificar cada carácter . Si el esclavo detecta corrupción de datos, la solicitud recibida se ignora y no se genera ningún mensaje de respuesta. El anfitrión puede detectar un error sin respuesta.

Modbus TCP no proporciona comprobaciones de integridad de datos adicionales. Los protocolos TCP/IP proporcionan una transmisión de datos sin distorsiones.

En errores del segundo tipo, el dispositivo esclavo envía un mensaje de error (si la solicitud se dirige a este dispositivo, no se envía ninguna respuesta a las solicitudes de difusión). Una indicación de que la respuesta contiene un mensaje de error es el bit alto establecido del número de función. El número de función va seguido del código de error y, si es necesario, de datos de error adicionales en lugar de los datos habituales.

Códigos de error estándar

• 01 - No se pudo procesar el código de función recibido.
• 02 - La dirección de datos especificada en la solicitud no está disponible.
• 03 - El valor contenido en el campo de datos de la solicitud no es un valor válido.
• 04 - Ocurrió un error irrecuperable mientras el esclavo intentaba realizar la acción solicitada.
• 05 - El dispositivo esclavo ha recibido la solicitud y la está procesando, pero lleva mucho tiempo. Esta respuesta evita que el maestro genere un error de tiempo de espera.
• 06 - El dispositivo esclavo está ocupado procesando el comando. El maestro debe repetir el mensaje más tarde cuando el esclavo esté libre.
• 07 - El dispositivo esclavo no puede ejecutar la función del programa especificada en la solicitud. Este código se devuelve para una solicitud de programa fallida utilizando los números de función 13 o 14. El maestro debe solicitar información de diagnóstico o error del esclavo.
• 08: el dispositivo esclavo encontró un error de paridad al leer la memoria extendida. El capitán puede repetir la solicitud más tarde, pero por lo general en tales casos se requiere la reparación del equipo.

Ejemplos

A continuación se muestra un ejemplo de un comando maestro y respuestas de esclavo (para Modbus RTU).

Solicitud
Dirección de transferencia	dirección del dispositivo esclavo	número de función	Dirección		Número de banderas		Número de bytes de datos	Datos		CDN
			byte alto	byte bajo	byte alto	byte bajo		byte alto	byte bajo	byte bajo	byte alto
Cliente→Servidor	0x01	0x0F	0x00	0x13	0x00	0x0A	0x02	0xCD	0x01	0x72	0xCB

Responder
Dirección de transferencia	dirección del dispositivo esclavo	número de función	Dirección		Número de banderas		CDN
			byte alto	byte bajo	byte alto	byte bajo	byte bajo	byte alto
Servidor→Cliente	0x01	0x0F	0x00	0x13	0x00	0x0A	0x24	0x09
Mensaje de error
Dirección de transferencia	dirección del dispositivo esclavo	número de función	código de error	CDN
				byte bajo	byte alto
Servidor→Cliente	0x01	0x8F	0x02	0xC5	0xF1

Notas

1. ↑ El protocolo Modbus en profundidad. Archivado el 29 de junio de 2017 en Wayback Machine National Instruments
2. ↑ Especificación Modbus UDP. Archivado el 7 de julio de 2017 en Wayback Machine Java Modbus Library .
3. ↑ PROMOTIC - Comunicación por protocolo Modbus . Consultado el 7 de julio de 2015. Archivado desde el original el 8 de julio de 2015. (indefinido)
4. ↑ 1 2 Tutorial de interfaz Modbus . Consultado el 23 de marzo de 2009. Archivado desde el original el 3 de marzo de 2011. (indefinido)
5. ↑ Acerca de Modbus-IDA . Consultado el 23 de marzo de 2009. Archivado desde el original el 3 de marzo de 2016. (indefinido)
6. ↑ Charles Palmer, Sujeet Shenoi (ed) Critical Infrastructure Protection III: Third IFIP WG 11. 10 International Conference, Hanover, New Hampshire, EE. UU., 23-25 ​​de marzo de 2009, Revised Selected Papers Springer, 2009 ISBN 3-642-04797- 1 , página 87
7. ↑ 1 2 3 4 Desarrollo de aplicaciones con Modbus . Consultado el 7 de julio de 2015. Archivado desde el original el 8 de julio de 2015. (indefinido)

Literatura

• Especificaciones del protocolo original en inglés
• Especificaciones de Modbus y guías de implementación (Modbus TCP/IP)

Enlaces

• Modbus-IDA es una organización sin fines de lucro que apoya este protocolo
• Adquisición y control de datos: comunicaciones de datos en Curlie Links Directory (dmoz)
• Adquisición y control de datos: software en Curlie Link Directory (dmoz)

UART
Capas físicas	punto a punto RS-232 IrDA CIERVO módem bucle actual IRP midi Enlace IO (IEC 61131-9) La red RS-422 RS-423 RS-485 LIN autobús m Especial estándar de la ciudad de Kansas Casete compacto disco de gramófono
Protocolos	punto a punto PPA DESLIZAR IrDA CIERVO ISO 7816 midi Enlace IO (IEC 61131-9) La red modbus LIN DMX-512 P-RED profibus CEI 60870
áreas de uso	Puerto serial IrDA midi red industrial
Implementaciones	Controladores 8250 UART 16550 UART Conductores MAX232