Wir fliegen zum Jupiter

Ein paar von uns wären vermutlich sofort dabei, wenn es tatsächlich möglich wäre, als Mensch zum Jupiter zu fliegen. Bislang ist dieses Privileg aber unbemannten Raumfahrten vorbehalten. Unter anderem deshalb, weil es etwa acht Jahre braucht, bis man beim größten Planeten unseres Sonnensystems angekommen ist.

Trotzdem fliegt die bevuta zum Jupiter. Denn unsere Software macht sich voraussichtlich im April 2023 auf den Weg dorthin. Und die ist ja irgendwie ein Teil von uns.

Wie es so ist, in einem Raumfahrtprojekt mitzuarbeiten, was unsere Software dort macht, und was wir daraus gelernt haben, darüber haben wir mit unserem Kollegen Felix Winkelmann gesprochen, der bei uns, zusammen mit dem Max-Planck-Institut für Sonnensystemforschung (MPS), an der Software für dieses ehrgeizige Projekt gearbeitet hat.

Aber erstmal verraten wir euch, was die Mission, an der wir zusammen mit dem MPS beteiligt sind, zum Ziel hat.

Gibt es Wasser in Europa?

Die Frage klingt nicht mehr ganz so abstrus, wenn man weiß, dass Europa nicht nur ein Kontinent, sondern auch einer der Jupitermonde ist. Gemeinsam mit Ganymed, Kallisto und 89 weiteren Monden umkreist Europa den größten Planeten unseres Sonnensystems. Und eine der Fragen, die Wissenschaftler*innen umtreibt, ist ganz einfach: Gibt es flüssiges Wasser im Inneren dieser Monde? Denn das wäre die Grundvoraussetzung dafür, dass dort Leben, wie wir es kennen, entstehen könnte.

Eiskalt – und trotzdem lebendig?

Im Jupitersystem ist es kalt. So liegt zum Beispiel die durchschnittliche Oberflächentemperatur des Mondes Europa bei etwa -171°C. Aber es gibt Hinweise darauf, dass sich unter der äußeren Eisschicht der Monde unterirdische Ozeane erstrecken. Durch Ritzen und Spalten könnten Teilchen aus dem Inneren der Eismonde in die Atmosphäre gelangen. Und dort möchte JUICE sie messen.

Die Raumsonde JUICE (Jupiter Icy Moon Explorer) der europäischen Weltraumagentur ESA soll am 13. April 2023 zum Jupitersystem aufbrechen und dort jede Menge Fragen beantworten – unter anderem die nach dem Wasser unter der Oberfläche. Dafür benötigt sie verschiedene wissenschaftliche Instrumente, die zum Beispiel die Zusammensetzung der Atmosphäre messen. Zwei dieser Instrumente steuert das Max-Planck-Institut für Sonnensystemforschung bei . Damit die Messinstrumente mit dem Satellitenbus kommunizieren und ihre Messergebnisse übertragen können, brauchen sie eine entsprechende Software – und an der Software für die Integration des Submillimeter Wave Instrument (SWI) haben wir gearbeitet. Insbesondere Felix Winkelmann, Gründer des Chicken Scheme Projekts und Software-Entwickler bei der bevuta seit 2012, war mehrere Jahre mit dem Projekt am Max-Planck-Institut für Sonnensystemforschung in Göttingen beschäftigt.

Felix, du hast von 2014 bis 2022 zusammen mit dem MPS an der Software für das Submillimeter Wave Instrument gearbeitet. Kannst du uns erklären, was die Aufgabe dieses Instruments ist?

Natürlich. Das SWI soll im Jupitersystem – also in der Jupiteratmosphäre und in der Atmosphäre der drei Eismonde Ganymed, Kallisto und Europa – chemische Verbindungen aufspüren. Das tut es, indem es die Infrarotstrahlung analysiert, die aus dem Jupitersystem ins All gesendet wird (aus Gestein, Eiskrusten und Atmosphären). Wasser, Sauerstoff, Kohlenstoffoxid, Methan und andere Kohlenwasserstoffe erscheinen als Absorptionslinien im Spektrum der Infrarotstrahlung – und dies hoffen wir, mit dem SWI messen zu können.

Und eure Software verbindet das SWI mit dem Satellitenbus – richtig?

Genau. Wir haben am Design der Flight Software mitgearbeitet – also der Software, die tatsächlich mit in der Raumsonde mitfliegt – als auch das EGSE (Electronic Ground Support Environment) entwickelt – quasi das Software-Gegenstück, das auf der Erde bleibt. Außerdem die dazugehörige Software für den Test sowie zur Verknüpfung von Flight Software und EGSE.

Ist es anders, für ein Raumfahrtprojekt zu entwickeln als für andere Softwareprojekte?

Ja, in mancher Hinsicht schon. Die ESA gibt zum Beispiel sehr strikte Richtlinien vor, nach denen die Software zu entwickeln ist. Die Anforderungen beziehen sich auf die Projektorganisation genauso wie auf die Qualität der Komponenten und Prozesse sowie auf ihre Funktionsfähigkeit. Man ist in vielen Aspekten eingeschränkter als bei anderen Projekten.

Kannst du dafür ein Beispiel geben?

Vom technischen Standpunkt aus gesehen ist die eingeschränkte Rechenleistung der Hardware eine Herausforderung. Die Hardware-Basis, auf der die SWI-Software läuft, ist ein SPARC LEON Board der Firma Gaisler und hat eine Taktfrequenz von gerade mal 20 MHz und einen Arbeitsspeicher von 2 MB, also etwa so viel wie ein typischer Computer auf der Erde Ende der 1980er Jahre. Viel richtet sich nach der Maßgabe, dass der Energieverbrauch des gesamten Systems inklusive aller Subsysteme so niedrig wie möglich sein muss.

Woher kommt denn überhaupt die Energie?

Anders als bei US-Raumsonden, die meist mit Radionuklidbatterie ausgestattet sind, speist JUICE seine Systeme ausschließlich mit Energie aus Sonnenkollektoren. Die sind mit einer Gesamtfläche von 85 m2 die größten, die jemals für eine interplanetare Raumfahrtmission gebaut wurden. Das müssen sie wohl auch sein, denn weil die Mission so weit weg von der Sonne operiert, ist die Ausbeute nicht sonderlich hoch. Im schlechtesten Fall werden nur 46 W/m² erreicht.

Dabei kommt JUICE der Sonne während seiner Reise erstmal noch näher, oder?

Richtig. Um ausreichend Schwung für die lange Strecke bis zum Jupiter zu holen, wird die Raumsonde zunächst die Schwerkraft von Erdmond, Erde und Venus nutzen. Dabei kommt sie so nah an die Sonne heran, dass mit Temperaturen von ca. +110 °C zu rechnen ist. Am Ziel angekommen, das fünfmal so weit von der Sonne entfernt ist wie die Erde, fallen die Temperaturen aber auf bis zu -230 °C. Das heißt, das gesamte System, also auch hochsensible Mechanik und Elektronik, muss massive Temperaturunterschiede aushalten können. Ganz abgesehen von der hohen elektromagnetischen Strahlung, die am Jupiter tausende Male stärker ist als hier auf der Erde, und vor der die Instrumente der Raumsonde geschützt werden müssen.

Wie wirkt sich denn die große Entfernung auf die Kommunikation zwischen Raumsonde und Erde aus?

Eine direkte Auswirkung der großen Entfernung sind die sehr langen Signallaufzeiten und damit Latenzen: Auf die von der Raumsonde übertragenen Daten warten wir hier zwischen 33 und 53 Minuten. Bis überhaupt eine Reaktion auf ein Kommando an die Raumsonde eintrifft (Round-Trip-Time), dauert es also bis zu 1 h 46 Min.

Dazu kommt, dass das Netz aus Empfangsanlagen hier auf der Erde Daten von verschiedenen Satelliten und Raumsonden empfängt und deshalb für jeden Sender nur zu begrenzten Empfangszeiten verfügbar ist. Für die Datenübertragungen gibt es einen klar festgelegten Stundenplan: Wann steht welche Empfangsanlage für welche Mission zur Verfügung? Vorgesehen ist für JUICE ein durchschnittliches Kommunikationsfenster von 8 Stunden pro Tag.

Weil das unter anderem aufgrund der eingeschränkten Zeitfenster alles bis ins kleinste Detail geplant sein muss, ist der erlaubte Datenumfang für die zu übertragenden Messdaten begrenzt. Vor allem aber passiert auf dieser Mission nichts spontan. Alle „Telecommands“ (Operationen, die der Instrumentencomputer ausführen soll) werden Wochen voraus auf die Millisekunde geplant und präzise ausgeführt.

Klingt anstrengend und zeitintensiv.

Ja, das ist es auch. Jeder einzelne Schritt muss zahlreiche Test-, Validierungs- und Freigabeprozesse durchlaufen, bevor er ausgeführt werden kann und muss lange im Voraus bekannt sein.

Das ist unter anderem auch für die Planung der Energieversorgung wichtig. Kein Gerät darf sich einfach so einschalten oder den Modus wechseln – etwa vom wartenden Idle Mode in den deutlich energieintensiveren Science Mode. Das Kontrollzentrum muss jederzeit genau wissen, wie viel Strom das Instrument wann verbrauchen wird. Nur so lässt sich die knappe Energie gezielt verteilen.

Es gibt also nicht viel Spielraum für Spontanreaktionen?

Quasi gar keine. Selbst kurzfristige Änderungen werden mindestens 24 Stunden vorher (meist deutlich länger) festgelegt. Das Gerät selbst reagiert tatsächlich nur im Notfall spontan – wenn irgendetwas Unerwartetes passiert, schaltet es sich ab. Das muss aber auch kontrolliert und sauber passieren, sonst kann die Hardware Schaden nehmen. Und auch die Autonomie der Software ist um ein Vielfaches geringer als in anderen Projekten.

Was bedeutet das konkret?

Die Software muss zum Beispiel zu jedem Zeitpunkt Befehle vom Bordcomputer empfangen können, ganz egal, wie ausgelastet sie gerade ist oder in welchem Modus sie sich befindet – ob sie etwa gerade mitten in der Messung ist oder Befehle ausführt.

Auch wenn die Software einerseits besonders streng validiert und getestet wird, muss sie natürlich flexibel in Bezug auf die wissenschaftlichen Anforderungen sein. Es kann ja sein, dass sich im Laufe der Messungen Erkenntnisse ergeben, die Anpassungen nötig machen. Hierzu gibt es eine eingeschränkte Skripting-Möglichkeit für Mess-Szenarien, so dass die Messpläne modifizierbar sind. Es gilt aber: So wenig Veränderung wie möglich, weil alle Veränderungen immer aufwendig validiert werden müssen. Es ist eine ständige Gratwanderung zwischen Flexibilität und Sicherheit.

Konntet ihr dafür auf bereits bestehenden Komponenten aufbauen oder ist alles an der Software neu?

Die Software ist vollständig missionsspezifisch – alle Komponenten sind Neuentwicklungen. Das war für mich auch ein ganz neues Erlebnis, weil wir sonst viel mit Open-Source-Bibliotheken arbeiten und der eigene Code dann nur einen Teil der Software ausmacht.

Klingt nach einer herausfordernden Aufgabe.

Ja, die ist es, auf jeden Fall, aber das ist ja gerade das Spannende daran. Um ehrlich zu sein, habe ich aber die organisatorischen Herausforderungen als viel größer erlebt als die technischen. Technische Probleme lassen sich immer irgendwie bewältigen. Wenn die Ressourcen dazu ausreichen.

Organisatorisch ist das nicht immer so einfach. Die vielen extern ausgelagerten Subsysteme des Instruments bringen einen hohen Reibungsverlust im Austausch von Informationen mit sich. Dazu kommt, dass Wissenschaftler andere Anforderungen haben als Ingenieure, dadurch entstehen Missverständnisse. Zum Beispiel durch unterschiedliche Benennungen oder Auffassungsweisen ein und desselben Konzeptes.

Das heißt, das Arbeiten mit Maschinen ist einfacher als mit Menschen?

Könnte man so sagen. (lacht)

Eigentlich sind aber weniger die Menschen das Problem, sondern die Strukturen. Die ESA erzwingt einen hohen bürokratischen Aufwand, der mit einer (geteilten) Stelle schwierig zu bewältigen ist.

Und es gab auch eine recht hohe Fluktuation innerhalb des Projektteams von Wissenschaftlern, Ingenieuren und Managern, das führte dazu, dass sich Anforderungen immer mal wieder geändert haben und Ansprechpartner fehlten.

Wenn du eine Nachfolge einarbeiten müsstest, was würdest du ihr als Empfehlung mit auf den Weg geben?

Die direkte Kommunikation suchen! Einen direkten Kontakt zu anderen Abteilungen und Unternehmen herzustellen, hat uns immer am schnellsten ans Ziel gebracht. Zum Beispiel haben wir uns direkt mit CBK in Polen ausgetauscht, wo die DPU (Data Processing Unit) und das Interface FPGA (Field Programmable Gate Array) entwickelt wurden.

Um erste Verständnishürden zu überwinden, haben wir uns außerdem mit den Entwicklern für ein anderes Instrument im MPS kurzgeschlossen. Der Jargon und die Denkweisen in der Entwicklung von Instrumentensoftware waren zum Teil doch recht neu für uns. Hätten wir das alles auf schriftlichem Weg zu lösen versucht, hätte das deutlich mehr Zeit gekostet.

Also doch wieder mit Menschen arbeiten.

Auf jeden Fall. Die Zusammenarbeit in unserem kleinen Team war auch wirklich gut und wir haben viel daraus mitgenommen und gelernt. Vor allem über die völlig unterschiedlichen Anforderungen eines Weltraumprojekts, das mit ganz anderen Einschränkungen zu tun hat als konventionelle Software-Projekte.

Wie geht es mit dem Projekt jetzt weiter?

Das Instrument ist in die Raumsonde eingebaut und wurde bei Airbus Defence and Space ausgiebig getestet. Es handelt sich hier ja um 11 verschiedene Instrumente aus der ganzen Welt, jedes mit spezifischen Problemstellungen und Herausforderungen, jeweils Konsortien von mehreren Firmen und Institutionen, die sich koordinieren müssen. Wir sind soweit zufrieden mit der SWI-Software, die Architektur ist solide und das System ist effizient. Wirklich bewähren wird sich alles erst in ein paar Jahren, wenn erste Messungen gemacht werden. Momentan verlagert sich die Entwicklung bei SWI nun auf Fragen der Datenarchivierung und -auswertung und auf die wissenschaftliche Planung.

Das heißt, es kann jetzt losgehen?

Eigentlich schon, ja. Die Raumsonde ist inzwischen auch im Raumfahrtzentrum in Kourou in Französisch Guayana angekommen. Innerhalb des geplanten Startfensters im April 2023 wird derzeit der 13. April angestrebt. Es wird also ernst. :)

Wird bestimmt ein tolles Gefühl, wenn die eigene Software tatsächlich zum Jupiter fliegt, oder?

Ja, das erfüllt einen Kindheitstraum, Astronaut werden ist ja doch nicht so einfach… 😄. Aber natürlich ist der persönliche Anteil immer eingeschränkt, so ein Projekt ist ja das Ergebnis vieler beteiligter Personen, die (in Anbetracht der langen Projektlaufzeit) kommen und gehen. Aber selbst triviale Details sind hier von entscheidender Bedeutung und das ergibt einen ganz neuen Blick auf die tägliche Arbeit. Hier mitzuarbeiten war schon eine aufregende Erfahrung, aber es macht auch demütig: Es kann so viel schiefgehen und die technischen Rahmenbedingungen sind extrem. Weltraumtechnologie ist keine Magie, darin stecken enorm viel Planung, Arbeit und Ressourcen. Aber sollte alles gut gehen, und die Software (und mein kleiner Anteil daran) am Ende ihre Aufgaben zufriedenstellend lösen, dann wäre das schon ein großartiges Erlebnis. Ich bin gespannt.

Bildnachweise

Headerbild: Family Portrait of Jupiter's Great Red Spot and the Galilean Satellites, © NASA/JPL/DLR

Jupitermond Europa, aufgenommen während der NASA-Mission "Juno" am 29. September 2022 | © Image data: NASA/JPL-Caltech/SwRI/MSSS | Image processing: Kevin M. Gill CC BY 3.0

Operating in an extreme environment (© acknowledgement: work performed by ATG under contract to ESA, CC BY-SA 3.0 IGO

Die JUICE-Raumsonde während funktionaler Tests und Reinigungsarbeiten im Raumfahrtzentrum Guayana in Kourou. © Lars Naber, Auf Distanz