Welche Art von Daten hat New Horizons an die Erde gesendet, um das Problem beim Wechsel in den abgesicherten Modus zu diagnostizieren?

Der erste Hinweis war, auf welche Frequenz das Raumschiff umschaltete, also lernten sie viel, indem sie einfach die Kommunikationssperre wieder herstellten. Dann scheint es, dass die notwendigen Daten in den normalen Haushaltsdaten/Logfiles waren, da keine spezielle Datenerhebung erwähnt wird.

Multithreading war nicht das Problem und tatsächlich stürzte die Software nie ab. Es wurde einfach gebeten, zwei rechenintensive Dinge gleichzeitig zu tun: (1) Wissenschaftsdaten zu komprimieren und (2) eine Befehlslast in einen nichtflüchtigen Speicher zu kopieren. Dadurch wurde mehr CPU-Prozentsatz verwendet als vom System erwartet, und die Fehlerverwaltungssysteme entschieden, dass sich der Prozessor falsch verhielt, und erzwangen einen Wechsel zum Backup-Computer. Ein Stacktrace wäre in diesem Fall nicht hilfreich gewesen.

Quelle: Washington Post

New Horizons trägt zwei Computersysteme. Wie das Team von New Horizons am 4. Juli veröffentlichte :

Das Operationszentrum der Mission im Applied Physics Laboratory der Johns Hopkins University, Laurel, Maryland, verlor den Kontakt mit dem unbemannten Raumschiff – jetzt 10 Tage nach der Ankunft auf Pluto – um 13:54 Uhr EDT und stellte die Kommunikation mit New Horizons um 3 wieder her: 15 Uhr EDT, über das Deep Space Network der NASA.

Während dieser Zeit hat der autonome Autopilot an Bord des Raumfahrzeugs ein Problem erkannt und – wie in einer solchen Situation programmiert – vom Haupt- auf den Backup-Computer umgeschaltet. Der Autopilot versetzte das Raumschiff in den „sicheren Modus“ und befahl dem Backup-Computer, die Kommunikation mit der Erde wieder aufzunehmen. New Horizons begann dann mit der Übertragung von Telemetriedaten, um die Ingenieure bei der Diagnose des Problems zu unterstützen.

Am 5. Juli haben sie dies gepostet und das Problem erklärt:

Die Untersuchung der Anomalie, die dazu führte, dass New Horizons am 4. Juli in den „abgesicherten Modus“ wechselte, hat ergeben, dass am Raumschiff kein Hardware- oder Softwarefehler aufgetreten ist. Die zugrunde liegende Ursache des Vorfalls war ein schwer zu erkennender Zeitfehler in der Befehlssequenz des Raumfahrzeugs, der während einer Operation zur Vorbereitung des nahen Vorbeiflugs auftrat. Für den Rest der Pluto-Begegnung sind keine ähnlichen Operationen geplant.

„Ich freue mich, dass unser Missionsteam das Problem schnell identifiziert und den Zustand des Raumfahrzeugs sichergestellt hat“, sagte Jim Green, NASA-Direktor für Planetenforschung. „Jetzt – mit Pluto im Visier – stehen wir kurz davor, zum normalen Betrieb zurückzukehren und nach Gold zu greifen.“

Sie erwähnten nichts über die Notwendigkeit, Protokolle herunterzuladen, nur "Telemetrie", und angesichts der Kommunikationsverzögerung und Schnelligkeit, mit der sie das Problem diagnostizierten, bezweifle ich, dass sie viele Daten heruntergeladen haben. Ich weiß wenig über die technischen Details, aber ich wäre absolut schockiert, wenn sie keinen Simulator oder keine doppelte MIPS R3000-CPU auf der Erde hätten.

Ich nehme an, sie haben einfach die Reihe von Befehlen, die sie an die Sonde gesendet haben, an ihren "virtuellen New Horizons"-Computer auf der Erde repliziert und den Fehler ihres Timing-Fehlers erkannt. Der Fehler, obwohl sie sagen, dass er schwer zu erkennen war, ist vielleicht (sehr vereinfacht) etwas in der Art von:

1. Befehl A ausgeführt.
2. Die Sonde benötigt X Sekunden, um sich neu auszurichten.
3. Befehl B wurde Y Sekunden später ausgeführt.

Y < X. Befehl B schlägt fehl. Computer erkennt Fehler, schaltet auf Backup um, telefoniert nach Hause.