Caso de estudio: monitoreo de rectificador 48 V en data center Tier III edge

Aviso de transparencia: este es un caso ilustrativo anonimizado, construido a partir de patrones recurrentes de mercado observados en operadores de data center edge en Brasil. No corresponde a un cliente específico. Los números de MTBF, MTTR, costo evitado y el drift de 50 mV citado son valores ilustrativos basados en órdenes de magnitud típicos del sector; deben sustituirse por datos reales de campo cuando se apliquen a un cliente identificable. El objetivo de este material es demostrar la arquitectura técnica y el razonamiento de ingeniería, no declarar resultados de un caso real.

Un operador regional brasileño con 12 sitios edge Tier III en el Sudeste convivía con una alarma genérica de rectificador 48 V que volvía cada seis meses sin causa raíz. El oncall iba al sitio, encontraba el panel OK, hacía power-cycle y volvía. La sospecha era cell drift en el banco LiFePO4, sin datos granulares. Este caso reconstruye, en formato Situación–Tarea–Acción–Resultado, cómo dos AEM-60DC8 por sala, integrados al DCIM existente, transformaron una alarma ciega en mantenimiento predictivo programado.

Situación

El operador opera 12 sitios Tier III edge en el interior de SP, Vale do Paraíba y Sur de Minas Gerais. Cada sitio tiene una a tres salas técnicas, todas con el mismo patrón:

• 4 racks de equipos críticos (routers de borde, switches ToR, caché CDN, appliances).
• Dos rectificadores 48 V en paralelo redundante (N+1), salida nominal 200 A en -48 V CC.
• Banco LiFePO4 con 30 min de autonomía a plena carga, 16 celdas en serie (51,2 V nominal, 48,0 a 57,6 V) y BMS propietario.
• DCIM existente (Schneider EcoStruxure IT o Vertiv LIFE Services) con gateway Modbus TCP por sala.
• NOC remoto 24/7 en SP capital, escuadrón regional, SLA contractual de 4 h para llegada presencial.

Los rectificadores exponen solo alarmas binarias al DCIM vía contacto seco (AC fail, DC low, overtemp, general fault), sin lectura granular de tensión o corriente. El BMS del banco expone SOC y tensión de pack agregada vía Modbus, pero no tensión por celda en tiempo real.

El problema

Cada cinco a siete meses, en tres de los doce sitios, el DCIM disparaba "General Fault — Rectifier". Sin contexto. Playbook del oncall:

1. VPN al sitio, verificar telemetría.
2. La alarma era binaria — solo el bit encendido.
3. Reset remoto. En la mitad de los casos limpiaba en 30 a 90 min. En la otra mitad, persistía.
4. Si persistía, oncall iba al sitio — traslado medio 2,5 h.
5. En campo, panel normal: tensión OK, corriente equilibrada, SOC adecuado. Power-cycle y la alarma desaparecía.

En dos años, 37 ocurrencias en 12 sitios. En 23 el técnico fue al sitio sin hallar falla — viaje improductivo. En 4 se identificó celda fuera de rango tras barrido manual. En 1 el banco colapsó en descarga durante un corte de 18 min, derribando el sitio por 4 min — incidente reportable al cliente final.

La sospecha apuntaba a cell drift: celdas perdiendo capacidad o desbalanceando durante recarga rápida tras corte de AC. Pero el BMS no exponía lecturas por celda en tiempo real, y el log interno era difícil de extraer. Sin datos, no había forma de probar la hipótesis.

La tarea

Alcance validado con operaciones y finanzas:

• Instrumentar la barra DC y celdas críticas sin sustituir rectificador ni banco — parálisis vetada por SLA.
• Integrar al DCIM existente (EcoStruxure o Vertiv LIFE), sin segunda pantalla para el NOC.
• Costo objetivo por sala: hasta BRL 8.000 (~USD 1.500) en hardware (ilustrativo).
• Plazo: piloto en 30 días, replicación en los 11 sitios restantes en hasta 6 meses.
• Criterio de éxito: reducir al menos 60% los viajes improductivos en el primer semestre post-rollout.

La restricción más dura era integración sin rip-and-replace. Sustituir rectificador implicaba 4 a 6 h de parálisis y renegociación de SLA. Sustituir banco implicaba CAPEX de seis dígitos. La ingeniería necesitaba instrumentación paralela, leyendo lo que rectificador y BMS ya entregaban a la barra, sin entrar en el camino de potencia.

La solución

La arquitectura aprobada fue: dos AEM-60DC8 por sala, en roles complementarios.

Unidad A — barra de salida del rectificador A+B. Conectada a la barra -48 V principal que alimenta la regleta DC de los racks. Mide salida del rectificador A (canal 1), salida del rectificador B (canal 2), barra común tras el diodo OR (canal 3) y tensión antes y después del interruptor principal DC (canales 4 y 5). Tres canales libres para expansión.

Unidad B — banco de baterías LiFePO4. Conectada a ocho puntos de tap, muestreando celdas estratégicas: 1, 2, 3, 4 (extremo negativo, más propenso a drift), 8 y 9 (centro, baseline) y 15, 16 (extremo positivo). Un compromiso pragmático que cubre los dos extremos y el centro, dentro del rango 0–60 V (cada celda LiFePO4 queda entre 2,5 V y 3,65 V).

Topología de comunicación: las dos unidades quedan en bus RS-485 propio, dedicado a la instrumentación, separado físicamente del bus del BMS. Direcciones Modbus 1 (barra) y 2 (banco), 19200 bps, paridad par. Un gateway Modbus RTU a Modbus TCP (industrial, DIN, 24 V auxiliar) hace de puente a la LAN de gestión. El DCIM consume vía Modbus TCP — en EcoStruxure por driver genérico, en Vertiv LIFE por integrador OPC UA ya existente.

¿Por qué dos y no uno? Separación de dominios de falla. Un cortocircuito en el banco durante medición no puede tumbar la medición de la barra principal. La aislación canal-a-canal da seguridad eléctrica; la separación física en dos unidades da seguridad de arquitectura.

Polling y alarmas configuradas

Polling calibrado para extraer señal relevante sin saturar el RS-485 ni el histórico del DCIM:

Variable	Tasa de polling	Retención local	Alarma
Tensión de barra -48 V (canales 1–3 de la Unidad A)	1 Hz	30 días	±2% del nominal (47,0 V a 49,0 V en flotación)
Tensión antes/después del interruptor DC (canales 4–5 de la Unidad A)	0,2 Hz (5 s)	30 días	Diferencial > 0,5 V indica interruptor degradado
Tensión por celda muestreada (8 canales de la Unidad B)	0,5 Hz (2 s)	30 días	Drift > 30 mV respecto a la mediana de las celdas muestreadas
Tendencia de drift (cálculo agregado)	1 muestra/min	90 días en el DCIM	Drift sostenido > 20 mV por 10 minutos

El log persistente de 30 días en el propio AEM-60DC8 (firmware v1.03) garantiza histórico aun con gateway TCP caído. Escalonamiento al NOC en tres niveles:

• Aviso (ámbar): drift 20–30 mV en una celda. Notifica al turno, no despierta a nadie.
• Alarma (rojo): drift > 30 mV por 10 min, o tensión de barra fuera de ±2%. Activa oncall.
• Crítico (rojo + página): drift > 50 mV o diferencial entre rectificadores > 0,8 V. Activa oncall y supervisor.

Regla de oro: no despertar a nadie por datos que pueden esperar hasta mañana. El drift evoluciona en horas, no minutos.

Lo que mostró el monitoreo

En el primer mes tras instrumentar el sitio piloto, durante el segundo evento de recarga rápida tras corte de AC (8 min por mantenimiento de la concesionaria), la celda 16 presentó drift transitorio de ~50 mV respecto a la mediana de las demás muestreadas (valor ilustrativo).

El comportamiento: drift casi nulo en flotación, creciente durante los primeros 4 min de recarga en alta corriente, recuperación parcial al entrar en flotación. Patrón clínico de celda con resistencia interna elevada — invisible en BMS agregado, en alarma binaria, en inspección visual.

Con el dato, ingeniería abrió RMA antes de que la celda fallara en descarga real. Sustitución programada en ventana de mantenimiento, con el sitio en rectificador único momentáneamente. Ningún oncall despertado, ningún viaje improductivo, ningún cliente impactado.

Meses después, el sistema identificó patrones equivalentes en 2 de los 12 sitios, todos resueltos en mantenimiento programado.

Lecciones aprendidas

Cinco lecciones aplicables a cualquier proyecto similar:

1. Separar el bus de medición del de potencia. Mantener el RS-485 de instrumentación en bus propio simplifica troubleshooting y aísla fallas de cableado.
2. Redundancia en lugares críticos. Dos unidades con dominios separados (barra × banco) cuestan más que una, pero evitan que una falla tumbe la observabilidad de todo el sitio.
3. No polling demasiado agresivo. Tensión de barra a 10 Hz no agrega nada que 1 Hz no dé; el drift LiFePO4 evoluciona en escala de minutos.
4. Las alarmas graduales salvan noches de sueño. Escalonamiento en tres niveles reduce fatiga de oncall y mantiene foco en lo importante.
5. La persistencia local importa. Treinta días de log en el propio AEM-60DC8 garantizan que una falla de gateway no borra la historia. El log es fuente de la verdad.

Sexta lección, cultural: la alarma binaria del rectificador es deuda técnica disfrazada de producto terminado. La instrumentación paralela complementa lo que el rectificador debería haber informado siempre.

KPIs antes y después

Números ilustrativos, 18 meses pre × 12 meses post-rollout en los 12 sitios. En un proyecto real, relevar del histórico del DCIM y de los tickets de oncall.

KPI	Antes (baseline)	Después (12 meses)	Variación
MTBF entre alarmas "General Fault"	~6 meses por sitio	sin ocurrencias sin causa raíz	n/a — alarma jubilada
MTTR de evento crítico DC	4 h 20 min (traslado + diagnóstico)	35 min (diagnóstico remoto, mantenimiento programado)	-87%
Viajes improductivos/año (12 sitios)	23	2	-91%
Incidentes reportables al cliente final por banco	1 (colapso en descarga)	0	-100%
Energía recuperada (kWh/año vía prevención de colapso)	n/a	~180 kWh (ilustrativo)	—
Costo evitado en traslado (BRL/año, flota)	—	~BRL 95.000 (ilustrativo)	—
Costo total de instrumentación (CAPEX 12 sitios)	—	~BRL 95.000 (ilustrativo)	payback ~12 meses

Importante: BRL 95.000 y 180 kWh son órdenes de magnitud ilustrativas. En una divulgación con cliente identificado, sustituya por los números reales del histórico.

Replicabilidad

Checklist consolidado para replicar la arquitectura:

• Relevar topología eléctrica: nominal del rectificador, química y capacidad del banco, exposición del BMS vía Modbus.
• Confirmar que las tensiones medidas queden en el rango 0–60 V en todos los canales (incluyendo ecualización y transitorios).
• Verificar el DCIM existente: driver Modbus TCP nativo, necesidad de OPC UA, límite de tags simultáneos.
• Definir puntos de medición: barra principal, salida de cada rectificador, celdas estratégicas (extremos + centro).
• Especificar gateway Modbus RTU→TCP industrial con alimentación 24 V auxiliar y fuente redundante.
• Reservar bus RS-485 propio para instrumentación, separado físicamente del bus del BMS.
• Configurar direcciones Modbus antes de la instalación (1 = barra, 2 = banco — estandarizar en la flota).
• Validar la aislación galvánica compatible con el ambiente (5 kV para sitios con surge atmosférico expuesto).
• Definir tasas de polling: barra a 1 Hz, celdas a 0,5 Hz, log persistente 30 días.
• Definir tres niveles de alarma (aviso ámbar / alarma rojo / crítico página) calibrados con el NOC.
• Documentar el runbook: qué hacer con drift de 20, 30, 50 mV en una celda.
• Ventana de instalación: 2 a 4 horas con rectificador en modo único, sin caída de carga.
• Validación post-instalación: 72 horas de monitoreo continuo antes de jubilar la alarma antigua.
• Calibración periódica: verificación anual de offset contra multímetro de referencia.
• Fin de vida del banco: gatillo de sustitución con drift sostenido > 40 mV o pérdida de SOC útil > 20%.

FAQ

¿Por qué dos AEM-60DC8 por sala en vez de uno único con 16 canales?

Separación de dominios de falla. Una sola unidad funcionaría, pero concentra riesgo: una falla de comunicación o alimentación tumba toda la observabilidad. Dos equipos con direcciones Modbus distintas mantienen observabilidad parcial aun si una unidad falla.

¿La medición interfiere con la barra de potencia?

No. El AEM-60DC8 mide en alta impedancia (megaohms), drenando corriente despreciable. Instalación en tap paralelo, sin interrumpir el camino de potencia.

¿El monitoreo sustituye al BMS del banco?

No. El BMS sigue siendo responsable de protección, balanceo y desconexión crítica. El AEM-60DC8 actúa como capa independiente de observabilidad, exponiendo datos granulares al DCIM en tiempo real — algo que muchos BMS propietarios simplemente no hacen.

¿Qué pasa si el gateway Modbus TCP cae?

El log persistente de 30 días en el propio AEM-60DC8 (firmware v1.03) preserva el histórico. Al volver el gateway, el DCIM rescata los datos vía bloque de histórico en el mapa Modbus.

¿Estos números (MTBF, MTTR, costo evitado) son reales?

Son valores ilustrativos. En una replicación real, relevar del histórico del DCIM y de los tickets del propio cliente. La dirección (menos viajes, MTTR menor, alarmas binarias jubiladas) tiende a repetirse; la magnitud varía.

---