¿Cómo funciona la conmutación de controlador en un DCS redundante?

Volver al glosario

El primario y el respaldo mantenidos al paso

Un arreglo redundante de procesadores de control es un par: un miembro es el primario, que ejecuta activamente el control y mueve las salidas, mientras que el otro es el respaldo, listo para tomar el mando. Para que la conmutación sea sin costuras, el respaldo no puede arrancar en frío cuando el primario falla; debe ya tener el retrato actual del proceso. Esto se logra sincronizando de forma continua el respaldo con el primario, de modo que los dos lleven la misma configuración y, de forma crítica, el mismo estado de control en vivo en todo momento.

La sincronización de estado es lo que hace esto posible y es el corazón de un par redundante bien diseñado. El primario pasa de forma continua su estado en evolución al respaldo, incluidos los valores que importan para que el control continúe de forma correcta, como el estado interno de los algoritmos de control. El ejemplo clásico es el término integral, o de reset, de un controlador PID, un valor interno acumulado que debe llevarse intacto, porque si el respaldo empezara con uno distinto las salidas saltarían en el instante en que tomara el mando. Mantener este estado dinámico al paso es precisamente lo que permite que la entrega sea suave en vez de un arranque nuevo.

Más allá del estado en vivo, el par también comparte la base de datos de configuración, así que ambos miembros conocen las mismas estrategias de control y los mismos tags. La combinación, configuración coincidente más estado dinámico continuamente espejeado, significa que el respaldo no es un simple repuesto con el mismo programa; es un gemelo en marcha que sostiene el mismo estado de control momento a momento que el primario. Ese es el prerrequisito de todo lo que sigue, porque una conmutación solo puede ser sin brinco si el miembro que toma el mando ya sabe exactamente dónde estaba el proceso.

El instante del cambio de mando

La conmutación misma se dispara cuando ya no se puede confiar en que el primario siga controlando, casi siempre porque ha fallado o se ha detectado como defectuoso, o a veces porque un ingeniero ha iniciado deliberadamente un cambio para mantenimiento. En ese instante, el mando pasa al respaldo, que se vuelve el miembro activo y empieza a mover las salidas. Como se ha mantenido sincronizado, toma el mando desde el mismo estado que sostenía el primario en vez de desde cero, así que continúa los lazos exactamente donde estaban.

El requisito definitorio del cambio es que sea sin brinco. Sin brinco significa que las salidas de control no dan un paso ni un tirón cuando el mando pasa de un miembro al otro; las posiciones de válvula y las demás salidas continúan de forma suave como si nada hubiera cambiado. Esto es consecuencia directa de la sincronización de estado descrita arriba: como el respaldo sostiene el mismo estado de algoritmo, incluidos términos como el reset del PID, sus primeras salidas coinciden con lo que el primario habría producido, así que el proceso ve continuidad en vez de un disturbio. Un brinco en la conmutación derrotaría gran parte del propósito, ya que alteraría los mismos lazos que la redundancia debe proteger.

La velocidad es la otra mitad del panorama. El cambio tiene que completarse lo bastante rápido para que las salidas sean en efecto continuas, de modo que en el breve intervalo de la entrega el proceso no derive ni las salidas se interrumpan de una forma que la planta sentiría. En un par redundante de procesadores bien diseñado la conmutación sucede rápida y limpia, así que los operadores por lo general ven una indicación de que ocurrió una conmutación en vez de cualquier disturbio en el proceso mismo. La medida de una buena conmutación es exactamente esa: la planta sigue adelante, y solo los diagnósticos revelan que el mando pasó de un miembro al otro.

Por qué la conmutación sin brinco importa en operaciones más amplias

La razón por la que la conmutación se ingenieriza con tanto cuidado es que todo el valor de la redundancia es la continuidad del control, y una mala conmutación rompería exactamente lo que la redundancia existe para proteger. Si el cambio causara un brinco, la falla que el par redundante debía sortear se anunciaría en cambio como un disturbio de proceso, propagando potencialmente la perturbación por lazos conectados. Una conmutación limpia, sin brinco y rápida es lo que convierte una falla de controlador de un incidente en un no evento, que es por qué la sincronización de estado y el manejo sin brinco de la salida se tratan como requisitos centrales en vez de refinamientos.

Esta preocupación por el control ininterrumpido frente a la falla de equipo no se confina a los controladores de una planta; es un tema general en operaciones que no pueden darse el lujo de quedarse ciegas ni perder el control cuando algo falla. Las operaciones distribuidas monitoreadas por SCADA enfrentan el reto paralelo de que la pérdida de un solo elemento, un enlace de comunicación o una pieza de infraestructura central, no debería derribar la capacidad del operador de ver y gobernar los activos. El principio es el mismo que la conmutación de controlador a mayor escala: incorporar redundancia y hacer la transición al respaldo lo bastante sin costuras para que las operaciones continúen.

Una plataforma SCADA en la nube como Merobix refleja la misma filosofía en el nivel supervisorio, donde la meta es que los operadores conserven su vista y control de los sitios remotos aun cuando componentes individuales fallen, para que una sola falla no se vuelva una interrupción operativa. Donde un par redundante de procesadores de control asegura que un controlador fallado no detenga un lazo, una infraestructura de nube resiliente busca asegurar que un componente fallado no detenga a los operadores de monitorear sus sitios. En ambos casos el objetivo es la continuidad a través de la falla en vez de la mera existencia de un repuesto, que es exactamente lo que entrega una conmutación bien ejecutada a nivel de controlador.

Preguntas frecuentes