Case study: monitoramento de retificador 48 V em data center Tier III edge

Aviso de transparência: este é um case ilustrativo anonimizado, construído a partir de padrões recorrentes de mercado observados em operadores de data center edge no Brasil. Não corresponde a um cliente específico. Os números de MTBF, MTTR, custo evitado e o drift de 50 mV citados são valores ilustrativos baseados em ordem de grandeza típica do setor; devem ser substituídos por dados reais de campo quando aplicado a um cliente identificável. O objetivo deste material é demonstrar a arquitetura técnica e o raciocínio de engenharia, não declarar resultados de um caso real.

Um operador regional brasileiro com 12 sites de borda Tier III no Sudeste convivia com um alarme genérico de retificador 48 V que voltava a cada seis meses sem causa raiz. O oncall ia ao site, encontrava o painel OK, fazia power-cycle e voltava. A suspeita era cell drift no banco LiFePO4, mas sem dados granulares para provar. Este case study reconstrói, no formato Situação–Tarefa–Ação–Resultado, como dois AEM-60DC8 por sala, integrados ao DCIM existente, transformaram um alarme cego em manutenção preditiva programada.

Situação

O operador opera 12 sites Tier III edge no interior de SP, Vale do Paraíba e Sul de Minas. Cada site tem uma a três salas técnicas, todas com o mesmo padrão:

• 4 racks de equipamentos críticos (roteadores, switches ToR, cache CDN, appliances).
• Dois retificadores 48 V em paralelo redundante (N+1), saída nominal 200 A em -48 V CC.
• Banco LiFePO4 com 30 min de autonomia a plena carga, 16 células em série (51,2 V nominal, 48,0 a 57,6 V) e BMS proprietário.
• DCIM existente (Schneider EcoStruxure IT ou Vertiv LIFE Services) com gateway Modbus TCP por sala.
• NOC remoto 24/7 em SP capital, squad regional, SLA contratual de 4 h para chegada presencial.

Os retificadores expõem apenas alarmes binários ao DCIM via contato seco (AC fail, DC low, overtemp, general fault), sem leitura granular de tensão ou corrente. O BMS do banco expõe SOC e tensão de pack agregada via Modbus, mas não tensão por célula em tempo real.

O problema

A cada cinco a sete meses, em três dos doze sites, o DCIM disparava o alarme "General Fault — Rectifier". Sem contexto. O playbook do oncall mandava:

1. Conectar VPN e verificar telemetria.
2. Como o alarme era binário, não havia mais informação além do bit ligado.
3. Tentar reset remoto. Em metade dos casos, o bit limpava em 30 a 90 minutos. Na outra metade, ficava ativo.
4. Em caso de alarme persistente, oncall ia ao site — deslocamento médio de 2,5 horas.
5. Em campo, o técnico encontrava painel em estado normal: tensão OK, corrente equilibrada, SOC adequado. Power-cycle do retificador e o alarme sumia.

Em dois anos, o time consolidou 37 ocorrências em 12 sites. Em 23 o técnico foi presencialmente sem encontrar falha — viagem improdutiva. Em 4 foi identificada uma célula fora de faixa após varredura manual. Em 1 o banco crashou em descarga durante corte de 18 minutos, derrubando o site por 4 minutos até religar o AC — incidente reportável ao cliente final.

A suspeita apontava para cell drift: células do banco perdendo capacidade ou desbalanceando durante recarga rápida pós-corte. Mas o BMS não expunha leitura por célula em tempo real, e o log interno era de difícil extração. Sem dados granulares, não havia como provar a hipótese.

A tarefa

Escopo validado com operações e finanças:

• Instrumentar o barramento DC e células críticas sem trocar retificador nem banco — paralisação vetada por SLA.
• Integrar ao DCIM existente (EcoStruxure ou Vertiv LIFE), sem segunda tela para o NOC.
• Custo-alvo por sala: até R$ 8.000 em hardware (ilustrativo).
• Prazo: piloto em 30 dias, replicação nos 11 demais em até 6 meses.
• Critério de sucesso: reduzir em pelo menos 60% as viagens improdutivas no primeiro semestre pós-rollout.

A restrição mais dura era integração sem rip-and-replace. Trocar retificador implicava paralisação de 4 a 6 horas e renegociação de SLA. Trocar banco implicava CAPEX de seis dígitos por site. A engenharia precisava de instrumentação paralela, lendo o que retificador e BMS já entregavam ao barramento, sem entrar no caminho de potência.

A solução

A arquitetura aprovada foi: dois AEM-60DC8 por sala, em papéis complementares.

Unidade A — barramento de saída do retificador A+B. Conectada ao barramento -48 V principal que alimenta a régua DC dos racks. Mede saída do retificador A (canal 1), saída do retificador B (canal 2), barramento comum após o diodo OR (canal 3), tensão antes e depois do disjuntor principal DC (canais 4 e 5). Três canais sobrando para expansão.

Unidade B — banco de baterias LiFePO4. Conectada a oito pontos de tap, amostrando células estratégicas: 1, 2, 3, 4 (extremidade negativa, mais propensa a drift), 8 e 9 (centro, baseline) e 15, 16 (extremidade positiva). É um compromisso pragmático que cobre as duas extremidades e o centro, dentro do range 0–60 V (cada célula LiFePO4 fica entre 2,5 V e 3,65 V).

Topologia de comunicação: os dois AEM-60DC8 ficam em barramento RS-485 próprio, dedicado à instrumentação, separado fisicamente do RS-485 do BMS. Endereços Modbus 1 (barramento) e 2 (banco), 19200 bps, paridade par. Um gateway Modbus RTU para Modbus TCP (industrial, DIN, 24 V auxiliar) faz a ponte para a LAN de gerência. O DCIM consome via Modbus TCP — no EcoStruxure via driver genérico, no Vertiv LIFE via integrador OPC UA já existente.

Por que dois e não um? Separação de domínios de falha. Um curto no banco durante medição não pode derrubar a medição do barramento principal. A isolação canal-a-canal dá segurança elétrica; a separação física em duas unidades dá segurança de arquitetura.

Polling e alarmes configurados

Polling calibrado para extrair sinal relevante sem saturar o RS-485 nem o histórico do DCIM:

Variável	Taxa de polling	Retenção local	Alarme
Tensão de barramento -48 V (canais 1–3 da Unidade A)	1 Hz	30 dias	±2% do nominal (47,0 V a 49,0 V em flutuação)
Tensão antes/depois disjuntor DC (canais 4–5 da Unidade A)	0,2 Hz (5 s)	30 dias	Diferencial > 0,5 V indica disjuntor degradado
Tensão por célula amostrada (8 canais da Unidade B)	0,5 Hz (2 s)	30 dias	Drift > 30 mV em relação à mediana das células amostradas
Tendência de drift (cálculo agregado)	1 amostra/min	90 dias no DCIM	Drift sustentado > 20 mV por 10 minutos

O log persistente de 30 dias no próprio AEM-60DC8 (firmware v1.03) garante histórico mesmo com gateway TCP fora. Escalonamento ao NOC em três níveis:

• Aviso (âmbar): drift 20–30 mV em uma célula. Notifica turno, não acorda ninguém.
• Alarme (vermelho): drift > 30 mV por 10 min, ou barramento fora de ±2%. Aciona oncall.
• Crítico (vermelho + página): drift > 50 mV ou diferencial entre retificadores > 0,8 V. Aciona oncall e supervisor.

Regra de ouro: não acordar ninguém por dado que pode esperar até amanhã. Drift evolui em horas, não minutos.

O que mostrou o monitoramento

Resultado direto, no primeiro mês após instrumentação do site piloto: durante o segundo evento de recarga rápida após corte AC (8 minutos por manutenção da concessionária), a célula 16 apresentou drift transitório de aproximadamente 50 mV em relação à mediana das demais células amostradas (valor ilustrativo; em campo real, registre o valor medido).

O comportamento foi específico: drift quase nulo em flutuação, drift crescente durante os primeiros 4 minutos de recarga em alta corrente, recuperação parcial ao entrar em flutuação. Padrão clínico de célula com resistência interna elevada — invisível em medida agregada do BMS, invisível em alarme binário do retificador, invisível em inspeção visual.

Com o dado, a engenharia abriu RMA com o fabricante antes que a célula falhasse em descarga real. A substituição foi programada em janela de manutenção, com o site rodando em retificador único momentaneamente. Nenhum oncall acordado, nenhuma viagem improdutiva, nenhum cliente final impactado.

Nos meses seguintes, o sistema identificou padrões equivalentes em 2 dos 12 sites, todos resolvidos em manutenção programada (números ilustrativos).

Lições aprendidas

Cinco lições aplicáveis a qualquer projeto similar:

1. Separar barramento de medição do de potência. Manter o RS-485 da instrumentação em barramento próprio simplifica troubleshooting e isola falhas de cabeamento.
2. Redundância em locais críticos. Dois AEM-60DC8 com domínios separados (barramento × banco) custam mais que uma unidade só, mas evitam que uma falha derrube a observabilidade de todo o site.
3. Sem polling agressivo demais. Tensão de barramento a 10 Hz não acrescenta nada que 1 Hz não dê; drift de célula LiFePO4 evolui em escala de minutos.
4. Alarmes graduais salvam noites de sono. Escalonamento em três níveis reduz fadiga de oncall e mantém foco no que importa.
5. Persistência local importa. Trinta dias de log no próprio AEM-60DC8 garantem que uma falha de gateway não apaga a história. O log é fonte da verdade.

Sexta lição, cultural: alarme binário do retificador é dívida técnica disfarçada de produto pronto. Instrumentação paralela complementa o que o retificador deveria sempre ter informado.

KPIs antes e depois

Números ilustrativos, 18 meses pré × 12 meses pós-rollout nos 12 sites. Em projeto real, apurar do histórico do DCIM e dos tickets de oncall.

KPI	Antes (baseline)	Depois (12 meses)	Variação
MTBF entre alarmes "General Fault"	~6 meses por site	sem ocorrência sem causa raiz	n/a — alarme aposentado
MTTR de evento crítico DC	4 h 20 min (deslocamento + diagnóstico)	35 min (diagnóstico remoto, manutenção programada)	-87%
Viagens improdutivas/ano (12 sites)	23	2	-91%
Incidentes reportáveis ao cliente final por banco	1 (crash em descarga)	0	-100%
Energia recuperada (kWh/ano via prevenção de crash)	n/a	~180 kWh (ilustrativo)	—
Custo evitado em deslocamento (R$/ano, frota)	—	~R$ 95.000 (ilustrativo)	—
Custo total de instrumentação (CAPEX 12 sites)	—	~R$ 95.000 (ilustrativo)	payback ~12 meses

Importante: R$ 95.000 e 180 kWh são ordens de grandeza ilustrativas. Em divulgação com cliente identificado, substituir pelos números reais do histórico.

Replicabilidade

Checklist consolidado para replicar a arquitetura:

• Levantar topologia elétrica: nominal do retificador, química e capacidade do banco, exposição do BMS via Modbus.
• Confirmar que tensões medidas ficam no range 0–60 V em todos os canais (incluindo equalização e transientes).
• Verificar o DCIM existente: driver Modbus TCP nativo, necessidade de OPC UA, limite de tags simultâneas.
• Definir pontos de medição: barramento principal, saída de cada retificador, células estratégicas (extremidades + centro).
• Especificar gateway Modbus RTU→TCP industrial com alimentação 24 V auxiliar e fonte redundante.
• Reservar barramento RS-485 próprio para instrumentação, separado fisicamente do BMS.
• Configurar endereços Modbus antes da instalação (1 = barramento, 2 = banco — padronizar na frota).
• Validar isolação galvânica compatível com o ambiente (5 kV para surto atmosférico exposto).
• Definir taxas de polling: barramento a 1 Hz, células a 0,5 Hz, log persistente 30 dias.
• Definir três níveis de alarme (aviso ámbar / alarme vermelho / crítico página) calibrados com o NOC.
• Documentar runbook: o que fazer com drift de 20, 30, 50 mV em uma célula.
• Janela de instalação: 2 a 4 horas com retificador em modo único, sem queda de carga.
• Validação pós-instalação: 72 horas de monitoramento contínuo antes de aposentar o alarme antigo.
• Plano de calibração periódica: verificação anual de offset contra multímetro de referência.
• Plano de fim de vida do banco: gatilho de substituição em drift sustentado > 40 mV ou perda de SOC útil > 20%.

FAQ

Por que dois AEM-60DC8 por sala em vez de um único com 16 canais?

Separação de domínios de falha. Uma única unidade funcionaria, mas concentra risco: uma falha de comunicação ou alimentação derruba toda a observabilidade. Dois equipamentos com endereços Modbus distintos mantêm observabilidade parcial mesmo se uma unidade falhar.

A medição interfere no barramento de potência?

Não. O AEM-60DC8 mede em alta impedância (megaohms), drenando corrente desprezível. Instalação em tap paralelo, sem interromper o caminho de potência.

O monitoramento substitui o BMS do banco?

Não. O BMS continua responsável por proteção, balanceamento e desligamento crítico. O AEM-60DC8 atua como camada independente de observabilidade, expondo dados granulares ao DCIM em tempo real — algo que muitos BMS proprietários simplesmente não fazem.

O que acontece se o gateway Modbus TCP cair?

O log persistente de 30 dias no próprio AEM-60DC8 (firmware v1.03) preserva o histórico. Ao voltar o gateway, o DCIM resgata os dados via bloco de histórico no mapa Modbus.

Esses números (MTBF, MTTR, custo evitado) são reais?

São valores ilustrativos. Em replicação real, apurar do histórico do DCIM e dos tickets do próprio cliente. A direção (menos viagens, MTTR menor, alarmes binários aposentados) tende a se repetir; a magnitude varia.

---