Margaret Hamilton murió el 30 de septiembre de 2026 a los 90 años, pero el código que escribió para el Apollo Guidance Computer sigue publicado en GitHub, línea por línea, tal como voló en 1969. Esa computadora decidió en segundos no abortar el alunizaje del Apolo 11 cuando dos alarmas desconocidas empezaron a sonar durante los minutos finales del descenso.
TL;DR
- El sistema de prioridades del AGC descartó tareas de baja prioridad y evitó abortar el alunizaje de 1969.- Las alarmas 1202 y 1201 eran desbordamientos del ejecutivo, no fallas de hardware.- GitHub alberga el código fuente real de Luminary099, el software que guio el módulo lunar.- Margaret Hamilton acuñó el término ingeniería de software para legitimar la disciplina en los años sesenta.- Clonar chrislgarry/Apollo-11 y correr grep deja ver hoy las rutinas reales que volaron en 1969.
¿Qué es el Apollo Guidance Computer?
El Apollo Guidance Computer es la computadora de guiado que diseñó el Instrumentation Laboratory del MIT para las naves Apolo, construida por Raytheon y basada en memoria de núcleo trenzada a mano. Ejecutaba navegación, control de actitud y las secuencias de descenso lunar con apenas unos pocos miles de palabras de memoria disponible.
El AGC pesaba unos 32 kilos y consumía cerca de 55 vatios de potencia.
Por qué importa
En los años sesenta, programar no se consideraba ingeniería real: era una tarea manual, casi de oficina, subordinada al hardware. Hamilton lideró la división de software del MIT Instrumentation Lab con más de 400 personas a su cargo y empezó a llamar a su trabajo ingeniería de software para que se le diera el mismo peso que a construir un cohete.
La etiqueta pegó. En 1968 la OTAN convocó la primera conferencia formal de ingeniería de software en Garmisch, Alemania, reconociendo que escribir código para sistemas críticos necesitaba procesos y especificaciones, no solo talento individual. Hamilton pasó dos décadas en ese cruce entre matemática, meteorología (trabajó antes con Edward Lorenz, pionero del caos) y programación de sistemas críticos.
El reconocimiento llegó tarde pero llegó: en 2016 el presidente Barack Obama le entregó la Medalla Presidencial de la Libertad, citando que su arquitectura de software llevó a saltos gigantes para la humanidad. Murió a los 90 años, autora de más de 130 publicaciones técnicas.
Cómo funciona el sistema de prioridades del AGC
El AGC manejaba la consola DSKY (Display and Keyboard) con un principio simple: cualquier tarea de bajo nivel debía poder ceder el paso de inmediato si el astronauta apretaba una tecla. Esa prioridad del humano sobre el software corría en paralelo al mecanismo que, horas después, salvó el alunizaje.
El Executive: la primera planificación de prioridades
El Apollo Guidance Computer corría un sistema operativo propio, bautizado Executive, que repartía el procesador entre distintas tareas usando números de prioridad: cuanto más bajo el número, más urgente la tarea. Cada tarea necesitaba un bloque de memoria llamado core set para guardar sus variables temporales, y el AGC solo tenía unos pocos de esos bloques disponibles a la vez.
Si todos los core sets estaban ocupados y llegaba una tarea de mayor prioridad, el Executive no esperaba: cancelaba la tarea de menor prioridad activa, le quitaba su core set y arrancaba la nueva. Esa decisión de diseño, descartar antes que colapsar, es la base de lo que hoy llamamos planificación por prioridades en un sistema de tiempo real.
flowchart TD
A["Nueva tarea en la cola"] --> B{"Hay nucleo disponible"}
B -- "Si" --> C["Ejecutar la tarea"]
B -- "No" --> D{"Prioridad mayor que la tarea activa"}
D -- "Si" --> E["Descartar la tarea de menor prioridad"]
E --> C
D -- "No" --> F["Disparar alarma 1202 y reiniciar el Executive"]
F --> G["Restaurar solo guiado y navegacion"]
La alarma 1202: cuando el radar mintió
La causa real no fue un error de programación: fue un interruptor. La tripulación dejó encendido el radar de encuentro, pensado para la fase de regreso, durante todo el descenso. Ese radar le mandaba al AGC pulsos eléctricos adicionales constantes, pidiendo ciclos de cómputo que no estaban planeados en ninguna tarea registrada.
El Executive intentó darle espacio a esas peticiones y se quedó sin core sets libres para las tareas reales. Ahí aparecieron las alarmas 1202 y luego 1201, que en inglés significan desbordamiento del ejecutivo sin áreas disponibles. El sistema no se congeló: descartó tareas de menor prioridad, como la actualización del display, y conservó guiado, navegación y control, las tres que de verdad necesitaba para no estrellarse.
En el Control de Misión, el oficial de guiado Steve Bales y el ingeniero Jack Garman reconocieron la alarma en segundos gracias a una lista que el propio equipo de Hamilton había preparado tras reproducir fallas similares en simulaciones previas. Dieron GO y Neil Armstrong y Buzz Aldrin siguieron el descenso.
sequenceDiagram
participant R as Radar de encuentro
participant E as Executive del AGC
participant G as Tarea de guiado
R->>E: Interrupciones no planeadas
E->>E: Cola de tareas se satura
E-->>G: Alarma 1202, reinicio parcial
Note over E,G: Solo sobreviven las tareas de mayor prioridad
Cada palabra del AGC medía 15 bits más 1 bit de paridad, antes del byte estándar de 8 bits.
Ejemplos prácticos: el código real del AGC
El código nunca se perdió. Hoy cualquiera puede clonarlos y leer exactamente lo que ejecutó el Apolo 11.
El ensamblador original se llamó YUL, y hoy existe una reimplementación llamada yaYUL, dentro del proyecto Virtual AGC, que recompila ese mismo código fuente y produce binarios equivalentes a los que volaron en 1969. Esa verificación es la prueba de que el texto en GitHub no es una reconstrucción aproximada.
La mayoría del código usa instrucciones como TC (transfer control), CCS (count, compare and skip) y DXCH (double exchange). Una revisión de combustible se veía así, en una versión simplificada inspirada en la estructura real del Executive:
CCS FUEL_LOW_FLAG # Compara la bandera y decide el salto
TC ALARM_JOB # Si es negativa, dispara la alarma
TC RETURN_TO_WAITLIST
ALARM_JOB TC PRIORITY_INSERT
CA LOW_PRIORITY
TC EXECUTIVE
Este fragmento no ejecuta nada por sí solo, necesita el resto del programa y el emulador, pero representa el patrón real: comparar, decidir y entregarle la decisión al Executive en lugar de a un if aislado.
El archivo real que enciende el motor de ascenso lunar se llama, literalmente, BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc, y la rutina que atiende los botones y luces del panel de control se llama PINBALL_GAME_BUTTONS_AND_LIGHTS. Los programadores de Hamilton nombraban sus rutinas con ese tono informal incluso en código que literalmente mandó a tres personas a la Luna.
Cómo empezar: explorar el código del Apolo 11
Clonar el repositorio solo requiere tener git instalado. En Linux o macOS corré estos comandos en una terminal:
git clone https://github.com/chrislgarry/Apollo-11.git
cd Apollo-11
grep -rln "BURN_BABY_BURN" .
La salida esperada es una sola línea con la ruta del archivo real:
./Luminary099/BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc
En Windows, los mismos comandos funcionan igual dentro de Git Bash o WSL. Para ubicar las rutinas detrás de la alarma del alunizaje, corré:
grep -rln "1202" . | head -5
Esto devuelve los archivos del módulo lunar que mencionan la alarma, incluyendo las rutinas del propio Executive que la dispara.
💡 Tip: si grep no encuentra nada, confirmá que estás parado dentro de la carpeta Apollo-11 clonada; el repositorio organiza el código por misión.
De la Luna a Marte: la misma lección 28 años después
La lógica de descartar antes que colapsar volvió a ponerse a prueba en 1997, cuando el rover Mars Pathfinder empezó a reiniciarse solo en la superficie marciana. La causa fue casi lo opuesto a un desbordamiento de prioridades: una tarea de baja prioridad retenía un recurso compartido y bloqueaba a una de alta prioridad, un problema llamado inversión de prioridades.
El equipo de la NASA, usando VxWorks, corrigió el comportamiento de forma remota activando herencia de prioridades, una técnica que ya existía en la teoría pero que Pathfinder volvió famosa en la práctica. El paralelo con el Apolo 11 es directo: ambas misiones sobrevivieron porque alguien, antes del lanzamiento, ya había diseñado un mecanismo para que el sistema de prioridades se corrigiera solo.
Hoy esa filosofía aparece en estándares de software aeroespacial como DO-178C, que exige clasificar cada función según cuánto daño causaría su falla, y en cualquier sistema operativo de tiempo real. El AGC no inventó la idea de prioridades, pero fue el primer sistema crítico de misión humana que demostró, con tres astronautas a bordo, que esa idea funcionaba.
Errores comunes y lecciones del Apolo 11
- Confundir alarma con falla: 1202 y 1201 eran desbordamientos de un contador de tareas, no daños físicos en la computadora.- Culpar solo al software: la causa raíz fue un procedimiento humano, el interruptor del radar de encuentro, no un bug en el código de guiado.- Suponer que Hamilton trabajó sola: lideraba dos equipos con más de 400 personas entre el módulo lunar y el módulo de mando.- Pensar que más memoria resuelve la sobrecarga: el AGC tenía apenas 2.048 palabras de memoria borrable y resolvió la saturación con una política de descarte, no con más hardware.
Comparativa: planificación por prioridades, de 1969 a hoy
El esquema de prioridades fijas del Executive sigue vivo, con variaciones, en los sistemas operativos de tiempo real actuales.
SistemaTipo de planificaciónQué pasa si se saturaAGC Executive (1969)Prioridad fija cooperativaDescarta tareas de menor prioridad y reiniciaVxWorksPrioridad fija preemptiva, 256 nivelesLa tarea de mayor prioridad siempre desaloja a la actualFreeRTOSPrioridad fija preemptivaIgual que VxWorks, pensado para microcontroladoresLinux (CFS)Tiempo virtual justo, sin prioridades fijasReparte CPU proporcionalmente entre procesos
Profundizando: aritmética de punto fijo y memoria de núcleo trenzada
El AGC no tenía hardware de punto flotante: cada valor físico (velocidad, altitud, ángulo) se representaba como un entero escalado a un rango fijo, y el programador decidía a mano el factor de escala para que no se desbordara ni perdiera precisión. Esa disciplina de punto fijo obligaba a razonar la física del vuelo antes de escribir una sola instrucción.
Una resta de posiciones orbitales, por ejemplo, se escribía reservando por adelantado cuántos bits representaban la parte entera y cuántos la fracción, algo así:
# Escala: 1 unidad = 2^(-7) millas nauticas
DAS POSICION_ACTUAL # Resta doble precision
DXCH POSICION_DESTINO # Intercambia el resultado
La salida no era un número de punto flotante como 1500.75: era un entero escalado que el programador debía interpretar manualmente contra la tabla de escalas del programa, documentada en papel junto al código.
El programa final no vivía en un disco: se tejía. La memoria fija de 36.864 palabras se fabricaba como una core rope memory, un conjunto de núcleos magnéticos atravesados a mano por hilos de cobre siguiendo el código binario exacto del programa. Cambiar una instrucción después de tejida la memoria significaba empezar una rope nueva, un proceso de semanas, así que cada versión del software pasaba por meses de revisión antes de llegar a la fábrica de Raytheon.
Hamilton defendía algo poco popular en su época: especificar las interfaces con el mismo rigor formal que el código, para que un error de un astronauta no pudiera corromper datos de otro programa en pleno vuelo. Años antes del alunizaje ya había pedido blindar ese tipo de error después de ver a su propia hija ejecutar por accidente un programa de prelanzamiento durante una simulación; NASA respondió que los astronautas entrenados no cometen errores. La propuesta no entró a tiempo, y una falla parecida contribuyó a la sobrecarga que disparó las alarmas del Apolo 11.
📖 Resumen en Telegram: Ver resumen
Tu próximo paso: cloná chrislgarry/Apollo-11 y corré grep -rn "P01" para encontrar la rutina de prelanzamiento que casi repite el error que Hamilton había advertido antes del vuelo.
Preguntas frecuentes
¿Qué es el Apollo Guidance Computer exactamente?
Es la computadora digital que guio tanto el módulo de mando como el módulo lunar del programa Apolo, diseñada por el MIT entre 1961 y 1969 y fabricada por Raytheon con circuitos integrados, novedosos para la época.
¿Por qué el AGC disparó las alarmas 1202 y 1201 en el Apolo 11?
Porque el radar de encuentro, encendido por error durante el descenso, saturó al Executive con peticiones de cómputo no planeadas hasta dejarlo sin memoria para nuevas tareas. El sistema respondió descartando las tareas menos críticas, no apagándose.
¿Qué rol tuvo Margaret Hamilton en el software del AGC?
Dirigió la división de ingeniería de software del MIT Instrumentation Lab, con más de 400 personas trabajando en el código de guiado, navegación y control del módulo lunar y del módulo de mando.
¿Dónde puedo ver el código real del AGC?
En el repositorio público chrislgarry/Apollo-11 en GitHub, que reúne los listados escaneados de Luminary099 y Comanche055 tal como se imprimieron en 1969.
¿El AGC tenía un sistema operativo como los de hoy?
Tenía uno propio, llamado Executive, con un planificador de prioridades y una lista de tareas diferidas, pero sin memoria virtual, sin disco y con apenas dos kilopalabras de memoria de trabajo.
¿Por qué el Apolo 11 ayudó a crear el término ingeniería de software?
Porque Hamilton necesitaba que su disciplina se tomara tan en serio como la ingeniería mecánica o eléctrica del cohete, y el éxito del AGC durante la emergencia del alunizaje demostró en público que el software podía ser cuestión de vida o muerte.
Referencias
- MIT News: obituario oficial de Margaret Hamilton publicado por el MIT.- GitHub: chrislgarry/Apollo-11: código fuente escaneado de Luminary099 y Colossus237.- Wikipedia: especificaciones técnicas del AGC, la computadora de guiado del Apolo.- Wikipedia: biografía y trayectoria de Margaret Hamilton.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)