Architektur ändern. Mission erhalten.
Die Architektur trennt Missionsabsicht von Implementierung, behandelt nun jedoch Hardwarezustand, Modellgültigkeit, Konfiguration und Missionsprioritäten als einen erweiterten Laufzeitzustand.
Mission → Funktion → Service → Ressource.
Die Hierarchie bleibt nach der Forschungsrevision bestehen. Die zentrale Änderung liegt auf Ressourcenebene: Ressource ist alles, dessen Zustand die Realisierung einer Funktion begrenzt – einschließlich Modelle und Algorithmen.
Die Hierarchie bleibt das strukturelle Rückgrat. Das aktuelle Modell erweitert ihre Ressourcenebene und ergänzt Übergangszulässigkeit und Timing außerhalb der Hierarchie selbst.
Der Supervisor beobachtet nicht nur die Hardware.Abschnitt öffnen
Der Supervisor beobachtet nicht nur die Hardware.
Ein Schätzer oder gelerntes Modell, dessen Vorhersagen nicht mehr mit Beobachtungen übereinstimmen, wird als degradierte epistemische Ressource dargestellt. Dadurch können physische Fehler und Verlust der Modelladäquanz in dieselbe Leistungsfähigkeitsberechnung eingehen.
Ein Kandidat ist nur dann nutzbar, wenn alle drei Fragen beantwortet sind.Abschnitt öffnen
Ein Kandidat ist nur dann nutzbar, wenn alle drei Fragen beantwortet sind.
Kann sie noch genügend von der Mission erfüllen?
Der Ressourcenzustand propagiert über Services und Funktionen zum Leistungsfähigkeitsscore auf Missionsebene \(S\).
Ist der strukturelle Übergang zulässig?
Das Ziel muss zum verifizierten Katalog gehören und Ressourcen-, Funktions- und Stabilitätsbedingungen erfüllen.
Darf sich das System jetzt ändern?
Die Reaktionslatenz muss klein genug sein, zugleich müssen Konfigurationsänderungen weit genug auseinanderliegen, um die Schaltgarantie zu erhalten.
Beobachten → validieren → bewerten → planen → freigeben → ausführen.Abschnitt öffnen
Beobachten → validieren → bewerten → planen → freigeben → ausführen.
Die Garantien gehören zum Graphen, nicht zum Optimierer.Abschnitt öffnen
Die Garantien gehören zum Graphen, nicht zum Optimierer.
Der Katalog ist endlich, da jede Konfiguration vor dem Einsatz verifiziert werden muss. Lernen oder Erfahrung zur Laufzeit können Präferenzen und Übergangswahrscheinlichkeiten ändern, aber keine unverifizierte Konfiguration oder Kante erzeugen.
Verschiedene Ebenen arbeiten weiterhin mit unterschiedlichen Raten.Abschnitt öffnen
Verschiedene Ebenen arbeiten weiterhin mit unterschiedlichen Raten.
Die Abstraktionshierarchie beschreibt, was das System bedeutet. Die Ausführungshierarchie beschreibt, wo Entscheidungen berechnet werden und wie schnell sie wirken.
- L3 Mission Manager — Trajektorienziel, Prioritäten und Horizont.
- L2 Supervisor — Diagnose, Gültigkeit, Graphplanung und Rekonfiguration.
- L1 Servo Control — Streckenregelung innerhalb der aktiven Konfiguration.
- L0 Hardware — Sensorik, Aktorik, Interrupts und physisches I/O.
Die Architektur muss drei unabhängige zeitliche Bedingungen erfüllen.
Das Diagramm links beschreibt den Mechanismus; die aktuelle Theorie beschränkt die Sequenz.
Die frühere Architektur beschrieb Diagnose und strukturelle Rekonfiguration korrekt. Die aktuelle Arbeit ergänzt ein quantitatives Leistungsfähigkeitsmodell, epistemische Gültigkeit, Übergangszulässigkeit, eine Verweilzeitgrenze und Trajektorienplanung.
Modelländerung nachvollziehen →Experimente bleiben die Audit-Spur der Architektur.
EXP‑01 bis EXP‑03 bleiben im Umfang unverändert; die neue Preprint-Reihe formalisiert die Grenzen, die bei der Verallgemeinerung dieser Mechanismen sichtbar wurden.