Viel Starlink ist in Crew Dragon - und umgekehrt

"Bei den Starlink-Satelliten müssen wir aber auch eher wie bei Servern in einem Datencenter als bei speziellen, einmaligen Vehikeln denken", führte Monson weiter aus. "Bei manchen Fragen müssen wir absolut sicher sein (Command, Software Update, Power und Sicherheit der Hardware) und brauchen dort mehr spezifische Tests. Bei anderen genügt eine Herangehensweise wie an Webservices."

Zudem habe man bei den Satelliten die Möglichkeit, eine neue Version erst auf einige wenige Satelliten aufzuspielen und dann deren Verhalten mit dem der restlichen, also denen mit der alten Version, zu vergleichen. Danach kann noch einmal nachgebessert oder ein Rollback durchgeführt werden, bevor die Software auf allen Satelliten landet. Bei Raketen und Orbitern ist hingegen alles kritisch und muss sofort funktionieren.

Starlink wirft aber viele Informationen über den Betrieb von Linux-Computern im Weltraum ab. Ein einziger Starlink-Start enthält 60 kleine Starlink-Satelliten. Diese 60 Satelliten enthalten zusammen "mehr als viertausend Linux-Computer", schreibt Monson. Zusammengenommen habe die Starlink-Konstellation 30.000 Linux-Nodes mit mehr als 180 Fahrzeugjahren an Orbiterfahrung.

Es wird viel getestet

Klar ist, dass neue Software ausführlich getestet werden muss. Aber auch bei nicht geänderten Programmteilen kann es durch benachbarte Änderungen zu unerwünschten Nebeneffekten kommen. Die Frage, wie bei SpaceX Software getestet wird, ist interessant - fällt doch das Testen in vielen Projekten bei knapper Zeit gerne mal als Erstes unter den Tisch.

Dietrick, dem führenden Software-Entwickler zufolge, wird bei SpaceX aber auf "jede Art, die wir uns vorstellen können" getestet. Er nennt Unit-Tests, containerisierte integrierte Tests und vollständige HITL-Tests, also Hardware-in-the-Loop-Tests für echte Flughardware - ebenfalls mit einer vollständigen Simulation.

Die integrierten computerisierten Tests haben den Vorteil, dass sie auf jeder Entwicklermaschine ausführbar sind, während es deutlich höheren Aufwands bedarf, um die Tests auch auf der Original-Hardware, für welche die Software letztlich bestimmt ist, laufen zu lassen. "Die Verbindung der Flugsoftware mit dem Simulator ist das leistungsstärkste Tool, das wir haben, insbesondere wenn es auf der realen Hardware ausgeführt wird. Wir können eine ganze Mission und sogar viele detaillierte Fehlerszenarien simulieren, wobei die Vehikel-Hardware nur auf einem Tisch im Labor liegt", erklärt Dietrick.

Wendy Shimata, die das Dragon-Software-Team leitet, wird noch etwas genauer: "Für jedes Fahrzeug haben wir eine Hardware im On-The-Loop-Simulator (alle flugkritische Hardware plus simulierte Physik und Erfassung), an der wir eine Vielzahl von Tests durchführen, bevor wir sie jemals in einem Serienfahrzeug oder für den Flug einsetzen."

Das Team stelle sicher, dass es Unit-Tests für den Code gibt und Funktionstests, um sicherzustellen, dass die Software wie beabsichtigt funktioniert. "Außerdem gibt es Tests auf Systemebene für Missionsphasen, die sowohl planmäßige als auch nicht planmäßige Fälle durchlaufen."