Was war das erste ungeplante „Over-the-Air“-Software-Update eines Raumfahrzeugs?

Februar bis August, mehrmals, 1969.

(TL;DR)

Q:

Was war das erste ungeplante „Over-the-Air“-Software-Update eines Raumfahrzeugs?

A:

Die Sonden Mariner 6 und 7 , die 1969 zur Beobachtung des Mars gestartet wurden , unterschieden sich von den früheren Sonden dadurch, dass sie neue Computer hatten, die neu programmiert werden konnten. Dadurch konnten erstmals Änderungen an den Missionen vorgenommen werden, die vor dem Start nicht geplant waren.

• Daher wäre eine Neuprogrammierung, ob geplant oder ungeplant vor dem Start, vor dem Start der CCS-Computer auf den Mariner-Sonden unmöglich gewesen. Das früheste Datum für ein OTA-Software-Update für irgendein Raumschiff wären also diese beiden Sonden im Jahr 1969.

(Dies führte auch dazu, dass die reprogrammierbaren und Backup-Computer bei den Viking-Missionen verwendet wurden, die wiederum identische Hardware bei den Voyager-Missionen von 1977 mit Softwareverbesserungen verwendeten, die es ermöglichten, die Meuterei von Voyager 2 zu unterdrücken.)

Mariner 6 und Mariner 7 waren identische Raumfahrzeuge, die am 24. Februar 1969 bzw. 27. März 1969 gestartet wurden, und ihre Missionen waren ausschließlich der Vorbeifluguntersuchung des Mars gewidmet.

Auf dem Weg zum Mars, wahrscheinlich aufgrund eines Batteriebruchs, wurde der Kontakt mit Mariner 7 am 30. Juli vorübergehend unterbrochen. Nach einer 7-stündigen Stille wurde der Kontakt wiederhergestellt, aber es wurde bald klar, dass das Instrument für die Meldung der Ausrichtung des Fernsehers verantwortlich war Kameras waren beschädigt und funktionierten nicht mehr. Ohne diese Informationen konnten die Kameras der Mariner 7 nicht richtig ausgerichtet werden, und da die Mars-Begegnung nahe bevorstand, musste schnell eine Lösung gefunden werden.

Am 1. August brachte die manuelle Kalibrierung durch Bodenmannschaften den Mars in das Sichtfeld der Kameras von Mariner 7, und am 2. August begann Mariner 7, Bilder von weit entfernten Begegnungen mit dem Mars zu übertragen. Die Restaurierung des Bildgebungssystems Mariner 7 war ein hervorragendes Beispiel für das Know-how, das Missionsbetreiber während dieser frühen interplanetaren Missionen entwickelt haben, und das Ereignis war ein Beweis dafür, wie wichtig es ist, einen reprogrammierbaren Computer auf dem Raumschiff zu haben .

https://nssdc.gsfc.nasa.gov/planetary/mars/mariner.html

Das neue Central Computer and Sequencer (CCS)-System, das zum ersten Mal bei dieser Mission verwendet wird und einen äußerst flexiblen Betrieb des Raumfahrzeugs ermöglicht, indem der Computerspeicher während des Fluges per Funkbefehl neu programmiert wird.

Frühere Missionen verwendeten ein relativ einfaches Gerät mit fester Sequenz, bei dem eine Reihe von Ereignissen vorprogrammiert und vor dem Start fest verdrahtet waren. Die einzigen Ereignisse, die nach dem Start geändert werden konnten, waren die Kurvendauern, das Geschwindigkeitsinkrement während des Kurses und die Zeit des Kurses während des Kurses.

Der Unterschied zu diesem neuen System war ... obwohl dieses Flugprogramm vor dem Start in seinen 128-Wörter-Speicher geladen wird, kann das CCS im Flug per Funkbefehl vollständig neu programmiert werden.

Während des Fluges der Raumschiffe Mariner VI und Mariner VII wurde das CCS viele Male vom Bodenkommando neu programmiert. Bis zum 17. Juni 1969 hatte die Mariner VI 575 Funkbefehle erhalten und die Mariner VII 217.

Die durch das umprogrammierbare CCS ermöglichte Flexibilität ermöglichte es dem Betriebsteam, viele Sequenzen durchzuführen, die zuvor nicht geplant worden waren . Es hat auch alternative Ansätze ermöglicht, wenn Probleme in anderen Subsystemen des Raumfahrzeugs aufgetreten sind.

Beispielsweise zeigten die Kalibrierung und das Testen auf dem Ersatzfernsehsystem von Mariner 1969, dass die automatische Blendensteuerung in einer Weise positioniert worden war, die eine übermäßige Helligkeit einiger der frühen Fernsehbilder bei Nahbegegnungen verursachen konnte. Dies war das Ergebnis abrupter Helligkeitsänderungen, die wahrgenommen wurden, als das Sichtfeld des Fernsehers über die Linie fegte, die die Dunkelheit des Weltraums und den hellen Rand des Planeten trennte. Das CCS wurde per Bodenbefehl umprogrammiert, um eine automatische Sequenz zu veranlassen, die die Kamerablendensteuerung über mehrere Bilder hinweg auf einer Position mit minimaler Verstärkung halten würde, wonach sie in einen automatischen Kompensationsmodus übergehen würde.

Dies ist nur ein Beispiel von vielen Fällen, in denen das CCS umprogrammiert wurde, um sich an Leistungsschwankungen anzupassen, so dass das Raumfahrzeug in der Lage ist, eine nominelle Mission auszuführen, falls das Befehlssystem zu einem späteren Zeitpunkt ausfällt.

Diskussion am Ende des Beitrags:

F. Sie erwähnen, dass das Ausmaß der Flexibilität die Effizienz gesteigert hat. Was verstehen Sie in diesem Zusammenhang unter Effizienz? Wurde er berechnet oder gemessen?

A. Die Verbesserung der Effizienz der Mission Mariner 1969 ist ein Beispiel: Während der Zeit nach der größten Annäherung an den Planeten wurden etwa 300 Befehle an das Raumschiff gesendet, um den Digitalcomputer an Bord neu zu programmieren, wodurch das Raumschiff eine Serie ausführen konnte von Manövern, die den Himmel vollständig im Ultraviolett abbilden.

Dies war eine Mission, die vor dem Start nicht in das Raumfahrzeug hineinkonstruiert worden war , aber durch unsere Fähigkeit ermöglicht wurde, das Kontrollsystem vom Boden aus neu zu programmieren. Missionsverbesserungen wurden durch Neuprogrammierung des Digitalcomputers vorgenommen.

https://www.sciencedirect.com/science/article/pii/S1474667017687755

Die Umprogrammierung während des Fluges, die begann, als die programmierbaren Sequenzer auf Mariner s flogen, und auf Mariner X auf einen hohen Qualitätsstand gebracht wurde, war zum Zeitpunkt des Starts der Voyager im Jahr 1977 eine nahezu routinemäßige Aufgabe. Sowohl der CCS- als auch der Flight Data System-Computer haben dies getan umfangreich umprogrammiert.

https://history.nasa.gov/computers/Ch6-2.html

Als Schlussbemerkung, nicht die erste, aber sicherlich eine, die mir sofort eingefallen ist, abgesehen von Viking und Voyager (durch einen Blick auf Viking bemerkte ich Mariner..), für die Neuprogrammierung war der International Sun-Earth Explorer-3 (ISEE-3 ) Satellit - umprogrammiert, um ICE zu werden.

https://en.wikipedia.org/wiki/International_Cometary_Explorer

und zum Schluss noch ein Video:

Mariner 6 und 7 Programme Missionen zum Mars, 1969 HACL Film 00033

Um 8:58 wird erwähnt, dass die Befehle an Mariner gesendet werden.

und zuletzt erinnert mich das an Voyager, aber umgekehrt:

https://meh.com/forum/topics/building-the-plane-on-the-way-up

Als die Voyager-Sonden mit Reed-Solomon-Encodern an Bord gestartet wurden, gab es auf der Erde keine Reed-Solomon-Decoder.

Außerdem nebenbei:

Die ursprüngliche Steuerungs- und Analysesoftware von Voyagers wurde in Fortran 5 geschrieben.

NASA-Studie zur Komplexität von Flugsoftware

Growth in Code Size:

1969 Mariner-6 (30)
1975 Viking (5K)
1977 Voyager (3K)
1989 Galileo (8K)
1990 Cassini (120K)
1997 Pathfinder (175K)
1999 DS1 (349K)
2003 SIRTF/Spitzer (554K)
2004 MER (555K)
2005 MRO (545K)
1968 Apollo (8.5K)
1980 Shuttle(470K)
1989 ISS (1.5M)

https://www.nasa.gov/pdf/418878main_FSWC_Final_Report.pdf

Beinahe-Verlust von SOHO
Es gibt drei "Premieren", die meiner Meinung nach für diese Frage relevant sind. Der erste ist der Beinaheverlust von SOHO am 24. Juni 1998. Sie können die Details auf der Wikipedia-Seite lesen, aber die Zusammenfassung ist, dass das Flugbetriebsteam einige normale Tests zur Lagekontrolle durchführte, als die Sensoren des Raumfahrzeugs die Sonne aus den Augen verloren und das Raumfahrzeug verursachten in Panik geraten. Der gesamte Aufwand endete nach fast einem Jahr, und das Flugbetriebsteam musste ein neues Lageregelungssystem entwerfen, schreiben und implementieren, das nicht von den jetzt funktionslosen Gyroskopen abhängig war. Ich denke, dieser letzte Teil erfüllt Ihren "ungeplanten" Aspekt eines Software-Updates, da ich nicht vorhersehen kann, dass sie während der anfänglichen Entwurfsphase der Mission darüber nachdenken, wie sie das Raumschiff ohne die Gyroskope steuern können.

Verlust von STEREO-B
Das zweite ungeplante Problem trat während des Verlusts von STEREO -B auf. Während die Wikipedia-Seite nicht genau beschreibt, was passiert ist, war das eigentliche Problem, dass APL (am 1. Oktober 2014) einige Lagemanöver durchführte, in Erwartung, dass das Raumschiff hinter die Sonne (relativ zur Erde) flog. Sehen Sie, das Raumschiff musste "umdrehen", bevor es hinter der Sonne vorbeiflog, damit beim Verlassen des Sonnenrandes die Antenne mit hoher Verstärkung auf die Erde zeigen würde. Das Team begann mit der Durchführung von Manövern (beachten Sie, dass sich das Raumschiff über einer astronomischen Einheit befandentfernt, dh mehr als 8 Lichtminuten) und plötzlich merkte, dass etwas nicht stimmte. Sie stellten schnell fest, dass das Raumschiff in eine unkontrollierte Drehung geraten war, erhoben das Problem jedoch nicht zu einem Notfall (dh dies hätte ihnen erlaubt, das Deep Space Network (DSN) zu nutzen ).hätte das Raumschiff sofort und wahrscheinlich geborgen). Das Raumschiff konnte sich nicht selbst neu orientieren, da es sich zu schnell drehte, also ging es in einen sicheren Modus und wartete auf Hilfe. Seine Rotationsachse würde relativ zu seiner ursprünglichen Sonnenlinie zwischen Raumfahrzeug und Sonne ungefähr fixiert bleiben, sodass die Sonnenkollektoren im Laufe der Zeit nicht mehr beleuchtet würden und es sterben würde. Nach vier Jahren gab die NASA schließlich den Versuch auf, das Raumschiff zu bergen. In diesem Fall bestand der "ungeplante" Teil aus all den Bemühungen, ein Raumschiff zu versuchen, es zu entdrehen, wenn die Kommunikation unterbrochen ist, und dann zu versuchen, das Raumschiff zu bergen, nachdem es hinter der Sonne hervorgekommen ist.

Interessante Randnotiz: Die Leute vom Flugbetrieb wussten zunächst nicht, dass sie das Raumschiff umdrehen mussten, nachdem sie hinter der Sonne vorbeigegangen waren, da dies unter anderem weit über die geplante Missionslebensdauer hinausging.

Double SEU on Wind
Das dritte ungeplante Problem trat Ende Oktober 2014 auf, als die Raumsonde Wind zwei simultane Single-Event-Upsets (SEUs) hatte.in seiner Befehls- und Datenverarbeitungshardware (C&DH). Das Flugbetriebsteam musste zusammen mit DSN das Raumschiff manuell erfassen (was ich immer noch erstaunlich finde), indem es die Ausrichtung einer der 34-Meter-Schüsseln bei DSN manuell anpasste. Sobald dies erledigt war, mussten sie das Problem nur mithilfe des Echtzeit-Telemetriestreams diagnostizieren und beheben. Dies führte dazu, dass mindestens zwei der Flugbetriebsingenieure die alten Drei-Ring-Ordner des Raumfahrzeug-Befehlscodes ausgraben und ihn dann in Echtzeit (dh sie sahen sich die Drei-Ring-Ordner beim Tippen an) in den aktuellen übersetzen von DSN verwendete Software. Sie mussten dann die gesamten Raumfahrzeug-Befehlstabellen (SCTs) von Grund auf neu erstellen und neu schreiben (einige werden alle paar Tage während der üblichen Downlink-Intervalle aktualisiert und geändert, aber nicht alle). Dies wurde sofort zu einem Notfall hochgestuft und das Raumschiff wurde innerhalb von ~ 11 Tagen wieder in einen betriebsbereiten Zustand gebracht (alte Raumschiffe brauchen viel Zeit, um ganze SCTs neu hochzuladen, und uns wurden nur ~ 3-4 Stunden pro Tag gegeben, nachdem es eingerichtet wurde wir könnten das Raumschiff nach Belieben kontaktieren). Das Raumschiff war nach weiteren etwa 20 Tagen wieder im vollen wissenschaftlichen Betrieb. In diesem Fall bestand der „ungeplante“ Teil darin, die SCTs neu zu erstellen, ein scheinbar nicht reagierendes Raumschiff zu diagnostizieren, indem nur Echtzeit-Telemetrie in einem Beacon-Modus verwendet wurde, und den zweiten C&DH-Prozessor zu verwenden, bis der erste zurückgesetzt und ordnungsgemäß neu programmiert werden konnte.

Interessante Randnotiz: Der zweite Befehls- und Einstellungsprozessor (CAP2) wurde nicht verwendet, bis diese Anomalie auftrat. Die CAPs enthalten den Fehlercodierer, der sicherstellt, dass die empfangenen Bits auf der Erde die richtigen sind (z. B. Reed-Solomon-Codierer).). Der Reed-Solomon-Encoder auf CAP1 fiel bereits 1997 aus, hatte aber immer noch einen Faltungs-Encoder, also war er immer noch gut. Es war vorher nicht bekannt, aber bei der Verwendung von CAP2 entdeckten die Flugbetriebsleute, dass der Faltungscodierer ausgefallen war. Das Design der Encoder ermöglichte es, den Reed-Solomon-Encoder elektronisch zu umgehen, aber nicht den Faltungs-Encoder, sodass wir erkannten, dass wir uns für den Betrieb nicht auf CAP2 verlassen konnten und CAP1 vollständig wiederherstellen mussten. Die Fehlerrate ohne Encoder betrug nur 1 in 10.000 Bits (oder 1 Bit pro ~1250 Bytes), aber das ist immer noch problematisch, wenn es ein Bit ist, das den Code darüber informiert, wohin er in einer Binärdatei zeigen soll, wenn er nach Daten sucht. Die CAP1-Wiederherstellung begann also etwa einen Monat, nachdem der Betrieb unter Verwendung von CAP2 vollständig wiederhergestellt worden war, und CAP1 wurde etwa einen Monat danach (d. h. ungefähr am 30.

Ich bin mir sicher, dass es andere, interessantere Beispiele gibt, aber das waren die ersten, die mir auf Anhieb eingefallen sind.