A poucos minutos do primeiro pouso humano na Lua, em 20 de julho de 1969, o computador do módulo lunar Eagle começou a emitir alarmes inesperados. Primeiro apareceu o 1202. Depois, outro 1202. Mais perto da superfície, veio o 1201 e novos 1202. Foram cinco ocorrências durante a descida. Neil Armstrong e Buzz Aldrin não tinham uma resposta pronta para aqueles códigos e pediram uma avaliação a Houston.
A resposta curta para o que aconteceu é esta: o Apollo Guidance Computer estava sobrecarregado, mas não havia deixado de funcionar. Seu software detectou que faltavam recursos para acomodar todas as tarefas, iniciou procedimentos de recuperação e retomou o trabalho essencial. Em Houston, controladores acompanharam a trajetória, interpretaram os alarmes e concluíram que a descida ainda podia continuar.
Na prática, três camadas trabalharam juntas:
- o computador recebeu uma carga de processamento maior do que a prevista;
- o software detectou o excesso, recuperou-se e preservou as funções prioritárias;
- a equipe de Houston verificou que o sistema continuava guiando a Eagle corretamente antes de autorizar a continuação do pouso.
É justamente essa combinação que torna os alarmes 1201 e 1202 mais interessantes do que a versão simplificada de que “o computador quase travou”.
O que significavam os alarmes 1201 e 1202
Os dois códigos pertenciam à mesma família de problemas: um Executive overflow, ou seja, uma situação em que o sistema executivo do computador não conseguia reservar os recursos necessários para iniciar mais uma tarefa.
O software da Apollo trabalhava com áreas temporárias de memória associadas aos trabalhos em execução. Entre elas estavam os chamados core sets e as áreas VAC, de vector accumulator. Quando uma nova tarefa precisava ser iniciada, o sistema procurava espaço disponível para ela.
Os códigos distinguiam qual recurso havia se esgotado:
- 1201: não havia uma área VAC disponível;
- 1202: não havia um core set disponível para a nova tarefa.
O próprio código-fonte preservado do programa Luminary mostra o 1201 associado à falta de áreas VAC e o 1202 à falta de core sets. Isso é importante porque os números não descreviam uma pane geral do computador. Eram diagnósticos específicos produzidos pelo sistema executivo ao reconhecer que sua fila de trabalho havia ultrapassado uma condição prevista.
Por que o computador ficou sobrecarregado
Uma explicação comum diz que o radar de rendezvous estava ligado e mandava dados desnecessários ao computador durante o pouso. A ideia básica está correta, mas omite um detalhe importante: ligar esse radar não foi simplesmente um erro de Armstrong ou Aldrin.
No debriefing técnico da missão, os astronautas explicaram que o radar de rendezvous estava ligado conforme uma configuração que vinha sendo usada nos procedimentos e simulações. Mantê-lo disponível fazia sentido porque o equipamento seria necessário caso a descida fosse abortada e o módulo lunar tivesse de reencontrar o módulo de comando Columbia.
A análise técnica posterior de Don Eyles, um dos engenheiros que programaram o software de pouso do módulo lunar no MIT Instrumentation Laboratory, foi mais específica. Segundo ele, havia um problema não corrigido na interface com o radar de rendezvous. Determinadas condições elétricas faziam o sistema gerar atividade desnecessária para o computador, fenômeno conhecido como cycle stealing. Eyles calculou que isso consumia aproximadamente 13% do tempo de processamento disponível durante a descida.
Treze por cento parece pouco até se considerar que o programa de pouso já utilizava grande parte da capacidade disponível. O computador continuava recebendo suas tarefas normais de navegação, orientação, controle e exibição enquanto o sistema do radar consumia ciclos adicionais. Tarefas começaram a se acumular mais rapidamente do que podiam ser concluídas.
Assim surgiram os alarmes.
O detalhe muda a interpretação do episódio. Não se tratava simplesmente de “dados demais” em sentido genérico nem de um astronauta pressionando uma chave errada. Era uma interação entre hardware, interface elétrica, procedimentos operacionais e uma máquina que já funcionava perto do limite planejado.
O que o software fez quando faltou capacidade
É aqui que a história deixa de ser apenas sobre limitações do computador e passa a ser sobre arquitetura de software.
O Apollo Guidance Computer utilizava um sistema executivo orientado por prioridades. Nem todo trabalho tinha a mesma importância. Manter orientação, navegação e controle da espaçonave tinha prioridade sobre tarefas que podiam ser adiadas ou reiniciadas sem colocar imediatamente o veículo em risco.
Quando o executivo encontrou a condição que produzia um 1201 ou 1202, ele não ficou simplesmente congelado esperando espaço. O software acionou seu mecanismo de recuperação, reinicializou a execução e retomou programas selecionados a partir de pontos protegidos para reinício. As tarefas críticas voltavam; trabalhos que haviam contribuído para encher as filas não precisavam ser todos reconstruídos da mesma forma.
É mais preciso dizer que houve reinícios controlados do software do que afirmar que o computador “travou e voltou”.
Também é impreciso imaginar que a máquina tomou uma decisão abstrata de “salvar o pouso”. As prioridades e os mecanismos de recuperação haviam sido definidos e testados pelos engenheiros. Durante a missão, o computador apenas executou essa arquitetura: detectou a falta de recursos, sinalizou o problema e recuperou a execução de acordo com regras já incorporadas ao sistema.
O resultado foi uma forma precoce e sofisticada de degradação controlada. Diante de carga excessiva, o sistema não precisava tratar cada função como igualmente indispensável.
Onde Margaret Hamilton entra nessa história
A contribuição de Margaret Hamilton precisa ser explicada sem transformar um esforço coletivo em obra de uma única pessoa.
Em 1969, o desenvolvimento do software de voo da Apollo era realizado no MIT Instrumentation Laboratory, instituição que posteriormente passou a se chamar Charles Stark Draper Laboratory. Hamilton liderava a Software Engineering Division do laboratório e a equipe responsável pelo software embarcado dos módulos de comando e lunar.
A NASA posteriormente destacou entre suas contribuições e as de sua equipe conceitos relacionados a software assíncrono, escalonamento por prioridades, testes de ponta a ponta e mecanismos capazes de lidar com situações inesperadas durante a missão.
Isso não significa que Hamilton tenha escrito pessoalmente cada rotina associada aos alarmes 1201 e 1202. O software da Apollo resultou do trabalho de muitos engenheiros. Don Eyles escreveu partes fundamentais do programa de descida; Peter Adler trabalhou nos programas de voo do módulo lunar; outros especialistas desenvolveram o executivo, rotinas de reinício, navegação, orientação e interfaces.
O papel de Hamilton é mais corretamente entendido como liderança de uma organização de software que precisava entregar um sistema embarcado capaz de operar em tempo real, com recursos extremamente limitados e sem possibilidade de manutenção física durante uma missão lunar.
Os alarmes da Apollo 11 acabaram oferecendo uma demonstração concreta do motivo pelo qual mecanismos de detecção e recuperação eram tão importantes.
O que Houston precisou decidir em poucos segundos
Um bom mecanismo de recuperação não bastava. Armstrong e Aldrin ainda precisavam saber se o alarme permitia continuar o pouso.
Depois do primeiro 1202, Armstrong pediu a Houston uma interpretação. Poucos segundos depois, o CAPCOM Charlie Duke transmitiu a autorização para continuar. O áudio e a transcrição da missão registram a rápida passagem entre o pedido da tripulação e a resposta de que o voo estava autorizado a prosseguir naquele alarme.
Por trás da comunicação curta havia uma cadeia de decisão.
Jack Garman, engenheiro da NASA que trabalhava dando suporte à equipe de orientação, havia preparado uma lista dos alarmes possíveis do computador. Quando Steve Bales, responsável por orientação na sala de controle, recebeu o 1202, Garman reconheceu a condição como uma sobrecarga temporária que, naquele contexto, não exigia automaticamente um aborto.
Bales combinou essa informação com aquilo que os controladores observavam na telemetria: a trajetória continuava coerente e o sistema de orientação permanecia funcionando. A recomendação seguiu pela estrutura de controle de voo, e Duke transmitiu o “go” à Eagle.
Quando surgiu o 1201, a reação foi ainda mais rápida porque Houston já sabia que se tratava do mesmo tipo geral de sobrecarga. A transcrição registra a confirmação quase imediata de que a tripulação podia continuar.
Isso ajuda a corrigir outra simplificação: Houston não ignorou o alarme porque confiava cegamente no computador. Os controladores aceitaram a continuação porque entendiam o significado da condição e, ao mesmo tempo, observavam que os parâmetros essenciais do pouso continuavam normais.
Buzz Aldrin também reduziu a carga durante a descida
A tripulação não ficou apenas esperando decisões do solo.
Depois de um dos 1202, Aldrin percebeu que os alarmes pareciam coincidir com a solicitação de uma determinada tela do computador, o comando Verb 16 Noun 68. Essa exibição apresentava informações úteis para a descida, mas acrescentava mais uma pequena demanda a um sistema que já operava sobrecarregado.
Em vez de insistir na consulta, parte do acompanhamento passou a ser feita pelo solo. Houston podia fornecer informações que a tripulação precisava sem exigir a mesma interação com aquela exibição durante o momento crítico.
Não foi essa mudança que eliminou a causa fundamental do problema, que continuava relacionada à interface do radar, mas ela reduziu uma demanda evitável enquanto os alarmes eram administrados.
Armstrong precisava lidar com o computador e com o terreno ao mesmo tempo
Os alarmes tiveram uma consequência operacional que vai além da eletrônica: consumiram atenção da tripulação.
No debriefing posterior, Armstrong explicou que o período no qual normalmente estaria avaliando mais intensamente o terreno e o ponto de pouso foi parcialmente ocupado pela necessidade de acompanhar os alarmes, confirmar que o veículo permanecia controlável e avaliar se seria necessário abortar.
Quando finalmente pôde dedicar mais atenção ao exterior, Armstrong percebeu que o ponto para o qual o sistema os conduzia ficava próximo de uma área coberta por pedras e por uma grande cratera. Ele então assumiu maior controle sobre a fase final da descida, entrou no programa P66 e conduziu a Eagle além do terreno inadequado antes de pousar.
Essa atuação também se encaixa numa trajetória que começou muito antes da Apollo 11. Armstrong tinha formação em engenharia aeronáutica, trabalhou como pesquisador e piloto de testes da NACA/NASA e participou tanto dos aspectos de pilotagem quanto dos de engenharia de programas como o X-15. A formação técnica de Neil Armstrong ajuda a entender por que ele era capaz de tratar uma máquina experimental não apenas como piloto, mas como parte de um sistema que precisava ser constantemente avaliado. Esse percurso anterior é o tema do artigo relacionado “Neil Armstrong antes da Lua”.
Isso não diminui o papel do computador ou de Houston. Pelo contrário: o pouso funcionou porque responsabilidades diferentes permaneceram conectadas. A máquina executava orientação e controle; Aldrin monitorava instrumentos e computador; Armstrong avaliava o voo e o terreno; Houston enxergava telemetria e reunia especialistas que conheciam o significado dos alarmes.
O problema foi entendido antes de a Eagle deixar a Lua
O trabalho técnico não terminou quando o módulo lunar tocou o solo.
Depois do pouso, equipes da NASA e do MIT investigaram a origem da sobrecarga. O comportamento do radar de rendezvous tornou-se uma das principais pistas. Antes da decolagem da superfície lunar, Houston alterou os procedimentos para evitar que o mesmo tipo de carga afetasse o computador durante a subida. Entre as instruções transmitidas à tripulação estava manter os disjuntores do radar de rendezvous abertos em momentos nos quais seu funcionamento não era necessário.
A resposta, portanto, ocorreu em dois tempos. Durante o pouso, a prioridade era saber se a Eagle podia continuar com segurança. Depois de pousar, a prioridade mudou para compreender a causa e impedir que ela reaparecesse na decolagem.
O que os alarmes 1201 e 1202 realmente demonstraram
A Apollo 11 não chegou à Lua porque seu computador nunca encontrou um problema. Chegou apesar de um problema porque diferentes camadas do sistema foram capazes de detectá-lo, absorvê-lo e tomar decisões coerentes.
O hardware tinha limites claros. A interface do radar conseguiu consumir uma parcela inesperada do processamento. O software reconheceu que seus recursos de execução haviam se esgotado e acionou a recuperação prevista pelos engenheiros. Houston soube interpretar esses sinais em contexto. Armstrong e Aldrin continuaram avaliando se a nave ainda respondia como deveria.
Por isso, os códigos 1201 e 1202 não são apenas uma curiosidade da história da computação. Eles mostram uma ideia que continua central em sistemas críticos: não basta tentar impedir toda falha; também é preciso projetar o sistema para reconhecer condições anormais, preservar o trabalho indispensável e permitir que pessoas qualificadas decidam o que fazer em seguida.
No pouso da Apollo 11, foi exatamente isso que aconteceu.
