Cuando una falla lo derrumba todo

El Gobierno de Colombia había intentado antes certificar un laboratorio de bioseguridad. Dos años atrás, el intento con una empresa internacional reconocida en control no logró la certificación: el sistema no pasó las pruebas, y ese laboratorio no pudo operar como bioterio. Este era el segundo intento, con un laboratorio nuevo, y tenía mucha visibilidad. No podían repetir el error.

Me asignaron al proyecto con información limitada. El diseñador del sistema de climatización compartió la ingeniería completa hasta el primer día en sitio. Ahí entendí el reto real: el sistema de control estaba concebido para confort ambiental, que era el expertise del equipo, pero el laboratorio requería algo diferente. No era un error de diseño sino de alcance: nadie había dimensionado desde el principio que un bioterio de bioseguridad necesita la lógica de un sistema crítico, no la de uno de confort.

El diagnóstico en el primer día

Un sistema de confort y un sistema crítico no son la misma cosa aunque controlen las mismas variables.

La diferencia está en lo que pasa cuando algo sale mal. Un sistema de confort prioriza el estado nominal: que la temperatura esté en rango, que la humedad no se desvíe. Un sistema crítico prioriza la continuidad operativa bajo falla: que cuando el sensor X deje de responder, el controlador Y tome decisiones sin depender de él. Que cuando se pierda la comunicación entre zonas, cada zona siga ejecutando su lógica de seguridad de forma autónoma. Que el sistema no solo funcione en condiciones normales, sino que resista los escenarios exactos que el proceso de certificación va a poner a prueba.

La ingeniería que recibí tenía medición. No tenía resiliencia.

La brecha no era técnica en el sentido estrecho. Era conceptual: el sistema de control no había sido modelado desde sus modos de falla, sino desde su funcionamiento esperado.

El problema real: variables interconectadas en cascada

Un bioterio de bioseguridad tiene docenas de variables interdependientes: temperatura por zona, presión diferencial entre recintos, tasas de renovación de aire, niveles de CO₂, humedad relativa, estado de compuertas de aislamiento, comunicación entre controladores, alimentación eléctrica por circuito.

El reto no era la cantidad sino la interdependencia: una falla en una variable arrastraba a las demás. Sin un modelo que representara esas conexiones, cualquier ajuste puntual podía tapar un síntoma mientras el riesgo real seguía intacto.

El primer intento no logró la certificación porque nunca se construyó ese modelo. Los controladores se diseñaron para el camino feliz y quedaron sin respuesta ante las cascadas de falla que el proceso de certificación estaba diseñado para provocar.

El rediseño: un día para cambiar la arquitectura completa

No podía modificar la ingeniería de forma incremental. Rediseñé la arquitectura de control en un día. El segundo día fue para afinar detalles.

El principio central era simple: cada modo de falla previsto en el proceso de certificación tenía que tener un plan de respaldo explícito, B, C, D si era necesario. No planes de recuperación reactivos. Planes de continuidad que el sistema ejecutara automáticamente, sin depender de intervención humana ni de que algún enlace de comunicación siguiera vivo.

Esto implicó tres decisiones de diseño que cambiaron la arquitectura de raíz.

La primera fue distribuir la lógica con autonomía por zona: cada controlador de campo tenía que poder ejecutar su lógica de seguridad de forma independiente ante pérdida de comunicación con el controlador maestro. No podía haber un punto único de falla que paralizara todo.

La segunda fue diseñar estrategias alternas de comunicación. Cuando un enlace fallaba, el sistema tenía que detectarlo y redirigir la coordinación entre zonas por una ruta alterna, sin que el operador tuviera que hacer nada.

La tercera, y la más importante, fue cambiar el criterio de validación: no "¿funciona bien en condiciones normales?" sino "¿qué pasa exactamente cuando este componente falla a mitad de operación?" Cada escenario de estrés que el proceso de certificación podía provocar tenía que tener una respuesta diseñada de antemano, no improvisada.

Como consecuencia, el alcance creció: más controladores, más tiempo. El proyecto pasó de 1 mes estimado a 3.5 meses de implementación con un equipo de cuatro ingenieros.

Las pruebas de precertificación

Con la instalación al 70%, el certificador llegó para someter el sistema exactamente a los escenarios de falla donde el primer intento no había logrado pasar. Mientras él conducía las pruebas, yo seguía programando las áreas restantes. Sabía que el sistema las iba a pasar.

Pasó todo. Sin una sola falla durante la semana de pruebas.

Al ver el rendimiento, el certificador aplicó pruebas adicionales de Nivel 3, un nivel por encima del que se exigía. El sistema las pasó también. Señaló que solo faltaría una caldera de respaldo, parte del diseño mecánico, para certificar formalmente en Nivel 3, porque el sistema de control ya tenía esa capacidad.

Terminé la implementación completa a los 3.5 meses. A partir de ahí, el laboratorio entró al año de operación que la normativa exige antes de la certificación final. Capacité de forma remota al ingeniero de planta que lo operaría. Un año después, confirmé que la certificación se logró sin inconvenientes. Para ese entonces yo ya no estaba en sitio, pero el sistema hizo el trabajo.