Résumé

  • L’étalonnage profond de RFC 1628 déchargeait volontairement la batterie afin d’évaluer son remplacement et son autonomie avec une forte confiance.
  • Le document avertissait qu’après ce test, la batterie restait faiblement chargée et devait récupérer avant d’offrir sa durée normale à la charge protégée.
  • Verrou de test, réponse SNMP, résultat, alarme, source de sortie, recharge et service utile formaient des preuves différentes.

Une estimation attachée à sa condition

RFC 1628, publié en mai 1994, divisait la gestion d’un UPS en groupes distincts : batterie, entrée, sortie, dérivation, alarmes, tests, commandes et configuration. Cette taxonomie empêchait un voyant général de devenir toute la réalité électrique.

Les minutes restantes étaient une estimation sous la charge présente, dans l’hypothèse où le secteur resterait absent. Le pourcentage de charge, la tension, le courant et la température répondaient à d’autres questions. La sortie pouvait provenir du secteur normal, de la batterie, du bypass, d’un mode de correction, ou ne plus avoir de source.

Même l’état « batterie faible » dépendait d’un seuil configurable. Il apparaissait lorsque l’autonomie estimée devenait inférieure ou égale à upsConfigLowBattTime. Modifier le seuil pouvait modifier l’étiquette sans ajouter ni retirer un seul électron. La valeur publique était une jointure entre observation et politique locale.

Le diagnostic créait une période de moindre protection

Le test rapide devait suffire à décider si la batterie exigeait un remplacement. L’étalonnage profond visait davantage : faire fonctionner le système sur batterie jusqu’à une décharge définie par le constructeur afin d’évaluer remplacement et durée avec un haut degré de confiance.

Son avertissement donnait le vrai prix. La batterie sortirait du test avec une charge faible ; il faudrait attendre avant qu’elle retrouve une autonomie normale pour les appareils protégés.

Le résultat n’était donc pas une photographie gratuite. Le test ouvrait une nouvelle époque d’exploitation. Avant, l’autonomie était moins certaine mais disponible. Pendant, la réserve alimentait une expérience. Après, l’estimation pouvait être meilleure alors que la marge immédiate restait inférieure.

Un résultat donePass ne fermait pas cette époque. Il ne prouvait ni recharge, ni stabilité du secteur, ni constance de la charge, ni continuité applicative. La maintenance n’était terminée qu’après des reçus ultérieurs.

Le verrou attribuait le résultat, pas le droit d’agir

Plusieurs stations de gestion pouvaient convoiter le même sous-système. Pour écrire upsTestId, RFC 1628 imposait de transmettre upsTestSpinLock dans le même message. Le gestionnaire lisait le verrou, attendait la fin d’un éventuel test, puis tentait le couple verrou-identifiant. Si un autre gestionnaire passait avant lui, l’écriture échouait et il recommençait.

Après lancement, il suivait résumé et détail. Un verrou devenu exactement la valeur mémorisée plus un rattachait le résultat à son essai plutôt qu’à celui d’un successeur.

Ce mécanisme réglait une course. Il n’accordait aucune autorité de maintenance. L’autorisation de diminuer la réserve appartenait à la politique d’accès SNMP, au responsable électrique et au propriétaire du service, pas à l’algorithme de concurrence.

Les résultats distinguaient réussite, avertissement, erreur, abandon, exécution et absence de test connu. Une réinitialisation du sous-système de gestion pouvait effacer l’historique si aucun stockage non volatil n’existait. « Aucun test initié » décrivait alors la mémoire disponible, non tout le passé physique.

Les alarmes vivaient dans l’époque de l’agent

La table des alarmes commençait vide au démarrage de l’agent, ajoutait une ligne quand une condition apparaissait et la supprimait lorsqu’elle cessait. Les identifiants pouvaient boucler ; une table clairsemée n’était pas un journal chronologique.

Une condition déjà active au démarrage recevait l’heure zéro. Ce zéro indiquait une limite d’observation, pas la naissance de la panne. Test en cours, échec du diagnostic, fonctionnement sur batterie, batterie faible, batterie épuisée, arrêt imminent et sortie effectivement coupée restaient des conditions distinctes.

La notification « sur batterie » se répétait chaque minute jusqu’à l’arrêt ou au retour hors batterie et portait minutes estimées, secondes écoulées et seuil faible. Sa persistance augmentait les occasions d’écoute. Elle ne prouvait ni réception, ni acquittement humain, ni action réussie.

Une variable pouvait commander une coupure

RFC 1157 expliquait que SNMP transforme les commandes impératives en variables : un délai de redémarrage pouvait être écrit, puis déclencher l’action de façon asynchrone. RFC 1628 appliquait ce modèle à l’électricité. Le gestionnaire choisissait arrêt de la seule sortie ou de tout l’UPS, programmait ou annulait un compte à rebours, demandait redémarrage et décidait du redémarrage automatique.

Les règles conservaient les exceptions visibles. Une nouvelle écriture remplaçait un délai. Un redémarrage de l’agent pouvait l’annuler sur certains systèmes. L’épuisement de la batterie avançait la coupure. Un démarrage arrivé à échéance pendant la panne attendait le retour du secteur.

RFC 1448 donne le contexte contemporain des opérations SNMPv2 ; RFC 3416 formalisa ensuite validation, engagement, annulation et réponse. Ces étapes prouvaient le traitement de l’agent. Il fallait encore observer sortie, charge protégée et service.

Le vocabulaire commun n’était pas son propre gardien

La section sécurité de RFC 1628 dit seulement que ces questions ne sont pas discutées. Cela ne démontre aucune exposition ni attaque réelle. Les relations administratives et les vues d’accès relevaient d’autres spécifications et des configurations locales.

Mais la limite est nette : normaliser des objets capables de décharger une batterie, taire une alarme ou couper une sortie ne suffisait pas à normaliser l’autorité qui devait les utiliser. Les errata vérifiés corrigèrent encore l’import d’une macro, deux bornes d’entiers et des numéros d’énumération. Le texte publié lui-même gardait une histoire de correction.

La notice RFC Editor établit publication et métadonnées de série, non l’adoption. Running-Code Primacy de Heng Lu empêche de confondre objet, écriture, batterie et service. Minimum Initial Specification situe la valeur d’un vocabulaire étroit sans lui céder la politique locale. Reality, Not Advocacy impose de ne pas inventer le déploiement absent des sources.

Le test mesurait la réserve en la dépensant. La responsabilité commençait précisément là : nommer l’auteur de cette dépense, dater son époque, suivre la recharge et vérifier séparément ce que la batterie était censée protéger.

Sources