Hat ein Space Shuttle seine Aufgabe im All erledigt, sollte es wieder zurück auf die Erde. Dabei hilft ihm ein Wiedereintrittskörper. Für das Space Shuttle Orbiter war das HL-20. Dieser wurde von der NASA mit Hilfe der Modellierungs- und Simulations-Software Simulink von Mathworks konzipiert. Die FDIR-Komponente (Fault Detection, Isolation, and Recovery; Fehlererkennung, -isolation und -kompensation) des HL-20 wird an ein System-Modell angebunden, das Umgebungsmodelle, Flugsteuerungen Leit-, Navigations- und Steuerungssysteme beinhaltet. Anschließend wird das Modell auf Systemebene zur Validierung des Verhaltens simuliert.
Als erster Schritt wird die Fehlermanagementlogik des Aktuatorsystems entwickelt. Im Anforderungsdokument sind fünf mögliche Modi oder Zustände für den Aktuator angegeben: Passiv, Standby, Aktiv, Isoliert und Aus. Der Einfachheit halber werden nur die ersten vier Modi berücksichtigt. Dazu werden einem Stateflow-Zustandsdiagramm vier Zustände hinzugefügt. Nun werden mit den im Anforderungsdokument enthaltenen Informationen Übergänge zur Verknüpfung der Zustände hinzugefügt und angegeben, welche Bedingungen für einen Zustandswechsel erfüllt werden müssen. Zudem werden die Zustände Passiv, Aktiv und Standby in einem übergeordneten Zustand gruppiert, da sie alle unter derselben Bedingung in den Zustand Isoliert wechseln. Mit diesem hierarchischen Modellierungsverfahren kann eine komplexe Logik in einem einfachen visuellen Format modelliert werden.
Als weiterer Schritt wird das Modell erstellt, indem jedes Element mit einer bestimmten Systemanforderung verknüpft wird. Die Rückverfolgbarkeit vom Modell zum Anforderungsdokument ermöglicht die Begründung von Design-Entscheidungen. Wurde die Logik für den linken inneren Aktuator erstellt, kann dieser Entwurf für den rechten inneren Aktuator wiederverwendet werden, da die Struktur identisch ist. Lediglich die Bedingungen für die jeweiligen Übergänge müssen geändert werden.
Testen mit Simulation
Zur Simulation wird nun ein einfacher Testrahmen (Harness) verwendet, mit dem Eingangssignale an die Komponente mit einer Kombination aus Switch- und Constant-Blöcken übertragen werden. Mit Simulink und Stateflow kann die
Simulation gestartet werden, ohne dass Variablen manuell definiert werden müssen. Klickt man auf die Schaltfläche Play, werden in einem Dialogfenster die Variablen angezeigt, die vor der Durchführung der Simulation definiert werden müssen. Mit einem Klick auf OK werden diese Variablen automatisch erstellt.
Während der Simulation liefert das animierte Zustandsdiagramm Informationen zum jeweils aktiven Zustand und den Übergängen von einem Zustand zu einem anderen. Spontantests, bei denen die Eingangssignale ein- und ausgeschaltet werden, zeigen Fehler im Entwurf. Bei Aktivierung des linken inneren Aktuators sollte der rechte innere Aktuator ebenfalls aktiviert werden. Beim Test des HL-20 konnten die Eingangsbedingungen so definiert werden, dass dies nicht passierte – der Entwurf war fehlerhaft.
Der Fehler lag in der Bedingung für den Übergang von Aktiv zu Standby. Da jede Bedingung mit einer Anforderung verknüpft ist, kann die Bedingung der zugrunde liegenden Anforderung zugeordnet werden. So war klar, dass der Fehler nicht im Entwurf entstand. Er wurde im Anforderungsdokument entdeckt und behoben.
Systemtest mit neuer Komponente
Nachdem die FDIR-Komponente separat zu testen ist, kann sie im Modell auf Systemebene geprüft werden. Dazu wird sie als Modellblock FDIR_application integriert. Nun kann die Arbeit daran unabhängig vom restlichen System mit der Modellreferenzierungs-Funktion fortgesetzt werden.
Das Modell wird auf Systemebene simuliert. Die Darstellung des Verhaltens der Komponente im Zustandsdiagramm und des Verhaltens des Gesamtsystems übernimmt FlightGear, ein Open-Source-Visualisierungstool. Zum Testen des Systems wird ein Harness eingerichtet, der Fehler in das Aktuatorsystem einstreut. Damit wird sichergestellt, dass die Komponente und das Gesamtsystem korrekt reagieren.
