Resumo

  • A calibração profunda de RFC 1628 colocava o UPS em bateria até um nível de descarga definido pelo fabricante, buscando alta confiança sobre substituição e autonomia.
  • O próprio documento avisava que o ensaio deixaria pouca carga e exigiria tempo de recarga antes de restaurar a duração normal para a carga protegida.
  • Bloqueio de teste, resposta SNMP, resultado, estimativa, alarme, saída elétrica e serviço útil eram comprovantes distintos.

A autonomia era uma hipótese com relógio

Publicado em maio de 1994, RFC 1628 organizou a gestão de um sistema de alimentação ininterrupta em grupos separados: identificação, bateria, entrada, saída, bypass, alarmes, testes, controles e configuração. Essa divisão já recusava a ideia de que um único indicador “saudável” pudesse descrever toda a proteção.

upsEstimatedMinutesRemaining não prometia minutos absolutos. Estimava o tempo até a descarga sob a carga presente, supondo que a rede elétrica estivesse ausente e continuasse assim. A porcentagem estimada de carga, a tensão, a corrente e a temperatura eram observações diferentes. A origem da saída também distinguia rede normal, bateria, bypass, elevação, redução ou ausência de alimentação.

Até a classificação de bateria baixa dependia de uma escolha local. Ela aparecia quando os minutos estimados ficavam menores ou iguais a upsConfigLowBattTime. Alterar esse limiar podia mudar o rótulo sem mudar a química naquele instante. A leitura só fazia sentido acompanhada da carga, da configuração e do momento da observação.

Mais confiança custava autonomia imediata

RFC 1628 descrevia dois ensaios com alcance desigual. O teste rápido era suficiente para indicar se a bateria precisava ser substituída. A calibração profunda fazia o sistema operar em bateria até um nível de descarga escolhido pelo fabricante, suficiente para avaliar substituição e tempo de operação com alto grau de confiança.

O aviso seguinte era parte essencial da especificação: a calibração deixaria a bateria em estado de pouca carga. Seria preciso recarregá-la antes que voltasse a oferecer duração normal à carga protegida.

A medição, portanto, não era neutra. Antes do ensaio, a capacidade podia ser incerta, mas estava disponível. Durante o ensaio, a reserva sustentava uma investigação deliberada. Depois, a estimativa podia ser melhor justamente quando a proteção imediata estava menor.

Um resultado donePass não fechava essa dívida. Ele dizia que o diagnóstico definido pela implementação terminara com aprovação; não dizia que a carga havia sido restaurada, que a rede continuaria presente, que o consumo não mudara nem que o serviço sobreviveria a uma falha iniciada naquele momento.

O bloqueio guardava a autoria da época

Mais de uma estação de gestão podia tentar iniciar um teste. Para escrever upsTestId, a mesma mensagem SNMP precisava incluir upsTestSpinLock. O gestor lia o bloqueio e o resultado corrente, aguardava enquanto outro teste estivesse em curso e então tentava escrever o valor lembrado junto do teste desejado. Se outro gestor chegasse primeiro, a verificação falhava e o procedimento recomeçava.

Após a partida, o gestor consultava resumo e detalhe. Se o bloqueio posterior fosse exatamente o valor lembrado mais um, o resultado pertencia ao seu teste, não a outro iniciado em seguida.

Esse mecanismo resolvia concorrência e proveniência. Não autorizava ninguém a gastar a bateria. A permissão SNMP, a janela de manutenção, o risco aceito pelo responsável elétrico e a tolerância do proprietário do serviço continuavam sendo decisões separadas.

Os resultados também não cabiam em um único sim ou não: aprovado, advertência, erro, abortado, em execução ou nenhum teste iniciado. O detalhe podia vir vazio. Sem armazenamento não volátil, a reinicialização do subsistema de gestão podia apagar o último resultado. “Nenhum teste conhecido” descrevia a memória do agente, não toda a história física.

O alarme registrava condições presentes

A tabela de alarmes começava vazia quando o agente iniciava. Uma linha surgia quando uma condição era detectada e desaparecia quando ela cessava. Os identificadores podiam dar a volta, e uma tabela esparsa não formava uma cronologia confiável.

Uma condição já ativa no início do agente recebia tempo zero. O zero marcava a fronteira de observação, não o instante real de origem. Teste em curso, falha de diagnóstico, operação em bateria, bateria baixa, bateria esgotada, desligamento pendente, saída desligada e UPS inteira desligada eram alarmes distintos porque comprovavam fatos distintos.

A notificação persistente de operação em bateria levava minutos estimados, segundos já decorridos e o limiar de bateria baixa. Ela se repetia a cada minuto até o UPS desligar ou sair da bateria. Repetição aumentava a chance de atenção, mas não provava entrega, leitura humana nem ação corretiva.

Segundos gravados podiam alterar a eletricidade

RFC 1157 explicou a disciplina peculiar do SNMP: comandos imperativos podiam ser representados como variáveis graváveis, como uma contagem regressiva para reinicialização. RFC 1628 levou essa abstração à alimentação física. Um gestor podia escolher entre desligar apenas a saída ou o UPS inteiro, programar e cancelar desligamento, agendar partida, solicitar reinicialização temporizada e configurar retorno automático.

A resposta ao SET não era o efeito final. Uma escrita posterior podia substituir a contagem. Em alguns sistemas, reiniciar o agente podia cancelá-la. A descarga podia antecipar o desligamento. Uma partida vencida durante falta de rede precisava esperar a alimentação voltar. O intervalo de reinicialização também podia se estender além do valor nominal.

RFC 1448 oferece o contexto das operações SNMPv2 da época; RFC 3416 depois explicitou validação, confirmação, reversão e resposta. Essas etapas chegam ao limite do agente gerenciado. Saída elétrica, equipamento protegido e serviço ainda exigem testemunhas posteriores.

O vocabulário de controle não continha toda a autoridade

A seção de segurança de RFC 1628 declara apenas que questões de segurança não são discutidas. Isso não demonstra produto exposto, comando indevido ou ataque real. Comunidades, visões e políticas de acesso pertenciam a especificações relacionadas e à configuração local.

Mas a omissão delimita o documento: padronizar objetos para descarregar bateria, silenciar alarme ou desligar saída não constituía, sozinho, um desenho completo de autorização. Os erros verificados corrigiram depois uma importação de macro, limites impossíveis de inteiros com sinal e números de enumeração divergentes. Até a sintaxe publicada permaneceu um registro mantido.

O registro do RFC Editor confirma o documento e seus metadados atuais, não implementação ou adoção. Em Running-Code Primacy, Heng Lu exige separar nome de objeto, resposta e realidade operacional. Minimum Initial Specification mostra como um vocabulário comum estreito pode preservar decisões locais de autoridade e recuperação. Reality, Not Advocacy impede que a existência da norma seja promovida a prova de implantação.

O legado mais útil de RFC 1628 é a contabilidade de uma troca. A calibração consumia autonomia para produzir evidência. Operar com responsabilidade exigia registrar quem aprovou essa troca, qual época de teste produziu o resultado, quanto da reserva restou, quando a recarga terminou e se o serviço protegido continuou de fato protegido.

Fontes