Schaltjahr legt OneWeb-Konstellation lahm

An das Y2K-Problem können sich die Älteren unter uns noch gut erinnern. Man befürchtete damals weitreichende Softwareausfälle, weil bei vielen Systemen das Jahr nur mit zwei Ziffern gespeichert war – die Entwickler der meist schon sehr alten Softwarecodes hatten nicht damit gerechnet, dass ihre Software am 1.1.2000 immer noch laufen würde.
Mit dieser Ausrede kann der Betreiber der OneWeb-Satellitenkonstellation, die in London sitzende Firma Eutelsat OneWeb, allerdings nicht kommen. Deren Software im Bodensegment der Konstellation hatte am 31.12., dem 366sten Tag des Jahres 2024, offenbar ein Problem damit, dass es sich um ein Schaltjahr handelte. Dabei kommen Schaltjahre alle vier Jahre vor. Offenbar lag das Problem in der Berechnung des Zeitunterschieds zwischen GPS-Zeit und koordinierter Weltzeit UTC.
Die Pflege der Software im Bodensegment erledigt die US-Firma Hughes Network Systems im Auftrag von OneWeb. Deren Mitarbeiter mussten wohl kurzfristig ihre Silvesterparties absagen.
OneWeb umfasst aktuell mehr als 630 Satelliten in einer Bahnhöhe von 1200 km, von denen die allermeisten nach 2020 gestartet wurden. Ich vermute, dass im letzten Schaltjahr, also 2020, noch andere Software erwendet wurde, die dieses Problem nicht hatte. Ansonsten wäre es kaum zu verstehen, wieso das Problem jetzt auftauchte.
Der Systemausfall begann am 31.12.; erst 36 Stunden später ging es zumindestens teilweise wieder online. Erst nach 48 Stunden konnte zum Normalbetrieb zurückgekehrt werden, wie am 2. Januar verlautbarte.
Wie immer nach solchen Pannen steht eine ausgedehnte Untersuchung an, wie es dazu kommen konnte und ob sich noch weitere solcher dicken Hunde im System verbergen. Der interne Ärger zwischen Auftraggeber und -nehmer geht üblicherweise erst richtig los, wenn das Problem aus den Schlagzeilen verschwunden ist. Da wird wohl der eine oder andere Mitarbeiter auch noch den Skiurlaub absagen müssen.
Probleme, die die kommerzielle Nutzlast betreffen, sind schon schlimm genug, weil ja Nutzer sich auf die Verfügbarkeit der Kommunikationsinfrastruktur verlassen. Es könnte aber auch vorkommen, dass Softwareprobleme im Bodensegment zeitweise die Steuerbarkeit oder gar den Kommandozugriff unterbinden. Das ist besonders bei Megakonstellationen kritisch, weil bei so vielen Satelliten auf derselben Bahnhöhe das Zusatzproblem des Kollisionsrisikos besteht. Im Fall von OneWeb mit einer Bahnhöhe von 1200 km würden jegliche freigesetzte Trümmer viele Jahrhunderte im Orbit bleiben.
Mehr dazu hier (AWST) .
Interessant ja, dass altbekannte Probleme immer wieder auftauchen, dass es also kein „Lernen für immer“ aus früheren Fehlern gibt. Dafür gibt es auch in der Raumfahrt unzählige Beispiele, etwa:
– die NASA beaufsichtigte SpaceX beim Aufbau ihres Shuttledienstes zur ISS, weil sie neu im Geschäft sei, kaum aber Boeing bei ihrem Starliner-Programm , denn die NASA-Inspektoren nahmen an, Boeing sei ein alter Hase und wisse schon wie‘s läuft. Bis dann der erste Starliner-Testflug die Kontrolleure eines besseren belehrte, enthielt doch die Starliner-Software eine ganze Reihe von Problemen
– mehr als ein Landeversuch von privaten Raumfahrtunternehmen auf dem Mond ging schief und das obwohl sehr wohl bekannt ist auf was man bei einer Mondlandung achten muss
– die missglückte ESA-Marslandung mit Schiaparelli berücksichtigte offensichtlich die bekannte hohe Dynamik bei Eintritt in die Marsatmosphäre nicht, was zum Zerschellen von Schiaparelli führte. Und das obwohl Daten von NASA-Marslandungen zur Verfügung standen, die zeigten, dass es beim Eintritt in die Marsatmosphäre zu starken Wankel- und Drehbewegungen kommen kann.
Wobei: das gleiche beobachten wir ja auch im Alltag. Selbst heute kommt es noch vor, dass etwa Teekannen einen falsch geformten Ausguss haben, so dass das Wasser beim Einschenken am Ausguss klebt – und das trotz tausender Jahre Erfahrung.
Neu in der Raumfahrt scheint mir die hohe Anzahl von Satelliten nicht nur von SpaceX, sondern auch von anderen Organisationen, die bald schon hunderte bis tausende Satelliten in tiefen bis mittleren Umlaufbahnen kreisen lassen wollen. Vor ein paar Monaten las ich dazu, dass wir jetzt tatsächlich kurz vor dem Kessler-Syndrom stehen. Satelliten in sehr erdnahen Umlaufbahnen sind unproblematisch in Bezug auf die Gefahr des Kessler-Syndroms, aber ab vielleicht 600 Kilometer Höhe der Umlaufbahn werden die Folgen einer Kollision immer verheerender, denn Objekte in dieser Höhe verbleiben für viele Jahrzehnte im Umlauf. Eigentlich sollte man in solchen kritischen Höhen viel strengere Anforderungen an Satelliten stellen und die verantwortlichen Satellitenbetreiber sogar verpflichten, für die Entsorgung ihrer Satelliten aufzukommen.
Ja, Betreiber sollten (1) hohe Bahnen nach Möglichkeit vermeiden, (2) ihre Satelliten nach Missionsende zum Wiedereintritt bringen, (3) Deorbitierung durch Aufräumdienste ermöglichen.
Es gibt aber keine weltweiten Vereinbarungen dazu und sowieso keine Möglichkeit, solche Vereinbarungen durchzusetzen. OneWeb erfüllt immerhin schon Forderungen (2) und (3) (siehe auch hier), aber wenn es bei1200 km mal krachen sollte, nützt das auch nichts.