Domanda:
L'errore 1202 e il riavvio associato hanno impedito il disastro all'atterraggio dell'Apollo 11?
orome
2019-07-22 01:37:33 UTC
view on stackexchange narkive permalink

La maggior parte dei resoconti del famoso errore 1202 riportato dall'AGS durante l'atterraggio dell'Apollo 11 LM caratterizzano l'evento come risultato del buon funzionamento dell'AGS, svuotando un reset di un computer sovraccarico preservando le criticità dati necessari per procedere al riavvio.

Tuttavia la rivisitazione di Alan Klumpp descrive una situazione in cui il sovraccarico dell'AGS potrebbe provocare un disastro:

. .. i comandi dell'acceleratore e dello sterzo ... erano spesso calcolati in modo incompleto e venivano messi in coda per il completamento successivo. Qualsiasi tentativo di mettere in coda un comando quando la coda era già piena (circa cinque comandi) farebbe sì che il computer svuotasse la coda e emettesse l'allarme. Ma quando l'alimentazione del radar era in fase, i comandi in coda, validi solo in un tempo remoto passato, potevano essere completati ed emessi in ordine inverso, prendendo momentaneamente il controllo per guidare il LM fuori dalla sua normale traiettoria di atterraggio. Sebbene i comandi di lavaggio causerebbero allarmi, l'emissione di comandi errati non lo sarebbe. Le simulazioni hanno mostrato che comandi difettosi potrebbero mettere il LM su un percorso accelerato e la guida tenterebbe di portare il LM al sito di atterraggio attraverso una traiettoria che passava sotto la superficie lunare.

Tuttavia, è non è chiaro quando o se questa situazione si sia effettivamente verificata. Questo passaggio ha lo scopo di confermare l'account generale: che il comportamento di svuotamento associato a un errore 1202 ha impedito che si verificasse questo disastro. O sta dicendo che questo potrebbe essere accaduto quando sono stati segnalati gli errori 1202, o in un altro momento durante la missione? (In effetti, un'interpretazione è che il sovraccarico fuori fase che ha innescato gli errori 1202 assicurati contro una tale catastrofe.)

L'errore 1202 e il riavvio associato hanno impedito il disastro all'atterraggio dell'Apollo 11?

Un recente articolo su WIRED https://www.wired.com/story/apollo-11-mission-out-of-control/ ha alcune informazioni interessanti sulla coda, ecc.
Due risposte:
Organic Marble
2019-07-22 03:12:48 UTC
view on stackexchange narkive permalink

Sono d'accordo con il tuo commento "non è chiaro quando o se questa situazione si sia effettivamente verificata". Leggendo sia il racconto di Klumpp che il libro del suo collega Don Eyles Sunburst and Luminary non credo che abbiamo abbastanza informazioni per sapere se la situazione poteva essere esistita su Apollo 11. I credo di sapere che non esisteva su Apollo 11, perché l'alimentazione del radar non era in fase, e Klumpp dice

Ma quando l'alimentazione del radar era in fase , i comandi in coda, validi solo in un tempo passato remoto, potevano essere completati ed emessi in ordine inverso, prendendo momentaneamente il controllo per guidare il LM fuori dalla sua normale traiettoria di atterraggio.

(Enfasi mia)

Ecco il resoconto di Eyles del problema dalle pagine 215-16 di S&L.

All'alba del 1970, con la P66 Auto finita e a bordo per la missione imminente, Allan e io abbiamo trovato il tempo di riconsiderare il problema che ha quasi rovinato l'atterraggio dell'Apollo 11 - privazione del tempo del processore, che abbiamo chiamato TLOSS- - ma ci siamo occupati in modo diverso ays.

Allan continuava a ronzare l'IBM 360 mentre eseguiva simulazioni sulla fune dell'Apollo 13 per vedere come si comportava con quantità variabili di TLOSS. Sapevamo già che se la quantità di TLOSS fosse stata giusta, durante un periodo di alta attività i lavori di SERVICER incompleti avrebbero potuto accumularsi nella coda dei dirigenti. L'ultima cosa che il SERVICER ha fatto su ogni passaggio è stata inviare le informazioni al DSKY per la visualizzazione. Poco prima ha emesso i comandi di assetto e, prima ancora, i comandi dell'acceleratore. Ciò che preoccupava Allan era cosa sarebbe successo se un lavoro di SERVIZIO fosse interrotto prima che fosse inviato il comando di accelerazione o assetto. Se si accumulasse un numero sufficiente di questi lavori sospesi, si verificherebbe un riavvio del software, come accadde su Apollo 11, ei lavori sospesi scomparirebbero. Ma cosa succederebbe se il carico computazionale si attenuasse prima che venissero eliminate?

Quello che poteva accadere, scoprì Allan, era che i lavori sospesi (che Allan li aveva soprannominati "lurkers") potessero tornare in vita, ignari di essere stati in ibernazione, e procedere a emettere un atteggiamento o un comando di accelerazione applicabile a un punto precedente nella traiettoria . All'improvviso il LM potrebbe manovrare con l'atteggiamento sbagliato. I casi peggiori si sono verificati quando i lavori sospesi accumulati durante P64 sono stati eseguiti dopo il passaggio a P66.

Il 4 marzo Allan ha pubblicato un promemoria scritto con cura che descrive "una raccolta di manifestazioni note di perdita di tempo". Allan ha descritto otto diverse modalità di cattivo comportamento, a partire da un TLOSS di circa l'8%. In una precauzione insolita, Allan firmò il promemoria e chiese a Gerry Levine di firmarlo perché lo aveva approvato.

(Enfasi mia)

La mia interpretazione è che il problema accadere,

  1. l'alimentatore del radar rendezvous dovrebbe essere sincronizzato
  2. dovrebbe accadere qualcosa che ha reso i lavori di SERVICER lunghi e non completati
  3. Qualunque cosa abbia causato 2) avrebbe dovuto sparire prima che la situazione diventasse abbastanza grave da svuotare la coda

Sappiamo che su Apollo 11 1) non era il caso, ma non lo so se abbiamo informazioni sufficienti per sapere se 2) è successo o meno.

Questa risposta cerca di spiegare la parte relativa all'alimentazione del radar che è sfasata.

Bella risposta. Quindi è possibile che se l'alimentatore del radar rendezvous fosse stato sincronizzato (1), un 1202 (o 1201?) Avrebbe indicato un aborto (per evitare un atterraggio di fortuna)?
@orome Penso che hai ricevuto gli allarmi solo se il computer si è effettivamente riavviato. Questo tipo di problema intermedio in cui i lavori sono stati sospesi, quindi ripresi, ma il computer non si è riavviato potrebbe aver provocato problemi di traiettoria senza allarme, il che è davvero preoccupante. Questa è tutta la mia interpretazione però.
Ah, sì, penso che tu abbia ragione. L'allarme indica che le cose vanno bene perché c'è stato un riavvio. (Fondamentalmente è il modo di dire dell'AGS, sono sovraccarico e me ne occuperò prendendo un secondo per ripulire e tornare alle attività ad alta priorità.) La situazione di trasporto descritta si sarebbe verificata solo in * assenza * di un allarme 1202.
Penso che tu abbia * quasi * corretto, tranne per il fatto che le fasi di alimentazione si stavano spostando l'una rispetto all'altra, il che significa che potevano andare alla deriva dentro e fuori fase. Quando dice "quando l'alimentazione del radar era in fase", significa * momentaneamente * in fase, abbastanza a lungo da consentire al computer di recuperare il ritardo. Quindi questo * potrebbe * essere accaduto l'11.
TLOSS basso costante = comportamento nominale. TLOSS alto (ish) coerente = comportamento sicuro perché l'eliminazione del carico impedisce alla coda di diventare profonda e impedisce che le attività del SERVICER immediate e in coda si mescolino. Ma se quella fase si aggira e il TLOSS va al di sopra e al di sotto della soglia, il sistema potrebbe finire per riprendere un'attività piuttosto vecchia. O questo non è accaduto, oppure è accaduto ma non ha avuto un effetto importante sulla stabilità fisica del sistema. Ad ogni modo, un po 'di fortuna è stata coinvolta, e questa sembra essere la vera carne di Klumpp. Potrebbe essere andata piuttosto male.
L'account di Eyles - vedi risposta collegata - non menziona la deriva. Sembra che ci fosse una relazione stabilita al potenziamento, e solo alcuni erano abbastanza brutti da causare problemi. Ma non posso escludere quello che dici.
Penso che sia corretto. Sembra che la relazione di fase sia stata stabilita all'accensione (possiamo saperlo con certezza?), Quindi la situazione menzionata nell'osservazione di Klumpp è solo qualcosa che potrebbe accadere e non intende descrivere cosa stava succedendo durante l'atterraggio dell'Apollo 11.
@hobbs Leggendo ulteriormente in [account di Klumpp] (https://wehackthemoon.com/sites/default/files/2019-03/Allan%20Klumpp%20Vignettes.pdf), scrive che "Molti comandi di guida sono stati messi da parte; alcuni non sono mai stati emessi, altri sono stati emessi fuori sequenza ". Il che suggerisce che potresti avere ragione sul fatto che ci fosse una deriva?
@orome Eyles dice "Tuttavia, l'angolo di fase tra i due segnali era completamente casuale, a seconda dell'istante in cui l'LGC, che era sempre acceso dopo l'ATCA, ha iniziato a inviare il primo segnale di sincronizzazione della frequenza". http://www.klabs.org/history/apollo_11_alarms/eyles_2004/eyles_2004.htm
Sì, ho pensato che significava che l'angolo di fase è stato fissato in modo casuale e è rimasto a quell'angolo per tutto il tempo (non si è spostato). Ma non riesco a conciliare il fatto che con Klumpp "molti comandi di guida sono stati accantonati; alcuni non sono mai stati emessi, altri sono stati emessi fuori sequenza" nel contesto del suo affermare che tale comportamento si verificava quando gli angoli di fase concedevano.
Ho un [seguito] (https://space.stackexchange.com/q/37730/855) sul motivo per cui RR e AGC sono fuori fase causano così tante interruzioni in primo luogo.
@hobbs Come ricordo, i segnali erano bloccati in frequenza ma non bloccati in fase. (La mancanza di aggancio di fase era un problema.) * Se due segnali sono bloccati in frequenza, non dovrebbe esserci alcuna deriva di fase * tra di loro; se c'è, non sono bloccati in frequenza, ma sono solo a frequenze simili. Non riesco a vedere come potresti avere due segnali alla stessa identica frequenza ma con una deriva di fase diversa l'uno rispetto all'altro.
DrSheldon
2019-07-22 02:36:10 UTC
view on stackexchange narkive permalink

Il modulo lunare aveva due computer. L'allarme 1202 si è verificato sul Lunar Guidance Computer, che svolgeva molte attività diverse: infatti, l'allarme 1202 era un avvertimento che il suo sistema multitasking era a rischio di essere (ma non ancora completamente) sovraccarico.

C'era anche il sistema di guida all'aborto. Il suo computer e software erano design completamente diversi rispetto all'LGC, sviluppato da diversi appaltatori. L'AGS aveva un solo compito: riportare l'LM nello spazio, dove poteva essere raccolto dal CSM. Non poteva essere sovraccaricato dalle attività extra che l'LGC doveva svolgere. Sebbene l'AGS non abbia mai dovuto essere utilizzato in una vera missione, è stato accuratamente testato e non c'è motivo di pensare che avrebbe funzionato male.

Gli equipaggi dell'Apollo si sono esercitati a riconoscere quando era necessario un aborto e ad attivare l'AGS. L'articolo di ArsTechnica che citi afferma addirittura:

E, per essere chiari, un aborto durante l'atterraggio non era una cosa da poco. La procedura avrebbe coinvolto Armstrong premendo il pulsante "ABORT STAGE" sul pannello dell'LM, che avrebbe sparato dardi esplosivi e ghigliottine e avrebbe separato la fase di salita dell'LM dalla sua fase di discesa. Quindi, il motore di risalita si accenderebbe, facendo del suo meglio per aggiungere velocità alla nave in discesa, tentando di spingerla indietro in una sorta di orbita stabile in modo che l'equipaggio potesse trovare e incontrarsi con il Modulo di comando. Era qualcosa a cui gli equipaggi si erano addestrati , ma non sarebbe stato facile. E avrebbe portato con sé lo stigma di una missione interrotta.

Il problema 1202 non ha interferito con il controllo del veicolo spaziale, ed è per questo che l'equipaggio ha avuto il via libera per sbarcare. Tuttavia, se avesse effettivamente interferito in qualche modo con il controllo del veicolo spaziale, l'addestramento di Armstrong era quello di attivare immediatamente l'AGS. Quindi nessun disastro sarebbe accaduto , ma l'opportunità di atterrare sulla luna andrebbe persa.

Spiacente non è questo il problema: la domanda dipende dalla relazione tra "i comandi in coda, validi solo in un tempo remoto passato, potrebbero essere completati ed emessi in ordine inverso" potrebbero accadere e cosa ciò ha a che fare con la situazione che si è verificata (quando è successo il 1202).
Non sono i dati che vengono messi in coda, sono le attività (proprio come i thread del processo Unix). Il programma esecutivo decide quale attività eseguire successivamente in base alla priorità. Durante un riavvio graduale, le code delle attività vengono cancellate; non vengono danneggiati o invertiti. Non emetterà comandi di governo in ordine inverso.
Secondo il libro di Eyles, le attività vengono riavviate e questo è ciò che causa l'emissione dei comandi errati. Il caso si verifica quando le attività vengono sospese ma il sistema viene ripristinato prima del riavvio.
Se questa era la modalità di guasto era possibile, perché non è stata osservata nella simulazione?
@RussellBorogove è stato osservato in simulazioni eseguite al MIT ma stavano esercitando "quantità variabili di TLOSS". Per entrare in questo caso devi avere la giusta quantità di TLOSS. I simulatori di addestramento non contenevano AGC reali, quindi è improbabile che venga trovato questo tipo di problema dipendente dall'hardware.
Ghaa. I simulatori non avevano veri AGC?
@RussellBorogove no, erano troppo costosi e ottenere le attuali "corde" era un problema. Sono stati emulati nel software di simulazione. I simulatori di addestramento dello Shuttle avevano dei veri computer di volo, ma penso che fosse un'innovazione. I simulatori di bombardieri B-52 su cui ho lavorato avevano anche computer di volo emulati. Anche i simulatori di addestramento della ISS hanno emulato i computer di bordo.


ⓘ
Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...