Cómo fijar las tasas de sondeo en SCADA
Una tasa de sondeo, o tasa de poll, es cada cuánto el sistema SCADA le pide a un dispositivo el valor actual de un tag, y es uno de esos ajustes callados que la gente deja en el valor por defecto hasta que causa un problema. Ponga cada tag a sondear tan rápido como se pueda e inunda el dispositivo y, en un enlace celular o de radio, el plan de datos, con tráfico que no le compra nada para valores que apenas cambian. Ponga todo lento y el proceso se siente lerdo y los eventos importantes se notan tarde. El oficio de fijar tasas de sondeo es ajustar la tasa de cada valor a qué tan rápido de verdad necesita verse, lo que casi siempre significa ordenar los tags en unos pocos grupos en vez de ajustarlos uno por uno. Esta guía cubre cómo elegir y aplicar las tasas de sondeo: agrupar tags en clases de sondeo, balancear la respuesta contra la carga que pone en el PLC y el ancho de banda que gasta, y usar el reporte por excepción y la banda muerta para recortar tráfico sin perder los eventos que importan.
Fijar tasas de sondeo en SCADA en una línea: Para fijar las tasas de sondeo en SCADA, ordene sus tags por qué tan rápido de verdad necesita actualizarse cada uno y asígnelos a unas pocas clases de sondeo en vez de ajustar cada tag de forma individual, una clase rápida para valores que un operador controla activamente y clases lentas para valores que cambian de a poco o solo se registran. Ajuste la tasa de cada clase a la necesidad real, porque sondear más rápido carga más al PLC y, en enlaces celulares o de radio, gasta más datos y dinero. Donde el protocolo lo soporte, use el reporte por excepción con una banda muerta para que un valor solo se envíe cuando cambia en una cantidad significativa, lo que recorta el tráfico de forma drástica para puntos que se mueven despacio.
Agrupar los tags en clases de sondeo
Fijar una tasa de sondeo en cada tag de forma individual es a la vez tedioso e innecesario, porque la mayoría de los tags caen de forma natural en unas pocas categorías de velocidad. El enfoque estándar es la clase de sondeo, a veces llamada grupo de sondeo o grupo de poll, que es una tasa de sondeo con nombre que muchos tags comparten. Usted define un puñado de clases, y luego asigna cada tag a la clase que le convenga, de modo que en vez de fijar mil tasas individuales fija unas pocas clases y suelta los tags en ellas. Esto también hace el sistema mucho más fácil de entender y ajustar después, ya que cambiar la tasa de la clase rápida actualiza cada tag en ella de golpe en vez de exigir mil ediciones.
La manera correcta de dividir los tags en clases es por qué tan rápido de verdad necesita verse el valor, lo que suele reducirse a qué hace una persona con él. Un valor que un operador vigila y controla activamente, una presión que ajusta, un flujo que afina, necesita un sondeo rápido para que la pantalla responda y pueda cerrar el lazo en tiempo real. Un valor que cambia despacio y está ahí sobre todo por contexto, un nivel de tanque que se mueve en horas, una temperatura ambiente, queda perfectamente bien servido por un sondeo mucho más lento. Un valor que solo se registra para reportes o se mira rara vez puede sondearse más lento de todos. Ordenar los tags así, por la velocidad que la persona o el control de verdad requieren, es toda la base de un buen diseño de clases de sondeo.
Ayuda resistir la tentación de hacer todo rápido por si acaso. Un instinto común es que más rápido siempre es mejor, así que la gente empuja cada tag a la tasa más veloz disponible, pero este es justo el error que causa dispositivos sobrecargados y planes de datos reventados. El sondeo rápido solo es valioso para valores donde la velocidad de verdad se usa, y para la gran mayoría de los puntos que una persona mira de vez en cuando o que cambian de a poco, un sondeo lento no es un compromiso sino la elección correcta. Un sistema bien ajustado suele tener un número pequeño de tags en la clase rápida y el grueso de los tags en clases más lentas, que es la forma que mantiene cómodos a la vez al dispositivo y a la red.
Balancear la respuesta contra la carga y el costo de datos
Cada sondeo es una petición que el dispositivo tiene que responder, así que sondear más rápido pone más carga en el PLC o la RTU, y hay un límite real a cuánto puede servir un dispositivo. Un controlador ocupado respondiendo una avalancha de peticiones de sondeo tiene menos tiempo para su verdadero trabajo de control, y un dispositivo o su puerto de comunicación simplemente puede saturarse, punto en el cual los sondeos empiezan a tomar más que su intervalo y todo el sistema se atrasa. Por eso el sondeo rápido es un recurso para gastar con deliberación y no una mejora gratis. La capacidad del dispositivo es finita, y las tasas de sondeo son cómo la reparte, así que gasta los sondeos rápidos en los valores que los necesitan y deja que todo lo demás corra lento para que el dispositivo se mantenga responsivo donde cuenta.
En redes de planta cableadas el ancho de banda suele ser lo bastante barato para que la carga del dispositivo sea la restricción principal, pero el cálculo cambia por completo en enlaces celulares, de radio o satelitales, donde los datos en sí cuestan dinero y a menudo se miden. En esos enlaces, cada sondeo de cada tag son bytes por el aire en un plan que usted paga, y sondear rápido una lista grande de tags puede acumular una factura mensual sorprendente o agotar una asignación de datos por valores que nunca necesitaron vigilarse tan de cerca. Este es un costo operativo real que las tasas de sondeo controlan de forma directa, y es una de las razones más fuertes para sondear despacio donde no se necesita de verdad la actualización rápida. Un tag que se sondea cada segundo por celular envía sesenta veces los datos del mismo tag sondeado cada minuto, por información que en la mayoría de los casos no es más útil.
El balance práctico, entonces, es dar a un conjunto pequeño de valores críticos y controlados activamente un sondeo rápido y mantener la gran mayoría de los tags en clases más lentas, sobre todo en cualquier enlace medido. Esto no se trata de matar de hambre de datos al sistema; se trata de gastar tanto la capacidad del dispositivo como el plan de datos donde producen valor. La prueba correcta para cualquier tag es simple: alguien de verdad usaría una actualización más rápida, un operador actuaría antes o un lazo de control cerraría más ajustado. Si no, el sondeo más rápido es puro costo, más carga en el dispositivo y más bytes en la factura, a cambio de información que nadie usa. Acertar este balance es la diferencia entre un sistema que se mantiene ágil y asequible y uno que es lerdo o caro.
Banda muerta y reporte por excepción para sitios remotos
La herramienta más poderosa para recortar tráfico sin frenar nada es el reporte por excepción, donde en vez de sondear el valor y enviarlo en cada sondeo, solo se envía cuando de verdad cambia. Emparejado con una banda muerta, un umbral de cuánto debe moverse el valor antes de contar como un cambio, esto se vuelve reporte por excepción con banda muerta: una presión que se mantiene estable no envía nada, y solo cuando se mueve más que la banda muerta sale un valor nuevo. Para valores que se quedan quietos la mayor parte del tiempo, que son muchos valores de proceso, esto colapsa el tráfico de una corriente constante de lecturas idénticas a una actualización ocasional solo cuando algo pasa, sin dejar de atrapar cada cambio real.
La banda muerta es el ajuste que hace funcionar esto, y elegirla es un balance entre tráfico y resolución. Una banda muerta demasiado chica y el ruido ordinario de la señal cuenta como un cambio, así que el valor chasquea y pierde la mayoría del ahorro. Una banda muerta demasiado grande y se pierde movimientos reales y significativos porque no cruzaron el umbral, así que el valor reportado se retrasa de la realidad. Una banda muerta bien elegida es apenas mayor que el ruido de la señal y apenas menor para atrapar los cambios que importan, así que filtra el temblor mientras reporta con fidelidad el movimiento genuino. Ajustar la banda muerta por valor, o por clase de valores similares, es donde el reporte por excepción pasa de un instrumento burdo a uno preciso.
Esta combinación es justo lo que hace práctico y no ruinosamente caro el monitoreo en la nube de sitios remotos por enlaces celulares. En una plataforma SCADA en la nube como Merobix, una RTU remota se puede configurar para reportar valores por excepción con una banda muerta, así que un pozo o un tanque que corre de forma estable envía solo actualizaciones ocasionales y consume casi nada de datos, y aun así un cambio real, una presión que sube, un nivel que baja, se reporta pronto y llega al operador de inmediato. Esto deja que un solo plan de datos cubra una flota de sitios remotos que sería inasequible si cada tag se sondeara en un intervalo fijo y rápido. Las decisiones de tasa de sondeo y banda muerta de esta guía son, al final, lo que determina si monitorear una operación de campo dispersa cuesta una fortuna en datos o casi nada, así que vale la pena fijarlas con cuidado real en vez de dejarlas en los valores por defecto.
Preguntas frecuentes
¿Qué es una clase de sondeo y por qué usar una?
Una clase de sondeo, también llamada grupo de sondeo o grupo de poll, es una tasa de sondeo con nombre que muchos tags comparten, así que en vez de fijar una tasa individual en cada tag define unas pocas clases y asigna cada tag a la que le convenga. Esto hace el sistema mucho más fácil de manejar, ya que cambiar la tasa de una clase actualiza cada tag en ella de golpe. Las clases suelen reflejar qué tan rápido de verdad necesita verse cada valor, con una clase rápida para valores controlados activamente y clases más lentas para valores que cambian de a poco.
¿Sondear más rápido cuesta algo?
Sí, de dos maneras. Cada sondeo es una petición que el dispositivo debe responder, así que sondear rápido carga más al PLC o la RTU y puede saturarlo, dejando menos capacidad para el control y frenando todo el sistema. En enlaces celulares, de radio o satelitales también cuesta datos, ya que cada sondeo son bytes por un plan medido, y un tag sondeado cada segundo envía sesenta veces los datos del mismo tag sondeado cada minuto. Así que el sondeo rápido es un recurso para gastar con deliberación en valores que de verdad lo necesitan, no una mejora gratis.
¿Cómo reduce la banda muerta el uso de datos en un sitio SCADA celular?
Con el reporte por excepción, un valor solo se envía cuando cambia en vez de en cada sondeo, y la banda muerta fija cuánto debe moverse para contar como un cambio. Una presión que se mantiene estable no envía nada y consume casi nada de datos, mientras que un movimiento real mayor que la banda muerta se reporta pronto. Esto colapsa el tráfico de valores que se quedan quietos la mayor parte del tiempo, que son muchos datos de proceso, y es lo que hace asequible monitorear una flota de sitios celulares remotos en vez de ruinoso.
Servicios de automatización
¿Necesita convertir esta información en un sistema que funcione?
Merobix integra SCADA, programa PLC Allen-Bradley y Siemens, y diseña y fabrica tableros de control industrial.
Las solicitudes de reunión se revisan antes de confirmarse.