Desarrollo de aplicaciones con Modbus

¿Por qué usar Modbus?

Modbus es abierto, común, relativamente fácil de usar y tiene algunas restricciones en su aplicación; sin embargo, tiene sus deficiencias. En muchos casos, un usuario no tiene otra opción más que usarlo debido a las limitaciones de hardware, tales como sensores existentes u otros dispositivos que deben hablar a través de Modbus. Ya sea que usted deba usar Modbus o tenga varias opciones, debe entender los beneficios y las restricciones propias del protocolo.

Si Modbus es adecuado para el trabajo, entonces es importante que usted sepa cómo usarlo. ¿Cuáles son las opciones para implementarlo? ¿Cómo debe diseñar una aplicación para poder aprovechar este protocolo?

Selección de protocolos y consideraciones de diseño

La capa de aplicación de Modbus es implementada como un diseño maestro-esclavo de solicitud-respuesta para transmitir datos de un solo punto en varias capas en red. Este diseño fundamental funciona bien, pero tiene sus desventajas para algunas aplicaciones.

Modbus es un protocolo de solicitud-respuesta para interacción entre sistemas de control supervisorio y adquisición de datos (SCADA) y dispositivos de automatización. Para cada solicitud que se envía, el dispositivo final debe responder. Hay una respuesta para cada solicitud. Además, las solicitudes con frecuencia proceden de una sola fuente y se dirigen a un solo dispositivo. Estos sistemas pueden ser caracterizados como un dispositivo cliente que genera una solicitud y espera la respuesta junto con un dispositivo servidor que analiza las solicitudes del cliente, se encarga de ellas y después regresa una respuesta (ver Figura 1). La terminología de Modbus con frecuencia se refiere al cliente como el maestro, ya que suele actuar como el servidor del SCADA, y se refiere al servidor como el esclavo. El esclavo es comúnmente un sensor o controlador de automatización.

Figura 1. Un modelo de solicitud-respuesta/cliente-servidor

El patrón de mensajes de Modbus es similar al definido por el protocolo HTTP. Una ventaja de este patrón es que no requiere un capa de red extremadamente confiable. Si el cliente (o maestro) envía una solicitud y no recibe respuesta, sabe que algo ha salido mal y puede volver a enviar la solicitud. Haciendo una analogía con HTTP, esto sería equivalente a dar clic en el botón actualizar en un navegador de internet. Si usted envía solicitudes repetidamente y no obtiene una respuesta del servidor, usted puede pensar que el servidor no está funcionando y temporalmente dejará de intentar tener acceso a él. Esto es similar al comportamiento presentado por algunos servidores OPC, como KEPServerEX y NI OPC Servers, cuando se pierde la comunicación Modbus. Aunque esto no protege contra la pérdida de control, sí garantiza que los dispositivos maestros sepan cuando se pierde el control y les da la capacidad de proceder de manera apropiada, por ejemplo activar un mecanismo de seguridad o usar un dispositivo redundante para mantener el control. Esto no ocurre con el esclavo o servidor.

Debido al requerimiento de que todas las solicitudes vengan desde el dispositivo maestro, un esclavo inteligente no tiene un indicador confiable de que la comunicación se ha perdido. Si el esclavo no recibe solicitudes, podría significar que la red no está funcionando, el maestro no está funcionando o que el maestro ha decidido detener el envío de solicitudes. Esta falta de información confiable sobre el estado puede resolverse de diferentes maneras, pero un desarrollador de sistemas debe comprender la necesidad.

Una solución común para este problema es que los dispositivos tengan un temporizador tipo watchdog. Si alguna solicitud no se recibe en un periodo de tiempo designado, el dispositivo esclavo supone que algo ha fallado y entra en estado seguro. Dependiendo del dispositivo y la aplicación en particular, esto puede ser beneficioso o perjudicial para el control del sistema en general.

La solución simple del temporizador watchdog tiene limitaciones, por ejemplo que solamente confirma que las solicitudes se están recibiendo. Usted puede usar esquemas de mayor complejidad, pero un enfoque simple y efectivo que se utiliza comúnmente es implementar un heartbeat (señal periódica) a nivel del registro. Si el dispositivo lo soporta o si usted está desarrollando un nuevo dispositivo desde cero, este enfoque garantiza una comunicación constante entre un maestro y esclavo al nivel de la aplicación. Es decir, si el código de control en el maestro es responsable de cambiar el valor del heartbeat y el código de control en el esclavo es responsable de leerlo, el valor del heartbeat representa una prueba simple que confirma el funcionamiento normal del sistema. La funcionalidad del sistema desde el código de control maestro a través de las capas de red y hasta el ciclo de control del esclavo es verificada por esta prueba de heartbeat a nivel del registro. Otro registro, modificado en el esclavo y leído en el maestro también podría ser utilizado para indicar la comunicación en la otra dirección.

Figura 2. Una implementación de heartbeat simple

La naturaleza de esta arquitectura maestro-esclavo también significa que los esclavos Modbus no pueden proporcionar datos cuando no son solicitados por un maestro. Aunque el maestro puede implementar una arquitectura basada en eventos para enviar datos al esclavo, debe interactuar continuamente con los esclavos a una frecuencia definida para obtener los nuevos datos. Esto requiere una significativa carga adicional si los cambios son limitados, tanto en términos de ancho de banda de la red como en la utilización del CPU del maestro.

Cuando hay que actualizar información con regularidad (por ejemplo, desde un sensor de temperatura), este diseño funciona bien. Ya que estos datos varían constantemente, tiene sentido consultarlos a una frecuencia definida por la aplicación. Por el contrario, un elemento de datos que se actualiza lentamente como un bit de alarma o el estado de un interruptor físico se monitorea de manera más efectiva esperando que ocurra un cambio en su valor y actualizando solamente el maestro cuando este cambio ocurre. Modbus, sin embargo, requiere que cada valor sea consultado periódicamente.

Esta incapacidad del esclavo para enviar datos no solicitados a un maestro significa que Modbus ofrece un nivel de control a través de la red que requieren algunas aplicaciones. En una red frágil, un protocolo de solicitud-respuesta puede garantizar que el maestro es el único dispositivo que puede determinar cuando ocurre comunicación en la red. Si es configurado correctamente, esto significa que el maestro puede eliminar colisiones de paquetes de red y garantizar un nivel más alto de determinismo.

Esto también puede tener más beneficios generales para un sistema de control debido a que la comunicación en red está siempre en un estado estable. Si la información basada en eventos se transmitiera a través de la red por cualquier esclavo, introduciría fluctuaciones en el sistema. Aunque esto puede ser aceptable para algunas aplicaciones, usar un mecanismo estricto de polling para transferencia de datos reduce este riesgo.

Los datos de Modbus están orientados en torno al concepto de etiquetas (tags) o variables. Estos elementos de datos, registros de retención, registros de entrada, bobinas y entradas discretas, son llamados con nombres diferentes en el protocolo, pero la idea es la misma. Estas etiquetas son elementos de datos que se pueden escribir o leer en cualquier momento, pero únicamente proporcionan el valor actual. Esto tiene sentido para varias aplicaciones; sin embargo, implementar conceptos como eventos, mensajes o búferes de memoria primero en entrar, primero en salir (FIFO) puede ser difícil.

Modbus define cuatro bancos de datos, correspondientes a los cuatro tipos mencionados anteriormente, que almacenan la gran mayoría de la información transportada por el protocolo. Cada solicitud desde un maestro puede realizar una sola operación en un solo banco de datos. Es decir, una sola solicitud puede leer desde el banco de bobinas o escribir al banco de bobinas, pero no ambas. Sin embargo, existen excepciones. Por ejemplo, el código de función 23 permite a un maestro escribir a registros de retención y leer registros de retención en un solo ciclo de solicitud/respuesta. Sin embargo, esto no es un código de función implementado comúnmente. La documentación de los dispositivos maestro y esclavo debe ser evaluada para verificar si este código de función está disponible.

También es importante comprender que los datos en un determinado banco solamente se pueden acceder de forma secuencial y hasta el límite de tamaño de paquete del protocolo Modbus. Este límite generalmente está alrededor de 240 a 250 bytes, pero depende de la función específica que se utilice. Esto hace extremadamente importante diseñar cuidadosamente los bancos de registro.

Por ejemplo, una determinada aplicación puede requerir la transferencia de cantidades significativas de datos a una alta velocidad . En este caso, es recomendable disminuir el número de solicitudes requeridas. Ya que se debe tener acceso a los datos de manera secuencial, tendría sentido para esta aplicación concentrarse en la mayor cantidad posible de datos en un solo banco de registros y agrupar datos con el número mínimo de elementos de datos no utilizados.

Otra aplicación puede tener un esclavo más complejo que permita algo de control local. En esta situación, puede haber algunos datos que son leídos a una alta velocidad y algunos datos que son monitoreados periódicamente. En este caso, los datos deben ser agrupados según la velocidad de transferencia. Los datos de actualización rápida deben ser concentrados en un solo lugar, mientras que los datos de actualización lenta deben ser organizados en diferentes bloques para que a una sola solicitud le sea más fácil leer o actualizar un conjunto de datos en particular.

Para probarlo, considere un conjunto de cinco valores de actualización rápida (F1-F5) y cinco valores de actualización lenta (S1-S5). Además, S1, S2 y S3 corresponden a un módulo de código mientras que S4 y S5 corresponden a otro módulo de código; es decir, que se pueden actualizar en momentos diferentes. En la Figura 3, la organización ideal para este caso brinda al maestro la habilidad de leer los datos de actualización rápida en una sola solicitud y, conforme se vaya necesitando, lee los otros conjuntos de datos de actualización lenta.

Figura 3. Datos bien organizados

Si no se tiene cuidado, un conjunto de datos podría organizarse fácilmente como se muestra en la Figura 4. En este caso, se cambia de un poco más de 20 solicitudes por segundo a más de 80 solicitudes por segundo. En realidad, es más eficiente para un conjunto de datos pequeño leer todo en un solo bloque. Sin embargo, estos enfoques se vuelven rápidamente imposibles de escalar para un sistema complejo.

Figura 4. Mala organización de datos

Numeración de etiquetas

Aunque internamente, los datos en cada banco de Modbus se acceden usando valores de dirección desde 0 hasta 65,535, es más común para la documentación hacer referencia a los elementos de datos utilizando un esquema de dirección común. En dicho esquema, a la dirección del elemento de datos se le asigna un prefijo con un número que define el banco al que accede. La Tabla 1 muestra estos prefijos.

Tabla 1. Prefijos para acceso de datos

Dependiendo de la documentación en particular que se consulte, la dirección puede comenzar en cero o uno y utiliza un ancho fijo de entre cuatro y seis valores. De tal manera que, los diferentes documentos podrían referirse al mismo registro de retención como 4005, 40004 y 400005. La documentación debe definir el esquema de dirección usado y cualquier nuevo desarrollo del sistema debe publicar esta información.

Los protocolos de solicitud-respuesta no necesariamente aprovechan al máximo el ancho de banda de la red. Aunque una solicitud desde el maestro para leer una pieza de datos en particular definitivamente necesita una respuesta, una solicitud para escribir no la necesita. Sin embargo, el protocolo de aplicación Modbus requiere que una respuesta sea enviada a cada solicitud. Esto significa que se debe formar un paquete Modbus completo, incluyendo datos de protocolo, datos de aplicación y cualquier dato de red requerido. También significa que el proceso de solicitar datos y recibirlos en una respuesta puede tardar mucho más de lo que podría requerir una simple emisión de los datos, debido a la latencia de la red, el tiempo de procesamiento de esclavos y cualquier colisión o interferencia en la red.

Esto se agrava aún más por las consideraciones de organización de datos descritas anteriormente. Si los datos son organizados de manera deficiente en el espacio de la memoria Modbus, el número de ciclos de solicitud-respuesta requeridos puede incrementar drásticamente. Debido a las consideraciones de latencia, existe una velocidad limitada en que los ciclos de solicitud-respuesta pueden operar, aún sin interferencia en la red. Como resultado, reducir el número de solicitudes requerido para interacción entre un maestro y esclavo es una de las maneras más significativas de mejorar el rendimiento del sistema.

El protocolo Modbus ofrece poca o ninguna seguridad. En el pasado, la naturaleza aislada de las redes industriales significaba que era necesaria una violación de seguridad física para infiltrarse en la red. Conforme las redes se han vuelto más interconectadas, la seguridad se ha vuelto una preocupación más seria. En años recientes, varios esquemas han sido formulados para agregar seguridad a la comunicación del protocolo Modbus. Sin embargo, estos esquemas generalmente eliminan la compatibilidad con dispositivos y redes Modbus existentes.

Consideraciones de implementación

La utilidad de un determinado sistema también varía dependiendo de la implementación del controlador que se elija. Generalmente, los maestros Modbus se integran en una aplicación ya sea a través de una biblioteca o a través de una herramienta autónoma como un servidor OPC. Por el contrario, un esclavo Modbus generalmente se integra en un dispositivo usando cierto tipo de biblioteca o se desarrolla como parte del firmware del dispositivo. En cualquier caso, es importante comprender la variedad de implementaciones disponibles para hacer la elección más apropiada para una determinada aplicación.

Generalmente, una aplicación como KEPServerEX o NI OPC Servers es más completa que una biblioteca, pero ofrece menos control. Por ejemplo, ambas aplicaciones de servidor OPC pueden ser configuradas para ofrecer elementos de datos específicos a una velocidad específica y ambas pueden convertir los datos Modbus originales en un tipo de datos definido. Sin embargo, están limitadas en cuanto a que usted no puede generar y enviar directamente una solicitud Modbus; todas las solicitudes pasan por la aplicación y las opciones de configuración son limitadas. Una biblioteca, por el contrario, generalmente proporciona los datos sin procesar y requiere que usted inicie todas las solicitudes. Esto ofrece flexibilidad y le brinda un estricto control sobre todo el tráfico.

En cualquiera de los casos de implementación de biblioteca o aplicación, alguna parte del sistema es responsable de programar la frecuencia y determinar el formato de las solicitudes. Generalmente, las implementaciones toman una de las dos formas. La primera posibilidad requeriría que todas las solicitudes y respuestas ocurran en secuencia. Este enfoque de diseño sincrónico es una elección común ya que el código es fácil de escribir y es independiente de la red, pero puede no utilizar plenamente una red TCP/IP. En un diseño sincrónico, el maestro debe realizar las siguientes operaciones: generar una solicitud, enviar la solicitud a través de la red, esperar que el servidor tenga tiempo de procesar la solicitud y generar una respuesta, esperar que la respuesta recorra la red y finalmente procesar esa respuesta, todo antes de generar otra solicitud. Para un dispositivo esclavo o capa de red lentos, el tiempo de este trayecto de ida y vuelta puede ser bastante.

La alternativa es un diseño asincrónico, en el cual un proceso en el maestro es responsable de generar solicitudes y otro proceso es responsable de recibir respuestas y enrutar internamente dichas respuestas al código que necesita los datos. Este diseño es mucho más eficiente porque soporta múltiples solicitudes en la red al mismo tiempo, pero requiere que el esclavo tenga un búfer en la memoria lo suficientemente grande para manejar las solicitudes entrantes y que el desarrollador de la implementación del maestro invierta muchos más recursos en el problema. La Figura 5 muestra la diferencia entre estos dos esquemas para enviar mensajes. Cada flecha a la derecha indica una solicitud y cada flecha a la izquierda indica una respuesta.

Figura 5. Envío de mensaje sincrónico versus asincrónico

Algunas aplicaciones como KEPServerEX y NI OPC Servers encuentran un punto medio e implementan un esquema de comunicación que ofrece algunos de los beneficios de ambas implementaciones. Es decir, las etiquetas y los dispositivos se pueden organizar para que todas las solicitudes ocurran sincrónicamente, en un solo hilo o puedan ser organizadas en diferentes hilos. En este caso, todas las etiquetas en un hilo determinado son solicitadas sincrónicamente, pero se puede tener acceso en paralelo a múltiples dispositivos. Esto mantiene un buen control sobre la red y también mejora el rendimiento general del sistema.

Modbus es flexible en parte porque prácticamente no pone restricciones para los datos en el sistema. En cambio, los datos del sistema constan de hasta cuatro bloques de hasta 65,635 registros de tamaño de palabra o elementos Booleanos. Los datos pueden ser almacenados en elementos de ambos tipos, U16 o Booleano, o pueden ser almacenados como valores de sub-registros o como datos que cruzan los límites de múltiples registros.

Desafortunadamente, esta flexibilidad no implica funcionalidad. Al igual que con TCP y serial, donde los datos son transferidos como un flujo de bytes, se requiere código de aplicación que use Modbus para dar un formato a los datos, de tal manera que tenga sentido para el resto del sistema. Por ejemplo, la conversión de los datos a partir de los 32 bits que componen el primer y el segundo registro a un valor de punto flotante de precisión simple depende totalmente del código de la aplicación. Para hacer las cosas todavía más confusas, el orden de estos datos no está definido por el protocolo. Define que los registros sean transferidos por la red en formato big-endian, pero varios dispositivos manejan los límites entre los registros de manera diferente.

Es importante considerar esta situación en todas las implementaciones, ya que puede haber variaciones entre los diferentes dispositivos. Una biblioteca generalmente proporciona datos no manipulados en forma de registros, lo que significa que usted tiene que transformar los datos para cumplir las necesidades de su aplicación. Si una biblioteca proporciona datos escritos, la documentación se debe consultar para comprender el formato esperado. Por el contrario, una aplicación normalmente toma en cuenta algunas variaciones. Por ejemplo, KEPServerEX y NI OPC Servers le brindan la habilidad de cambiar el formato endianness de los tipos de datos de múltiples registros por dispositivo. Si esta opción no está expuesta, tiene que implementarla usted mismo y tratar los registros como datos sin manipular.

Manejar direcciones

Como se ha mencionado anteriormente, manejar direcciones en Modbus es complicado debido a la variedad de esquemas usados. Aunque la especificación define estrictamente un esquema para las direcciones (es decir, el registro de retención número cinco es leído al solicitar la dirección 0x04 con el código de función 0x03), los dispositivos normalmente convierten esta información en un solo número. La documentación desde diferentes fuentes puede utilizar el mismo número para referirse a diferentes valores. Es importante que esto sea considerado al utilizar una biblioteca estándar o una aplicación.

Normalmente, una biblioteca no proporciona abstracciones para convertir desde un esquema común de direcciones, como "400005", en una solicitud para los datos almacenados por el registro de retención cinco. Algunas bibliotecas, especialmente aquellas que tienen soporte de tipo de datos, lo hacen.

En cambio, en los servidores OPC y otras aplicaciones, es más probable que se utilice el esquema más general de direcciones. Las aplicaciones como NI OPC Servers y KEPServerEX incluso proporcionan opciones para cubrir muchas de las permutaciones en esquemas de direcciones (que el índice comience en cero o uno, por ejemplo). Sin embargo, estas aplicaciones todavía pueden tener requisitos inusuales, especialmente cuando se trata de interpretar registros como diferentes tipos de datos, la documentación de la aplicación siempre debe ser consultada para garantizar que los datos se transfieran e interpreten correctamente.

Seleccionar una arquitectura e implementación de Modbus

Si usted selecciona Modbus como el protocolo para desarrollar una aplicación, NI ofrece tres herramientas principales para comunicación a través de Modbus. En el nivel más bajo de abstracción, se encuentran disponibles una variedad de bibliotecas de APIs diferentes. Estas bibliotecas usualmente proporcionan soporte para maestro y esclavo. Los módulos NI LabVIEW Datalogging and Supervisory Control (DSC) y LabVIEW Real-Time ofrecen una herramienta llamada Modbus I/O server, la cual proporciona alguna de la flexibilidad y la facilidad de uso de una biblioteca de bajo nivel. Los servidores de E/S también proporcionan soporte para maestro y esclavo. Finalmente, NI OPC Servers es un servidor OPC completamente funcional que puede incluir soporte de controlador para maestros Modbus.

NI OPC Servers es una aplicación de servidor OPC autónoma y con gran funcionalidad que puede ser la base de un sistema SCADA. Como todos los servidores OPC anteriores al lanzamiento de OPC UA, NI OPC Servers es un programa para Windows únicamente y como tal es más adecuado para usarse como un sistema supervisorio que como un sistema de control de alta velocidad de los dispositivos esclavos. NI OPC Servers ofrece un extenso conjunto de controladores que permiten comunicación no solamente con dispositivos Modbus, sino también con dispositivos que utilizan una gran variedad de protocolos específicos de cada proveedor o protocolos estándares como OPC UA. Un sistema típico se vería similar a la Figura 6.

Figura 6. Esta aplicación SCADA típica utiliza un conjunto de dispositivos Modbus TCP/IP y un servidor NI OPC Servers como host.

Como muchos servidores OPC, NI OPC Servers tiene herramientas para manejar grandes tipos de datos, configuración de endiannes por dispositivo, funciones para agendar solicitudes y muchas otras características para abstraer algunos detalles de bajo nivel de Modbus. Una vez que los datos están en la aplicación, pueden ser transmitidos usando OPC u OPC UA hacia registradores, interfaces humano-máquina (HMIs) y otras aplicaciones de Windows.

Figura 7. Esta vista de una aplicación SCADA típica incluye interacción entre registros históricos basados en Windows y HMIs.

Los servidores de E/S Modbus incluidos en LabVIEW ofrecen una opción intermedia entre la variedad de servidores OPC fáciles de usar y las potentes bibliotecas de bajo nivel que brindan control completo del protocolo. Como en un servidor OPC, los servidores de E/S permiten una interfaz simple basada en configuración para comunicarse con un dispositivo Modbus. Como en un servidor OPC, los servidores de E/S incluyen su propio sistema para agendar solicitudes y resuelven varios de los problemas de bajo nivel en Modbus, como el formato endianness de los datos. Sin embargo, los servidores de E/S si ofrecen una interfaz simple en LabVIEW y brindan a los programas la habilidad de tener acceso rápida y fácilmente tanto a datos procesados (el valor de punto flotante de precisión simple en los registros 45 y 46) como a los datos sin procesar (el entero de 16 bits sin signo en el registro 45). Al igual que un servidor OPC, los servidores de E/S generalmente son usados en aplicaciones en los que el control supervisorio es importante, mientras que los microcontroladores distribuidos son responsables del control de alta velocidad en el sistema.

Servidor de E/S maestro Modbus

Los servidores de E/S pueden ser considerados como un servidor OPC básico que se ejecuta dentro de su aplicación. En un uso típico, el servidor de E/S maestro Modbus se implementa como parte de una aplicación, y luego la aplicación es directamente responsable de pasar los datos a una HMI o a una base de datos. En algunos casos, este nivel de participación del desarrollador reduce la facilidad de uso del sistema final, un servidor OPC completo es más escalable. Sin embargo, para sistemas más pequeños tiene más sentido eliminar el OPC intermediario y crear una sola aplicación para manejar todo.

Figura 8. Una aplicación de control de muestra que usa un servidor de E/S maestro Modbus

Servidor de E/S esclavo Modbus

Al igual que con el servidor de E/S maestro, los servidores esclavos también deberían utilizarse para control supervisorio solamente. Dado que el servidor de E/S se ejecuta en segundo plano, el código de usuario no tiene manera de saber cuándo se ha recibido una solicitud. Esto hace a los servidores de E/S ideales para aplicaciones en las que una pieza de hardware más potente, como un PAC, se usa para encargarse de la mayoría del control, con actualizaciones ocasionales de baja prioridad desde un hub central. En una aplicación de este tipo, los datos de Modbus en el servidor de E/S serían escaneados en cada iteración de un ciclo de control y usados para tomar decisiones, pero esos datos no serían usados para comunicación crítica (como un paro de emergencia).

Figura 9. Una aplicación de muestra de servidor de E/S esclavo Modbus

Existen muchos controladores para Modbus de bajo nivel en varios lenguajes. Los módulos LabVIEW DSC 2014 y LabVIEW Real-Time 2014 proporcionan un API de Modbus de bajo nivel para complementar las características de NI OPC Servers y servidores de E/S Modbus.

Con estos controladores, usted puede definir de manera explícita lo que sucede cuando una solicitud de Modbus es enviada o recibida. También suelen ofrecer un rendimiento mayor que los controladores de más alto nivel. A cambio, por lo general usted tiene que escribir gran cantidad de código de procesamiento de datos, lo que permite a su aplicación interactuar eficazmente con otros dispositivos en el sistema. La funcionalidad y el comportamiento de este código varía si el dispositivo es un maestro o un esclavo.

La Figura 10 muestra cómo un maestro de bajo nivel, el API de LabVIEW para Modbus, ofrece control total de las solicitudes específicas enviadas y la temporización de dichas solicitudes.

Figura 10. Un maestro de bajo nivel controla la temporización y el contenido de una solicitud leída..

Maestro de bajo nivel

Cuando se utiliza como un maestro, un PAC de alto rendimiento que utiliza un controlador Modbus de bajo nivel puede ser usado para controlar de manera efectiva un sistema que requiere alta velocidad y fiabilidad. Dado que las solicitudes son generadas directamente por el código de la aplicación, cualquier falla también se reporta y se conoce de inmediato, lo que permite que el sistema entre en un estado seguro o tome medidas correctivas.

Además, la aplicación tiene un control total sobre exactamente cuando se transmiten los datos, lo cual permite al código de la aplicación usar de manera eficiente el ancho de banda de la red. En vez de escanear todo a la misma velocidad, se pueden utilizar diferentes velocidades para diferentes dispositivos esclavos. Si es necesario, la aplicación podría incluso utilizar rutas de red completamente diferentes (dos conexiones TCP o diferentes líneas seriales) para cumplir con los requerimientos de rendimiento de la aplicación.

La figura 11 muestra una aplicación de ejemplo en la que el desarrollador ha optado por desarrollar un ciclo de control supervisorio basado en eventos de baja velocidad, similar a lo que podría tener en un sistema SCADA basado en Windows. En un proceso paralelo, se usa un ciclo de control determinístico para comunicarse con una bomba a una velocidad alta.

Figura 11. Esta aplicación de ejemplo del PAC NI CompactRIO utiliza un controlador de maestro Modbus de bajo nivel.

Además, debido a que estos controladores de bajo nivel son tan flexibles, usted puede utilizarlos para recrear algunas de las características de una interfaz de alto nivel, como un servidor de E/S, y aún mantener el control sobre las prioridades, que son tan importantes para el comportamiento del sistema. En esta aplicación de ejemplo, un ciclo de comunicación ha sido desarrollado para que agende todas las solicitudes y respuestas de tal manera que se adapte a las necesidades específicas de la aplicación. Un ciclo de control determinístico puede entonces ser escrito conociendo cuando están disponible nuevos datos desde el ciclo de comunicación, proporcionando muchos de los beneficios del primer sistema sin las potenciales desventajas por fallas de comunicación.

Figura 12. Esta aplicación de control personalizada mueve las comunicaciones a un ciclo secundario para reducir el impacto de las fallas de comunicación y cumple con los requerimientos de rendimiento del sistema.

Esclavo de bajo nivel

Debido a las dificultades de manejar la parte del servidor de un protocolo de solicitud-respuesta directamente en el código de la aplicación, muchas implementaciones de esclavo Modbus proporcionan un proceso en segundo plano que maneja la respuesta a las solicitudes del maestro. Esto es similar en principio al comportamiento de los esclavos en un servidor de E/S.

Sin embargo, en un controlador de bajo nivel, es típico y se espera que el código de la aplicación pueda ajustar el comportamiento de este proceso para cumplir con las necesidades del sistema. En algunos casos, los esclavos de bajo nivel proporcionan un evento que el código de la aplicación puede manejar. Esto le da la habilidad de responder inmediatamente a los datos entrantes desde el maestro sin tener que consultar los cambios en la memoria del dispositivo.

Figura 13. Este controlador esclavo de bajo nivel utiliza eventos para indicar los cambios de datos en un modelo de datos compartidos.

En casos más avanzados, el controlador de bajo nivel puede ser escrito de tal manera que el código de la aplicación pueda ser inyectado directamente en el modelo de datos del API esclavo. Por lo tanto, en lugar de simplemente leer desde una ubicación de memoria, el esclavo puede ser capaz de responder a las solicitudes del maestro de una manera específica para esa aplicación. Esto brinda muchos de los beneficios proporcionados por el maestro de bajo nivel, sin tener que escribir un código para el servidor en la aplicación.

Figura 14. Esta aplicación de esclavo de bajo nivel utiliza un modelo personalizado de datos para interactuar directamente con el código de control determinístico de una manera específica para este sistema.

Beneficios

• Usado comúnmente, con varias implementaciones disponibles
• Flexible
• Especificación disponible gratis
• La arquitectura de solicitud-respuesta ofrece reconocimiento a nivel de la aplicación

Desventajas

• La arquitectura solicitud-respuesta desaprovecha la red o complica el código de la aplicación
• Alta sobrecarga de la red
• Tamaño del paquete limitado, que aumenta la sobrecarga y disminuye la velocidad máxima de consulta
• La transferencia continua de datos (streaming) es difícil o imposible
• No hay soporte nativo de tipo de datos fuera de enteros de 16 bits sin signo y bits individuales
• Sin características de seguridad integradas
• Requiere una arquitectura de consulta (polling)

Modbus es y seguirá siendo un protocolo usado comúnmente a pesar del número de nuevas tecnologías introducidas en los últimos años. A pesar de que tiene limitaciones que usted debe tener en cuenta, su naturaleza simple y flexible lo hace una excelente opción para algunos diseños.

Referencias relacionadas

• Información detallada sobre el protocolo Modbus
• Especificación del protocolo de aplicación Modbus
• ¿Por qué es importante OPC UA?
• Biblioteca Modbus Java
• Recursos técnicos de Modbus