Consultas industriales, saturación y reintentos

Un maestro Modbus RTU envía una petición, espera la respuesta o el fin del plazo y solo entonces envía la siguiente. Por eso un bus RS-485 tiene un límite de capacidad que ninguna configuración aumenta. Una pasarela Modbus TCP delante del bus no añade capacidad. Si el sistema de consultas pide más, crece la cola de peticiones y los valores del panel se retrasan cada vez más respecto al reloj. Cuente las transacciones antes de configurar los intervalos.

Esta guía forma parte de la serie sobre calidad y transmisión de datos.

Cuente las transacciones en la conexión compartida

Calcule en el punto más estrecho. Diez clientes Modbus TCP que leen a través de una pasarela serie comparten su único puerto RS-485, por muy rápida que sea la conexión Ethernet. La pasarela pone sus peticiones en cola y las envía al bus de una en una.

Ejemplo en un bus RS-485 a 9.600 bit/s, con 8 bits de datos, paridad par y 1 bit de parada:

Este bus actualiza cada punto aproximadamente cada 3,4 s y no puede hacerlo más rápido. Un intervalo de consulta de 1 s exige 3,4 veces su capacidad. La calculadora de tiempos Modbus RTU de abajo utiliza los mismos datos: 85 ms por intercambio y 0,68 s para una petición a cada uno de los ocho contadores. Cinco bloques por contador elevan el tiempo a 3,4 s.

Con 11 bits por carácter, un carácter tarda 1,15 ms a 9.600 bit/s y el silencio entre tramas de 3,5 caracteres tarda 4,0 ms. Por encima de 19.200 bit/s, la guía de línea serie fija el silencio entre tramas en 1,75 ms y el tiempo máximo entre caracteres en 0,75 ms (sección 2.5.1.1). Una velocidad de transmisión mayor reduce el tiempo en el cable, pero no la demora del dispositivo. A 38.400 bit/s, el mismo intercambio tarda unos 37 ms, de los cuales 20 ms corresponden al contador.

Lea bloques más grandes. Cada transacción paga el coste de la petición, el retardo del dispositivo y el silencio entre tramas, independientemente de cuántos registros devuelva. A 9.600 bit/s y con 20 ms de retardo del dispositivo, 20 lecturas de 2 registros tardan unos 870 ms. Una sola lectura de los mismos 40 registros contiguos tarda unos 130 ms. Las funciones 03 y 04 leen hasta 125 registros por petición (protocolo de aplicación Modbus V1.1b3, secciones 6.3 y 6.4). Un bloque que incluya una dirección no implementada fallará con la excepción 02, dirección de datos no válida. Agrupe bloques solo dentro de rangos que el mapa indique como legibles y compruebe si el dispositivo impone un límite menor por petición.

BACnet MS/TP tiene un límite parecido por otro motivo. Un controlador solo transmite cuando posee el testigo y un router envía como máximo Max_Info_Frames peticiones en cada turno. Edge consulta BACnet por BACnet/IP, por lo que llega a los controladores MS/TP mediante un router y cada lectura espera el turno de este. La guía de BACnet/IP frente a MS/TP calcula el tiempo de rotación del testigo.

El coste de un dispositivo desconectado

Cada petición a un dispositivo que no responde espera hasta agotar el plazo completo. En el ejemplo, con un plazo de 1 s y cinco peticiones por contador, un contador desconectado añade 5 s a cada ciclo. El ciclo pasa de 3,4 a 8,0 s y los otros siete contadores sanos se leen menos de la mitad de veces.

La guía de línea serie da entre 1 s y varios segundos a 9.600 bit/s como plazo de respuesta habitual (sección 2.4.1). Es seguro para un dispositivo lento, pero caro en un bus ocupado. Configure el plazo según mediciones. Registre la respuesta más lenta de cada dispositivo durante un día normal y utilice aproximadamente el doble. Un contador cuya respuesta más lenta es 150 ms recibe un plazo de 300 ms. Así, la penalización por el dispositivo desconectado baja de 5 a 1,5 s.

Después, retrase las nuevas peticiones a ese dispositivo. Por ejemplo, tras tres agotamientos consecutivos, sáquelo de su programación normal y marque sus puntos como obsoletos. Envíele una petición de prueba cada 60 s. Cuando responda, restablezca la programación. Los contadores sanos vuelven a su ciclo de 3,4 s y el desconectado cuesta 0,3 s por minuto.

El bus sigue necesitando margen para los plazos agotados antes de comenzar el retraso. Con un intervalo de 5 s, el bus del ejemplo dispone de 1,6 s de margen. Un contador desconectado con plazo de 300 ms cuesta 1,5 s y cabe; con plazo de 1 s cuesta 5 s y no cabe. Si los agotamientos de un dispositivo superan el margen, divida el bus.

Cuando llegan peticiones más rápido de lo que terminan

Si se consulta el bus del ejemplo cada 1 s, el sistema genera 40 peticiones por segundo y el bus completa unas 12. La cola crece unas 28 peticiones por segundo. Si se atiende por orden, la petición enviada después de diez minutos llevaba unos siete minutos en cola. Todos los indicadores pueden permanecer verdes: el bus está ocupado, los dispositivos responden y ninguna petición falla. Solo las marcas temporales revelan que los datos tienen siete minutos de retraso.

Decida qué hacer con los trabajos atrasados:

Vigile la antigüedad de la petición más antigua además de la longitud de la cola. En un bus que mantiene el ritmo, ninguna espera más de un intervalo de consulta. Genere una alarma si la más antigua supera dos intervalos.

Separe los puntos en directo de los registros de energía

La mayoría de los puntos no necesitan el intervalo más corto. Un registro de energía en kWh es un acumulado; leerlo cada 15 minutos no pierde energía porque la lectura siguiente incluye todo lo acumulado. La potencia, una consigna o el estado de un interruptor usados para control requieren segundos.

Ponga los pocos puntos en directo en un intervalo corto, y los registros de energía y configuración en uno largo. Suponga que cada contador del ejemplo tiene un bloque en directo leído cada 5 s y cuatro bloques de energía cada 15 minutos. Las lecturas en directo consumen 8 × 85 ms = 0,68 s de cada 5 s. Las 32 lecturas de energía consumen 2,7 s una vez cada 15 minutos. Distribúyalas a lo largo del intervalo para que no coincidan todas en el cuarto de hora y retrasen 2,7 s las lecturas en directo.

Reintente solo lo que pueda funcionar

Detrás de una pasarela Modbus TCP hay dos plazos en serie: el del cliente y el de la conexión serie de la pasarela. El plazo del cliente debe superar el de la pasarela más la espera de la petición en su cola. De otro modo, el cliente abandona una petición que la pasarela aún procesa, la reintenta y coloca una segunda copia de la misma lectura en el bus. La guía de Modbus TCP frente a RTU explica plazos y límites de conexiones.

Que se agote el plazo de una escritura (función 06 o 16) no demuestra que fallara. El dispositivo pudo aplicar el cambio y perderse la respuesta. Lea el registro de nuevo antes de reintentar. Escribir dos veces una consigna absoluta no causa daño, pero una escritura que inicia una acción, como reiniciar un contador o dar una orden de arranque, puede ejecutarse dos veces: nunca la reintente sin una lectura de comprobación.

El retraso exponencial con variación aleatoria importa cuando muchos clientes comparten un servidor. Varios clientes Modbus TCP detrás de una pasarela, o una flota de Gateways que vuelve a conectarse a un servidor tras una interrupción, reintentarán al mismo tiempo salvo que cada uno añada un retraso aleatorio. AWS describe este patrón, con límites de intentos y de espera máxima. Sin ello, los reintentos tras la recuperación pueden mantener saturada una conexión lenta después de desaparecer el fallo. En un bus RS-485 solo hay un maestro, así que la variación aleatoria no aporta nada: importa el retraso por dispositivo.

Pruebe la recuperación bajo carga

1. Ejecute la lista completa de puntos con los intervalos previstos durante al menos una hora. Registre el tiempo de ciclo. Debe ser menor que el intervalo de consulta más rápido, con margen al menos para los plazos agotados de un dispositivo.
2. Apague un dispositivo. Cuando empiecen a espaciarse sus peticiones, las lecturas de los demás deben volver a tener menos de dos intervalos de antigüedad.
3. Vuelva a encenderlo. Sus puntos deben recuperar su vigencia dentro de un periodo de prueba, 60 s en el ejemplo.
4. Interrumpa la conexión con el destino durante 30 minutos. Las lecturas locales deben conservar sus marcas temporales normales y la cola de salida debe crecer al ritmo previsto: puntos por minuto × 30.
5. Restablezca la conexión. Todas las lecturas en cola deben llegar una vez. Cuéntelas por punto y marca temporal en el receptor y compruebe que el tiempo de ciclo del bus vuelve al valor del primer paso dentro de dos ciclos.

Consultas periódicas en Edge

Edge en el Gateway ZGW-20 dispone de cinco conexiones Modbus. Cada una se asigna a un endpoint: un puerto serie o un host y puerto TCP. Cada conexión tiene sus propias colas, límites de ritmo, métricas de latencia y retraso tras errores, además de una pausa de 2.000 ms en las lecturas en directo después de una escritura. Todos los ID de unidad de una conexión comparten estos recursos; por eso un dispositivo averiado detrás de una pasarela puede retrasar a los sanos de la misma conexión. Utilice una conexión para cada endpoint independiente.

El retraso tras errores cuenta peticiones fallidas consecutivas en la conexión, no por dispositivo. Después de 3, Edge deja de leer esa conexión durante 5 s o dos intervalos de consulta, el mayor de los dos. Después de 6, la pausa es de 15 s o tres intervalos; después de 10, de 30 s o cinco intervalos. Una respuesta correcta reinicia el contador. Los dispositivos sanos de la misma conexión suelen responder entre las peticiones al averiado, así que rara vez se llega a 3. Los plazos agotados del averiado continúan en cada ciclo; por eso importa su duración.

Por defecto, una conexión envía como máximo 20 peticiones en directo y 5 programadas, alineadas con el reloj, por segundo. Ambos límites pueden configurarse de 1 a 100. El límite predeterminado en directo supera la capacidad del bus del ejemplo, unas 12 por segundo a 9.600 bit/s: ajústelo por debajo de la capacidad medida. La cola programada admite 5.000 peticiones y descarta primero las más antiguas. La cola en directo admite 250 y unifica lecturas equivalentes. Si la latencia de una conexión supera 5.000 ms, Edge reduce sus consultas en directo a una petición por segundo. Edge agrupa lecturas contiguas en bloques de hasta 125 registros. Cada conexión informa de la latencia última y media y del número de errores; Edge registra un aviso cuando descarta lecturas programadas. Un dispositivo queda desconectado tras perder dos consultas esperadas y nunca antes de cinco minutos.

Estos límites protegen un bus lento, pero no aumentan su capacidad. Una interfaz Modbus ZMB es el maestro RS-485 de su propio bus corto. La ZMB-31 lee hasta 30 registros del equipo cercano y los envía al Gateway por la red Zigbee. Varios ZMB sustituyen un bus largo compartido por varios buses cortos, cada uno con su propio presupuesto de tiempos de espera.