A medida que los procesos de tratamiento de agua se han vuelto más exigentes —evaporación y cristalización para descarga líquida cero, agua ultrapura de grado semiconductor, la separación profunda de sales (salt-splitting) y la detoxificación de metales pesados en efluentes industriales difíciles—, la capa de automatización que los sustenta ha tenido que crecer con ellos. Dos arquitecturas han dominado esa capa durante décadas: el sistema de control distribuido (DCS) y el controlador lógico programable (PLC). El hardware y el software han convergido en cierta medida con los años, dando lugar a plataformas DCS híbridas y a controladores de automatización programables (PAC) que difuminan la frontera sobre el papel. Pero bajo esa convergencia, ambas arquitecturas siguen apoyándose en supuestos distintos sobre la estructura de base de datos, la planificación de tareas, la redundancia y la profundidad de los lazos de control —diferencias que importan mucho más de lo que sugiere el viejo resumen de “el PLC maneja señales discretas, el DCS maneja señales analógicas”.
Dos filosofías en competencia: la máquina y el proceso
La herencia del PLC, centrada en la máquina. El linaje del PLC se remonta a la sustitución de la lógica de relés en las líneas de ensamblaje automotriz. Fue concebido para manejar lógica discreta rápida y determinista, con la atención puesta en piezas de equipo individuales —una bomba, una válvula, un rascador— y en sus transiciones de estado, secuenciación y enclavamientos de seguridad. Su modelo mental es entrada, lógica, salida, y valora ante todo la velocidad de respuesta y la autonomía autocontenida en un único controlador.
La herencia del DCS, centrada en el proceso. El DCS surgió de las industrias petroquímicas y de proceso continuo, concebido para gestionar procesos físicos y químicos de gran escala, a nivel de planta completa —evaporación térmica, extracción, reacción continua— como un único sistema fluido e indivisible. Su modelo mental es el balance del proceso, la regulación multilazo y el monitoreo a escala de planta, y valora ante todo el acoplamiento dinámico entre variables, la precisión en estado estacionario del control analógico y la consistencia absoluta de los datos en toda la instalación.
Arquitectura de base de datos: un modelo unificado frente a dos ensamblados a la fuerza
Un DCS se construye de arriba hacia abajo alrededor de una única base de datos global. Dentro del entorno de ingeniería, un tag, su tipo de variable, su dirección de E/S de hardware, sus límites de alarma, sus unidades de ingeniería y su configuración de historiador, junto con sus gráficos de HMI, quedan todos vinculados en la misma base de datos unificada. Cuando un ingeniero define un bloque PID o un bloque de control de válvula a nivel de controlador, el sistema genera automáticamente el faceplate de operador, el ítem de tendencia y la entrada de registro de alarmas correspondientes. Cualquier cambio en línea sobre la lógica o las propiedades de una variable se propaga a todos los nodos relacionados sin un paso de sincronización aparte, lo que reduce drásticamente el riesgo de desajuste de tags que atormenta a los proyectos de ingeniería de larga duración.
Un PLC, en cambio, ha usado tradicionalmente una base de datos centrada en el hardware, construida de abajo hacia arriba. Su núcleo es un controlador independiente que ejecuta lógica a alta velocidad, y su base de datos es en esencia un mapa de memoria de hardware —direcciones de memoria o tags independientes. El PLC y el sistema supervisorio (SCADA/HMI) suelen ser, por completo, productos de software separados. Los ingenieros definen las E/S y las variables intermedias dentro del entorno del PLC, y luego mapean esas variables hacia la base de datos propia y separada del sistema SCADA mediante OPC (Open Platform Communications) o un driver de comunicación dedicado. Esa estructura de doble base de datos implica que las conversiones de tipo de dato de las variables, los cambios de límites de alarma y la configuración del archivado de tendencias deben configurarse y mantenerse dos veces —una en el PLC, otra en el SCADA. Si la dirección de memoria de una variable cambia alguna vez en el lado del PLC, el lado del SCADA debe volver a vincularse manualmente, o el resultado es un corte de comunicación o un valor desincronizado de forma silenciosa.
Planificación de tareas: ciclos de escaneo fijos frente a multitarea por segmentación temporal
Un PLC funciona mediante ejecución cíclica basada en escaneo: muestreo de entradas, escaneo de la lógica de programa, actualización de salidas y manejo de comunicaciones, en un bucle fijo de cuatro etapas. Los tiempos de escaneo suelen situarse en el rango de a (aproximadamente 1-10 ms), determinados sobre todo por cuántas líneas de código debe ejecutar el escaneo. Eso le da al PLC un determinismo temporal excelente y un rendimiento muy rápido en lógica discreta —justo lo que necesitan los enclavamientos de alta velocidad y el control secuencial.
Un DCS, en cambio, funciona con planificación multitarea, segmentada en el tiempo y dirigida por interrupciones. La lógica de control se divide en tareas periódicas con distintas prioridades de ejecución: los enclavamientos de seguridad y la lógica de alta velocidad reciben la prioridad más alta (un ciclo de 50 ms, por ejemplo), mientras que la regulación PID continua compleja, el control por desacoplamiento y los algoritmos de control avanzado de proceso (APC/MPC) se ejecutan en tareas periódicas de menor prioridad (ciclos de 200-500 ms). Ese modelo de planificación es lo que evita que una CPU se atasque o dispare un timeout de watchdog cuando está gestionando varios cientos, o varios miles, de lazos PID simultáneos en un proceso continuo de gran escala.
Redundancia: arquitectura nativa del sistema frente a complemento modular
La alta disponibilidad es la razón de ser del control de procesos, y el DCS y el PLC difieren de manera fundamental en cómo —y con cuánta transparencia— la logran.
Un DCS ha sido diseñado desde el origen para una producción ininterrumpida, 24/7/365, de modo que su redundancia es nativa a nivel de sistema. Los controladores, los módulos de alimentación, el bus de control de proceso, el bus de E/S y los canales de E/S individuales suelen construirse con conmutación en caliente (hot standby) sin fisuras. Los controladores primario y de respaldo permanecen sincronizados hasta el milisegundo a través de un enlace de espejado de memoria dedicado en hardware —estado de ejecución, variables intermedias, imagen de memoria, todo. Si el controlador primario sufre una falla de hardware o pierde alimentación, el respaldo entra en operación sin sobresaltos: sin discontinuidad en ninguna salida analógica, sin sacudida en la válvula de control, y sin código adicional de sincronización de redundancia que el ingeniero deba escribir. El votado tolerante a fallas a nivel de tarjeta y canal (esquemas 1oo2, 2oo3) suele venir integrado directamente en el hardware y en el software de configuración.
La redundancia de un PLC suele ensamblarse a partir de módulos externos de redundancia de hardware, racks de doble CPU y módulos de comunicación de redundancia dedicados. Los PLC modernos de gama media y alta pueden, sin duda, lograr una conmutación en caliente del controlador, pero cuán libre de sobresaltos resulta realmente esa conmutación, y cuánto de ella maneja la plataforma de forma transparente, depende en gran medida de la implementación específica. En una configuración típica de redundancia de PLC, los ingenieros a menudo deben configurar explícitamente los bloques de sincronización de datos, mapear las banderas de estado y, en algunos casos, gestionar ellos mismos el comportamiento de retención de módulos específicos —una tarjeta de salida analógica, por ejemplo— durante el transitorio de la conmutación.
Donde sea que esa conmutación finalmente termine, queda aguas abajo del elemento final de control propiamente dicho. Sea cual sea la arquitectura que emite la orden, la válvula de control o la bomba dosificadora que la recibe tiene su propia cuestión de dimensionamiento por separado —el Selector de Actuadores Neumáticos de este sitio cubre esa parte del panorama.
Profundidad del algoritmo de control
La biblioteca de control de proceso del DCS. Un DCS viene con una amplia biblioteca de bloques de control de proceso de orden superior, probados industrialmente. Su bloque PID integra de forma nativa la protección antiwindup, la transferencia manual/automático sin sobresaltos, la compensación feedforward, el control de razón, la ganancia adaptativa, predictores de Smith para retardo fijo y algoritmos de desacoplamiento multivariable. Configurar un PID en cascada o un PID feedforward-feedback es, en gran medida, cuestión de conectar entre sí dos pines de bloques de función; el algoritmo gestiona internamente el seguimiento de estado maestro/esclavo y la lógica de conmutación manual/automático.
Cómo implementa el PLC la misma matemática. Un PLC también ofrece un bloque de función PID básico, pero más allá de eso, típicamente solo calcula la fórmula PID estándar en tiempo discreto:
En cuanto el proceso necesita desacoplamiento multivariable, superposición feedforward o conmutación de estado manual/automático, el ingeniero debe escribir código adicional en texto estructurado (ST) para manejar a mano el enclavamiento del estado integral, el recorte (clamping) de salida y la gestión de variables de seguimiento (tracking). Cualquier hueco en esa lógica tiende a manifestarse como un salto brusco en la salida de control justo en la transferencia manual/automático, que la válvula de campo percibe como una sacudida repentina.
Tres dimensiones del ciclo de vida de ingeniería que deciden al verdadero ganador
Por debajo de las diferencias de arquitectura de cómputo, la “ergonomía” y la experiencia operativa cotidiana de un sistema de control a lo largo de todo su ciclo de vida de proyecto son lo que realmente decide si una elección fue correcta.
Facilidad de uso en ingeniería e implementación
La facilidad de uso tiene que ver con la velocidad de desarrollo —desde el diseño de ingeniería y la escritura de lógica, pasando por la configuración de pantallas, hasta la puesta en marcha en campo.
Para la configuración de lazos de control, la rica biblioteca de bloques de función de un DCS —antiwindup, transferencia sin sobresaltos, feedforward, control de razón, desacoplamiento multivariable, todo integrado— permite a un ingeniero configurar un lazo complejo prácticamente arrastrando conexiones entre bloques preconstruidos y completando parámetros. Un PLC, con solo un bloque PID básico disponible, exige que los ingenieros escriban código adicional en diagrama de escalera (LD) o texto estructurado (ST) para la lógica en cascada, feedforward o de desacoplamiento, manejando a mano el windup integral, la transición sin sobresaltos y la confianza ante valores atípicos —un listón de desarrollo más alto y con resultados menos estandarizados.
Para el desarrollo de HMI, un DCS es sumamente eficiente a nivel de configuración de sistema: al agregar un nuevo bloque de función de bomba o válvula en el controlador, la interfaz de operador hereda y genera automáticamente un faceplate estándar —estado de marcha, conmutador manual/automático, texto de alarma de falla, tendencia en tiempo real, todo. Un PLC, en cambio, exige “doble trabajo”: tras escribir la lógica de control en el entorno del PLC, el ingeniero debe abrir por separado el software SCADA, dibujar manualmente los gráficos de la válvula, construir manualmente el mapeo de comunicación de tags, y escribir manualmente los scripts de ventanas emergentes y la lógica de disparo de alarmas para el panel de operador.
Para la integración de skids de fabricantes de equipo original (OEM), el panorama se invierte. Como un DCS depende de una base de datos unificada y de una arquitectura de hardware particular, incorporar un tablero de control independiente proveniente de un proveedor externo de skids —un skid de bombeo de alta presión, un skid generador de ozono— tiende a ser engorroso; los datos de ese tercero normalmente deben mapearse a través de una pasarela genérica Modbus o Profinet, lo que rompe la consistencia de la base de datos nativa. Un PLC, en cambio, es intrínsecamente abierto y modular: la inmensa mayoría de los paquetes de skids OEM se construyen de forma nativa alrededor de un PLC como su controlador local, de modo que en la capa de integración a nivel de planta, los sistemas PLC pueden enlazar los paquetes de skids de distintos proveedores a través de un bus industrial común con relativamente poca fricción.
Comodidad operativa y de mantenimiento
La mantenibilidad determina directamente el tiempo medio de recuperación (MTTR) de una planta tras una falla no planificada, y cuánta operación diaria transcurre sin ninguna interrupción.
Para la programación y descarga en línea, la razón de ser de un DCS es, precisamente, no detenerse. Admite una verdadera compilación incremental en línea a nivel global y descarga sin sobresaltos: cuando un ingeniero modifica la lógica de control, reajusta un PID o agrega una nueva variable, la descarga no tiene ningún efecto sobre el estado de ejecución de la CPU del controlador —las salidas de válvula en campo permanecen estables, los lazos PID no dan saltos, y la pantalla SCADA ni siquiera parpadea en su enlace de comunicación. Un PLC moderno de gama media-alta admite la modificación en línea de algunos segmentos de código, pero cualquier cambio en la estructura de un bloque de datos, en la configuración de hardware o una reconstrucción de lógica a gran escala típicamente obliga a una descarga completa, que puede poner al PLC en un modo de parada de milisegundos a segundos, o interrumpir brevemente la comunicación con el SCADA —un riesgo real en una etapa de proceso químico o térmico de alto riesgo y funcionamiento continuo, como un evaporador MVR, donde ese tipo de interrupción puede disparar un paro de seguridad.
Para el diagnóstico y el intercambio en caliente (hot-swap), un DCS mantiene zonas estrictas de contención de fallas desde el nivel de canal, pasando por el nivel de tarjeta, hasta el nivel de bus, junto con capacidad nativa de hot-swap (RIOP). Si un canal de entrada analógica se destruye por un cortocircuito en un instrumento de campo, la limitación de corriente interna de la tarjeta y el aislamiento óptico impiden que la falla se propague a un canal vecino o al bus de backplane, y la tarjeta puede reemplazarse sin reiniciar el software. Las plataformas DCS típicamente también ofrecen registro de secuencia de eventos (SOE) a nivel de sistema conforme al estándar de gestión de alarmas ISA-18.2, con resoluciones de hasta 1 ms, lo que facilita mucho rastrear la verdadera causa inicial de un incidente. Las tarjetas de E/S distribuidas de un PLC también suelen admitir hot-swap, pero la información de diagnóstico por lo general debe extraerse mediante la llamada, por parte del ingeniero, a un bloque de función de sistema de diagnóstico dedicado (SFC/SFB) en el programa del PLC, pasando explícitamente el resultado interpretado al SCADA. Si esa rutina de diagnóstico nunca se escribió, una falla a nivel de tarjeta en campo puede aparecer en el SCADA sin más precisión que una “pérdida de comunicación” abstracta.
Escalabilidad y preparación para el futuro
La capacidad de actualización determina cuánto conserva su valor un activo de automatización, y cuánto cuesta una renovación tecnológica, a lo largo de un ciclo de vida de planta de 10-20 años.
Para la compatibilidad hacia atrás y el ciclo de vida, los proveedores de DCS, como categoría, se comprometen con un estándar inusualmente estricto de compatibilidad hacia adelante —los ciclos de vida típicos del sistema van de 15-20 años o más. Un controlador DCS de nueva generación con frecuencia puede montar una tarjeta de E/S instalada veinte años antes, y un proyecto de ingeniería antiguo puede migrar hacia adelante con poca disrupción. Esa evolución fluida reduce de manera significativa el costo de capital y el riesgo técnico de las futuras actualizaciones de automatización de una planta. El ciclo de iteración de un PLC es más corto —los ciclos de vida típicos de hardware van de 8-12 años— y los componentes electrónicos de grado de consumo que contiene se descontinúan más rápido. Un salto generacional de una familia de plataformas PLC a su sucesora suele venir acompañado de un cambio integral en el protocolo de bus, el software de programación y el backplane de hardware, de modo que migrar un programa habitualmente requiere herramientas de conversión dedicadas, o reescribir la lógica directamente.
Para la expansión de hardware y la topología de red, la expansión de un DCS suele construirse alrededor de una arquitectura de red de proceso fija y redundante: agregar una nueva estación remota de E/S permite que el sistema asigne automáticamente una dirección de nodo y complete la configuración de enrutamiento, lo cual es estandarizado pero viene con restricciones de topología bastante rígidas. Un PLC tiene una flexibilidad de red industrial considerablemente mayor, con soporte simultáneo para Profinet, EtherNet/IP, Modbus TCP, EtherCAT y otros protocolos. Cuando se expande un sistema pequeño o mediano, o cuando hay que incorporar un dispositivo heterogéneo de terceros —un variador de frecuencia, un analizador inteligente de calidad de agua, un robot—, la adaptabilidad de red de un PLC es la opción más ágil.
Dieciséis dimensiones, lado a lado
| Dimensión | DCS | PLC |
|---|---|---|
| Filosofía de diseño | Centrada en el proceso, control de proceso continuo | Centrada en la máquina, control de lógica discreta |
| Arquitectura de base de datos | Única base de datos global unificada | Base de datos de controlador independiente, mapeada al SCADA vía OPC/driver |
| Tipo de control dominante | Analógico, lazos PID complejos, desacoplamiento multivariable | Discreto/digital, lógica de alta velocidad, control secuencial |
| Ejecución de la lógica | Planificación multitarea por segmentación temporal, tareas periódicas | Ejecución cíclica de escaneo de ciclo fijo |
| Tiempo de escaneo/respuesta | Ciclo típico: 50 ms – 500 ms | Muy rápido: 1 ms – 10 ms |
| Facilidad de uso en ingeniería | Rica biblioteca nativa de algoritmos; faceplates y alarmas de HMI autogenerados | Biblioteca de algoritmos básica, requiere programación en escalera/ST; HMI configurado por separado |
| Comodidad operativa/mantenimiento | Descarga incremental en línea global sin sobresaltos; aislamiento nativo de fallas a nivel de canal | Las descargas profundas pueden forzar una parada; el diagnóstico requiere bloques de función codificados a mano |
| Redundancia | Redundancia total nativa a nivel de sistema (alimentación, controlador, red, E/S), sin sobresaltos | Redundancia opcional modular, requiere módulos dedicados y sincronización a nivel de código |
| Capacidad PID analógica | Biblioteca rica (feedforward, cascada, predictor de Smith, MPC), fuerte desacoplamiento | Bloque PID básico, el desacoplamiento multivariable es comparativamente difícil |
| HMI | Integración nativa profunda; faceplates de válvula/bomba/PID autogenerados | Software SCADA independiente, pantallas y comunicación de tags construidas por separado |
| Ciclo de vida y compatibilidad | 15-20+ años, fuerte compatibilidad de hardware hacia atrás, actualizaciones fluidas | 8-12 años, iteración más rápida, la migración generacional requiere conversión/reconfiguración |
| Eficiencia de desarrollo de ingeniería | Muy rápida para procesos continuos de gran escala, alta reutilización, cambios en línea sin sobresaltos | Eficiente para lógica de dispositivos discretos; los procesos grandes requieren un extenso mapeo manual de tags |
| Topología de red y bus | Ethernet industrial híbrida cerrada-y-abierta, redes en anillo/duales de alta redundancia | Muy abierta, admite Profinet, EtherNet/IP, Modbus TCP, y otros |
| Aislamiento de fallas | Zonas estrictas de contención de fallas a nivel de controlador y bus de E/S | Una falla en una sola tarjeta puede propagarse a otros módulos a través del bus interno de backplane |
| Escala típica | Cantidad de E/S superior a ~2,000 puntos, alta proporción analógica (>30%), sistemas a escala de planta | De algunas decenas a varios miles de puntos, distribución flexible, predominantemente discreto |
| CAPEX inicial | Más alto (costos de controlador y licenciamiento de software) | Más bajo (fuerte relación precio-desempeño de hardware, ventaja clara para sistemas pequeños) |
Ajustar la arquitectura al segmento de tratamiento de agua
Distintos procesos de tratamiento de agua tienen naturalezas físicas y químicas fundamentalmente diferentes, y eso es lo que en realidad determina la arquitectura de control adecuada.
El tratamiento municipal de agua potable y residual está geográficamente disperso y dominado por señales discretas, de modo que funciona con PLC en red bajo una capa central de SCADA. Una planta municipal de tratamiento de aguas residuales abarca estaciones de bombeo, rejas de barras, desarenadores, reactores biológicos —A²/O, MBR, o de otro tipo—, clarificadores secundarios y deshidratación de lodos. La planta está geográficamente dispersa, con un alto grado de autonomía en cada subestación; el equipo (bombas, rascadores, válvulas) está dominado por el control de estado discreto, y la lógica de control es en su mayoría conmutación secuencial basada en nivel o en tiempo. Los lazos PID (control de OD en la cuba de aireación, control de la tasa de dosificación) son relativamente pocos y en gran medida independientes entre sí. La arquitectura casi universal es un sistema central de monitoreo SCADA sobre subestaciones PLC de campo regionales: cada área de proceso tiene su propio tablero PLC que gestiona los enclavamientos locales de equipo, mientras el SCADA agrega los datos mediante una Ethernet industrial —una estructura con una clara ventaja tanto en costo de capital como en flexibilidad de disposición de red.
Las aguas residuales industriales de alta dificultad y la descarga líquida cero constituyen un proceso termodinámico y químico fuertemente acoplado, y ese es terreno del DCS. En los sistemas ZLD construidos en torno a aguas residuales de la industria carboquímica, petroquímica o de desulfuración de gases de combustión, la cadena de proceso recorre el pretratamiento, la concentración por membranas y la evaporación-cristalización térmica (MVR o evaporación de múltiple efecto). El nivel del evaporador, la presión del vapor secundario, el caudal de la bomba de circulación y la sobresaturación del licor madre interactúan de forma fuerte y dinámica entre sí. Las E/S analógicas suelen representar entre el 30% y el 50% del total de E/S, con un gran número de lazos de control en cascada, feedforward y de desacoplamiento. Si un controlador queda fuera de línea o un lazo PID comienza a oscilar, el evaporador puede incrustar sales (scaling) o la bomba de circulación forzada puede cavitar y obstruirse —y el costo de una parada, limpieza y reinicio es severo. Un DCS nativo resulta aquí prácticamente obligatorio: su biblioteca de algoritmos de desacoplamiento, su planificación multitarea determinista, su base de datos global unificada y su modificación en línea sin sobresaltos son lo que mantiene a un sistema ZLD funcionando de forma continua en estado estacionario.
El agua ultrapura (UPW) para semiconductores exige control de impurezas a nivel de partes por billón y una resistividad que se aproxima al límite teórico de . Un sistema UPW se construye a partir de un gran número de skids OEM prefabricados y densamente empaquetados —filtración de arena, RO, EDI, lecho mixto de pulido— y necesita un monitoreo de calidad del agua de frecuencia extremadamente alta; en el momento en que la calidad del agua se sale de especificación, una válvula debe cerrarse en milisegundos para proteger la línea de obleas aguas abajo. La arquitectura casi universal es un híbrido: skids PLC distribuidos de alta velocidad más un DCS o SCADA central de monitoreo. Cada skid es desarrollado y puesto en marcha de forma independiente por su proveedor OEM en torno a un PLC, lo que asegura eficiencia de entrega modular y una respuesta de protección a escala de milisegundos; la capa de monitoreo central se unifica luego en el DCS de la planta o en un gran sistema SCADA, aportando programación del balance hídrico y trazabilidad de calidad a escala de planta. El artículo sobre contaminación traza en agua ultrapura para semiconductores de este sitio profundiza en el lado de la pureza de ese panorama.
El tratamiento de aguas residuales con metales pesados y de tipo especial —efluentes mineros, metalúrgicos y de galvanoplastia con arsénico, antimonio, plomo, cadmio o cianuro— exige dos cosas a la vez: una dosificación química extremadamente precisa (ajustada de forma continua en función del ORP, el pH y la concentración de metales pesados en el influente, un lazo de control que la Calculadora de Dosificación Química de este sitio puede ayudar a dimensionar) y enclavamientos de seguridad extremadamente confiables, ya que una descarga fuera de especificación debe cortarse y desviarse a una cuenca de contención de emergencia en cuestión de segundos. La arquitectura típica es un PLC grande de doble redundancia en caliente, o un micro-DCS, elegido específicamente por su fuerte procesamiento analógico junto con la redundancia a nivel de hardware.
Tres casos de campo
Caso 1: ZLD de alta salinidad y cristalización por separación de sales en la industria carboquímica
El proyecto de descarga líquida cero de un gran complejo carboquímico, dimensionado en 12,000 m³/d, trata un influente con aproximadamente 42,000 mg/L de TDS (incluyendo sulfato en torno a 17,000 mg/L y cloruro en torno a 11,000 mg/L) mediante un tren de nanofiltración de separación de sales en dos etapas, cristalización evaporativa de sulfato de sodio, concentración por RO y cristalización evaporativa de cloruro de sodio —recuperando finalmente sulfato de sodio con una pureza y cloruro de sodio con una pureza , con una fracción de sal mixta de apenas alrededor del 10%.
Al principio del proyecto, se puso a prueba una opción de PLC+SCADA frente a un DCS, cara a cara. En la etapa de evaporación-cristalización por circulación forzada MVR, el DCS mostró tres ventajas decisivas:
Desacoplamiento termodinámico complejo. El nivel del cristalizador, la presión de vapor y el caudal de la bomba de circulación interactúan fuertemente. El DCS ejecutó un algoritmo feedforward-cascada a través de su módulo integrado de control avanzado de proceso (APC):
funcionando en estado estacionario con un ciclo de control de 200 ms y manteniendo la sobresaturación de cristalización con precisión dentro de la zona metaestable. El sistema PLC probado en paralelo, al carecer de un algoritmo de desacoplamiento nativo, mostró una severa oscilación (hunting) entre lazos PID, disparando sobrepresiones frecuentes en el evaporador.
Cambios en línea sin sobresaltos. Durante la fase de escalado y depuración (debugging), la lógica de razón de dosificación necesitaba ajustes frecuentes. La compilación incremental global en línea del DCS surtió efecto sin fisuras, sin ninguna perturbación en ninguna salida PID. En la prueba con el PLC, el intento de descargar un bloque de datos modificado disparó una breve desconexión del SCADA, y la válvula de dosificación cayó momentáneamente a cero.
Aislamiento de hardware a nivel de canal. Durante la operación, un cortocircuito en el densímetro del licor madre provocó un reflujo a alta presión. El aislamiento de canal de la tarjeta del DCS logró bloquear la propagación de la falla; el controlador retuvo automáticamente su salida previa, generó una alarma y permitió reemplazar la tarjeta averiada en caliente, sin ninguna parada (RIOP nativo).
Caso 2: sistema de agua ultrapura de una fábrica de semiconductores
El sistema UPW de una fábrica de obleas de 12 pulgadas, dimensionado en 15,000 m³/d, funciona con una arquitectura de “paquetes de skids PLC más SCADA/DCS central”.
Protección a escala de milisegundos. Cuando un analizador de TOC en línea, en el punto de uso, detecta un incumplimiento de calidad del agua (por encima de aproximadamente 2 ppb), el PLC local del skid ejecuta una rutina fija de interrupción terminal cíclica de 5 ms, completando la acción de una válvula de corte de tres vías en 40 ms —bloqueando con éxito que agua fuera de especificación llegue jamás a la línea de producción.
Entrega modular OEM. Dieciocho skids independientes (filtración de arena, RO, EDI, lecho mixto) fueron cada uno escritos y puestos en marcha internamente por distintos proveedores utilizando un PLC, y luego conectados al sistema central en sitio mediante los protocolos estándar Profinet y OPC UA —comprimiendo notablemente el cronograma de construcción de la planta.
Caso 3: planta municipal de tratamiento de aguas residuales de 100,000 m³/d, modernización inteligente
Una planta municipal de tratamiento de aguas residuales de 100,000 m³/d reconstruyó su configuración original de “siete subestaciones PLC independientes más SCADA” en un sistema de control híbrido unificado.
Distribución de controladores. Antes de la modernización: siete subestaciones PLC independientes, sin comunicación directa entre controladores. Después: una arquitectura de control distribuido integrada sobre una plataforma unificada.
Gestión de bases de datos. Antes: siete bases de datos PLC separadas más una base de datos SCADA, cada una configurada de forma independiente. Después: una única base de datos de ingeniería centralizada y unificada.
Control de OD en aireación. Antes de la modernización, el OD se mantenía mediante un simple control de encendido/apagado por temporización, oscilando en un rango de aproximadamente . Tras la modernización, el OD pasó a funcionar con PID feedforward-cascada, siguiendo:
manteniendo el OD estable dentro de aproximadamente respecto del punto de consigna.
Mantenimiento y expansión. Antes de la modernización, cambiar una variable exigía configurar ambos extremos y una breve parada para la descarga; después, la planta admite descarga global en línea sin sobresaltos, y el mantenimiento resulta considerablemente más sencillo.
Energía. Tras la modernización, el consumo energético general de los sopladores cayó un 12%, y el consumo de dosificación cayó un 8%.
Un modelo cuantitativo de decisión
La elección entre DCS y PLC no debería reducirse a una preferencia subjetiva: puede puntuarse directamente contra los parámetros del proyecto. Definamos un índice de selección :
donde cada parámetro se define como sigue:
- : proporción de E/S analógicas (asignar 1 si es mayor al 30%, en caso contrario 0).
- : número de lazos PID complejos/en cascada/desacoplados (asignar 1 si es mayor a 30 lazos, en caso contrario 0).
- : necesidad de consistencia global de datos y de modificación en línea sin sobresaltos (asignar 1 si el requisito es fuerte, 0 si no existe).
- : costo de una interrupción de la producción continua (asignar 1 si las pérdidas por parada son muy altas, 0 si el tiempo de inactividad es tolerable).
- : proporción de equipos de skids OEM independientes de terceros (asignar 1 si la participación de skids supera el 50%, en caso contrario 0).
- : coeficientes de ponderación (recomendado: ).
Regla de decisión:
- Si : se recomienda firmemente un sistema DCS.
- Si : se recomienda firmemente una arquitectura PLC en red + SCADA.
- Si : se recomienda un sistema de control híbrido (Hybrid DCS/PAC).
Costo total de propiedad
El costo total de propiedad (TCO) combina el gasto de capital (CAPEX) y el gasto operativo (OPEX):
Cómo evoluciona el balance de costos. En la compra inicial, los costos de hardware y de licenciamiento de software de una solución PLC+SCADA suelen situarse entre un 30% y un 50% por debajo de los de un DCS, y esa ventaja de CAPEX resulta especialmente marcada en proyectos pequeños y medianos. Durante la ingeniería y la puesta en marcha, en procesos complejos e intensivos en variables analógicas como el ZLD, la base de datos global y la biblioteca de algoritmos nativa de un DCS pueden acortar el tiempo de puesta en marcha en campo en aproximadamente un 40%, reduciendo el costo de mano de obra de ingeniería. A lo largo de una vida útil operativa de 10-15 años, la descarga en línea sin sobresaltos de un DCS, el aislamiento de fallas a nivel de canal, la compatibilidad hacia atrás fluida y la capacidad de optimización de proceso (ahorro energético, reducción de consumo) recortan drásticamente las pérdidas por tiempo de inactividad y el costo de operación y mantenimiento —y, en la práctica, el costo total de propiedad de un DCS típicamente cae por debajo del de un sistema PLC que requiere reconfiguraciones frecuentes en algún punto alrededor de la marca de 5-7 años.
Conclusión
En el amplio panorama de la automatización del tratamiento de agua, el DCS y el PLC no son tanto competidores como dos arquitecturas arraigadas en genes técnicos distintos, cada una realizando un trabajo que la otra no puede reemplazar:
La fortaleza central del PLC es la eficiencia de la lógica discreta, el determinismo temporal y la agilidad modular. En el suministro y drenaje municipal de agua, en las subestaciones de plantas de tratamiento de aguas residuales y en los skids independientes de agua ultrapura, una arquitectura PLC más SCADA es la opción más rentable y de despliegue más flexible.
La fortaleza central del DCS es la continuidad del control de proceso, la consistencia global de datos y la tolerancia a fallas de alta disponibilidad. En las aguas residuales industriales de descarga líquida cero, la evaporación-cristalización y otros procesos térmicos y químicos complejos, el DCS es la herramienta que mantiene a una planta completa funcionando de forma segura, estable y continua.
Para los futuros proyectos de automatización del tratamiento de agua, la selección del sistema debería dejar de lado cualquier sesgo hacia una marca de hardware en particular, mirar a través de ella hacia la naturaleza física y química del proceso mismo, y encontrar el mejor equilibrio entre facilidad de uso en ingeniería, mantenibilidad, capacidad de actualización futura y costo total de propiedad.
Lecturas adicionales
- International Society of Automation, ISA-18.2 — Management of Alarm Systems for the Process Industries — la referencia normativa para el registro de secuencia de eventos y las prácticas de gestión de alarmas discutidas más arriba.
- International Electrotechnical Commission, IEC 61131-3 — Programmable Controllers, Part 3: Programming Languages — el estándar rector para la programación de PLC en diagrama de escalera y texto estructurado.
- International Electrotechnical Commission, IEC 61508 — Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems — la referencia fundacional para las consideraciones de enclavamiento de seguridad y SIL en aplicaciones de dosificación y enclavamiento de alto riesgo.
- International Society of Automation, ISA-95 — Enterprise-Control System Integration — el marco normativo para la arquitectura de datos entre los sistemas de control de planta y los sistemas empresariales.