El Computador de Navegación del Apolo o Apollo Guidance Computer (en adelante AGC) fue un elemento fundamental del programa Apolo. Su papel en el programa espacial fue proporcionar la capacidad de cálculo necesaria para controlar la orientación, y la navegación del módulo de mando (CM, de Command Module) y del módulo lunar (LM, de Lunar Module). Este ordenador destaca por haber sido uno de los primeros computadores basados en CIs.
El AGC y su interfaz DSKY se desarrollaron a principios de los 1960s por el MIT Instrumentation Laboratory para el programa Apolo.
Cada vuelo a la Luna (a excepción del Apolo 8, que no llevó módulo lunar en su misión a la órbita lunar) tenía dos AGCs, uno en el módulo de mando y otro en el módulo lunar. El AGC del módulo de mando estaba situado en el centro del sistema de navegación y orientación (G&C) de la nave. El AGC del módulo lunar llevaba su propio sistema primario de orientación, control y navegación del Apolo, conocido por el acrónimo de PGNCS (pronunciado como pings).
Cada misión lunar tuvo dos ordenadores adicionales:
El AGC se diseñó en el MIT Instrumentation Laboratory bajo la dirección de Charles Stark Draper, con el diseño hardware a cargo de Eldon C. Hall. Los primeros trabajos sobre la arquitectura llegaron de manos de J.H. Laning Jr., Albert Hopkins, Ramón Alonso, y Hugh Blair-Smith. La empresa Raytheon fabricó el hardware de vuelo, y Herb Thaler también estaba en el equipo de diseño.
El computador de vuelo del Apolo fue el primero en usar circuitos integrados (CIs). Mientras que la versión Block I usaba 4100 CIs, conteniendo cada uno una sencilla puerta NOR de 3 entradas, la versión posterior Block II (usada en los vuelos tripulados) empleó 2800 CIs, cada uno con dos puertas NOR de 3 entradas.:34 Los CIs, de Fairchild Semiconductor, se implementaron usando lógica resistencia-transistor (RTL) en un flat-pack. Fueron conectados mediante wire wrap, y luego el cableado se incorporó en un molde plástico de epoxy. Al usar un único tipo de integrado (las doble NOR3) para todo el AGC, se evitaron los problemas que plagaban los primeros diseños de computadores basados en CIs, como el computador de guiado Minuteman II, que usaba una mezcla de puertas con lógica diodo-transistor y otras con lógica diodo-resistor.
El computador tenía 2048 palabras de memoria de núcleos magnéticos volátil y 36 kilopalabras de memoria de núcleos cableados de solo lectura. Ambas tenían un ciclo de 11,72 micro-segundos. La longitud de la palabra de memoria era de 16 bits: 15 bits de datos y 1 bit de paridad impar. El formato de palabra de la CPU de 16 bits eran 14 bits de datos, 1 bit de overflow, y 1 bit de signo (en representación complemento a uno).
La interfaz de usuario con la que se accedía al AGC era la DSKY (abreviatura del inglés display and keyboard, que en castellano significa teclado y pantalla), pronunciado comúnmente como dis-key. Poseía un vector de indicadores luminosos, varios visualizadores numéricos y un teclado tipo calculadora. Los comandos se introducían como números de dos dígitos: Verbo, y Nombre. El Verbo describía el tipo de la acción a realizar y el Nombre especificaba el dato afectado por la acción indicada por dicho verbo.
Los numerales se mostraban a través de visualizadores de siete segmentos electroluminescentes de alto voltaje de color verde. Para controlar estos visualizadores se usaban relés electromecánicos que limitaban su velocidad de refresco (la versión posterior Block II usaban rectificadores controlados de silicio más veloces). En ellos se podían visualizar tres números de 5 dígitos con signo en base octal o decimal, y se usaban típicamente para mostrar vectores tales como la actitud del vehículo espacial o un cambio de velocidad necesario (delta-V). Aunque los datos se almacenaban internamente en unidades métricas, estos se mostraban según el sistema anglosajón de unidades. Esta interfaz tipo calculadora fue la primera de su clase, y el prototipo para todas la interfaces de paneles de control similares.
El módulo de mando tenía dos DSKYs conectadas a su AGC; una situado en el panel de instrumentos principal y una segunda en la bahía de equipos cerca de un sextante que se usaba para alinear la plataforma de navegación inercial. El módulo lunar tenía una única interfaz DSKY para su AGC. Unos indicadores de actitud (FDAI), controlados por el AGC, se situaban sobre la DSKY en la consola del comandante y en el LM.
En 2009, se vendió un DSKY por $50788 en la subasta pública organizada por Heritage Auctions.
El cristal oscilador del reloj del AGC tenía una frecuencia de unos 2,048 MHz. Esta señal se dividía por dos para producir un reloj de 1,024 MHz de cuatro fases que usaba el AGC para realizar las operaciones internas. Además, la señal de 1,024 MHz se dividía por dos para producir una señal de 512 kHz denominada frecuencia maestra; esta señal se usaba para sincronizar los sistemas externos del Apolo.
A su vez, la frecuencia maestra primero se dividía mediante un escalador por cinco, usando un contador en anillo para producir una señal de 102,4 kHz. Luego era dividida por dos a través de 17 etapas consecutivas: desde F1 (51,2 kHz) hasta F17 (0,78125 Hz). La etapa F10 (100 Hz) era retroalimentada hacia el AGC para incrementar el reloj en tiempo real y otros contadores involuntarios usando el Pinc (detallado a continuación). La etapa F17 se usaba para cargar intermitentemente el AGC cuando trabajaba en modo standby.
El AGC tenía cuatro registros de 16 bits con propósitos computacionales conocidos como los registros centrales:
También había cuatro posiciones en la memoria central, en las direcciones 20-23, denominadas posiciones de edición porque lo que estuviera almacenado allí sería devuelto desplazado o rotado un bit, excepto para lo que fuera desplazado a la derecha 7 bits, para extraer uno de los 2 códigos de operación de 7 bits empaquetados en una palabra. Esto era común a los AGCs del Bloque I y del Bloque II.
El AGC tenía varios registros adicionales que se usaban internamente durante el transcurso de una operación:
El formato de las instrucciones emplea 3 bits para el código de operación y 12 bits para las direcciones. Block I tenía 11 instrucciones: TC, CCS, INDEX, XCH, CS, TS, AD, y MASK (básicas), y SU, MP y DV (extras). Las ocho primeras, llamadas instrucciones básicas eran utilizadas directamente por el código de operación de 3 bits. El acceso a las últimas tres instrucciones era a través de un tipo especial de la instrucción INDEX llamada EXTEND, justo antes de la instrucción.
Las instrucciones del AGC de Block I son:
Las instrucciones se implementaban en grupos de 12 pasos, llamados pulsos de temporización (timing pulses). Los pulsos se nombraban de TP1 a TP12. Cada conjunto de 12 pulsos se llamaba subsecuencia de instrucción. Las instrucciones simples, como TC, se ejecutaban en una sola subsecuencia de 12 pulsos. Las instrucciones más complejas necesitaban varias subsecuencias. La instrucción de multiplicación (MP) usaba 8 subsecuencias: una inicial llamapa MP0, seguida de una subsecuencia MP repetida 6 veces y terminada por MP3. Se redujo a 3 subsecuencias en Block II.
Cada pulso de temporización (TP) en una subsecuencia podía disparar hasta 5 pulsos de control. Los pulsos de control eran señales que hacía en trabajo de la instrucción, como leer el contenido de un registro en el bus, o escribir datos del bus en un registro.
La memoria del AGC Block I estaba organizada en bancos de 1K palabras (KP). El primer banco (banco 0) era de memoria volátil (RAM). Todos los siguientes bancos eran memoria fija (ROM).
Cada instrucción AGC tenía un campo de direccionamiento de 12 bits. Los bits más bajos (1-10) direccionan la memoria dentro de cada banco. Los bits 11 y 12 seleccionan el banco: 00 selecciona el banco RAM (banco 0), 01 el banco 1 (ROM), 10 el siguiente (banco 2, ROM) y 11 selecciona el registro de banco, que se puede usar para seleccionar cualquier banco por encima del 2. Los bancos 1 y 2 se denominaban bancos de memoria fijo-fijo porque siempre estaban disponibles independientemente del contenido del registro de banco. Los bancos 3 y superior e llamaban fijo-seleccionable porque el banco seleccionado se seleccionaba por el registro de banco.
Originalmente, el AGC Block I tenía 12KP de memoria fija, pero se incrementó posteriormente a 24 KP. El Block II tenía 32 KP de memoria fija y 4 KP de memoria RAM.
El AGC transfería datos desde y hacia la memoria a través del registro G en un proceso llamado ciclo de memoria. El ciclo de memoria duraba 12 pulsos de temporización (11,72 μs), comenzando en el TP1 cuando el AGC cargaba la dirección de memoria a ser leída en el registro S. El hardware de la memoria recuperaba el dato/la palabra de la memoria de la dirección especificada en el registro S. Las palabras de la RAM se depositaban en el registro G en el TP6; las palabras de la ROM estaban disponibles en el TP7. La palabra recuperada de la memoria quedaba disponible en el registro G para el acceso del AGC durante los TP7 a TP10. Después del TP10, el dato existente en el registro G se escribía en la memoria.
El ciclo de memoria del AGC tenía lugar de forma continua durante el funcionamiento del AGC. Las instrucciones que necesitaban datos de la memoria accedían a ellos durante los pulsos TP7-10. Si el AGC cambiaba la palabra de memoria en el registro G, la palabra cambiada era restaurada en memoria tras el pulso TP10. De esta forma, las palabras de datos ciclaban continuamente de la memoria al registro G, y de nuevo a la memoria.
Los 15 bits más bajos de cada palabra contenían instrucciones AGC o datos, usando el bit 16 como bit de paridad. Este bit se ponía a 0 o 1 a través de un circuito de generador de paridad de forma que la suma de 1 en cada palabra en la memoria, siempre fuera un número impar. Para verificar el bit de paridad, se disponía de un circuito de chequeo de paridad que se encargaba de la verificación en cada ciclo de memoria; si el bit no tenía el valor esperado, se asumía que el dato estaba corrompido y se iluminaba la luz de alarma de paridad en el panel.
El AGC tenía un modo de ahorro de energía controlado por un interruptor de standby. Este modo cortaba la corriente del AGC excepto al reloj de 2,048 MHz y al contador de impulsos. La señal F17 del contador de impulsos encendía y apagaba el AGC en intervalos de 1,28 segundos. En este modo, el AGC ejecutaba funciones esenciales, chequeaba el interruptor de standby y si estaba pulsado, cortaba la corriente y volvía a dormir hasta la siguiente señal F17.
En el modo standby el AGC permanecía dormido la mayor parte del tiempo, por lo que no se despertaba para ejecutar la instrucción Pinc necesaria para actualizar el reloj en tiempo real del AGC a intervalos de 10 ms. Para compensarlo, una de las funciones ejecutadas por el AGC cada vez que se despertaba era actualizar el reloj en tiempo real en 1,28 segundos.
El modo standby se diseñó para reducir el consumo de energía de 5 a 10 W (sobre 70 W) durante el curso medio del vuelo, cuando el AGC no era necesario. Sin embargo, en la práctica, el AGC se dejó encendido en todas las fases de la misión y nunca se usó esta característica.
El ACG tenía unos buses de lectura y escritura de 16 bits. Los datos de los registros centrales (A, Q, Z o LP), u otros registros internos se podían colocar en el bus de lectura con una señal de control. El bus de lectura se conectaba con el bus de escritura a través de un búfer, de forma que cualquier dato que aparecía en el bus de lectura, también aparecía en el de escritura. Otras señales de control podían copiar los datos del bus de escritura en los registros.
Las transferencias de datos se comportaban de la siguiente manera: para mover la dirección de la siguiente instrucción desde el registro B al registro S, se empleaba una señal de control RB (READ B). Esto causaba que la dirección se moviese del registro B al bus de lectura y de ahí al bus de escritura. Una señal de control WS (WRITE S) movía la dirección desde el bus de escritura al registro S.
Existía la posibilidad de leer simultáneamente varios registros en el bus de lectura. Cuando esto ocurría, los datos de cada registro se incorporaban al bus a por medio de un OR (inclusivo). Este OR se usó para implementar la instrucción MASK que era una operación AND lógica. Debido a que el AGC no tenía posibilidad de hacer un AND lógico, pero sí un OR lógico a través del bus, y se puede invertir datos a través del registro C, según el teorema de De Morgan, se podía implementar un AND lógico a base de OR lógico y NOT, invirtiendo ambos operandos, ejecutando un OR lógico en el bus e invirtiendo el resultado.
Cuando se terminaron de definir los requisitos de diseño del AGC, el software necesario para su desarrollo, así como las técnicas de programación apropiadas no existían, por lo que tuvieron que ser diseñadas desde cero.
El software AGC estaba escrito en lenguaje de programación AGC, y era almacenado en memoria de núcleos cableados. Existía un simple sistema operativo de tiempo real que consistía en el Exec, un sistema de ordenamiento de procesos que podía ejecutar hasta ocho 'tareas' a la vez usando una arquitectura cooperativa multitarea (cada tarea debía periódicamente devolver el control al Exec, que entonces comprobaba si había alguna tarea pendiente con mayor prioridad). También existía un componente de interrupción llamado Waitlist, que podía programar múltiples tareas de una duración determinada. Estos procesos eran cortas listas de código de ejecución que podía autoprogramarse para una nueva ejecución en el Waitlist, o podía lanzar una operación mayor, al iniciar una 'tarea' con el Exec.
La ejecución de los procesos del Exec se basaban en su prioridad. La tarea de menor prioridad, llamada dummy job, se encontraba siempre presente. Realizaba chequeos de diagnóstico y controlaba una luz verde relacionada con la actividad del ordenador en el DSKY: si la aplicación dummy estaba en marcha, significaba que el ordenador no tenía ninguna aplicación más prioritaria, por lo que la luz se encontraba apagada. La aplicación dummy se cancelaba si existía alguna tarea de mayor prioridad pendiente de ejecutar, lo que se indicaba mediante el encendido de la luz de iluminación de la actividad del ordenador.
El AGC también disponía de un sofisticado intérprete de software, desarrollado por el MIT Instrumentation Laboratory, que implementaba una máquina virtual de mayor complejidad y capacidad de pseudo-instrucciones que el AGC nativo. Estas instrucciones simplificaban los programas navigacionales. El código interpretado, que permitía trigonometría de doble precisión, aritmética escalar y vectorial (16 y 24 bits), e incluso instrucciones MXV (matriz × vector), podía mezclarse con código AGC nativo. Mientras que el tiempo de ejecución de las pseudo-instrucciones se incrementaba (debido a la necesidad de interpretar estas instrucciones durante la ejecución) el intérprete proporcionaba muchas más instrucciones de las que el AGC soportaba de forma nativa, y los requisitos de memoria eran mucho más bajos que en el caso de que se incorporaran estas instrucciones al lenguaje de programación nativo del AGC, que requerirían la utilización de memoria adicional en el ordenador (en aquel tiempo la capacidad de memoria era muy cara). El tiempo medio de ejecución de las pseudo-instrucciones era de 24 ms. El compilador y el sistema de control de versión, llamado YUL por el prototipo previo Christmas Computer, aseguraba las transiciones adecuadas entre el código nativo e interpretado.
Una serie de rutinas para interfaz del usuario llamadas Pinball proporcionaban los servicios de display y teclado para realizar las tareas de funcionamiento del AGC. Un extenso conjunto de rutinas de acceso estaban disponibles para permitir al operador (el astronauta) mostrar los contenidos de varios bloques de memoria en formato sistema octal o decimal en grupos de 1, 2, o 3 registros al mismo tiempo. También se proporcionaban rutinas de monitoreo para que el operador pudiera iniciar una tarea para volver a mostrar periódicamente los contenidos de ciertos bloques de memoria. Era posible también iniciar tareas. Las rutinas Pinball conformaban el equivalente (de forma muy aproximada) del núcleo UNIX.
La mayor parte del software se encontraba en memoria de solo lectura y por tanto no podía ser cambiado en ejecución, pero algunas partes determinadas del software estaban almacenadas en memoria de núcleos magnéticos editables, por lo que podían ser sobreescritos por los astronautas utilizando la interfaz DSKY, como de hecho ocurrió durante el vuelo del Apolo 14.
Los principios de diseño del AGC desarrollados por el MIT Instrumentation Laboratory, entonces bajo la dirección de la científica Margaret Hamilton, formarían los cimientos de la llamada "ingeniería de software", un término acuñado por Anthony Oettinger - particularmente para el diseño de sistemas más fiables que se apoyaran en software asíncrono, planificación por prioridad, testeo y modelos en los que la capacidad de decisión del humano estuviera presente. El software del Apollo Guidance Computer software influyó en el diseño posterior del Skylab, el transbordador espacial y los primitivos sistemas de aviónica basados en fly-by-wire.
En 1966 se diseñó una nueva versión del AGC, llamada Block II (bloque II). Mantenía la misma arquitectura básica del bloque I, pero incrementaba la memoria volátil de 1.000 a 2.000 palabras. La memoria fija se expandió de 24.000 a 36.000 palabras. Las instrucciones se expandieron de 11 a 34 y se implementaron canales I/O para reemplazar a los registros I/O del bloque I. La versión del bloque II fue la que se utilizó en los vuelos que llegaron a la Luna. El bloque I fue utilizado durante los vuelos no tripulados del Apolo 4 y Apolo 6, así como a bordo del malogrado Apolo 1.
El PGNCS del Apolo generó avisos de error no previstos durante el vuelo de descenso a la superficie lunar del Apolo 11, en la que el AGC mostraba la alarma 1201 ("Executive overflow - no vacant areas") y la alarma 1202 ("Executive overflow - no core sets"). Esto se debió a una rápida y continuada corriente de "robos de ciclo" realizados por el radar de aproximación, dejado de forma intencionada en standby durante el descenso en caso de que fuera necesario por un aborto de la maniobra de alunizaje.
Durante esta parte del descenso, el procesador se debía encontrar normalmente a casi un 85% de carga de trabajo. Los 6.400 ciclos extras por segundo añadieron el equivalente a un 13% de carga, dejando justo la necesaria para que todas las tareas pudieran ejecutarse. A los cinco minutos de iniciar el descenso, Buzz Aldrin programó el ordenador con el comando 1668 que daba instrucciones de calcular y mostrar DELTAH (la diferencia entre la altitud medida con el radar y la calculada por el ordenador). Esto añadió un 10% adicional a la carga de trabajo del procesador, causando un desbordamiento y la alarma 1202. Tras el permiso desde el control de tierra en Houston, que dio luz verde para el alunizaje, Aldrin introdujo de nuevo el comando 1668, y la alarma 1202 volvió a saltar. Cuando informó de la segunda alarma, Aldrin comentó "Parece que aparece cuando tenemos la tarea 1668 en ejecución". Afortunadamente para el Apolo 11, el software del AGC había sido diseñado con control de prioridad. Justo para lo que había sido diseñado, el software se recuperó automáticamente, eliminando las tareas no prioritarias incluyendo el comando 1668, para completar las tareas críticas de control y guiado. El controlador de vuelo Steve Bales y su equipo de apoyo, que incluía a Jack Garman, dio permiso en repetidas ocasiones para la continuidad del alunizaje, y este fue un éxito. Por su trabajo, Bales recibió la Medalla Presidencial de la Libertad en nombre de todo el equipo del centro de control y los tres astronautas del Apolo.
El problema no era un error de programación del AGC ni un error de pilotaje. Era un error en el diseño del hardware periférico que ya había sido detectado y documentado por los ingenieros del Apollo 5. Sin embargo, como el problema había ocurrida una sola vez durante las pruebas, determinaron que era más seguro operar con el hardware existente (que ya había sido probado), que volar con un sistema de radar más nuevo pero no probado. En el hardware real, la posición del radar de encuentro se codificó con una sincronización excitada por una fuente diferente de CA de 800 Hz diferente a la utilizada por la computadora como referencia de tiempo. Las dos fuentes de 800 Hz fueron enclavadas en frecuencia pero no en fase, y las pequeñas variaciones aleatorias de fase hicieron que pareciera que la antena estaba "oscilando" rápidamente en su posición a pesar de estar completamente estacionaria. Estos movimientos fantasmas generaron la serie rápida de robos de ciclo.
Tras su uso en el programa Apolo, el AGC formó parte de un sistema experimental fly-by-wire (FBW) instalado a bordo de un F-8 Crusader para demostrar la practicidad de un FBW manejado mediante ordenador. El AGC usado en la primera fase del programa fue reemplazado por otro sistema en la segunda fase, y la investigación realizada en el programa derivó en el desarrollo de sistemas FBW para el transbordador espacial. El AGC también sirvió, aunque indirectamente, al desarrollo de sistemas FBW para la generación de cazas que se estaban desarrollando en aquella época.
El AGC también fue usado en el Vehículo de rescate de inmersión profunda (DSRV, Deep Submergence Rescue Vehicle) de la Armada de los Estados Unidos.
Escribe un comentario o lo que quieras sobre Apollo Guidance Computer (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)