Linux im Orbit? Das ist seit vielen Jahren Wirklichkeit. Mit einigen Tricks hat das freie Betriebssystem die Vorherrschaft im Weltraum angetreten.

“Der Weltraum, unendliche Weiten. Wir schreiben das Jahr 2200.” So beginnt die bekannte Geschichte von Star Trek. Welche Software die schicken LCARS-Displays auf der Brücke des Raumschiffs Enterprise befüllt, wird in den Filmen nicht verraten – dass es aber eine Weiterentwicklung von Linux sein könnte, wäre durchaus denkbar. Schon heute transportieren regelmäßig Raketen wie die Falcon 9, deren Software maßgeblich auf Linux basiert, Satelliten, Fracht und Personen in den Weltraum (Abbildung 1).

Abbildung 1: SpaceX vertraut bei der Steuerung seiner Raumfahrzeuge auf Linux. Quelle: NASA (iss073e0545547)

Linux hilft sowohl bei der Steuerung als auch beim Wiedereinfangen der Flüssigtreibstoff-Booster, die daraufhin für den nächsten Flug aufbereitet werden. “Powered by Linux” sind auch die per Falcon 9 im Weltall ausgesetzten, Zigtausende Starlink-Satelliten. Dasselbe gilt für die Raumkapsel Crew Dragon, mit der Astronautinnen und Astronauten sicher und (im Vergleich zu den Apollo-Missionen) bequem die Reise zur und von der Internationalen Raumstation ISS zurück zu Mutter Erde antreten.

Komplexe Missionen benötigen betriebssichere Software. Schon der kleinste Fehler kann zum Verlust des Raumfahrzeugs und damit auch zum Tod der Passagiere führen, vom finanziellen Verlust ganz abgesehen. Zu Zeiten des Space-Shuttles benötigte jede einzelne Mission eine eigens dafür erstellte Software, die auf redundant ausgelegten Spezialrechnern lief. Genau genommen handelte es sich sogar um zwei Software-Instanzen, da nicht nur die Hardware redundant ausgelegt war, sondern auch die Software. Ein immenser Aufwand!

Konservative Ingenieurinnen und Ingenieure sahen und sehen aus Gründen der Sicherheit und Zuverlässigkeit keine Alternative zu speziell ausgewählten Hard- und Softwarekomponenten, die typischerweise dem MIL-Standard entsprechen und mit großen Temperaturschwankungen umgehen können. Sie kommen auch besser mit der im Weltraum auftretenden Strahlung zurecht. Dem großen Durchbruch bei der Eroberung der unendlichen Weiten stehen allerdings die damit verbundenen exorbitanten Kosten entgegen.

Startklar

Einer der Gründe für den Erfolg von SpaceX liegt darin, einen anderen Weg zu gehen. SpaceX setzt auf Standardhardware und eben auf Linux. Dabei läuft das freie Betriebssystem nicht einfach nur auf Notebooks, wie auf der ISS, sondern übernimmt tatsächlich die Steuerung missionskritischer Systeme wie eben der Falcon 9, der Crew Dragon oder auch des Starship. Linux im Orbit hat bereits in über mehreren hundert Jahren Orbitalzeit seine Zuverlässigkeit und Eignung unter Beweis gestellt. Sogar die NASA wagte schon erste Schritte mit Linux: Beim berühmten Mars-Hubschrauber Ingenuity saß der Pinguin auf dem Pilotensitz [2].

Allerdings greifen Entwicklerinnen und Entwickler nicht zum aktuellen Release-Kandidaten des Linux-Kernels, sondern zu einer typischerweise bereits abgehangenen Version. SpaceX setzte lange Zeit auf den bewährten Kernel 3.2, in den modernen Satelliten-Generationen kommt vermutlich eine etwas aktuellere Version mit einer Vier oder sogar einer Fünf vor dem Punkt zum Einsatz. Diese Kernel bringen bereits alles mit, was man für einen Raumflug benötigt, zudem ist die Codebasis noch vergleichsweise übersichtlich.

Das Hauptproblem dieser Kerne, die fehlende Echtzeitfähigkeit, muss allerdings über den bekannten PREEMPT_RT-Patch nachgerüstet werden. In aktuellen Kerneln hat Linus Torvalds ihn mittlerweile eingepflegt, sodass damit ein Patchen nicht mehr notwendig wäre. Abseits von Echtzeitfähigkeit gibt es nach Aussage der beteiligten Entwicklerinnen und Entwickler keine weiteren signifikanten Änderungen, die zur Ansteuerung der diversen Sensoren und Aktoren der Raumfahrzeuge und Satelliten benötigt würden, sieht man von den Gerätetreibern ab.

Systembuilder

Die Software an Bord eines Raumfahrzeugs besteht nicht nur aus dem Kernel mit den Gerätetreibern, es wird auch ein Userland benötigt. Wie im Bereich der eingebetteten Systeme üblich und den besonderen Anforderungen und vorhandenen Ressourcen geschuldet, kommt ein Systembuilder zum Einsatz, um ein maßgeschneidertes Gesamtsystem zu erstellen. SpaceX greift hier nicht zu Yocto oder OpenEmbedded, sondern setzt auf das erheblich schlankere und ressourcenschonendere Buildroot, das aus einer Konfiguration in kurzer Zeit ein komplettes Linux mit genau den benötigten Komponenten zusammenschraubt. Ein solches System lässt sich leichter pflegen und vor allem testen als etwa ein ausgewachsenes Debian.

Die Software selbst, so erklärten die Entwicklerinnen und Entwickler von SpaceX 2020 in einem Ask me Anything (AMA [3]) auf Reddit, ist Echtzeitprogrammierung vom Feinsten [4]. Dazu gehören die Verwendung von C als Programmiersprache sowie die Vermeidung von Endlosschleifen und unnötiger Parallelität. Die ausgefuchste Vergabe von Real-Time-Prioritäten an Kernel-Threads vermeidet eine sogenannte Prioritätsinversion, mit der Linux aber prinzipiell sogar zurechtkäme. Die benötigten Ressourcen werden direkt zum Programmstart reserviert (Stichwort Stack- und Heap-Prefault), um zeitliche Probleme durch Swapping oder Paging zu vermeiden.

Bis zu diesem Punkt gibt es noch kaum Unterschiede zwischen einem eingebetteten System auf unserem Heimatplaneten und einem in den Weiten des Weltraums. Selbst auf der Erde gibt es genügend Anwendungen, die außergewöhnliche Anforderungen an das Zeitverhalten, die Betriebssicherheit und die Zuverlässigkeit stellen. Der wesentliche Unterschied zu einem Raumfahrzeug zeigt sich letztlich im Zeitmanagement. Albert Einstein hat uns die Erkenntnis beschert, dass Zeit relativ und raumabhängig ist. Diese Zeitdilatation gilt es beim Betrieb außerhalb unseres Planeten unbedingt zu berücksichtigen.

Gekrümmte Raumzeit

Das Science-Fiction-Epos “Interstellar” führt das eindrucksvoll vor Augen. Die Astronauten Cooper, Brand und Doyle verweilen nur wenige Stunden zur Erkundung auf Millers Planet, auf dem im Orbit geparkten Raumschiff Endurance jedoch vergehen derweil über 23 Jahre. Aufgrund der gewaltigen Anziehungskraft des Schwarzen Lochs Gargantua läuft die Zeit auf dem Planeten aus Sicht des Raumschiffs extrem langsam ab.

Hätte der auf der Endurance zurückgebliebene Romilly einen Videostream zum Lander, sähe er alles in extremer Zeitlupe, nahezu als Standbilder. Das liegt daran, dass für jedes Objekt die Zeit in Abhängigkeit von Bewegung und Position individuell vergeht. Für bewegte Objekte läuft sie langsamer als für ruhende, und ebenso vergeht Zeit für Systeme langsamer, die sich wie Millers Planet tiefer in einem Gravitationsfeld befinden.

Nehmen wir als Beispiel einen GPS-Satelliten, der sich mit 3,87 km/s bewegt – immerhin 0,0013 Prozent der Lichtgeschwindigkeit –, ergibt sich allein dadurch alle 24 Stunden eine Zeitabweichung von -7 Mikrosekunden gegenüber einem Beobachter am Boden. Andererseits resultiert aus der reduzierten Gravitation in der Erdumlaufbahn eine tägliche Zeitabweichung von +45 Mikrosekunden. In Summe führt das zu einem Unterschied von +38 Mikrosekunden – ein GPS-Satellit altert also aus unserer Sicht langsamer. Ohne Zeitkorrektur würde unsere GPS-basierte Navigation jeden Tag um 11,4 km danebenliegen.

Langer Rede kurzer Sinn: Ein Objekt im Orbit benötigt neben der Eigenzeit (seiner konstant verlaufenden Lebenszeit) auch die Weltzeit (UTC) beziehungsweise die internationale Atomzeit (TAI, Temps Atomique International) von Mutter Erde.

Zwei Herzen

Darauf ist die Zeitverwaltung des Linux-Kernels vorbereitet. Grundsätzlich arbeitet Linux mit einem Zeitzähler, der beim Booten bei null anfängt und dann mit hoher Frequenz – und damit hoher Genauigkeit – immer weiter hochzählt. Auf den Wert dieses Zeitzählers greift man über den Zeitgeber CLOCK_MONOTONIC_RAW zu. Das ist die Eigenzeit des Systems.

Unten auf dem Planeten lassen sich die relativistischen Effekte der Zeitdilatation kaum messen. Eigentlich sollten also alle deutschen Uhren gleich zur gesetzlichen Referenz laufen, der Cäsium-Atomuhr der Physikalisch-Technischen Bundesanstalt in Braunschweig, deren Zeitzeichen der Sender DCF77 ausstrahlt. Da das jedoch nicht der Fall ist, korrigieren Betriebssysteme sowohl die Frequenz als auch die Phase mithilfe von Netzwerkprotokollen wie dem Network Time Protocol (NTP). Die korrekte Zeit berechnet sich dann aus der Eigenzeit plus einem Offset und einer Drift. Diese korrigierte Eigenzeit ist über den Zeitgeber CLOCK_MONOTONIC zugänglich.

Um damit auf die aktuelle, für die meisten Anwendungen relevante Weltzeit UTC zu kommen, muss das System nur die zum Systemstart vorherrschende Weltzeit addieren, die sich über den Zeitgeber CLOCK_REALTIME auslesen lässt. Sie berücksichtigt übrigens auch Zeitsprünge, wie sie bei der Umstellung von Normal- auf Sommerzeit und umgekehrt vorkommen.

Im Orbit lässt man diesen Mechanismus einfach weiterlaufen. CLOCK_MONOTONIC_RAW liefert dann die Eigenzeit des Systems, quasi seine Lebenszeit, während CLOCK_MONOTONIC und CLOCK_REALTIME weiterhin mit der Erde synchronisiert werden. Je weiter sich ein Raumschiff von der Erde entfernt, desto mehr spielt die Zeitdilatation eine Rolle, und die CLOCK_MONOTONIC_RAW und CLOCK_MONOTONIC laufen auseinander (Abbildung 2). Die Werte für Offset und Drift wachsen also an.

Abbildung 2: Je länger sich ein Satellit im Orbit befindet, desto mehr laufen Lebens- und Weltzeit auseinander.

Zeit stauchen

Für das Management dieser Zeiten ist im Linux-Kernel der System Call adjtimex() zuständig. Er stellt sicher, dass es zu keinen Zeitsprüngen kommt, da diese ansonsten das System ziemlich durcheinanderbringen würden. Tatsächlich wird die CLOCK_MONOTONIC bei größeren Differenzen peu à peu angepasst.

Der Vorteil der Synchronisation über ein Protokoll direkt mit der koordinierten Weltzeit (UTC) liegt darin, dass kein komplexer Algorithmus zur Berechnung der Weltzeit notwendig ist. Die Fehler, die sich zwischen den Synchronisationszeitpunkten einschleichen, lassen sich vernachlässigen. Als Protokoll zur hochgenauen Zeitsynchronisation kommt anstelle von NTP das Precision Time Protocol (PTP [1]) zum Einsatz. Es ist einfacher zu implementieren und vor allem dank typischerweise vorhandener Hardwareunterstützung auf Mikrosekunden genau. Mit etwas Schliff lässt sich sogar Nanosekundengenauigkeit erzielen.

Die aktuellen Werte der Zeitgeber Ihres Linux-Systems lesen Sie bei Bedarf auf der Konsole über das Kommando timedatectl status aus. Der Befehl timedatectl timesync-status zeigt zudem die Korrekturfaktoren an. Ein Beispiel für dessen Ausgabe zeigt Listing 1. Am Anfang stehen die Netzwerkparameter. Da die Daten nicht auf einem Satelliten erfasst wurden, sondern auf der Erdoberfläche, ist NTP statt PTP im Einsatz. Die Angaben umfassen unter anderem die IP-Adresse der Zeitquelle, die Anzahl der Hops zur realen Zeitquelle (Stratum 2), eine ID und schließlich die theoretische Auflösung der lokalen Uhr (hier 1 Mikrosekunde).

Bei Leap handelt es sich um ein Warn-Flag. Steht es auf jump statt auf normal, stünde eine Schaltsekunde an, die das System daraufhin einfügen oder löschen müsste. In der Raumfahrt ist das mindestens so kritisch wie hier auf der Erde. Rechnersysteme mögen es gar nicht, wenn die Zeit eine Sekunde lang stehenbleibt oder gar rückwärts springt.

Als Nächstes folgen Synchronisationswerte. Die Root distance gibt die geschätzte, kumulierte Ungenauigkeit (hier 754 µs) gegenüber der primären Zeitquelle (Stratum 0) an. Beim Offset handelt es sich um die Phasendifferenz. Der Rechner im Beispiel hinkt mehr als 2,2 Millisekunden hinter der Serverzeit her. Diesen Wert versucht der Kernel nun über langsames Beschleunigen – quasi ein Stauchen der Zeit – auszugleichen. Die reine Netzwerklatenz (Delay) beträgt im Beispiel 23 Millisekunden. So lange braucht ein Paket, um hin und wieder zurück zu wandern. Der Jitter gibt an, um welchen Betrag diese Latenz schwankt.

Bleibt als Letztes die hier mit +0,318ppm ausgewiesene Frequency. Die Einheit ppm steht für Parts per Million und bedeutet hier konkret, dass der lokale Quarz des Systems von Natur aus minimal zu langsam schwingt. Ohne Korrektur gehen pro einer Million Sekunden etwa 0,318 Sekunden verloren. Anders ausgedrückt: Ohne Korrektur ginge die Uhr alle 36 Tage um etwa eine Sekunde falsch.

$ timedatectl timesync-status
       Server: 185.125.190.57 (ntp.ubuntu.com)
Poll interval: 34min 8s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: C279CFF9
    Precision: 1us (-25)
Root distance: 754us (max: 5s)
       Offset: +2.253ms
        Delay: 23.210ms
       Jitter: 2.046ms
 Packet count: 26
    Frequency: +0,318ppm

Interplanetar

Die Erde taugt allerdings nur so lange als zeitlicher Bezugspunkt, wie wir uns nicht im interplanetaren Raum bewegen. Laut der Relativitätstheorie müssen wir nämlich für unsere Zeitmessungen den lokalen Massenschwerpunkt als Basis verwenden, das sogenannte Baryzentrum. Im Fall unseres Sonnensystems liegt das Baryzentrum in der Nähe der Sonne. Tatsächlich hat die International Astronomical Union (IAU) 1991 mit der Barycentric Coordinate Time (TCB, Temps Coordonnée Barycentrique) eine solche Sonnensystemzeit etabliert (Abbildung 3).

Abbildung 3: Das Schema der Beziehungen zwischen den unterschiedlichen Zeitsystemen von UTC (Erde) bis TCB (Sonnensystem).

Es erfordert eine Umrechnung über vier Dimensionen, um von der koordinierten Weltzeit UTC oder besser von der internationalen Atomzeit auf die baryzentrische Koordinatenzeit respektive die baryzentrische dynamische Zeit (TDB, Temps Dynamique Barycentrique) zu kommen. Dabei stellt die TCB den Zeitwert in vierdimensionalen Koordinaten dar. Da sie unabhängig von Gravitationseinflüssen unseres Sonnensystems selbst ist, läuft diese Uhr vereinfacht ausgedrückt im Jahr um 490 Millisekunden schneller als unsere Erdzeit. Als Nullpunkt für diese Zeit gilt übrigens per Definition der 01.01.1977. Im Linux-Kernel selbst spielt die baryzentrische Zeit gegenwärtig allerdings keine Rolle.

Neben dem Problem der gekrümmten Raumzeit stellt die Lebensfeindlichkeit des Weltraums den Betrieb vor große Herausforderungen. Systeme müssen dort sowohl mit Extremtemperaturen als auch mit Temperaturschwankungen umgehen. Von -180 bis +180 Grad Celsius – und beim Wiedereintritt in die Erdatmosphäre bis zu 2500 Grad Celsius – kommt alles vor. Zudem gibt es noch die Strahlung (Radiation), die nicht nur für den Menschen sehr gefährlich ist, sondern auch die Bits in den Onboard-Speichern kippen lässt. Hardware, die mit solchen Umweltbedingungen leidlich klarkommt, kostet Unsummen und stellt wesentlich weniger Funktionen bereit als heutige Prozessoren. Für moderne Software wie Linux eignet sie sich nur bedingt.

Zaubertrank

COTS-Komponenten (Commercial off-the-shelf, also kommerzielle Bauteile aus dem Regal) gepaart mit einem quelloffenen, hochfunktionellen Linux bilden die Zutaten eines Zaubertranks, der eine deutlich preiswertere Entwicklung bei gleichzeitig gesteigerter Funktionalität verspricht.

Die Geheimzutat, die das Radiation-Problem angeht, nennt sich Redundanz. In jedem der 9634 Starlink-Satelliten im Erdorbit (Stand Februar 2026) werkeln parallel mindestens drei Dual-Core-Prozessoren auf x86-Basis. Auf jedem davon läuft ein separates Linux. Ein hochverfügbarer Voter auf Basis einer PowerPC-CPU fällt anhand ihrer Rechenergebnisse im Ausgabezweig für die Aktorik eine Mehrheitsentscheidung (Abbildung 4).

Abbildung 4: Redundanz über Standardhardware löst zunehmend veraltete, aber weltraumerprobte Spezialkomponenten ab.

Damit ist Linux im Orbit mittlerweile keine Vision mehr, sondern schon lange Realität. Dank Redundanz kommt das freie Betriebssystem mit der lebensfeindlichen Umgebung des Weltalls zurecht, dank des pfiffigen Zeitmanagements handhabt Linux auch die gekrümmte Raumzeit. Die bei Star Trek verwendete Sternzeit kennt es allerdings noch nicht. “Geduld du haben musst, mein junger Padawan.” Bis zum Jahr 2200 ist es ja noch etwas hin … (jlu)