Control batch en química fina: por qué el cuello de botella no son las bombas ni las válvulas

La química fina española opera en 2026 con una infraestructura de control mayoritariamente instalada entre 1995 y 2012. Los equipos físicos —reactores, bombas, válvulas— han demostrado décadas de fiabilidad. El problema está en la capa que los gobierna: recetas embebidas en el código del controlador, sin modelo ISA-88, sin separación procedimental, sin datos contextualizados. Lo que en otros tiempos era una limitación tolerable se ha convertido hoy en el principal freno a la flexibilidad de campaña, la digitalización y cualquier proyecto serio de mejora continua.

Cuando una planta de química fina afronta un proyecto de modernización, la conversación suele empezar por los activos físicos: bombas más eficientes, válvulas de mayor precisión, reactores con mejor instrumentación. No es un mal punto de partida —la ingeniería de proceso tiene mucho que ganar de mejores activos—, pero en la mayoría de los casos ese no es el cuello de botella real.

El parque de equipos en química fina española es, en términos generales, sólido. Reactores de acero inoxidable y Hastelloy con décadas de operación probada, sistemas de dosificación calibrados, instrumentación fiable en campo. El problema no está en el músculo. Está en el cerebro: la arquitectura de control que orquesta esos equipos, que define cómo se ejecuta cada lote, que almacena las recetas y que —o no— produce los datos que una organización necesita para mejorar.

Ese cerebro, en la mayoría de las plantas con sistemas instalados antes de 2010, tiene una deuda arquitectónica severa que ningún proyecto de digitalización puede ignorar sin pagar las consecuencias más adelante.

La anatomía de la deuda legacy en control batch

Brecha 1: Las recetas viven en el código del controlador

En la gran mayoría de las plantas batch de química fina con sistemas instalados antes de 2010, las recetas de producción están embebidas directamente en el código del PLC o del DCS. No existen como entidades independientes. Existen como secuencias de instrucciones entrelazadas con la lógica de control del equipo: tiempos de agitación codificados en temporizadores, temperaturas de reacción en constantes del programa, secuencias de adición en ramas de ladder o bloques funcionales.

El resultado práctico es demoledor para la operación: cualquier cambio de parámetro —un tiempo de mezcla, una temperatura de consigna, una secuencia de dosificación— requiere intervenir el código de control. Eso implica un ciclo completo de ingeniería, gestión del cambio, prueba y en muchos casos re-validación parcial. Un cambio que en una arquitectura ISA-88 correcta tardaría horas puede llevar semanas. Y cuando el jefe de producción dice que "introducir un nuevo producto tarda meses", casi nunca está hablando de química: está hablando de arquitectura de control.

El problema no es la tecnología del controlador. Es que nadie le pidió en su momento que separara la receta del equipo. Eso tiene solución —pero requiere reconocer primero dónde está el problema.

Brecha 2: Los datos existen, pero no tienen contexto

La segunda brecha es menos visible pero igual de limitante. Los historians de proceso de una planta batch moderna almacenan miles de variables con resolución de segundos. Temperatura del reactor R-201, presión en el cabezal, caudal en la línea de dosificación. Está todo ahí. El problema es que esos valores no saben a qué lote pertenecen, a qué fase de receta corresponden, ni qué producto se estaba fabricando en ese momento.

Correlacionar el perfil térmico de dos lotes del mismo producto fabricados con un mes de diferencia requiere un trabajo de ingeniería de datos que, en la práctica, o se hace manualmente con hojas de cálculo o directamente no se hace. Comparar el rendimiento de campaña entre productos, detectar derivas tempranas de proceso, optimizar consignas basándose en datos históricos: todas estas iniciativas dependen de datos contextualizados que una arquitectura sin ISA-88 estructuralmente no produce.

Lo que cambia con ISA-88

La norma ANSI/ISA-88 lleva casi tres décadas resolviendo exactamente este problema. Su aportación fundamental es conceptualmente sencilla pero arquitectónicamente transformadora: separar la receta del equipo.

La receta define qué hay que hacer en un lote —la secuencia de operaciones, los parámetros de proceso, los criterios de avance entre fases. El modelo físico define qué puede hacer la instalación —qué unidades de proceso existen, qué módulos de equipos las componen, qué fases de control tiene disponibles cada módulo. En una arquitectura ISA-88 correctamente implementada, estas dos capas son independientes y se relacionan en tiempo de ejecución.

En la práctica, esto se traduce en fases reutilizables. Una fase ISA-88 es un bloque de control que encapsula una acción de proceso completa: agitar a X rpm durante Y minutos, dosificar Z kilos a un caudal controlado, elevar temperatura a W grados a una rampa definida. Una vez implementada y validada en el sistema de control, esa fase es un módulo que cualquier receta puede invocar con sus propios parámetros. El resultado: crear o modificar una receta pasa de ser una tarea de ingeniería de control a ser una tarea de proceso.

La curva de introducción de nuevos productos se acorta. La validación de cambios se delimita. La trazabilidad del lote mejora de forma estructural, porque la secuencia de ejecución queda registrada contra la receta y no como un log opaco de eventos de controlador.

El DCS como plataforma: capacidad infrautilizada

En química fina, el sistema de control distribuido sigue siendo la plataforma más adecuada para implementar ISA-88 en entornos de proceso batch complejos. Su arquitectura —con controladores distribuidos, redundancia integrada y capacidad de gestionar simultáneamente lazos de proceso continuos y lógica secuencial— está diseñada precisamente para la complejidad de un reactor batch multiproducto o una planta de síntesis con múltiples unidades.

El problema no es el DCS en sí. Es lo que se construyó sobre él. Muchos sistemas instalados en química fina tienen un DCS perfectamente capaz de gestionar recetas ISA-88 que no está aprovechando esa capacidad porque se configuró en su momento como si fuera un PLC con mejor interfaz. La lógica de secuenciación está en bloques funcionales directamente vinculados al proceso, sin el modelo procedimental que ISA-88 define.

La modernización en estos casos no requiere necesariamente nuevo hardware. Requiere rehacer la arquitectura de control sobre la plataforma existente: separar correctamente receta, lógica procedimental y lógica de control de equipo. Es trabajo de ingeniería de control especializada. El hardware ya está.

ISA-88 como condición necesaria para la digitalización real

En los últimos dos años, la digitalización industrial ha llegado a la química fina con promesas de optimización de proceso, mantenimiento predictivo y analítica avanzada de lote. Los resultados reales de estas iniciativas son, en general, decepcionantes —y el análisis de los factores de fracaso apunta consistentemente a la misma causa raíz: los datos que alimentan los modelos no tienen contexto funcional.

Un modelo de analítica entrenado sobre datos de historian sin contexto de fase ISA-88 no puede distinguir una variación de proceso relevante de un artefacto de medición. No sabe si ese pico de temperatura ocurrió durante la fase de reacción o durante el calentamiento inicial. No sabe si ese dato pertenece a un lote nominal o a uno que terminó fuera de especificación. La sofisticación del algoritmo no puede compensar la pobreza estructural del dato.

Las arquitecturas modernas basadas en Unified Namespace sobre MQTT/Sparkplug B resuelven parte de este problema publicando datos con contexto desde el origen. Pero un UNS sobre una arquitectura sin ISA-88 sigue produciendo datos sin contexto de receta. El UNS es el canal; ISA-88 e ISA-95 son el vocabulario que da significado a lo que circula por ese canal.

Sin ISA-88 correctamente implementado, el UNS solo transporta ruido semántico a mayor velocidad. La analítica procesa datos que nadie puede interpretar en clave de proceso. El gemelo digital replica un proceso que el sistema de control no sabe describir.

La secuencia no es opcional: ISA-88 primero, ISA-95 después, UNS encima, y entonces —y solo entonces— la analítica avanzada funciona sobre datos que tienen sentido industrial real.

Tres preguntas para cualquier responsable de planta

¿Dónde viven las recetas de mis productos? Si la respuesta es "en el PLC" o "en el DCS, integradas con la lógica de control", la deuda arquitectónica es real y condiciona todo lo que venga después.

¿Cuánto tarda introducir un nuevo producto o modificar una síntesis existente? Si la respuesta supera las dos semanas para un cambio de parámetros, o varios meses para un nuevo producto, el problema no es de proceso ni de equipo.

¿Puedo comparar el perfil de ejecución de dos lotes del mismo producto fabricados con un mes de diferencia? Si la respuesta es no, o "sí, pero con mucho trabajo manual", los datos no están en condiciones de soportar ningún proyecto serio de mejora basado en analítica.

Las bombas y las válvulas, en la mayoría de las plantas de química fina española, están bien. El problema es la arquitectura de control que las orquesta. Y ese problema tiene solución —pero requiere mirar al lugar correcto.

Pablo Vázquez

Consultor Senior independiente especializado en los estándares ISA-88/95 para la industria química fina y farmacéutica en España. 

----

Este artículo aparece publicado en el nº 569 de Automática e Instrumentación págs 40 a 42.