Modbus o MODBUS es un protocolo de comunicación de datos cliente/servidor en la capa de aplicación . [1] Fue diseñado originalmente para su uso con sus controladores lógicos programables (PLC), [2] pero se ha convertido en un protocolo de comunicación estándar de facto para la comunicación entre dispositivos electrónicos industriales en una amplia gama de buses y redes. [3] [1]
Modbus es popular en entornos industriales porque se publica abiertamente y no tiene derechos de autor . Fue desarrollado para aplicaciones industriales, es relativamente fácil de implementar y mantener en comparación con otros estándares y tiene pocas restricciones en cuanto al formato de los datos que se van a transmitir.
El protocolo Modbus utiliza líneas de comunicación serial , Ethernet o el conjunto de protocolos de Internet como capa de transporte. [1] Modbus admite la comunicación hacia y desde múltiples dispositivos conectados al mismo cable o red Ethernet. Por ejemplo, puede haber un dispositivo que mida la temperatura y otro dispositivo para medir la humedad conectados al mismo cable, ambos comunicando mediciones al mismo ordenador , a través de Modbus.
El Modbus se utiliza a menudo para conectar una computadora supervisora de planta/sistema con una unidad terminal remota (RTU) en sistemas de control de supervisión y adquisición de datos ( SCADA ). Muchos de los tipos de datos reciben su nombre de dispositivos de control industrial de fábrica, como la lógica de escalera , debido a su uso en el control de relés: una salida física de un solo bit se denomina bobina y una entrada física de un solo bit se denomina entrada discreta o contacto .
Fue publicado originalmente por Modicon en 1979. La empresa fue adquirida por Schneider Electric en 1997. En 2004, transfirieron los derechos a la Organización Modbus [4] , que es una asociación comercial de usuarios y proveedores de dispositivos compatibles con Modbus que aboga por el uso continuo de la tecnología. [5]
Los estándares o buses Modbus incluyen: [1]
Para admitir la comunicación Modbus en una red, muchos módems y pasarelas incorporan diseños propietarios (consulte el diagrama: Arquitectura de una red para la comunicación Modbus ). Las implementaciones pueden implementar comunicaciones por cable o inalámbricas, como en la banda de radio ISM , e incluso el Servicio de mensajes cortos (SMS) o el Servicio general de paquetes por radio (GPRS).
Modbus define cliente , que es una entidad que inicia una transacción para solicitar cualquier tarea específica de su receptor de solicitudes . [6] El "receptor de solicitudes" del cliente, con el que el cliente ha iniciado la transacción, se denomina entonces servidor . [6] Por ejemplo, cuando una unidad de microcontrolador (MCU) se conecta a un sensor para leer sus datos mediante Modbus en una red cableada, por ejemplo, un bus RS485, la MCU en este contexto es el cliente y el sensor es el servidor. En la terminología anterior, el cliente se denominaba maestro y el servidor, esclavo.
Modbus define una unidad de datos de protocolo (PDU) independientemente de sus protocolos de capa inferior en su pila de protocolos. La asignación del protocolo MODBUS en buses o redes específicos requiere algunos campos adicionales, definidos como la unidad de datos de aplicación (ADU). La ADU la forma un cliente dentro de una red Modbus cuando el cliente inicia una transacción. El contenido es el siguiente: [7]
La ADU es llamada oficialmente trama Modbus por la Organización Modbus, [7] aunque la trama se utiliza como unidad de datos en la capa de enlace de datos en el modelo OSI y TCP/IP (mientras que Modbus es un protocolo de capa de aplicación).
El tamaño máximo de la PDU es de 253 bytes. El tamaño máximo de la ADU en la red RS232/RS485 es de 256 bytes y con TCP es de 260 bytes. [8]
Para la codificación de datos, Modbus utiliza una representación big-endian para direcciones y campos de datos. Por lo tanto, para un valor de 16 bits, el byte más significativo se envía primero. Por ejemplo, cuando un registro de 16 bits tiene el valor 0x1234, el byte 0x12 se envía antes que el byte 0x34. [8]
El código de función es un byte que proporciona el código de la función que se va a ejecutar. Los códigos de función son valores enteros que van de 1 a 255 y el rango de 128 a 255 es para respuestas de excepción.
El campo de datos de la PDU tiene una dirección de 0 a 65535 (no debe confundirse con la dirección del campo de dirección adicional de la ADU). [9] El campo de datos de la PDU puede estar vacío y, en ese caso, tiene un tamaño de 0. En este caso, el servidor no solicitará ninguna información y el código de función define la función que se ejecutará. Si no hay ningún error durante el proceso de ejecución, el campo de datos de la respuesta de la ADU del servidor al cliente incluirá los datos solicitados, es decir, los datos que el cliente recibió previamente. Si hay algún error, el servidor responderá con un código de excepción. [6]
Una transacción Modbus entre cliente y servidor incluye: [6] [10]
En base a esto, Modbus define 3 tipos de PDU: [8]
Modbus define su modelo de datos basándose en una serie de tablas de cuatro tipos principales: [11]
Modbus define tres tipos de códigos de función: públicos, definidos por el usuario y reservados. [13]
Nota: Algunas fuentes utilizan terminología que difiere del estándar; por ejemplo, Forzar bobina simple en lugar de Escribir bobina simple . [14]
El código de función 01 (leer bobinas) permite leer el estado de 1 a 2000 bobinas de un dispositivo remoto. mb_req_pdu (PDU de solicitud) tendrá entonces 2 bytes para indicar la dirección de la primera bobina a leer (de 0x0000 a 0xFFFF), y 2 bytes para indicar el número de bobinas a leer. mb_req_pdu define la dirección de la bobina por el índice 0, es decir, la primera bobina tiene la dirección 0x0. mb_rsp_pdu (PDU de respuesta) – si se ejecuta correctamente – tiene 1 byte para indicar el número de bytes que es el número de bobinas que mb_req_pdu ha solicitado, y los bytes de la izquierda almacenan el estado (valor de encendido/apagado) de esas bobinas solicitadas. [15] Específicamente, mb_rsp_pdu y mb_rsp_pdu del código de función 01 son: [15]
Por ejemplo, mb_req_pdu y mb_rsp_pdu para leer el estado de las bobinas del 20 al 38 serán: [16]
Los códigos de función definidos por el usuario son códigos de función definidos por el usuario. Modbus ofrece dos rangos de valores para los códigos de función definidos por el usuario: 65 a 72 y 100 a 110. Obviamente, los códigos de función definidos por el usuario no son únicos. [13]
Los códigos de función reservados son códigos de función utilizados por algunas empresas para productos heredados y no están disponibles para uso público. [13]
Cuando un cliente envía una solicitud a un servidor, puede haber cuatro eventos posibles para esa solicitud: [17]
El mensaje de respuesta de excepción incluye otros dos campos en comparación con un mensaje de respuesta normal: [17]
Todos los códigos de excepción Modbus: [18]
El estándar Modbus también define Modbus over Serial Line, un protocolo sobre la capa de enlace de datos del modelo OSI para que el protocolo de capa de aplicación Modbus se comunique a través de un bus serial . [19] El protocolo Modbus Serial Line es un protocolo maestro-esclavo que admite un maestro y varios esclavos en el bus serial. [20] Con el protocolo Modbus en la capa de aplicación, se utiliza el modelo cliente/servidor para los dispositivos en el canal de comunicación. Con Modbus over Serial Line, el rol del cliente lo implementa el maestro y el rol del servidor lo implementa el esclavo . [20] [21]
La convención de nombres de la organización invierte el uso común de tener múltiples clientes y un solo servidor. Para evitar esta confusión, la capa de transporte RS-485 utiliza los términos "nodo" o "dispositivo" en lugar de "servidor", y el "cliente" no es un "nodo". [21]
La (Organización Modbus) utiliza "cliente-servidor" para describir las comunicaciones Modbus, caracterizadas por la comunicación entre [dispositivo(s) cliente(s), que inician la comunicación y realizan solicitudes a los dispositivos servidor(es), que procesan las solicitudes y devuelven una respuesta apropiada (o mensaje de error).
Un bus serial para Modbus sobre línea serial puede tener un máximo de 47 esclavos comunicándose con un maestro. Esos esclavos tienen una dirección única que va de 1 a 247 (valor decimal). [22] El maestro no necesita tener una dirección. [22] El proceso de comunicación lo inicia el maestro, ya que solo él puede iniciar una transacción Modbus. Un esclavo nunca transmitirá ningún dato ni realizará ninguna acción sin una solicitud del maestro, y los esclavos no pueden comunicarse entre sí. [23]
En Modbus sobre línea serie, el maestro inicia solicitudes a los esclavos en modos unicast o broadcast . En el modo unicast , el maestro iniciará una solicitud a un solo esclavo con una dirección específica. Al recibir y finalizar la solicitud, el esclavo responderá con un mensaje al maestro. [22] En este modo, una transacción Modbus incluye dos mensajes: una solicitud del maestro y una respuesta del esclavo. Cada esclavo debe tener una dirección única (de 1 a 247) a la que se debe dirigir de forma independiente para la comunicación. [22] En el modo broadcast , el maestro puede enviar una solicitud a todos los esclavos, utilizando la dirección broadcast 0, [22] que es la dirección reservada para los intercambios broadcast (y no la dirección del maestro). Los esclavos deben aceptar los intercambios broadcast pero no deben responder. [23] La asignación de la PDU de Modbus al bus serial del protocolo Modbus sobre línea serie da como resultado la PDU de línea serie Modbus. [22]
PDU de línea serie Modbus = Dirección + PDU + CRC (o LRC)
Con PDU = Código de función + datos
En la capa física , MODBUS sobre línea serie realiza su comunicación en bits por RS485 o RS232 , con la interfaz de dos cables TIA/EIA-485 como la forma más popular. También se utiliza la interfaz de cuatro cables RS485. TIA/EIA-232-E (RS232) también se puede utilizar pero está limitada a la comunicación de corto alcance punto a punto. [20] MODBUS sobre línea serie tiene dos modos de transmisión RTU y ASCII que corresponden a dos versiones del protocolo, conocidas como Modbus RTU y Modbus ASCII . [24]
Modbus RTU (Unidad terminal remota), que es la implementación más común disponible para Modbus, utiliza una representación binaria compacta de los datos para la comunicación del protocolo. El formato RTU sigue los comandos/datos con una suma de comprobación de redundancia cíclica como mecanismo de comprobación de errores para garantizar la fiabilidad de los datos. Un mensaje Modbus RTU debe transmitirse de forma continua sin vacilaciones entre caracteres. Los mensajes Modbus están enmarcados (separados) por períodos inactivos (silencio). Cada byte (8 bits) de datos se envía como 11 bits: [3] [24]
Una trama Modbus RTU será entonces: [25]
El cálculo CRC es ampliamente conocido como CRC-16-MODBUS, cuyo polinomio es x 16 + x 15 + x 2 + 1 (siendo el polinomio algebraico hexadecimal normal 8005y invertido A001). [26]
Ejemplo de una trama Modbus RTU en hexadecimal: 01 04 02 FF FF B8 80(el cálculo CRC-16-MODBUS para los 5 bytes de 01a FFda como resultado 80B8, que se transmite primero con el byte menos significativo).
Para garantizar la integridad de la trama durante la transmisión, el intervalo de tiempo entre dos tramas debe ser al menos el tiempo de transmisión de 3,5 caracteres, y el intervalo de tiempo entre dos caracteres consecutivos no debe ser mayor que el tiempo de transmisión de 1,5 caracteres. [25] Por ejemplo, con la velocidad de datos predeterminada de 19200 bit/s, los tiempos de transmisión de 3,5 (t3,5) y 1,5 (t1,5) caracteres de 11 bits son:
Para velocidades de datos más altas, Modbus RTU recomienda utilizar los valores fijos de 750 μs para t1.5 y 1.750 ms para t3.5. [25]
Modbus ASCII utiliza caracteres ASCII para la comunicación de protocolos. El formato ASCII utiliza una suma de comprobación de redundancia longitudinal . Los mensajes Modbus ASCII están enmarcados por dos puntos iniciales (:) y una nueva línea final (CR/LF).
Una trama ASCII Modbus incluye: [27]
Dirección, Función, Datos y LRC son valores codificados hexadecimales ASCII, en los que los valores de 8 bits (0–255) se codifican como dos caracteres ASCII legibles por humanos de los rangos 0–9 y A–F. Por ejemplo, un valor de 122 (7A 16 ) se codifica como dos caracteres ASCII, "7" y "A", y se transmite como dos bytes, 55(37 16 , valor ASCII para "7") y 65(41 16 , valor ASCII para "A").
LRC se calcula como la suma de valores de 8 bits (excluyendo los caracteres de inicio y fin), negados ( complemento a dos ) y codificados como un valor de 8 bits. Por ejemplo, si Dirección, Función y Datos son 247, 3, 19, 137, 0 y 10, el complemento a dos de su suma (416) es −416; esto recortado a 8 bits es 96 (256 × 2 − 416 = 60 16 ), dando el siguiente marco de 17 caracteres ASCII: :F7031389000A60␍␊. LRC se especifica para su uso solo como una suma de comprobación: debido a que se calcula sobre los datos codificados en lugar de los caracteres transmitidos, su característica "longitudinal" no está disponible para su uso con bits de paridad para localizar errores de un solo bit.
Modbus TCP o Modbus TCP/IP es una variante de Modbus utilizada para comunicaciones a través de redes TCP/IP , conectándose a través del puerto 502. [28] No requiere un cálculo de suma de comprobación, ya que las capas inferiores ya proporcionan protección de suma de comprobación.
La nomenclatura TCP de Modbus es la misma que la del protocolo Modbus sobre línea serie, ya que cualquier dispositivo que envía un comando Modbus es el "cliente" y la respuesta proviene de un "servidor". [29]
La ADU para Modbus TCP se denomina oficialmente Modbus TCP/IP ADU por la organización Modbus [30] y también se denomina Modbus TCP frame por otras partes. [3]
MODBUS TCP/IP ADU = Encabezado MBAP + Código de función + Datos
Donde MBAP, que significa encabezado de protocolo de aplicación MODBUS, es el encabezado dedicado utilizado en TCP/IP para identificar la unidad de datos de aplicación MODBUS.
El encabezado MBAP contiene los siguientes campos: [31]
El identificador de unidad se utiliza con dispositivos Modbus TCP que están compuestos de varios dispositivos Modbus, por ejemplo, pasarelas de Modbus TCP a Modbus RTU. En tal caso, el identificador de unidad es la dirección del servidor del dispositivo detrás de la pasarela.
El formato de una trama MODBUS TCP/IP ADU/Modbus TCP será entonces: [31] [30]
12 34 00 00 00 06 01 03 00 01 00 01
0x12y 0x34 : Con el ID de transacción = 0x1234 (2 bytes) como un "número único" para ser identificado entre el cliente/servidor Modbus TCP, el byte alto del ID de transacción es 0x12 y el byte bajo del ID de transacción es 0x340x00y 0x00 : Identificador de protocolo byte alto y byte bajo0x00y 0x06 : Longitud de byte alto y byte bajo. La longitud es de 6 bytes que incluye: identificador de unidad (dirección esclava) (1 byte), código de función (1 byte), byte alto de la dirección del registro a leer (1 byte), byte bajo de la dirección del registro a leer (1 byte) y datos (2 bytes = byte alto y byte bajo del número de registros a leer)0x01 : Identificador de unidad (dirección esclava)0x03 : Código de función (Leer múltiples registros de retención)0x00y 0x01 : byte alto y byte bajo de la dirección del registro a leer. La dirección del registro a leer en este caso es 0x0001.0x00y 0x01 : byte alto y byte bajo del número de registros a leer. El número de registros a leer en este caso es 0x0001. (es decir, 1 registro)Además de los ampliamente utilizados Modbus RTU, Modbus ASCII y Modbus TCP, existen muchas variantes de protocolos Modbus:
Los modelos de datos y las llamadas a funciones son idénticos para las primeras cuatro variantes mencionadas anteriormente; solo la encapsulación es diferente. Sin embargo, las variantes no son interoperables, como tampoco lo son los formatos de trama.
Otro protocolo de facto estrechamente relacionado con Modbus apareció más tarde y fue definido por el fabricante de PLC April Automates, fruto de un esfuerzo de colaboración entre las empresas francesas Renault Automation y Merlin Gerin et Cie en 1985: JBUS. Las diferencias entre Modbus y JBUS en ese momento (número de entidades, estaciones servidor) son ahora irrelevantes, ya que este protocolo casi desapareció con la serie de PLC April, que AEG Schneider Automation compró en 1994 y luego dejó obsoleta. Sin embargo, el nombre JBUS ha sobrevivido hasta cierto punto.
JBUS admite los códigos de función 1, 2, 3, 4, 5, 6, 15 y 16 y, por lo tanto, todas las entidades descritas anteriormente, aunque la numeración es diferente:
{{cite web}}: Mantenimiento de CS1: postscript ( enlace )