Zusammenfassung

  • Die Tiefenkalibrierung nach RFC 1628 schaltete die USV auf Batterie und entlud sie bis zu einer herstellerbestimmten Schwelle, um Austauschbedarf und Laufzeit mit hoher Gewissheit zu beurteilen.
  • Die Spezifikation warnte, dass danach nur wenig Ladung vorhanden war und die normale Schutzdauer erst nach dem Nachladen zurückkehrte.
  • Schreibzugriff, Spinlock, SetResponse, Testergebnis, Batteriezustand, Alarm, Ausgang und nutzbarer Dienst waren getrennte Belege.

Ein Messwert mit eingebauter Bedingung

Der im Mai 1994 veröffentlichte RFC 1628 ordnete die Verwaltung einer unterbrechungsfreien Stromversorgung in Identifikations-, Batterie-, Eingangs-, Ausgangs-, Bypass-, Alarm-, Test-, Steuerungs- und Konfigurationsgruppen. Das war mehr als ein Inventar: Die Taxonomie hielt Messung, Stellgröße und Wirkung auseinander.

upsEstimatedMinutesRemaining bezeichnete eine Schätzung bis zur Entladung unter der gegenwärtigen Last, falls die Netzversorgung ausfiel und ausgefallen blieb. Geschätzter Ladezustand, Spannung, Strom und Temperatur waren andere Größen. Die Quelle des Ausgangs unterschied Normalbetrieb, Batterie, Bypass, Anhebung, Absenkung und keinen Ausgang.

Auch „Batterie schwach“ war kein rein chemischer Befund. Der Zustand galt, wenn die geschätzten Minuten kleiner oder gleich der konfigurierten upsConfigLowBattTime waren. Eine geänderte Schwelle konnte die Klassifikation ändern, ohne die Batterie im selben Augenblick zu verändern. Aussagefähig wurde der Wert erst zusammen mit Last, Konfiguration und Messzeit.

Die Diagnose griff in ihren Gegenstand ein

RFC 1628 gab dem kurzen Batterietest und der Tiefenkalibrierung unterschiedliche Reichweiten. Der kurze Test sollte ausreichen, um Austauschbedarf festzustellen. Für die tiefe Kalibrierung lief das System auf Batterie bis zu einem vom Hersteller gewählten Entladungsgrad, der eine Beurteilung von Austausch und Laufzeit mit hoher Gewissheit erlaubte.

Der nächste Satz setzte die Betriebsgrenze: Die Batterie würde danach nur gering geladen sein. Sie brauchte Zeit, bevor sie der geschützten Last wieder ihre normale Dauer anbieten konnte.

Damit war Kalibrierung keine berührungslose Messung. Vorher war die Reserve womöglich ungenau bekannt, aber verfügbar. Währenddessen wurde sie für die Diagnose eingesetzt. Nachher konnte der Schätzwert besser sein, obwohl die augenblickliche Sicherheitsmarge kleiner war.

donePass war deshalb kein Synonym für wiederhergestellten Schutz. Das Ergebnis belegte den Abschluss des implementierten Tests. Es belegte weder das Nachladen noch fortbestehende Netzversorgung, unveränderte Last oder den Erfolg des Anwendungsdienstes bei einem jetzt einsetzenden Stromausfall.

Der Spinlock ordnete das Ergebnis einem Schreiber zu

Mehrere Managementstationen konnten dieselbe USV bedienen. Wer upsTestId schrieb, musste upsTestSpinLock in derselben SNMP-Nachricht mitsenden. Eine Station las Sperre und Ergebnis, wartete einen laufenden Test ab und schrieb dann den gemerkten Wert zusammen mit der gewünschten Testkennung. War eine andere Station schneller, scheiterte die Prüfung und der Ablauf begann erneut.

Nach dem Start fragte die Station Zusammenfassung und Detail ab. Entsprach der spätere Sperrwert genau dem früheren Wert plus eins, gehörte das Ergebnis zu ihrem Test und nicht zu einem Nachfolger.

Das war Nebenläufigkeitskontrolle und Ergebnisprovenienz, keine Berechtigung. Der Zähler entschied nicht, wer Reserve verbrauchen durfte, ob das Wartungsfenster tragfähig war oder ob der Diensteigner die vorübergehende Schwächung akzeptiert hatte.

Auch die Resultate blieben differenziert: bestanden, Warnung, Fehler, abgebrochen, in Arbeit oder noch kein Test. Das Detail durfte leer sein. Ohne nichtflüchtigen Speicher konnte eine Neuinitialisierung des Managementsubsystems das letzte Ergebnis löschen. „Kein Test bekannt“ sagte dann etwas über Agentengedächtnis, nicht über die physische Vergangenheit.

Alarmobjekte bildeten keinen vollständigen Verlauf

Beim Agentenstart war die Alarmtabelle leer. Erkannte Bedingungen erzeugten Zeilen, erledigte Bedingungen entfernten sie. Kennungen konnten umlaufen; eine lückenhafte Tabelle durfte nicht als chronologisch sortiertes Journal gelesen werden.

Für einen bereits beim Start bestehenden Zustand stand die Alarmzeit auf null. Null markierte die Grenze der Beobachtungsepoche, nicht den tatsächlichen Störungsbeginn. Laufender Test, Diagnosefehler, Batteriebetrieb, schwache oder erschöpfte Batterie, anstehende Abschaltung, abgeschalteter Ausgang und abgeschaltetes Gesamtsystem hatten eigene Alarme.

Die dauerhafte Batteriebetriebsbenachrichtigung enthielt geschätzte Minuten, Sekunden auf Batterie und die Niedrigschwelle und wurde minütlich wiederholt. Wiederholung erhöhte die Übermittlungschance. Sie bewies keinen Empfang, keine menschliche Kenntnisnahme und keine erfolgreiche Reaktion.

Eine geschriebene Zeit wurde zur Stellhandlung

RFC 1157 erklärte, weshalb SNMP imperative Befehle als veränderbare Variablen modellierte; ein Neustart ließ sich etwa als beschreibbarer Countdown darstellen. RFC 1628 übertrug dieses Muster auf physische Stromversorgung. Der Manager wählte Abschaltung nur des Ausgangs oder der ganzen USV, setzte oder brach Countdowns ab, plante den Start, verlangte einen zeitgesteuerten Neustart und konfigurierte automatisches Wiederanlaufen.

Die erfolgreiche Protokollantwort blieb vom Vollzug getrennt. Eine spätere Schreiboperation konnte einen Countdown ersetzen. Auf manchen Systemen brach ein Agentenneustart ihn ab. Batterieerschöpfung konnte die Abschaltung vorziehen. Ein Starttermin während fehlender Netzversorgung musste auf deren Rückkehr warten. Auch ein Neustart konnte länger als sein Nennintervall dauern.

RFC 1448 dokumentiert den damaligen SNMPv2-Operationskontext; RFC 3416 beschrieb später Validierung, Commit, Undo und Antwort ausdrücklich. Diese Schritte enden an der Protokollgrenze des verwalteten Systems. Elektrischer Ausgang, angeschlossenes Gerät und Dienst benötigen eigene Nachweise.

Die Steuersprache war nicht ihr eigenes Berechtigungssystem

RFC 1628 sagt in den Security Considerations lediglich, Sicherheitsfragen würden nicht behandelt. Daraus folgt kein Beleg für ein offenes Produkt, einen unbefugten Schreibzugriff oder einen Angriff. Administrative Beziehungen, Sichten und Zugriffsregeln lagen in begleitenden Spezifikationen und lokaler Konfiguration.

Die Aussage begrenzt dennoch den Anspruch: Ein gemeinsames Vokabular zum Entladen, Stummschalten oder Abschalten enthielt noch keine vollständige Autorisierungsordnung. Die verifizierten Errata korrigierten später einen fehlenden Makroimport, unmögliche Grenzen vorzeichenbehafteter Ganzzahlen und nicht übereinstimmende Enumerationswerte. Selbst die veröffentlichte Syntax blieb ein gepflegter Beleg.

Der Datensatz des RFC Editor belegt Dokument und Serienstatus, nicht Implementierung oder Verbreitung. Heng Lus Running-Code Primacy trennt Objektname, akzeptierte Operation und reale Wirkung. Minimum Initial Specification erklärt, warum ein schmales gemeinsames Vokabular lokale Autorität und Wiederherstellung offenlassen kann. Reality, Not Advocacy verhindert, dass aus einem Standard eine unbelegte Einsatzgeschichte wird.

RFC 1628 machte die Grenze zwischen Messen und Handeln besonders klar, weil die Messung selbst handelte. Sie verbrauchte Reserve, um Reserve besser zu kennen. Eine belastbare Betriebsakte musste deshalb Anfrage, Testergebnis, Restladung, Nachladen, Ausgang und Dienst getrennt halten — und jeder Stufe ihren verantwortlichen Entscheider zuordnen.

Quellen