Error 1202: La Alarma Que Casi Detuvo el Alunizaje

Doce Minutos Para la Historia

20 de julio de 1969. El Módulo Lunar Eagle acababa de separarse del Módulo de Comando Columbia, y los astronautas Neil Armstrong y Buzz Aldrin estaban iniciando su descenso propulsado hacia la superficie de la Luna. Detrás de ellos, Michael Collins orbitaba solo en el Columbia, esperando.

En el Control de Misión en Houston, cientos de ingenieros y controladores de vuelo monitorizaban cada parámetro del descenso. En las salas auxiliares, equipos de especialistas esperaban listos para asesorar a los controladores sobre cualquier anomalía. La atmósfera estaba cargada de anticipación — y temor. Nadie había intentado jamás un aterrizaje propulsado en otro mundo.

A una altitud de aproximadamente 12.200 metros, Armstrong y Aldrin iniciaron el Programa 63 (P63), la fase de frenado del descenso. El AGC — el Computador de Guía Apollo — tomó el control, regulando el motor de descenso para comenzar a desacelerar al Eagle desde su velocidad orbital de aproximadamente 1.676 metros por segundo.

Todo era nominal. El DSKY mostraba velocidad, tasa de altitud y altitud. Los números iban en la dirección correcta. Entonces, a una altitud de unos 10.200 metros, con seis minutos y treinta segundos para el contacto, el DSKY se iluminó con una alarma que nadie quería ver.

"Alarma de Programa"

La llamada vino de Buzz Aldrin, su voz firme pero urgente: "Alarma de programa." En el DSKY, el indicador PROG estaba encendido. Aldrin tecleó V05 N09 E para mostrar el código de alarma. Los registros mostraron: 1202.

Armstrong radió inmediatamente a Houston: "Es un 1202."

En el Control de Misión, todas las miradas se dirigieron al oficial de guía — un ingeniero de 26 años llamado Steve Bales. Bales era responsable de monitorizar el AGC y los sistemas de guía del Módulo Lunar. El código 1202 significaba una cosa: desbordamiento del ejecutivo. El planificador de tareas del AGC tenía más trabajos en cola de los que podía completar en el tiempo disponible.

El computador estaba sobrecargado.

Bales tenía segundos para tomar una decisión. Si declaraba "No Go," el descenso se abortaría. Armstrong encendería el motor de ascenso y regresaría a órbita. El alunizaje — el propósito mismo del Apollo 11 — se cancelaría. Si declaraba "Go" y el computador realmente fallaba, dos astronautas podrían morir.

El Software Que Salvó la Misión

Para entender por qué Bales declaró "Go," hay que comprender el software que se ejecutaba dentro del AGC — software diseñado por Margaret Hamilton y su equipo en el Instrumentation Laboratory del MIT.

El equipo de Hamilton había construido el sistema operativo del AGC en torno a un concepto llamado el ejecutivo basado en prioridades. A diferencia de un programa secuencial simple, el ejecutivo podía gestionar múltiples tareas ejecutándose concurrentemente, cada una con un nivel de prioridad asignado. Cuando el computador se sobrecargaba, no se colgaba. En cambio, hacía algo extraordinario: descartaba las tareas de menor prioridad y continuaba ejecutando las de mayor prioridad.

Esto no fue casualidad. Hamilton había insistido en incorporar una recuperación robusta de errores en el software. Había argumentado — contra el escepticismo de algunos gestores de la NASA — que el software podía y encontraría condiciones inesperadas durante una misión. Su equipo diseñó el sistema para que el AGC siempre priorizara las tareas esenciales para mantener a los astronautas con vida: guía, navegación y control.

La alarma 1202 era la forma en que el ejecutivo informaba de que se había visto forzado a reiniciar tareas de menor prioridad porque no había suficiente tiempo de procesamiento para completarlas todas. Pero — y este era el detalle crucial — los cálculos esenciales de guía seguían ejecutándose correctamente.

Qué Causó la Sobrecarga

La causa raíz de la alarma 1202 se rastreó hasta el radar de encuentro. Antes del descenso, un paso de la lista de verificación requería que el radar de encuentro se configurara en una posición específica. El radar estaba destinado para su uso durante el ascenso desde la superficie lunar, cuando el Eagle necesitaría encontrar y acoplarse con el Columbia. Durante el descenso, no era necesario.

Sin embargo, el radar se dejó encendido y en un modo donde enviaba datos al AGC. Los registros contadores del radar se actualizaban de forma asíncrona — impulsados por una fuente de alimentación de corriente alterna funcionando a una frecuencia ligeramente diferente del reloj del AGC. Esto creaba un flujo constante de interrupciones de "incremento de contador" que el AGC tenía que procesar.

En circunstancias normales, el AGC podía manejar estas interrupciones. Pero durante el descenso propulsado, el computador ya funcionaba cerca de su capacidad máxima, procesando las ecuaciones de guía del P63, monitorizando la unidad de medición inercial (IMU), controlando el acelerador del motor de descenso, gestionando las actualizaciones del display del DSKY y manejando la telemetría hacia el Control de Misión.

La carga adicional del radar de encuentro empujó al AGC más allá de su umbral de capacidad. El ejecutivo detectó el desbordamiento y activó la alarma 1202.

En la sala auxiliar del Control de Misión, Jack Garman — un ingeniero informático de 24 años — se había preparado para exactamente este escenario. Semanas antes de la misión, durante una simulación, había aparecido una alarma similar. Garman había investigado los códigos de alarma y compilado una lista de referencia. Había pegado una nota manuscrita en su consola: alarma 1202 — si no se repite, Go.

Cuando Bales se giró hacia su sala auxiliar y preguntó, la respuesta de Garman fue inmediata: "Es un Go."

"Estamos Go en Esa Alarma"

Bales pulsó su micrófono: "Estamos Go en esa alarma." El director de vuelo Gene Kranz transmitió la decisión a la tripulación a través del CapCom Charlie Duke: "Recibido, les tenemos. Estamos Go en esa alarma."

El descenso continuó. Pero la tregua duró poco. A unos 600 metros de altitud, apareció otra alarma: 1201. Estaba estrechamente relacionada con la 1202 — una alarma de "no hay áreas vacantes," que significaba que la cola de tareas del AGC estaba completamente llena. De nuevo, el ejecutivo de prioridad descartó tareas no esenciales y mantuvo la guía en funcionamiento.

Bales confirmó una vez más: "Mismo tipo. Estamos Go."

Las alarmas parpadearían intermitentemente durante el resto del descenso, cada vez provocando una oleada momentánea de adrenalina en el Control de Misión. Cada vez, el software funcionó exactamente como el equipo de Hamilton lo había diseñado. Los cálculos esenciales continuaron sin interrupción.

El Descenso Final

Mientras las alarmas del computador dominaban las comunicaciones por radio, Armstrong enfrentaba otra crisis. Mirando por la ventana del LM, podía ver que el punto de aterrizaje seleccionado por el computador estaba en un campo de rocas al borde de un gran cráter — que más tarde se bautizaría como Cráter West. El terreno era demasiado accidentado para un aterrizaje seguro.

Armstrong tomó el control semimanual usando el Programa 66 (P66), que le permitía anular la guía automática del computador mientras el AGC continuaba gestionando el acelerador y la actitud. Usando el controlador manual, pilotó el Eagle más allá del campo de rocas, buscando un punto de aterrizaje suave.

El DSKY mostraba las menguantes reservas de combustible. El CapCom Charlie Duke anunció el tiempo restante:

"Sesenta segundos." Esto significaba sesenta segundos de combustible antes de un aborto obligatorio.

Armstrong encontró un área despejada y comenzó su aproximación final. La sombra del LM apareció sobre la superficie. El polvo levantado por el motor de descenso empezó a oscurecer el suelo.

"Treinta segundos."

Entonces, una nueva señal llegó del DSKY — no una alarma esta vez, sino una indicación de contacto. Las sondas de 170 centímetros que colgaban bajo las patas del Eagle tocaron la superficie lunar.

Aldrin lo anunció: "Luz de contacto."

Armstrong apagó el motor. El Eagle se posó en la Luna con un suave golpe.

"Houston, aquí Base Tranquilidad. El Eagle ha aterrizado."

Charlie Duke, con la voz entrecortada por la emoción, respondió: "Recibido, Tranquilidad. Los copiamos en superficie. Aquí hay un grupo de tipos a punto de ponerse azules. Estamos respirando de nuevo. Muchas gracias."

Las Consecuencias Técnicas

Tras la misión, la NASA llevó a cabo una investigación exhaustiva de las alarmas 1202 y 1201. Se confirmó la causa raíz: las actualizaciones asíncronas de los contadores del radar de encuentro habían consumido aproximadamente el 15% de la capacidad de procesamiento del AGC durante una fase en la que el computador ya operaba al 85% de su carga.

La solución fue sencilla. Para las misiones Apollo posteriores, se modificaron los procedimientos para que el radar de encuentro se colocara en un modo diferente durante el descenso propulsado, eliminando las interrupciones espurias. Las alarmas no volvieron a producirse en los vuelos posteriores.

Pero la verdadera lección no era sobre interruptores de radar. Era sobre diseño de software.

El Legado de Margaret Hamilton

La insistencia de Margaret Hamilton en construir un ejecutivo basado en prioridades y tolerante a fallos en el software del AGC fue reivindicada el día más importante de la historia de los vuelos espaciales. Sin la capacidad del ejecutivo para descartar tareas no críticas y continuar los cálculos esenciales de guía, la alarma 1202 habría significado un aborto — o peor, un impacto.

Hamilton recordó más tarde que algunos gestores de la NASA habían cuestionado la necesidad de un software de gestión de errores tan elaborado. "Decían: 'Eso nunca pasará,'" recordaba. "Yo respondí: '¿Pero y si pasa?'"

Pasó. Y porque ella se había preparado para ello, Armstrong y Aldrin caminaron sobre la Luna.

La alarma 1202 del Apollo 11 se convirtió en un caso de estudio emblemático en ingeniería de software — un campo que la propia Hamilton ayudó a nombrar. Demostró que la robustez del software no era un lujo sino una necesidad para cualquier sistema de seguridad crítica. Los principios que ella fue pionera en establecer — recuperación asíncrona de errores, planificación por prioridades, degradación elegante — son ahora fundamentales para todo sistema operativo, todo sistema de control en tiempo real y toda aplicación de seguridad crítica del mundo.

El Elemento Humano

La historia de la alarma 1202 se cuenta a menudo como un triunfo de la ingeniería, y lo es. Pero también es una historia de coraje humano. Steve Bales tenía 26 años. Jack Garman tenía 24. Tuvieron segundos para tomar una decisión que determinaría si la humanidad aterrizaría en la Luna. Se habían preparado meticulosamente, confiaron en su análisis e hicieron la llamada correcta bajo una presión inimaginable.

Gene Kranz, el director de vuelo, dijo más tarde sobre aquel momento: "Cuando escuché la voz de Steve decir 'Go,' supe que teníamos a las personas adecuadas en los lugares adecuados."

Neil Armstrong, con su característica contención, describió las alarmas como "una sorpresa bastante desagradable." Más tarde reconoció que sin la capacidad del software para seguir funcionando durante la sobrecarga, "no lo habríamos logrado."

Qué Significa 1202 Hoy

La alarma 1202 se ha convertido en un icono de resiliencia en la cultura de la ingeniería. Los desarrolladores de software la citan como un ejemplo de manual de degradación elegante. Aparece en camisetas, tazas de café y — en apolloreplica.com — en los displays de réplicas del DSKY fielmente reproducidas.

Pero más allá del simbolismo cultural, el 1202 porta una lección más profunda: la importancia de diseñar sistemas que fallen de forma controlada en lugar de catastrófica. Margaret Hamilton y su equipo no podían predecir cada escenario que enfrentaría el AGC. En cambio, diseñaron software que podía manejar lo inesperado — software que seguía funcionando cuando el plan se venía abajo.

En una era de sistemas cada vez más complejos y autónomos, desde coches autónomos hasta naves espaciales controladas por inteligencia artificial, esa lección nunca ha sido más relevante. La alarma 1202 nos recuerda que la medida de la gran ingeniería no es si las cosas salen mal — siempre lo harán — sino qué hace el sistema cuando sucede.