Software zuerst. Hardware danach.
Was der Regler berechnen muss.Abschnitt öffnen
Vier Laufzeitfragen.
Was hat sich geändert?
Den erweiterten Zustand Z(t) schätzen: Streckenzustand, physische Ressourcen, Modellgültigkeit und aktive Konfiguration.
Was ist noch möglich?
Verbleibende Ressourcen auf Funktionen und Missionswert jeder verifizierten Konfiguration abbilden.
Welche Übergänge sind erlaubt?
Kandidaten verwerfen, die Machbarkeit, Stabilität, Safety oder den verifizierten Konfigurationsgraphen verletzen.
Wann darf geschaltet werden?
Reaktionslatenz, Umschaltzeit und Mindestverweilzeit vor dem nächsten Trajektorienschritt einhalten.
Berichtete Ergebnisse der Referenzsoftware.
Referenzsoftware: C++-Kern → ROS 2.Abschnitt öffnen
Referenzsoftware: C++-Kern → ROS 2.
Domänenunabhängiges C++
Strecke, Health, Leistungsfähigkeit, Entscheidung, Stabilität und Rekonfiguration bleiben unabhängig von ROS 2.
ROS-2-Integration
Typisierte Nachrichten und komponierbare Nodes stellen den verifizierten Kern bereit, ohne seinen numerischen Vertrag zu ändern.
Golden-Model-Äquivalenz
Gleichungen, Fault Injection, Konfigurations- und Stabilitäts-Gates sowie Timing werden gegen die C++-Referenz geprüft.
Deterministischer Servicezyklus
Health-, Entscheidungs- und Stabilitätspfade werden getrennt gemessen; Timing-Aussagen bleiben bis zur HIL-Validierung plattformspezifisch.
Geplanter Hardwarepfad: RISC-V → SoC IP.Abschnitt öffnen
Geplanter Hardwarepfad: RISC-V → SoC IP.
Verifizierte Kerne übernehmen
Leistungsfähigkeit, Stabilität und Übergangsüberwachung wandern aus der Software-Referenz, die Schnittstellen bleiben gleich.
Quantisierungsfehler begrenzen
Fixed-/Floating-Point-Formate werden aus der Sensitivität von Ranking-, Health- und Stabilitätsentscheidungen gewählt.
Stabile Hardwaregrenze
Eingänge: Zustand, Diagnose und Policy. Ausgänge: Health, Konfiguration, Stabilitätsstatus und Ressourcen-/Regelbefehle.
FPGA vor SoC
Numerische Äquivalenz, Zyklusbudgets und HIL-Fehlerszenarien müssen vor der SoC-Integration bestehen.
Verifikations-Gates.Abschnitt öffnen
Was muss vor der nächsten Stufe nachgewiesen sein?
Numerische Äquivalenz
Die Implementierung muss innerhalb definierter Fehlergrenzen zum mathematischen Golden Model bleiben.
Fehlerreaktion
Bekannte Degradationsklassen müssen erwartete Zustandsübergänge und Fallback-Verhalten erzeugen.
Timing
Entscheidung, Validierung, Umschalten und Rollback werden getrennt vermessen.
Physische Validierung
Aussagen bleiben begrenzt, bis HIL- und beschädigte-Strecke-Experimente das erwartete Verhalten reproduzieren.
Rechenstruktur pro Schritt.
| Komponente | Zeit | Speicher |
|---|---|---|
| Zustandsschätzung | \(\mathcal O(n^3)\) | \(\mathcal O(n^2)\) |
| Indikatorberechnung | \(\mathcal O(r)\) | \(\mathcal O(r)\) |
| Regimeklassifikation | \(\mathcal O(1)\) | \(\mathcal O(1)\) |
| Regelberechnung | \(\mathcal O(nm)\) | \(\mathcal O(nm)\) |
| Degradationsupdate | \(\mathcal O(r)\) | \(\mathcal O(r)\) |
| Gesamt | \(\mathcal O(n^3+r)\) | \(\mathcal O(n^2+r)\) |
Was noch nicht nachgewiesen ist.
Forschung in testbare Technologie überführen.
Contimech.org unterstützt die C++-/ROS-2-Referenzimplementierung, Testinfrastruktur und exploratives RISC-V-/SoC-Engineering. Diese Arbeit dient dem Technologieaufbau und ist kein kommerzielles Angebot.