Archivio per Software

Il Quarto Membro dell’Equipaggio (10) – Il DSKY

Posted in Storia, Tecnologia with tags , , on 6 maggio 2012 by raghnor

Il DSKY di Apollo 13
(© Bruce Yaroro & Smithsonian institution)

Dopo la doverosa pausa dovuta al quarantennale di Apollo 16, ritorno sull’argomento AGC che con questo post concludo. Argomento di oggi, il DSKY, l’unica parte (ben) visibile dell’AGC.

La comunicazione tra l’equipaggio e l’AGC avveniva tramite il DSKY, abbreviazione di DisplaY and KeYboard, solitamente pronunciato ‘dis-key’. Come il nome stesso descrive efficacemente, si trattava di un dispositivo dotato di una tastiera e di una serie di metodi di visualizzazione dei dati.

Le principali attività svolte tramite il DSKY erano:

  • visualizzare, controllare e aggiornare i dati utilizzati dall’AGC

  • eseguire e gestire i programmi dell’AGC per controllare le principali fasi della missione

  • eseguire specifici comandi per controllare la capsula o per modificare i programmi in esecuzione

L’importanza del DSKY era ben rappresentata dalla posizione occupata all’interno dei pannelli di controllo delle capsule Apollo dai 3 esemplari utilizzati per ogni missione:

  • un DSKY era posizionato sul pannello principale del CSM in modo da essere raggiungibile dei sedili centrale e di sinistra (quelli occupati dal CDR e CMP)

  • un secondo DSKY era posizionato nella Lower Equipment Bay del CSM, dove serviva per le operazioni con le ottiche del PGNCS (i due DSKY del CSM ovviamente erano collegati allo stesso AGC)

  • il terzo ed ultimo si trovava nel LM sul pannello principale tra le postazioni del CDR e del LMP

Il DSKY su entrambe le capsule era posizionato in modo da essere ben visibile e facilmente raggiungibile. In particolare, insieme ai due FDAI e all’EMS costituiva il poker di strumenti fondamentali per navigare il CSM.

Il DSKY era una unità a se stante, separata dal resto del’AGC, largo 17.8 cm e alto 21.6 cm, era dotato di una tastiera con 19 tasti, 3 display numerici detti Data Registers per visualizzare le informazioni in formato numerico e una batteria di spie. Erano inoltre presenti tre specifici display per rappresentare il Programma in esecuzione (Major Mode) e la combinazione Verb / Noun (Verbo / Nome) a cui i dati dei Data Registers facevano riferimento.

Ciascun Data Registers poteva visualizzare 5 cifre più il segno. Ogni cifra era costruita tramite 7 segmenti, come siamo abituati e vedere nelle calcolatrici, solo che nel DSKY non si utilizzavano i cristalli liquidi (LCD) o i LED bensì segmenti elettroluminescenti verdi controllati tramite relè. Ne erano presenti più di 100 (relè miniaturizzati) per gestire i segmenti. Cambiare lo stato del relè non era un’operazione istantanea: occorreva applicare un segnale elettrico per almeno 20 millisecondi.

Continua …

Il Quarto Membro dell’Equipaggio (9) – L’Interpreter

Posted in Storia, Tecnologia with tags , , on 15 aprile 2012 by raghnor

Una parte del codice di Luminary

Il linguaggio macchina (assembly) dell’AGC svolgeva il suo lavoro in modo egregio per codificare le routine di sistema a basso livello che costituivano il cuore dell’Executive.

Ma pensare di far codificare ai programmatori le complesse equazioni necessarie ai programmi relativi a fasi delle missioni Apollo come l’allunaggio, il decollo o la navigazione utilizzando le stesse istruzioni non era possibile. Era necessario ideare un sistema che permettesse un superiore livello di astrazione, ovvero un linguaggio di programmazione di più alto livello, e anche un lavoro di superamento dei limiti dell’architettura dell’AGC per permettere l’utilizzo di tipi di dati più complessi.

Non potendo realizzare un vero e proprio linguaggio di alto livello con relativo compilatore (ovvero un traduttore tra il suddetto linguaggio e l’assembly dell’AGC), l’MIT ideò l’Interpreter.

Continua a leggere

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

Posted in Storia, Tecnologia with tags , , on 7 aprile 2012 by raghnor
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.

Continua a leggere

Il Quarto Membro dell’Equipaggio (7) – L’Executive

Posted in Storia, Tecnologia with tags , , , on 1 aprile 2012 by raghnor

Alcuni dei moduli che costituivano l’AGC

L’AGC come abbiamo visto era un computer RTC (real time), multitasking e capace di interagire con una serie di interrupt. Il fatto di essere multitasking significa che era in grado di gestire l’esecuzione di diversi programmi (job) contemporaneamente. A questi programmi veniva assegnata una priorità: in ogni momento l’AGC eseguiva il programma con la priorità più alta. Un altro modo di definire l’AGC è che si trattava di un priority-interrupt system.

Per quanto riguarda il multitasking, questa era una tecnica fondamentale per un sistema real time, che si trovava a gestire operazioni diverse nello stesso momento. Ovviamente l’AGC aveva un solo ‘processore’ e quindi il multitasking era più un effetto generato dalla velocità di esecuzione e dalla lentezza della percezione umana: i job venivano in realtà eseguiti uno alla volta, ma la velocità con cui venivano eseguiti e il continuo passaggio da un job all’altro in base alla priorità creavano l’illusione dell’esecuzione contemporanea.

Il compito di orchestrare il multitasking, col suo balletto di job prioritizzati, era compito principalmente dell’ Executive. Questo programma può essere considerato il sistema operativo dell’AGC.

Continua …

Il Quarto Membro dell’Equipaggio (6) – Lo sviluppo del software

Posted in Storia, Tecnologia with tags , , on 25 marzo 2012 by raghnor

Un ‘piccolo’ listato

Lo sviluppo del software per l’AGC fu una delle sfide più difficili ed inizialmente sottovalutate della NASA e dell’MIT. Le difficoltà iniziali, che misero a rischio la possibilità del progetto di avere successo nei tempi dettati dalla sfida di Kennedy, portarono però alla fine alla definizione di una serie di procedure e tecniche che diedero i loro frutti al di là del Progetto Apollo.

All’inizio degli anni 60 la definizione di un ciclo di sviluppo (raccolta dei requisiti, progettazione, codifica, test e manutenzione) non erano appieno apprezzati dai programmatori. Persino all’interno di una elite come quella dei programmatori dell’MIT. L’inesperienza della NASA nella gestione di simili progetti, ben diversi dal punto di vista gestionale da quelli della realizzazione su grande scala di capsule, razzi, etc., contribuì ai problemi.

Uno di primi passi per cercare di ottenere il livello di controllo necessario sul processo fu la creazione di 3 commissioni che si occupassero delle gestione integrata di hardware e software:

  • L’Apollo Spacecraft Configuration Control Board, che controllava e valutava le modifiche richieste per i veicoli e anche per i sistemi di guida e navigazione

  • Il Procedures Change Control Board, si occupava dei requisiti di progettazione di ogni richiesta che impattava l’interfaccia utente

  • Il Software Configuration Control Board, si occupava delle modifiche richieste al software vero e proprio

Continua …