Una de las curiosidades en relación con el software es que este debía colocarse físicamente en la memoria "fija", equivalente a una ROM. En esa memoria, con nucleos magneticos en forma de anillos, el bit 0 o 1 se determinaba por la situación física de un hilo conductor respecto a un nucleo concreto: si pasaba por el interior del mismo, o lo sorteaba por el exterior. En definitiva, cuando el programa ya se había compilado y convertido en ceros y unos que debían escribirse en la memoria, la copia del programa implicaba crear la memoria físicamente a base de pasar los hilos adecuados por cada nucleo. Como eso resultaba muy laborioso, el software debía entregarse con un amplio margen antes de llegar a usarlo en cada misión. Y esa laboriosa y delicada labor de "confeccionar" la memoria la realizaban las LOLs, las Little Old Ladies, las viejecitas, experimentadas trabajadoras del sector textil, que ayudadas de máquinas especiales iban hilando bit a bit el programa en la memoria. Alucinante.
La otra curiosidad más destacable que se revela en el libro es la causa de las famosas alarmas del computador del modulo lunar que precedieron, y pusieron en peligro aparente, al alunizaje del Apolo 11.
La primera alarma se produjo tras llegar a los 37000 pies, cuando el radar de altitud empezó a responder dando su estimación. Cuando se iba a validar esa lectura, saltó la alarma. Aldrin preguntó al ordenador, con un comando, la naturaleza de la misma, con el resultado 1202. Abajo en la tierra los ingenieros del IL reconocieron que se trataba de una "sobrecarga del ejecutivo". El ordenador estaba sobresaturado, algo equivalente en Windows a ver en el administrador de tareas que la CPU está al 100% todo el tiempo. Algo estaba haciendo trabajar al ordenador más de la cuenta, incluso a pesar de que por diseño sólo se debía llegar al 85% de uso de la capacidad del ordenador cuando este estuviera a pleno rendimiento. Los ingenieros decidieron seguir, digamos que hacer caso omiso a la alarma. La alarma volvió a aparecer poco después del primer "seguir sin hacer caso". Pero poco después una acción automática que debía tener lugar se llevó a cabo sin problema. Parece que a pesar de todo el ordenador hacía lo que debía. Los ingenieros seguían estrujandose la sesera para dar con la causa de la alarma, buscando posibles "culpables" en alguno de los comandos al ordenador. A pesar de tanta alarma, Armstrong no abortó el descenso. Tras unos minutos se llegó a los 7000 pies y el ordenador cambió al programa adecuado, la fase de aproximación. Otra consulta a todos los controladores en tierra dió el resultado "GO". A 3000 pies otra alarma, esta vez 1201, del mismo tipo que la anterior, y despues otra 1202. El ritmo cardiaco de Amstrong pasó de los 120 a los 150 latidos por minuto.
El caso es que el único efecto adverso de las alarmas en el alunizaje fué desviar la atención de todos, incluido Armstrong, que miró por la ventanilla la zona de alunizaje más tarde de lo normal, a los 2000 pies, para darse cuenta de que había un gran cráter y una zona con muchas rocas grandes cubriendo buena parte de la superficie. El lugar no era el esperado, porque pronto en el descenso se vió que iban largos, con un poco más de velocidad de la debida. En esa parte final se describen las maniobras del comandante, con el mando para redesignar el punto de alunizaje, y pilotando con el sistema "manual", programa P66, desde los 550 pies. Hasta el esperado contacto, tras el que llegan las palabras de Buzz Aldrin
Engine stop. ACA out of detent.
Houston, Tranquility Base here. The Eagle has landed
En el control de la misión el respiro y la alegría no retrasaron la febril actividad para saber la causa de la alarma, pues el módulo lunar debía despegar en pocas horas. Los ingenieros del IL fueron a sus simuladores a intentar reproducir la alarma, y uno de ellos llegó corriendo al laboratorio desde casa, para indicar que había visto ese problema en una simulación causado por el radar de acoplamiento (rendezvous) activado en AUTO al aterrizar. Enseguida se consultó la telemetría, y se confirmó que ese radar estaba activado, en modo SLEW , aunque era innecesario para alunizar. Antes de despegar se indicó al módulo lunar pasar ese radar a modo LGC. El problema se solucionó y la alarma no volvió a aparecer.
Tanto en modo AUTO como en SLEW el radar enviaba sus datos al ordenador para presentarlos en la "pantalla" de la cabina. Resultó que el radar de acoplamiento y el ordenador tenián distintas fuentes de alimentación alterna, de igual frecuencia, pero que cayeron en un ángulo de fase especialmente desafortunado que desincronizó radar y ordenador, causando que los contadores del radar variasen constantemente debido al ruido eléctrico aleatorio, enviando el máximo flujo de datos al ordenador, que se veía obligado a incrementar o decrementar sus contadores para seguir los ángulos del radar, empleando cerca del 15% de su tiempo de proceso.
En tierra se habían hecho pruebas, pero conectando ambos sistemas a la misma fuente de alimentación, que evitaba ese problema.
Como se ve, el peligro se agazapa en los recovecos más inesperados. Y ya tiene guasa que lo que pudo haber abortado el alunizaje fuese un elemento que no jugaba entonces ningún papel y era usado sólo para el acoplamiento del módulo lunar con el de mando, tras despegar aquel de la Luna.
Pero al menos la robustez del diseño del ordenador salvó la situación. Además de tener un margen para encajar el 15% extra, el "ejecutivo asíncrono" diseñado por los ingenieros descartó, ante la sobrecarga, las tareas de baja prioridad, manteniendo las esenciales. Además se usó una "protección de reinicio", un requisito impuesto al equipo de software en 1968, que permitía reiniciar el sistema de forma prácticamente inmediata, nada que ver con los inicios y reinicios que sufrimos en los ordenadores normales hoy en día. Ese reinicio descartaba trabajos incompletos y de baja prioridad y seguía como si nada donde lo había dejado con el resto.
Y otro detalle explicado es que se habían tenido en cuenta reacciones a eventos improbables, y desarrollado errores de ordenador que probablemente nunca sucedieran, entre ellas una alarma indicando sobrecarga en el ordenador del módulo lunar. En una simulación pocos meses antes del despegue del Apolo 11 un controlador abortó la misión a causa de una alarma de programa, aunque el aterrizaje podría haberse completado, un error que preocupó mortalmente a todos, pues un aborto indebido de la misión era casi tan malo como no realizar uno necesario. Tras eso se pidió determinar para cada alarma qué podía pasar y qué se podía hacer. Uno de los ingenieros se hizo una chuleta que dejó en su consola de control. En esa chuleta aparecen los errores 1201 y 1202, y que no son causa de abortar. Cuando un controlador de vuelo pidió ayuda a su equipo de soporte tras la primera alarma 1202, ese ingeniero contestó "We´re go on that alarm". Para que luego hablen mal de las chuletas. Pero esa información no la conocía por ejemplo alguien que debería haber sido informado, el piloto Buzz Aldrin.
Al final, la causa del problema con las alarmas no era un error del ordenador o del software, sino un error de comunicación y en parte de ingeniería de sistemas. En proyectos grandes ( y no tan grandes) el mayor problema acaba siendo que la información que sabe A y puede evitar errores a B, no llega a este. Y la causa del éxito a pesar de todo reside también en mucha buena ingeniería, con amplios margenes, minuciosidad, pruebas, simulaciones, y llegar a explicar cualquier fallo que se produzca.
Sin embargo, en una pauta común y repetida, lo que trascendió a la prensa fué que el culpable era el ordenador. Al controlador que decidió seguir a pesar de la alarma se le recompensó por su "decision to proceed with the lunar landing when computer failed"
Aunque siempre se ha ponderado la actuación de los astronautas, y en todas las misiones Apolo que alunizaron el comandante hizo la parte final en modo "manual", incluso entonces las acciones manuales pasaban por el ordenador. Si de verdad hubiese fallado el ordenador, todavía ahora no haría 40 años de la llegada a la luna.
