Agenda llamada
INSIGHTS · OPERACIÓN

Mantenimiento predictivo en CRAH/CRAC: del ΔP del filtro al runbook ejecutado.

El predictivo en HVAC de sala blanca no necesita inteligencia artificial avanzada; necesita las señales correctas, modelos interpretables y un ciclo cerrado que termine en una orden de trabajo, no en un dashboard.

Publicado15 de abril de 2026Lectura13 minAutorVertiko Solutions

01 Por qué predictivo y no reactivo

El mantenimiento de CRAH y CRAC en data centers mexicanos suele estar atrapado entre dos esquemas que no funcionan: el correctivo (esperar a que falle) y el preventivo calendarizado (cambiar filtros cada 90 días "porque toca"). El primero es caro en SLA y en riesgo térmico; el segundo es caro en refacciones desperdiciadas y en horas-hombre que sub-optimizan refacciones que todavía servían.

El predictivo bien hecho no es ciencia ficción: es leer las señales correctas con la frecuencia correcta, modelar la degradación con matemática modesta y disparar una orden de trabajo cuando el patrón indica que la falla está a 7-30 días. Para HVAC de sala blanca, las señales relevantes son pocas y el modelo es interpretable.

Lo que aporta el predictivo respecto al preventivo

  • Ahorro en refacciones — un filtro promedio cambiado por delta-P real dura un 30-60 % más que el cambiado por calendario, dependiendo de calidad de aire del sitio.
  • Reducción del MTTR — cuando la pieza llega al sitio antes de que el equipo falle, el cambio se programa en ventana, no en madrugada.
  • Menor degradación acumulada — un compresor que opera durante semanas con un subíndice de degradación no detectado quema eficiencia. Detectarlo a tiempo recupera 3-5 % de eficiencia.

02 Las señales que sí predicen falla

En un CRAH/CRAC moderno hay docenas de variables disponibles. La experiencia operativa indica que un pequeño subconjunto concentra casi toda la señal predictiva:

ComponenteVariableFrecuenciaModo de falla detectable
FiltrosDelta-P de aire entre filtro limpio y sucio1 minSaturación, ruptura, sello defectuoso
Compresor scrollCorriente, presión de descarga, sobrecalentamiento1 minPérdida de refrigerante, scroll desgastado, contactor
Ventilador ECVelocidad demandada vs real, corriente, vibración1 minRodamiento, desbalance, falla de driver
Bomba de condensadosCiclos por hora, corriente pico5 minAtascamiento, falla de check valve
Sensor de humedadComparación con sensor redundante1 minDeriva del sensor
Válvula de expansión electrónicaApertura vs setpoint de superheat1 minAtascamiento, sensor de superheat fuera

Es deliberadamente corto. Cualquier intento de predecir falla con 80 variables sin priorizar termina en falsos positivos y en operadores que ignoran las alertas.

03 Caso 1: el delta-P del filtro

El caso más claro de predictivo y el que aporta ROI más rápido. La física es elemental: un filtro limpio tiene una caída de presión nominal de fabricación; conforme se satura, la caída crece. Cuando rebasa el máximo del fabricante, dos cosas malas pasan en paralelo: el ventilador trabaja más (consume más energía) y el flujo de aire baja por debajo del set de diseño (sube la temperatura de retorno).

El modelo

No hace falta un modelo estadístico sofisticado. Un ajuste exponencial sobre los últimos 30-60 días de delta-P versus tiempo predice con exactitud aceptable la fecha en que se cruzará el umbral crítico. La regla en producción es: cuando la proyección cruza el umbral en menos de 14 días, se dispara la orden de trabajo. Cuando cruza en menos de 5 días, la orden se escala.

Lo que se debe ajustar por sitio

  • Calidad de aire — un data center cerca de obra civil o de zona industrial mexicana satura filtros en 30-60 días. Uno con sala de filtración primaria y MERV adecuado puede durar 6 meses.
  • Tipo de filtro — bolsas, paneles plisados, HEPA terminal. La pendiente de saturación es muy distinta entre ellos y el modelo necesita conocer la familia.
  • Setpoint de ventilador — con ventiladores EC, el sistema compensa subiendo RPM. La señal combinada (delta-P + RPM) es más confiable que delta-P solo.

04 Caso 2: el compresor scroll

En CRAC con compresor scroll, las fallas predominantes son tres: pérdida lenta de refrigerante por sello, desgaste mecánico del scroll y falla de contactor por ciclos. Cada una tiene una firma reconocible si se tienen las señales correctas.

Pérdida de refrigerante

Se manifiesta como un superheat creciente sostenido durante días, una caída gradual de la capacidad y un ciclo de demanda más frecuente. Un modelo que monitorea la pendiente del superheat semanal detecta la fuga semanas antes de que el equipo entre en falla por bajo refrigerante. En la práctica mexicana esto importa especialmente porque el refrigerante R-410A y los HFO de nueva generación no son baratos ni inmediatos de conseguir.

Desgaste de scroll

Se manifiesta como ruido y vibración característicos más una eficiencia decreciente del ciclo (kWh por kW de capacidad). Si se tiene acelerómetro de bajo costo en la carcasa del compresor, la firma espectral cambia varias semanas antes de la falla crítica.

Contactor

La señal más simple y la más subutilizada: contar arranques y paradas por hora. Un compresor que está ciclando más de lo previsto por diseño tiene una causa raiz (lógica de control mal calibrada, carga térmica fluctuante, bypass mal abierto). Resolver la causa raiz vale más que cambiar el contactor.

05 Caso 3: el ventilador EC

Los ventiladores EC (electronically commutated) son hoy el estándar en CRAH modernos por su eficiencia y por que entregan telemetría digital nativa. Las fallas previsibles son tres: rodamiento desgastado, desbalance por suciedad acumulada y falla de driver.

Rodamiento

La señal clásica es vibración creciente. En ausencia de acelerómetro, una buena proxy es la corriente media a velocidad constante: cuando un rodamiento empieza a fallar, requiere más corriente para entregar el mismo flujo. Una tendencia ascendente sostenida de la corriente media de un ventilador EC sobre 60-90 días es señal de orden de trabajo programada.

Desbalance

En sitios mexicanos con polvo elástico (cementeras, minería, agroindustria cercana) las hélices acumulan material y se desbalancean. Eso aparece como vibración a frecuencia 1x y como ineficiencia. Limpieza con calendario dinámico basado en este indicador supera con creces al calendario fijo.

Driver EC

Los drivers EC fallan por electrolito y por sobrecalentamiento. El síntoma típico es una discrepancia creciente entre la velocidad demandada y la velocidad real. Monitorear esa brecha como variable derivada da una alerta de 1-2 semanas antes de la falla dura.

06 Del modelo al runbook ejecutado

El error más común de los proyectos de predictivo es quedarse en el dashboard. Una alerta "el filtro de CRAH-3 va a saturarse en 8 días" no es valor en sí misma; lo es solamente cuando dispara una cadena ejecutable.

La cadena completa

  1. Detección — el modelo dispara un evento con contexto: equipo, variable, proyección, severidad.
  2. Verificación automática — un agente cruza con condiciones operativas (no es alta carga estacional), descarta el falso positivo si aplica.
  3. Generación de orden de trabajo — el sistema crea OT en el CMMS con el runbook adjunto, el inventario de partes verificado y la ventana de mantenimiento sugerida.
  4. Aprobación humana — el Facility Manager aprueba la OT en un click. Esto sigue siendo humano por diseño.
  5. Ejecución con runbook — el técnico recibe la OT con pasos numerados, fotos del equipo, checklist de seguridad y lockout-tagout.
  6. Cierre verificable — al cerrar la OT, el sistema verifica con el BMS que la variable volvió al rango esperado.

Esto es lo que distingue un dashboard de un sistema de operación. Los runbooks no son PDFs; son procedimientos codificados con variables que el sistema valida.

El detalle que la mayoría olvida. El feedback loop. Si el modelo predijo falla a 8 días y el filtro aguantó 15, el modelo necesita aprender de ese sesgo. La calibración continua es la diferencia entre un sistema que mejora y uno que se vuelve ruido en 6 meses.

07 Cómo se mide que funciona

Un programa de mantenimiento predictivo se evalúa con cuatro métricas, no con cien:

  • Precisión de las alertas — de cada 10 alertas, cuántas terminaron en una intervención útil. Una precisión por debajo del 60 % en los primeros 90 días es esperable; debajo del 60 % al año es un problema de modelo.
  • Recall — de cada 10 fallas reales, cuántas fueron predichas con anticipación útil. Para HVAC, anticipación útil son 7 días o más.
  • Reducción del MTTR — el tiempo medio de reparación cuando una falla ocurre, comparado contra la línea base del año anterior. Una reducción del 30-50 % es realista en año uno.
  • Costo total de mantenimiento — suma de refacciones, horas-hombre y tiempo fuera de banda operativa. El predictivo bien hecho lo baja entre 15 y 30 % en año uno.

Lo que estas métricas no incluyen pero el negocio sí agradece: el tiempo del Facility Manager liberado para hacer ingeniería en vez de apagar incendios. Eso no aparece en hoja de cálculo pero suele ser el cambio que más notan los equipos a los 6 meses.

El error clásico de implementación

El error más caro que vemos en operadores que arrancan programas predictivos es querer cubrir todo el sitio el primer día. La curva de aprendizaje del equipo, del proveedor y del modelo es real, y meter 30 CRAH al programa simultáneamente genera tantas alertas que el operador termina ignorándolas y el programa se descredita en 90 días.

La trayectoria que sí funciona es escalonada: piloto en 2-3 equipos críticos del mismo tipo durante 60-90 días, ajuste de umbrales con datos reales del sitio, ampliación a una sala completa, después a otro tipo de equipo (compresores después de filtros, por ejemplo) y así sucesivamente. Llevar un programa predictivo a cobertura completa toma entre 9 y 18 meses en un sitio mediano. Cualquier promesa de cobertura en 30 días debería generar suspicacia.

Qué se necesita en infraestructura para arrancar

El requisito mínimo es muestreo a 1 minuto o menos en las variables relevantes, almacenamiento de al menos 12 meses de historia, y un sistema de tickets/CMMS que pueda recibir órdenes de trabajo programaticamente. Lo que no es requisito mínimo es una plataforma de IA cara; los modelos que mejor funcionan para HVAC son interpretables y livianos. La ingeniera necesaria es entender la física del equipo, no levantar un clúster GPU.

Quien gana cuando funciona

Vale terminar con quien se beneficia, porque sin alineación el programa no sobrevive. El Facility Manager gana noches sin llamadas. El CFO gana línea de costo más baja en refacciones y energía. El cliente final gana SLA estable. El técnico de campo gana órdenes de trabajo planeadas en lugar de emergencias. El único que pierde algo es el proveedor de mantenimiento que cobraba por visitas: ahí conviene renegociar el contrato a base de disponibilidad medida y no de visitas calendarizadas. Esa renegociación suele ser más política que técnica.

¿Operas infraestructura crítica?

Cuéntanos qué corres en una llamada técnica de 30 minutos sin slides. Diagnóstico, no demo.

Agenda llamada técnica →
Escríbenos