Die Validierungsleiter
Kein einzelner Test beweist einen Flugregler. Teams bauen Vertrauen Schritt für Schritt auf – von schnellen, günstigen und sicheren Tests hin zu langsamen, teuren und riskanten:
| Stufe | Was sie prüft | Was sie nicht abdeckt |
|---|---|---|
| Unit- und Modultests | Einzelne Funktionen, Filter und Zustandsautomaten | Wechselwirkungen, Timing und Hardware |
| Software-in-the-Loop (SIL) | Den gesamten Flugcode gegen ein simuliertes Fahrzeug auf dem PC | Reales Prozessortiming, reale Sensoren und E/A |
| Hardware-in-the-Loop (HITL) | Die reale Flugregler-Platine mit simuliertem Fahrzeug | Reale Sensoren und ihre Montage |
| Lageprüfstand | Reale Sensoren und Lageregelung unter physischer Drehung | Translation, Aerodynamik und Außenbedingungen |
| Gefesselter Flug und Flugtests | Alles zusammen | Nichts – aber jeder Test kostet Zeit und birgt Risiken |
Software-in-the-Loop: jeden Commit testen
ArduPilot und PX4 bringen Software-in-the-Loop-Simulatoren (SITL) mit, die den echten Flugcode auf dem PC gegen ein Fahrzeugmodell laufen lassen; Gazebo und andere Physik-Engines stehen zur Verfügung. Da SIL keine Hardware braucht, kann es bei jeder Codeänderung automatisch laufen: Missionen, Failsafes, Parameteränderungen und Grenzfälle, die in der Luft gefährlich wären.
Sein blinder Fleck ist alles Physische: Prozessorlast und Timing, Sensorrauschen, Verkabelung und die Wechselwirkung zwischen Zelle und Regler.
Hardware-in-the-Loop: die reale Platine in einer simulierten Welt
Bei HITL läuft der Flugcode auf der realen Flugregler-Platine. Der Simulator ersetzt die Sensoren durch simulierte Daten und liest die Motorausgänge; so werden realer Prozessor, Scheduler und Kommunikationsverbindungen mitgeprüft. PX4 bietet dafür einen HITL-Modus, individuelle HIL-Prüfstände leisten dasselbe mit eigener E/A.
HITL findet Zeitüberschreitungen, Schnittstellenfehler und Konfigurationsfehler, die SIL nicht findet. Die physischen Sensoren umgeht es aber weiterhin – hier kommt eine Bewegungsplattform ins Spiel. Wie solche Prüfstände aufgebaut sind, erklärt der Leitfaden zum HIL-Prüfstand.
Lageprüfstände: reale Sensoren, reale Bewegung
Auf einem 3-Achsen-Prüfstand dreht sich das komplette Fahrzeug oder der Flugregler in seiner realen Einbaulage um Roll-, Nick- und Gierachse, kann sich aber nicht verschieben. Seine eigenen Gyroskope und Beschleunigungssensoren erfassen echte Bewegung, sodass Sensorausrichtung, Vibration, Filterung und Lageschätzer gemeinsam getestet werden; Achs-Encoder liefern eine unabhängige Referenz für die Schätzung.
Eine motorisch angetriebene Plattform kann bei jedem Lauf dasselbe Profil wiederholen und macht Lagetests so zu Regressionstests. Mit einem Fahrzeugmodell im Kreis kann die Plattform der Lage folgen, die das Modell aus den Reglerausgängen berechnet: physisches HIL. INFINITE-HIL X1 ist für diese Stufe gebaut; Bauarten und Auswahlkriterien beschreibt der Leitfaden zum 3-DOF-Prüfstand.
Testfälle, die sich zu automatisieren lohnen
- Sprünge und Frequenzdurchläufe auf jeder Achse, um die Lageantwort zwischen Firmware-Versionen zu vergleichen. Worauf dabei zu achten ist, zeigt der Leitfaden zum PID-Tuning.
- Störgrößenunterdrückung: Böen oder Störmomente, eingespeist über das Modell oder die Plattform.
- Sensorfehler: eingefrorenes Gyroskop, Offset im Beschleunigungssensor, GNSS-Verlust oder Magnetometerstörung – und der Failsafe, der darauf folgen sollte.
- Aktuatorfehler: ein schwacher oder ausgefallener Motor und die Reaktion des Reglers.
- Genauigkeit des Schätzers: Lageschätzung gegen gemessene Referenz über lange und kombinierte Bewegungen.
- Timing und Last: Zykluszeiten und Prozessorlast bei laufender Aufzeichnung, Telemetrie und Nutzlastsoftware.
Daraus einen Regressionstest machen
- Szenario einfrieren. Profile, Modellversionen und Parameter zusammen mit der getesteten Firmware-Version ablegen.
- Bestanden-Kriterien festlegen. Überschwingen, Ausregelzeit, Schätzfehler oder Failsafe-Timing – mit vor dem Test vereinbarten Grenzen.
- Bei jedem Release ausführen. SIL bei jedem Commit, HITL- und Prüfstandstests bei jedem Release-Kandidaten.
- Aufzeichnungen vergleichen. Sollwerte, Schätzungen und gemessene Referenzen auf einer gemeinsamen Zeitbasis halten, damit sich Läufe überlagern lassen.
- Den Kreis mit Flugdaten schließen. Zeigt ein Flug ein Problem, einen Testfall ergänzen, der es am Boden reproduziert.
Was nur Flugtests beweisen können
Aerodynamik, translatorische Dynamik, realer Wind, GNSS-Verhalten und die gesamte Einsatzumgebung lassen sich nur in der Luft validieren. Die früheren Stufen ersetzen den Flugtest nicht; sie sorgen dafür, dass Sie mit weniger Unbekannten dort ankommen – mit kürzeren Testkampagnen, selteneren Abstürzen und Flügen, die bestätigen statt zu entdecken.
Für zertifizierte Luftfahrtsoftware legen Normen wie DO-178C die erforderlichen Verifikationsnachweise fest; ein gestuftes Vorgehen wie dieses hilft, sie zu erbringen. Wenn Sie einen Testaufbau für Ihren Flugregler besprechen möchten, nehmen Sie Kontakt auf.