Skip to Main Content Skip to Search
Accelerating the pace of engineering and science

 

Beschleunigung der Entwicklung von GN&C Flight Software bei der NASA

Von Scott Tamblyn und Joel Henry, NASA, und John Rapp, Lockheed Martin
E-Mail an Jon Friedman

Wenn das Flugsteuerungssystem (Guidance, Navigation, and Control, kurz GN&C) des bemannten Raumschiffs Orion in die Phase der entscheidenden Entwurfsprüfung (Critical Design Review, CDR) geht, werden 90 % der Flight Software bereits entwickelt sein – für die NASA eine Premiere bei einem Projekt dieser Größenordnung und Komplexität. Diese Leistung ist vor allem einem neuen Entwicklungsansatz zu verdanken, der sich auf Model-Based Design stützt.

Die meisten GN&C-Projekte der NASA folgen einem konventionellen Verfahren: Experten und Analysten aus den beteiligten Fachgebieten definieren das Verhalten der Kernalgorithmen in detaillierten Anforderungsdokumenten. Nach der entscheidenden Entwurfsprüfung werden diese Dokumente den Flight Software-Ingenieuren zur Umsetzung in die formale Flugsoftware übergeben. Allein die Aufstellung des Spezifikationsdokuments dauert oft Jahre. Und da die Programmierung erst beginnen kann, wenn diese Spezifikation feststeht, vergehen oft weitere Jahre, bevor auch nur Teile des Codes getestet werden können.

Der Entwurf und die Entwicklung der GN&C-Flugalgorithmen für das Crew Exploration Vehicle Orion findet in einer Partnerschaft aus NASA, Lockheed Martin und weiteren Unternehmen statt. Durch den Einsatz von Model-Based Design konnten diese Partner parallel sowohl an der Entwicklung des GN&C-Algorithmus als auch der Flight Software arbeiten. Simulink®-Modelle dienen als ausführbare Spezifikationen, aus denen die Flight Software automatisch generiert wird. Die Experten für dieses Fachgebiet – die GN&C-Analysten – arbeiten daher direkt mit den ausführbaren Algorithmen-Modellen statt mit Dokumenten, die von Software-Entwicklern erst noch interpretiert werden müssen (Abbildung 1).

Abb. 1: Schematischer Vergleich des konventionellen Entwicklungsprozesses mit dem zur Entwicklung der GN&C-Software für Orion verwendeten Ansatz. Bild mit freundlicher Genehmigung der NASA.

Abb. 1: Schematischer Vergleich des konventionellen Entwicklungsprozesses mit dem zur Entwicklung der GN&C-Software für Orion verwendeten Ansatz. Bild mit freundlicher Genehmigung der NASA.

Diese Verschmelzung der Entwurfs- und Analyseumgebung mit der Umgebung zur Entwicklung der Flight Software ermöglicht es dem neu entstandenen Gesamtteam, Probleme früher zu identifizieren und zu beheben; und sie hat das Potential, die Entwicklungszeit um ein Jahr oder mehr zu reduzieren.

Das Fundament für den neuen Ansatz

Während Lockheed Martin bereits mit Model-Based Design vertraut war, bedeutete dieser neue Ansatz für viele NASA- Ingenieure und Vertragspartner einen Paradigmenwechsel. Um hierfür ein tragfähiges Fundament zu schaffen, arbeiteten die leitenden GN&C- und Flight Software-Ingenieure gemeinsam die Vorteile des neuen Entwicklungsprozesses heraus und erklärten dem Team, wie dies die Rollen und die Verantwortlichkeiten der GN&C-Analysten und Flight Software-Entwickler verändern würde.

Es wurden Modellierungs-Standards entwickelt, die es den etwa 100 an den GN&C-Algorithmen arbeitenden Ingenieuren aus verschiedenen Organisationen ermöglichten, konsistente Modelle zu entwickeln, die Arbeit von Kollegen zu verstehen und erfolgreich zusammenzuarbeiten. Diese Standards stellen sicher, dass alle Modelle eindeutig und leicht lesbar sind – für ein großes Team, das diese Modelle als Dokumentation einsetzt, ein besonders wichtiger Punkt. Die Standards basieren auf Erfahrungen aus früheren Projekten sowie den Richtlinien des MathWorks Automotive Advisory Boards (MAAB).

Entwicklung und Integration der GN&C-Algorithmen

Im ersten Schritt der Entwicklung der GN&C-Systemarchitektur wurde die „Empty-Box Architecture“ (EBA) erzeugt. Sie enthält etwa 100 Funktionsmodule oder Computer Software Units (CSUs).

Der für eine CSU verantwortliche Ingenieur oder das jeweilige Team bauen ein Modell aus 100 oder mehr Simulink-Bibliotheksblöcken und -komponenten zusammen. Da die CSUs als Model Reference-Blöcke definiert sind, kann jede Unit umfassend auf dem PC simuliert werden, bevor sie dem Flight Software-Team übergeben wird. Mit Simulink Verification and Validation und dem Simulink Model Advisor wird verifiziert, ob das Modell die Modellierungsstandards erfüllt. Aus dem Modell wird dann probeweise Code erzeugt und sichergestellt, dass das Modell keine Fehler enthält, die die später folgende Codegenerierung unmöglich machen. Bei der Übergabe der CSUs liefert der Verantwortliche sowohl das Simulink-Modell als auch die Teststimuli und erwarteten Ergebnisse der Unit-Tests ab.

Um schließlich die gesamte GN&C-Software zu validieren, führt das Team das übergeordnete, aus allen Funktionseinheiten bestehende Modell in Closed-Loop-Simulationen aus, um die Algorithmen weitergehend zu testen und Fehler zu beseitigen. In solchen Situationen setzt die NASA Trick ein, eine Infrastruktur für hochgetreue Simulationen mit sechs Freiheitsgraden, die man dort seit über 20 Jahren stetig weiterentwickelt. Diese Simulationsumgebung enthält mathematische Modelle der Sensoren (etwa Trägheitsmesser und Sternverfolger) und Effektoren (zu denen die Steuerungssysteme gehören) des Raumschiffs sowie Umgebungsmodelle für Aerodynamik, Schwerkraft und den Weltraum.

Das übergeordnete Modell ist über eine Socket-Verbindung an die Trick-Umgebung angeschlossen. Dies gestattet das Debugging der CSU-Algorithmen in Closed-Loop-Simulationen mit sämtlichen in der Simulink-Umgebung verfügbaren Funktionen. Simuliert man beispielsweise den Wiedereintritt in die Atmosphäre, dann kann man mit Simulink-Scopes sämtliche Signale in der eigenen CSU oder in anderen Teilen der EBA überwachen.

Orion; Image courtesy NASA.

Bild mit freundlicher Genehmigung der NASA.

Orion

Die Orion wurde von der NASA für so genannte Deep Space-Missionen fern von der Erde entwickelt. Sie wird bemannt sein und soll eine neue Astronautengeneration weit über niedrige Erdumlaufbahnen hinaus an die verschiedensten Orte unseres Sonnensystems bringen, etwa zum Mond, zu Asteroiden sowie schließlich auf den Mars. Die Orion wird das Space Shuttle als wichtigstes NASA-Fahrzeug für die bemannte Raumfahrt ersetzen.

Codegenerierung mit Embedded Coder

Da der C++-Flight-Code automatisch aus den Simulink-Modellen generiert wird, wird ein Großteil der Software bereits vor der entscheidenden Entwurfsprüfung fertig gestellt sein. Neben dem Zeitvorteil und der Risikoverminderung hat die Codegenerierung mit Embedded Coder in diesem Projektstadium drei Vorteile: Erstens lässt sich verifizieren, ob der am Ende auf dem Zielfahrzeug eingesetzte Code tatsächlich generiert werden kann und ob er dieselben Ergebnisse liefert wie die Simulink-Simulationen der Quellmodelle. Zweitens können Ingenieure, die normalerweise Programmcode selber schreiben, den generierten C++-Code per Sichtprüfung inspizieren und dabei sogar direkt im Code debuggen. Drittens ermöglicht sie den Analysten eine drastische Verbesserung der Closed-Loop-Leistung durch die direkte Integration des generierten Codes in die Trick-Simulationsinfrastruktur.

Simulink eignet sich ideal für Closed-Loop-Simulationen, weil sich in dieser interaktiven und visuellen Umgebung Defekte rasch identifizieren und beseitigen lassen. Für umfassende analytische Verifikationstests ist dagegen die Simulationsgeschwindigkeit der wichtigere Aspekt, weil dabei Hunderttausende von Monte-Carlo-Simulationen für die unterschiedlichsten Szenarien ausgeführt werden müssen.

Closed-Loop-Simulationen mit dem in Trick integrierten generierten Code sind etwa zehnmal schneller als Echtzeit- Simulationen. Demzufolge kann eine 10-tägige Orion-Mission in nur einem Tag simuliert werden. Die Wiedereintrittsphase wurde mittlerweile mithilfe beider Methoden simuliert – mit dem an Trick angeschlossenen Simulink-Modell sowie durch direkte Integration des generierten Codes in Trick. Der Vergleich hat erwiesen, dass die Ergebnisse beider Verfahren bitgenau übereinstimmten; sie sind also bis auf Low-Level-Ebene identisch.

Auf Neuland

Das vorgestellte GN&C-Projekt eröffnet der NASA in vielerlei Hinsicht neue Wege. Mit Simulink und Embedded Coder kann ein großes Expertenteam von NASA, Lockheed und weiteren Vertragspartnern Algorithmen für komplexe Flugbahnen und Szenarien entwickeln, Simulationen in den bereits vorhandenen Simulationsumgebungen vornehmen und schließlich den einsatzfertigen Code für die Flight Software von Raumschiffen generieren.

Bei langfristigen Projekten wie diesem kommt es häufig vor, dass sich die Anforderungen und Prioritäten des Projektträgers ändern. Liegen die Algorithmen dann in Form von Modellen und nicht als Low-Level-Code vor, ist dies für die Ingenieure eine gute Ausgangsposition, das Projekt in die gewünschte Richtung erfolgreich vorantreiben zu können.

Veröffentlicht 2011
91958v00