Il Quarto Membro dell’Equipaggio (8) – I restart

I moduli AGC (photo by Marcin Wichary)

I moduli AGC (photo by Marcin Wichary)

In un computer complesso come l’AGC potevano verificarsi una serie di problemi. Alcuni causati da piccoli problemi procedurali (tipo sbagliare la sequenza di operazioni da compiere), altri da problemi logici inattesi o da interazioni non previste tra hardware e software. Ognuno di questi poteva avere conseguenze catastrofiche per l’intero veicolo e per l’equipaggio. La necessità per un sistema real-time di mantere il controllo della capsula era di primaria importanza, specialmente duranti le fasi più critiche della missione: l’AGC doveva reagire ai problemi in modo controllato e se necessario portarsi in un diverso stato conosciuto e stabile. E quindi era necessario prevedere meccanismi di gestione del riavvio (restart) di singoli job o dell’intero computer se necessario.

L’approccio a questo problema dell’AGC era molto flessibile e in grado di garantire che l’esecuzione proseguisse sempre ad eccezione dei casi più estremi. Se un job doveva essere in grado di riavviarsi, richiamava una specifica funzione dell’Executive, la PHASCHNG. Passando alcuni parametri si definiva la modalità e le routine di riavvio da utilizzare, oltre ad eventuali dati necessari.

L’AGC poteva utilizzare diverse strategie di restart in caso di errori in un job:

  • il job poteva essere semplicemente terminato senza alcuna intenzione di riavviarlo
  • il job poteva essere riavviato dall’inizio facendo un pò di pulizia dei dati lasciati nel Core Set e/o nel VAC, sperando che non si riverificasse lo stesso errore
  • il job ripartiva da uno specifico punto all’interno della routine (restart point) dopo avere fatto, anche in questo caso, un pò di pulizia (l’opzione più complessa)

Questa flessibilità era necessaria proprio dalla complessità del codice dell’AGC e dall’aver realizzato che non tutti gli errori erano necessariamente fatali.

Il sistema di restart dell’AGC prevedeva di assegnare i programmi ad uno di 6 restart group. Ogni gruppo gestiva un gruppo di programmi specifico e non poteva essere utilizzato nello stesso momento per più di un job. Ad esempio il restart group 4 del Command Module era responsabile per il restart dei programmi relativi all’SPS e anche a quelli utilizzati durante il rientro in atmosfera. Ovviamente non vi era alcuna possibilità di contrasto o di esecuzione contemporanea delle stesse routine, poichè l’SPS non era più disponibile al momento del rientro.

La restart table
Le informazioni relative a come gestire i restart si trovavano nella restart table, un’area della memoria non riscrivibile: per ciascuno dei 6 gruppi vi erano definite una o più restart phase (i restart point di cui parlavo in precedenza). A mano a mano che l’esecuzione di un job progrediva, questo richiamava la routine PHASCHNG per notificare l’Executive che si entrava in una differente restart phase.

La Restart Phase table

Ogni linea della tabella rappresentava una delle procedure di recupero (recovery). Erano necessarie in totale 3 word per definire una singola fase di restart: una che rappresentava la priorità e due per l’indirizzo di inizio della routine da eseguire. Non c’era una restart table universale: quella presente nel software del Lunar Module era molto diversa da quella del Command Module.

Per mantenere comprensibile l’argomento, utilizzerò la stessa notazione usata nell’eccellente libro di Frenk O’Brien sull’AGC (che ho ampiamente saccheggiato durante tutta questa serie di post), notazione che descrive i restart point come “G.P”, con G che indica il gruppo e P che indica la fase. In questo modo, la lista delle opzioni di restart era:

G.0 Inibire quel restart group
G.1 Rimostra gli ultimi dati validi sul DSKY
G.#Pari Eseguiva due routine di restart
G.#Dispari (>1) Eseguiva una routine di restart

G.0 e G.1 erano comuni quindi a tutti i gruppi. Durante un restart, ogni riga della phase table veniva controllata: se conteneva uno 0, quel gruppo non era attivo e non venivano eseguite ulteriori operazioni. La phase 1 si limitava a ricaricare sui display del DSKY i dati mostrati in precedenza. Negli altri due casi invece veniva effettivamente tentato riavvio del job: la differenza era nel numero di operazioni eseguite (una per le phase dispari, due per quelle pari).

La + phase / – phase table

I dati necessari per il riavvio di uno specifico job, passati come parametri alla routine PHASCHNG, erano salvati nella Phase Table. Una tabella che al contrario della Restart Phase Table si trovava nella sezione riscrivibile della memoria dell’AGC (poiché il suo contenuto variava ad ogni invocazione della routine di restart). Veniva salvato nella stessa tabella anche il valore dei parametri complementati bit per bit. Si trattava di una misura utilizzata per garantire la integrità dei dati durante il riavvio di un job.

I Program Alarm e il processo di riavvio
Su scala più ampia del singolo job, problemi di tipo procedurale legati ai Major Mode potevano essere segnalati come Program Alarm (tanto noti per le vicende di Apollo 11) e venivano gestiti tramite i meccanismi di riavvio dei job implicati (usando i meccanismi visti in precedenza).

Un problema più complesso era quello dell’abort di un programma, identificato con il codice P00DOO. Ad esempio se durante un calcolo si cercava di calcolare il radice quadrata di un numero negativo (operazione impossibile in matematica), il programma veniva immediatamente terminato senza passaggio attraverso le routine di restart. L’area di memoria riscrivibile non veniva cancellata ma nessun Major Mode era più in esecuzione. L’AGC entrava in uno stato definito ‘idle’ (libero), identificato sul DSKY dal Program 00. Quello che conta segnalare qui è che tutte le altre routine in seduzione (controllo dell’orientamento, telemetria, navigazione …) continuvano a funzionare correttamente.

Altri problemi erano più seri e l’unica opzione disponibile era un riavvio dell’AGC. Esistevano due possibili modalità di riavvio dell’AGC:

  • Software Restart: in questa modalità l’Executive eseguiva il processo di restart per i job di sistema e terminava tutti gli altri (ad esempio quelli schedulati dal Major Mode in esecuzione). Al termine del processo l’AGC era in stato idle (Program 00).

  • Hardware Restart (Reboot): la modalità più drastica, prevedeva la terminazione anche dei job di sistema. L’effetto di tale procedura era quindi di avere un AGC completamente ‘azzerato’. Venivano spenti i motori (se attivi). La IMU non era più utilizzabile perché il suo orientamento era andato perso. Al termine del processo l’AGC era in stato idle (Program 00).

Un’ultima nota peculiare: non esistevano routine di restart per il DAP (Digital AutoPilot) , la routine che gestiva le capsule durante le manovre attive. Essendo eseguita ogni 100ms, non era necessario. La frequenza di attivazione era alta a sufficienza da poter trascurare un problema durante l’esecuzione. Ovviamente una condizione di errore ripetuta avrebbe avuto impatto sul resto dell’elaborazione causando altri allarmi.

Già che ci siamo:

Buona Pasqua a tutti!

E ricordatevi che Varese ed Esplorando sono un’ottima destinazione per la gita di Pasquetta 😉

Una Risposta to “Il Quarto Membro dell’Equipaggio (8) – I restart”

  1. Generally I do not read article on blogs, however I wish to say that this write-up very forced me to take a look at and do so!
    Your writing style has been surprised me. Thank you, very great
    article.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...