El patrón que se repite
En más de 20 años ejecutando proyectos en plantas industriales, hemos visto el mismo escenario con variaciones menores: una planta que operaba bien durante meses o años se detiene sin previo aviso. El equipo de mantenimiento busca el componente defectuoso. El proveedor del PLC revisa el programa. El proveedor de instrumentación verifica sus sensores. Operaciones culpa al sistema de control. Control culpa a los instrumentos. Nadie encontró nada "roto".
Y sin embargo, la planta paró.
El problema casi nunca está en un componente específico. Está en la arquitectura del sistema en cómo fueron diseñadas las interacciones entre operación, instrumentación y automatización. O más precisamente: en que esas interacciones nunca fueron diseñadas como sistema.
Tres disciplinas, tres silos
La industria de procesos tiende a fragmentar el diseño y operación de sus sistemas en tres disciplinas que raramente se hablan entre sí:
Operación conoce el proceso las variables críticas, los límites que no se pueden cruzar, los procedimientos que funcionan. Pero frecuentemente no conoce con detalle cómo el sistema de control implementa esos procedimientos, ni qué supuestos hicieron los programadores.
Instrumentación selecciona, instala y calibra los sensores y actuadores. Pero la selección de instrumentos frecuentemente se hace sin considerar cómo los lazos de control los van a utilizar, ni qué pasa cuando un instrumento falla en condiciones de proceso crítico.
Automatización programa el sistema de control basándose en una descripción funcional que a veces está incompleta, a veces es ambigua, y casi siempre fue escrita por alguien que no conoce los detalles del proceso real.
En el 80% de los proyectos de migración que hemos diagnosticado, el sistema de control original tenía supuestos no documentados sobre el comportamiento de los instrumentos supuestos que el equipo de operación tampoco conocía, pero que eran críticos para que el proceso funcionara.
El costo real de la fragmentación
Cuando estas tres disciplinas trabajan en silos, los problemas no aparecen inmediatamente. Un sistema fragmentado puede operar correctamente durante meses en condiciones normales. Los problemas emergen cuando el sistema enfrenta condiciones fuera del rango esperado: una variación en la calidad de la materia prima, un cambio en la temperatura ambiente, un componente que empieza a degradarse gradualmente.
En esas condiciones, los supuestos no documentados empiezan a fallar. El sistema de control hace algo que operación no espera. Los instrumentos reportan valores que el control interpreta de una manera que instrumentación no anticipó. La planta para.
Y como nadie es responsable del sistema completo, nadie puede diagnosticar el problema con precisión.
Un ejemplo real: sistemas CIP en industria láctea
Los sistemas de limpieza CIP en plantas lácteas son un ejemplo ilustrativo. Un CIP típico involucra múltiples disciplinas trabajando en secuencia: válvulas de proceso controladas por el sistema de automatización, sensores de conductividad y temperatura que verifican la efectividad de la limpieza, y procedimientos operativos que definen cuándo una línea está limpia.
Cuando estas tres partes están diseñadas de forma integrada, el sistema funciona con precisión. Cuando están fragmentadas, los problemas son sutiles pero costosos: lotes rechazados, retrabajos de limpieza que consumen tiempo de producción, y eventualmente un paro no programado cuando el sistema llega a un estado que nadie anticipó.
La pregunta que hay que hacer
Cuando una planta evalúa un proyecto de automatización, la pregunta habitual es: "¿Qué tecnología vamos a usar?"
La pregunta que rara vez se hace es: "¿Quién va a ser responsable de que operación, instrumentación y automatización funcionen como un sistema?"
La respuesta honesta, en la mayoría de los casos, es: nadie. El integrador entrega el sistema de control. El proveedor de instrumentación entrega los instrumentos. Operaciones recibe todo y trata de hacer que funcione junto. Esa brecha de responsabilidad es donde viven la mayoría de los problemas que llevan a paros no programados.
Arquitectura antes de tecnología
La solución no es técnica en primera instancia. Es de arquitectura de sistema: definir antes de seleccionar equipos cómo deben interactuar las tres disciplinas, qué supuestos se están haciendo, y quién es responsable de validar que esas interacciones funcionen en condiciones reales.
- El diseño del sistema de control parte del proceso, no de las especificaciones del fabricante del PLC.
- La selección de instrumentación considera cómo el control va a usar esa señal en condiciones críticas.
- La descripción funcional define exactamente qué debe hacer el sistema en cada condición posible.
- La validación no termina cuando el sistema arranca en condiciones normales termina cuando se ha probado en los extremos reales del proceso.
La continuidad operacional depende de la arquitectura del sistema completo, no de un equipo aislado. Integrar operación, instrumentación y automatización bajo una sola arquitectura con un solo equipo responsable del conjunto es la diferencia entre un sistema que opera y uno que simplemente funciona.
En la práctica
En los proyectos donde hemos aplicado este enfoque desde plantas de tratamiento de agua hasta ingenios azucareros, desde tequileras hasta plantas lácteas la diferencia es consistente: los proyectos se entregan en plazo, los arranques son predecibles, y los paros no programados en el primer año son la excepción, no la regla.
La planta para cuando nadie esperaba porque nadie diseñó el sistema para que no parara. La solución empieza por cambiar esa pregunta.