Modbus

Modbus

Protocolo de comunicación
Desarrollador(es)	Modicon (1979-1997) Schneider Electric (1997-2004) Organización Modbus, Inc. (desde 2004)
Introducción	1979

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 usarse con 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]

• TCP/IP sobre Ethernet
• Comunicación serie asíncrona en una amplia gama de estándares, tecnologías: EIA/TIA-232-E, EIA-422, EIA/TIA-485-A, fibra, radiofrecuencia,...
• MODBUS PLUS, una red de paso de tokens de alta velocidad.

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]

• PDU = Código de función + datos
• ADU = Dirección adicional + PDU + comprobación de errores

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]}

• Paso 1: El cliente inicia una solicitud con PDU = Código de función + solicitud de datos
• Paso 2: El servidor recibe la solicitud del cliente. Luego, el servidor leerá/analizará el código de función, obtendrá la dirección del campo de datos de la PDU, luego obtendrá el valor de este campo de datos y, finalmente, realizará la acción en función del código de función. Si no hay ningún error durante esos pasos, el servidor responderá con PDU = Código de función + respuesta de datos. Siempre que no haya ningún error durante esos pasos, el código de función de respuesta del servidor también será el código de función enviado desde el cliente. Si hay algún error durante esos pasos, el servidor responderá con PDU = Código de función de excepción + Código de excepción (referencia a la PDU mb_excep_rsp_pdu definida a continuación).
• Paso 3: El cliente recibe la respuesta y finaliza la transacción.

En base a esto, Modbus define 3 tipos de PDU: ^[8]

• PDU de solicitud MODBUS, mb_req_pdu
• PDU de respuesta MODBUS, mb_rsp_pdu
• PDU de respuesta de excepción MODBUS, mb_excep_rsp_pdu

mb_req_pdu = Código de función (1 byte) + datos de la solicitud (n bytes)

El tamaño del campo de datos de solicitud depende del código de función y generalmente incluye valores como valores de variables, desplazamiento de datos y códigos de subfunción. ^[8]

mb_rsp_pdu = Código de función (1 byte) + datos de respuesta (n bytes)

Al igual que en mb_req_pdu, el tamaño del campo de datos de respuesta depende del código de función y generalmente incluye valores como valores de variables, desplazamiento de datos y códigos de subfunciones. ^[8]

mb_excep_rsp_pdu = Código de función de excepción (1 byte) + código de excepción (1 byte)

Código de función de excepción = Código de función (1 byte) + 0x80. El código de función de excepción es igual al código de función, excepto que su MSB se establece en 1.

El código de excepción (1 byte) de mb_excep_rsp_pdu se define en la tabla de códigos de excepción MODBUS.

Modbus define su modelo de datos basándose en una serie de tablas de cuatro tipos principales: ^[11]

Para cada una de las tablas principales, el protocolo permite la selección individual de 65536 elementos de datos, y las operaciones de lectura o escritura de esos elementos están diseñadas para abarcar múltiples elementos de datos consecutivos hasta un límite de tamaño de datos que depende del código de función de transacción. ^[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]

mb_req_pdu:

• Código de función: 0x01 (1 byte)
• Dirección de inicio (primera dirección de bobina a leer): de 0x0000 a 0xFFFF (2 bytes)
• Cantidad de bobinas a leer: Rango de 1 a 2000 (0x7D0) (2 bytes)

Descripción general del archivo mb_rsp_pdu:

• Código de función: 0x01 (1 byte)
• Número de bytes: 1 byte
• Estado de la bobina: n bytes

Por ejemplo, mb_req_pdu y mb_rsp_pdu para leer el estado de las bobinas del 20 al 38 serán: ^[16]

mb_req_pdu:

• Código de función: 0x01
• Dirección inicial Byte alto: 0x00
• Dirección inicial Byte bajo: 0x13
• Cantidad de salidas Byte alto: 0x00
• Cantidad de salidas Byte bajo: 0x13

La dirección inicial (2 bytes) es 0x0013 (o 19 en decimal), que es la bobina número 20.

La cantidad de salidas (2 bytes) es 0x0013, (o 19 en decimal) que corresponde a 19 valores de estado de las bobinas 20 a 38.

Descripción general del archivo mb_rsp_pdu:

• Código de función: 0x01
• Recuento de bytes: 0x03
• Estado de salidas 27-20: 0xCD
• Estado de salidas 35-28: 0x6B
• Estado de salidas 38-36: 0x05

Como se requieren 19 bobinas (20-38), se utilizan 3 bytes para indicar el estado de la bobina. Por lo tanto, el recuento de bytes es 0x03. Los estados de la bobina del 20 al 27 son 0xCD, que es 1100 1101 en binario. Por lo tanto, la bobina 27 es MSb y la bobina 20 es LSb. Lo mismo para las bobinas 28 a 35. Con las bobinas de 36 a 38, el estado será 0x05, que es 0000 0101. El estado de la bobina 38 es el tercer bit (cuenta desde la derecha), es decir, 1, la bobina 37 es 0 y el estado de la bobina 36 es el bit LSb, es decir, 1. Los 5 bits de la izquierda son todos 0.

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]

• Si el servidor recibe la solicitud y se ejecuta correctamente, el servidor devolverá una respuesta normal.
• Si el servidor no puede recibir la solicitud debido a un error en el canal de comunicación, no responderá nada al cliente. El cliente recibirá un error de solicitud de tiempo de espera.
• Si el servidor recibe la solicitud y detecta un error en el canal de comunicación (por ejemplo, paridad, LRC, CRC), no responderá nada al cliente. El cliente recibirá un error de solicitud de tiempo de espera.
• Si el servidor recibe la solicitud y no puede ejecutarla (por ejemplo, el cliente solicita leer un registro inexistente), el servidor devolverá una respuesta de excepción al cliente para indicar la naturaleza del error.

El mensaje de respuesta de excepción incluye otros dos campos en comparación con un mensaje de respuesta normal: ^[17]

• Código de función: el bit MSB del código de función de excepción es 1. Esto hará que este código de función sea 0x80 mayor que el código de función del mensaje de solicitud.
• Datos: El servidor devuelve el código de excepción dentro del campo Datos. Este campo define la naturaleza del error.

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

• La dirección es la dirección del esclavo
• La PDU se define de forma idéntica a la PDU del protocolo de aplicación Modbus
• El campo de comprobación de errores con CRC/LRC: Los métodos de comprobación de errores dependen de las versiones del protocolo MODBUS sobre línea serie, ya sea Modbus RTU o Modbus ASCII .

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]}

• 1 bit de inicio
• Datos/mensaje de 8 bits, el bit menos significativo se envía primero
• Paridad de 1 bit
• 1 bit de parada

Una trama Modbus RTU será entonces: ^[25]

El cálculo CRC es ampliamente conocido como CRC-16-MODBUS, cuyo polinomio es x ¹⁶ + x ¹⁵ + x ² + 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:

${\displaystyle t3.5=3.5*\left({\frac {11*1000}{19200}}\right)=2.005ms}$

${\displaystyle t1.5=1.5*\left({\frac {11*10^{6}}{19200}}\right)=859.375\mu s}$

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 ₁₆ ) se codifica como dos caracteres ASCII, "7" y "A", y se transmite como dos bytes, 55(37 ₁₆ , valor ASCII para "7") y 65(41 ₁₆ , 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 ₁₆ ), 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 de Modbus TCP 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 0x34
• 0x00y 0x00 : Identificador de protocolo byte alto y byte bajo
• 0x00y 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)

• Modbus sobre TCP/IP , Modbus sobre TCP o Modbus RTU/IP : una variante que se diferencia de Modbus TCP en que se incluye una suma de comprobación en la carga útil, como con Modbus RTU.
• Modbus sobre UDP : algunos han experimentado con el uso de Modbus sobre UDP en redes IP, lo que elimina la sobrecarga de TCP. ^[32]

Además de los ampliamente utilizados Modbus RTU, Modbus ASCII y Modbus TCP, existen muchas variantes de protocolos Modbus:

• Modbus Plus ( Modbus+ , MB+ o MBP ): Modbus Plus es propiedad de Schneider Electric , aunque no está publicado en lugar de patentado y, a diferencia de las otras variantes, admite comunicaciones peer-to-peer entre múltiples clientes. ^[33] A pesar del nombre, Modbus Plus ^[34] no es una variante de Modbus. Es un protocolo diferente , que implica el paso de tokens . Requiere un coprocesador dedicado para manejar la rotación rápida de tokens similar a HDLC . Utiliza par trenzado a 1 Mbit/s e incluye aislamiento de transformador en cada nodo, lo que lo hace activado por transición/borde en lugar de activado por voltaje/nivel. Se requiere hardware especial para conectar Modbus Plus a una computadora, generalmente una tarjeta hecha para el bus ISA , PCI o PCMCIA . Modbus Plus normalmente se implementa utilizando un conjunto de chips personalizado disponible solo para socios de Schneider.
• Pemex Modbus : una extensión del Modbus estándar compatible con datos históricos y de flujo. Fue diseñado para la empresa de petróleo y gas Pemex para su uso en el control de procesos y nunca se adoptó de forma generalizada.
• Enron Modbus : otra extensión del Modbus estándar desarrollado por Enron con soporte para variables de punto flotante y entero de 32 bits, y datos históricos y de flujo. Los tipos de datos se asignan mediante direcciones estándar. ^[35] Los datos históricos sirven para cumplir con un estándar de la industria del Instituto Americano del Petróleo (API) sobre cómo deben almacenarse los datos. ^{[ cita requerida ]}

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:

• El número y la dirección coinciden: la entidad # x tiene la dirección x en el marco de datos.
• En consecuencia, el número de entidad no incluye el tipo de entidad. Por ejemplo, el registro de retención n.° 40010 en Modbus será el registro de retención n.° 9, en la dirección 9 en JBUS.
• No se admite el número 0 (y, por lo tanto, la dirección 0). El servidor no debe implementar ningún dato real en este número y dirección, y puede devolver un valor nulo o generar un error cuando se lo solicite.

• Dado que Modbus se diseñó a fines de la década de 1970 para comunicarse con controladores lógicos programables, la cantidad de tipos de datos está limitada a los que entendían los PLC en ese momento. No se admiten objetos binarios grandes.
• No existe una forma estándar para que un nodo encuentre la descripción de un objeto de datos, por ejemplo, para saber que un valor de registro representa una temperatura entre 30 y 175 grados.
• Dado que Modbus es un protocolo cliente/servidor (anteriormente maestro/esclavo), ^[21] no hay forma de que un dispositivo de campo obtenga datos mediante el mecanismo de control de eventos (excepto a través de Ethernet TCP/IP, llamado open-mbus) ya que el nodo cliente debe sondear rutinariamente cada dispositivo de campo y buscar cambios en los datos. Esto consume ancho de banda y tiempo de red en aplicaciones donde el ancho de banda puede ser costoso, como en un enlace de radio de baja tasa de bits.
• Modbus está restringido a direccionar 247 dispositivos en un enlace de datos, lo que limita la cantidad de dispositivos de campo que pueden conectarse a una estación principal (nuevamente, Ethernet TCP/IP es una excepción).
• El protocolo Modbus por sí solo no proporciona seguridad contra comandos no autorizados o interceptación de datos. ^[36]

• Red Bac
• Bus CAN
• Trabajos en Lon

• Protocolo de aplicación MODBUS (2012). Especificación del protocolo de aplicación Modbus V1.1b3 (PDF) . La Organización Modbus . Consultado el 10 de octubre de 2023 .
• Protocolo MODBUS sobre línea serie (2006). Guía de implementación y especificación de MODBUS sobre línea serie V1.02 (PDF) .
• Mensajería MODBUS en TCP/IP (2006). Guía de implementación de mensajería MODBUS en TCP/IP V1.0b (PDF) . Organización Modbus.
• MODICON, Inc. (1996). Guía de referencia del protocolo Modicon Modbus/Modbus sobre línea serie (solo para aplicaciones heredadas) (PDF) .

• Sitio web de la Organización Modbus

• Organización Modbus: enlaces a especificaciones de protocolo
• Modbus sobre línea serial V1.02 – Organización Modbus (2006)
• Guía de referencia del protocolo Modbus de Modicon: Organización Modbus (1996). Esta es una especificación Modbus obsoleta que solo debe utilizarse para solucionar problemas heredados.

• Modbus para técnicos de campo en modbusbacnet.com
• Tutorial de Modbus en RF Wireless World