O Código que Nos Levou à Lua: A Engenharia de Software do Apollo 11

Em 20 de julho de 1969, dois homens estavam presos em uma lata de alumínio ultraleve, descendo em direção a um mundo alienígena a milhares de quilômetros por hora. Eles não estavam pilotando sozinhos. Entre eles e a morte certa nas rochas lunares, havia uma caixa dourada de 32 kg, zumbindo silenciosamente.

O Apollo Guidance Computer (AGC).

Hoje, é comum desprezar a tecnologia da época dizendo: "Seu micro-ondas tem mais poder de processamento que a Apollo 11". Embora tecnicamente verdade, essa comparação é injusta. Seu micro-ondas não precisa calcular trajetórias orbitais em tempo real, lidar com falhas de hardware no vácuo e reiniciar em menos de um segundo sem matar o usuário.

O AGC não foi apenas um computador. Foi o primeiro computador embarcado digital da história. Foi a máquina que forçou a invenção da Engenharia de Software como disciplina.

Mergulhar sob o chassi do AGC é entender como bits feitos de fio de cobre e uma linguagem Assembly exótica pavimentaram o caminho para a computação moderna. Vamos dissecar a engenharia que transformou segundos de terror no erro 1202 no maior triunfo da história do software.

Parte 1: O Hardware Impossível

Para entender o software, precisamos respeitar o hardware. Nos anos 60, computadores ocupavam salas inteiras. A NASA precisava de algo que coubesse no topo do cone do Módulo de Comando e no Módulo Lunar (LEM), consumisse pouca energia e fosse indestrutível.

O MIT Instrumentation Lab, liderado por Doc Draper, aceitou o desafio.

Especificações Técnicas (Block II AGC)

• Clock: 1.024 MHz (Na verdade, 2.048 MHz divididos por 2 para gerar 4 fases de pulso).
• RAM ("Erasable Memory"): 2048 palavras (palavras de 16 bits). Isso equivale a 4 KB de RAM.
• ROM ("Fixed Memory"): 36.864 palavras. Isso equivale a 72 KB de espaço de armazenamento (seu HD).
• Palavra (Word Size): 16 bits (14 bits de dados + 1 bit de sinal + 1 bit de paridade).
• Consumo: 55 Watts (menos que uma lâmpada antiga, operando a 28 Volts DC).
• Peso: 32 kg (70 lbs).
• Interface: DSKY (Display and Keyboard).

A Memória Tecida à Mão (Core Rope Memory)

Esta é a parte mais fascinante e "steampunk" da missão. Não existiam chips de memória Flash ou EEPROM confiáveis. A memória ROM, onde o software vivia, era física.

Era chamada de Core Rope Memory. Consistia em milhares de anéis de ferrite (núcleos magnéticos). Fios de cobre eram passados através ou ao redor desses anéis.

• Se o fio passasse por dentro do anel: Bit 1.
• Se o fio passasse por fora do anel: Bit 0.

Essa memória era tecida à mão por operárias têxteis nas fábricas da Raytheon em Waltham, Massachusetts. Muitas delas eram senhoras aposentadas da indústria têxtil, o que rendeu à memória o apelido carinhoso de LOL Memory (Little Old Lady Memory).

A Vantagem: Era a memória de maior densidade do mundo na época (2.5 megabits por pé cúbico) e era, por design, indestrutível. Uma tempestade solar, radiação cósmica ou a vibração violenta do foguete Saturn V não podiam "desprogramar" um software que era fisicamente amarrado no lugar. A Desvantagem: Se houvesse um bug no código, você não podia fazer um "patch" ou download. Você tinha que fabricar o computador de novo. O código tinha que estar certo na primeira vez.

Parte 2: A Interface DSKY (Verb-Noun)

Como os astronautas "conversavam" com o computador? Não havia mouse, janelas ou teclado QWERTY. Havia o DSKY (Display and Keyboard).

O DSKY usava uma interface linguística brilhante baseada em Verbos e Substantivos (Verb-Noun).

• Verb: O que você quer fazer? (Ex: Exibir, Monitorar, Mudar, Calcular).
• Noun: Com o quê? (Ex: Tempo, Velocidade, Ângulo, Estrela).

O astronauta digitava códigos numéricos de dois dígitos.

• Verb 16 (Monitorar Decimal)
• Noun 65 (Tempo Amostrado do Computador)
• Enter

Outros exemplos clássicos:

• V37: Change Program (Mudar o programa principal em execução).
• V06 N62: Mostrar velocidade inercial, velocidade vertical e altitude.

O DSKY então mostrava os valores nos displays eletroluminescentes (EL) verdes de 7 segmentos. Essa interface treinou os astronautas a pensar em termos de ação -> objeto, um paradigma que influenciou interfaces de linha de comando futuras.

Parte 3: O Erro 1202 (Executive Overflow)

O momento mais tenso da história da exploração espacial humana não foi causado por alienígenas, mas por um problema de agendamento de tarefas.

Cenário: O módulo Eagle está a 10.000 pés da Lua. O combustível está acabando (menos de 60 segundos). Neil Armstrong está focado em encontrar um local plano para pousar, desviando da cratera West. De repente, uma luz amarela de "Master Alarm" acende e um tom agudo soa no fone de ouvido. O DSKY pisca: 1202.

Neil (calmo, mas com urgência na voz): "Give us a reading on the 1202 Program Alarm." Houston (Charlie Duke): "Roger, 1202." (Silêncio tenso. Ninguém sabia de cabeça o que era 1202).

O Diagnóstico em Tempo Real

Em Houston, o jovem Jack Garman (24 anos), engenheiro de suporte de software, olhou sua "cola" de códigos de erro debaixo do vidro da mesa.

• 1202: Executive Overflow - No Core Sets.

O Problema Técnico: O computador estava sobrecarregado. O AGC tinha um sistema operacional multitarefa cooperativo. Ele tinha uma lista fixa de "Core Sets" (espaços na RAM para tarefas). Havia apenas 7 ou 8 slots. Devido a um erro de design no hardware do Radar de Encontro (Rendezvous Radar) - que deveria estar em standby -, o radar estava inundando o processador com 12.800 interrupções por segundo, roubando cerca de 15% do tempo de CPU com ciclos de "Cycle Stealing".

O computador tentava calcular a navegação de pouso (P63/P64), ler o radar de pouso, ler o painel e agora processar o ruído do radar de encontro. A fila de tarefas encheu. O computador não tinha onde colocar a próxima tarefa crítica.

A Genialidade da Recuperação

Em um computador moderno, isso daria Tela Azul da Morte (BSOD) ou Kernel Panic. O sistema travaria. Na Lua, isso significaria morte, pois os propulsores de atitude parariam de corrigir a orientação da nave.

Mas o software do MIT, supervisionado por Margaret Hamilton, tinha uma arquitetura de Tolerância a Falhas.

Quando o Overflow acontecia:

1. O "Executivo" (Kernel) percebia que não havia slots.
2. Ele acionava um Restart de Software (chamado BAILOUT).
3. Ele jogava fora todas as tarefas de baixa prioridade (atualizar o display DSKY, ler botões).
4. Ele mantinha as tarefas de alta prioridade (controlar o motor, manter a estabilidade, atualizar o vetor de estado).
5. Ele reiniciava do zero em milissegundos.

O piscar "1202" era o computador dizendo: "Estou reiniciando para limpar a memória, o display vai apagar por um segundo, mas não se preocupem, o motor continua ligado e eu ainda sei onde estamos."

Steve Bales (o oficial de orientação GUIDO em Houston), confiando na análise rápida de Garman, deu o famoso grito: "GO!". Eles confiaram que o software conseguiria se limpar rápido o suficiente. E conseguiu. O computador reiniciou várias vezes durante a descida, mas nunca parou de pilotar a nave.

Parte 4: A Engenharia de Software (Margaret Hamilton)

Não podemos falar do AGC sem falar de Margaret Hamilton. Nos anos 60, "Software" não era uma disciplina respeitada. Era visto como "algo que as secretárias fazem depois que os engenheiros de verdade constroem o hardware".

Hamilton lutou para legitimar a área. Ela cunhou o termo "Engenharia de Software" para dizer: "Nós também somos engenheiros. Nós construímos sistemas que não podem falhar, assim como as pontes e os foguetes."

Ela introduziu rigor nos testes. Antes de tecer a memória, o código passava por simuladores híbridos (computadores digitais mainframes conectados a maquetes físicas do motor e do cockpit). Muitas noites foram passadas debugando código impresso em papel contínuo que se estendia pelos corredores do MIT.

Sua filosofia de "Desenvolvimento Assíncrono" e "Priorização de Tarefas" salvou a missão. Se o AGC tivesse uma arquitetura de loop simples (executar A, depois B, depois C), o ruído do radar teria atrasado o loop inteiro e o módulo teria perdido controle. Com a arquitetura assíncrona, o ruído apenas matou tarefas não essenciais.

Conclusão: Um Legado Eterno

O AGC teve uma vida útil pós-Apollo. Uma versão dele foi usada no Skylab e outra foi adaptada para ser o primeiro sistema Fly-By-Wire digital em um caça F-8 Crusader, pavimentando o caminho para todos os aviões modernos (Airbus/Boeing) que são controlados por software.

Quando olhamos para o código do AGC hoje, vemos as raízes de tudo que usamos.

• O tratamento de exceções (Try/Catch) nasceu ali, no Restart.
• A multitarefa preemptiva (como no Windows/Linux) tem raízes na priorização do Executivo.
• A interface de usuário (UX) sob estresse foi definida pelo DSKY.

Neil Armstrong foi o primeiro humano a pisar na Lua, mas foi o código de Hamilton, Laning e da equipe do MIT que garantiu que ele tivesse uma Lua onde pisar, e não uma cratera onde colidir.

Apêndice Técnico A: Glossário do AGC

Para entender o software da Apollo, você precisa falar a língua do MIT de 1969.

Apêndice Técnico B: Excertos de Código (Luminary 1A)

O código original está disponível no GitHub. Aqui estão trechos comentados e traduzidos para entender a lógica.

A Rotina "Burn Baby Burn" (Master Ignition)

(Nota: Este comentário famoso apareceu na versão Luminary 99 para Apollo 14, mas a lógica era similar na 11).

# Routine to handle the master ignition logic for the descent engine
# Arquivo: BURN_BABY_BURN--MASTER_IGNITION_ROUTINE.agc

MASTER_IGNITION_ROUTINE:
    TC     BANKCALL      # Chamada de função (Transfer Control)
    CADR   IMU_CHECK     # Verificar se a Unidade Inercial (IMU) está alinhada

    TC     BANKCALL      # Verificar atitude (orientação da nave)
    CADR   ATTITUDE_CHK  

    # ... lógica de verificação de segurança ...

    TC     PHASCHNG      # Mudança de Fase do Programa
    OCT    04024         # Código da nova fase

    # IGNIÇÃO!
    TC     BITSET        # Setar bit (ligar interruptor digital)
    EXT    11,13         # Canal 11, Bit 13 (Engine On)

    # O comentário famoso:
    # "BURN BABY BURN" -- Referencia ao DJ Magnificent Montague

Instruções Exóticas do AGC

O set de instruções era otimizado para matemática vetorial de 15 bits.

• CCS (Count, Compare, and Skip): A instrução "Canivete Suíço". Ela verifica o valor de uma variável e pula para 4 lugares diferentes dependendo do resultado:
  • Se > 0: Pula para L+1
  • Se +0: Pula para L+2
  • Se < 0: Pula para L+3
  • Se -0: Pula para L+4
• TS (Transfer to Storage): Salva o valor do acumulador na memória (Store).
• DXCH (Double Exchange): Troca o conteúdo de dois registradores de 32 bits (Double precision) com a memória. Essencial para cálculos precisos de órbita.

Apêndice Técnico C: Cronologia do Pouso (20 de Julho de 1969)

A batalha entre o software e a realidade, segundo a segundo. (Horários em Ground Elapsed Time - GET).

• 102:33:05 (GET): Neil Armstrong e Buzz Aldrin iniciam a descida motorizada (PDI). O programa P63 (Braking Phase) começa a rodar. O motor acende a 10% de potência, depois sobe para 100%.
• 102:36:55: O Módulo Lunar gira de "barriga para cima" para "barriga para frente" para que o radar de pouso veja o chão.
• 102:38:22: Primeiro Alarme 1202. Neil Armstrong reporta. O coração dispara. Em Houston, Jack Garman identifica o erro. Steve Bales diz "GO".
• 102:39:07: O computador muda automaticamente para P64 (Approach Phase). A nave começa a inclinar para ficar vertical.
• 102:41:32: Neil vê que o computador está levando eles para uma cratera cheia de pedras (West Crater). Ele muda para o modo Semi-Automático (P66) para voar manualmente como um helicóptero.
• 102:42:05: Mais alarmes 1201 e 1202. O radar continua atrapalhando. Aldrin monitora o DSKY enquanto Armstrong olha pela janela.
• 102:42:42: "60 seconds". Aviso de combustível baixo.
• 102:43:08: "30 seconds". A tensão é máxima. Se o combustível acabar, a missão é abortada automaticamente (o estágio de subida dispara e separa a nave).
• 102:45:40: "Contact Light". As sondas nas patas tocam o solo.
• 102:45:41: Armstrong desliga o motor: "Shutdown". O computador registra o fim do voo.
• 102:45:58: Armstrong fala para o mundo: "Houston, Tranquility Base here. The Eagle has landed."

Perguntas Frequentes (FAQ)

Q: Qual linguagem o AGC usava? R: AGC Assembly Language. Não existia C, Python ou Java. O código era escrito em mnemônicos (TC, CA, AD) e montado (assembled) pelo assembler YUL rodando em mainframes IBM 360 na Terra.

Q: É verdade que o código foi escrito por uma mulher? R: Margaret Hamilton era a Diretora da Divisão de Engenharia de Software do MIT Instrumentation Lab. Ela liderou a equipe, definiu a arquitetura e escreveu partes críticas do código do sistema (Executivo), mas o código completo foi um esforço de uma equipe de dezenas de engenheiros brilhantes como Don Eyles (que escreveu o código de pouso) e Hal Laning. A foto famosa dela ao lado de uma pilha de código mostra a listagem impressa de todo o software Apollo.

Q: O AGC era menos poderoso que uma calculadora moderna? R: Em termos de clock e RAM, sim. Uma calculadora científica de R$ 50,00 hoje é muito mais rápida. Mas o AGC tinha I/O (Entrada e Saída) superior. Ele podia controlar giroscópios, ler radares e disparar motores com latência zero. Uma calculadora não pilota naves; o AGC pilotava. Ele era um sistema de Controle em Tempo Real, não uma calculadora de escritório.

Q: Por que usaram "Verb" e "Noun" em vez de menus? R: Os displays gráficos (CRTs) eram pesados demais e consumiam muita energia. Displays de 7 segmentos eram leves. A equipe precisava de uma forma de representar 300 comandos complexos usando apenas números. A gramática "Ação + Objeto" foi a solução mais compacta.

Q: O código do erro 1202 foi corrigido na Apollo 12? R: O bug de hardware do radar (a interferência) foi consertado com uma mudança nos procedimentos (não ligar o radar de encontro na hora errada). O software foi robustecido nas missões seguintes, mas a arquitetura de restart que salvou a Apollo 11 permaneceu, pois provou ser a decisão de design mais segura possível.

Q: Como eles atualizavam o software se a memória era de corda? R: Eles não podiam atualizar o software no espaço. Se houvesse um bug crítico, a missão abortava. A única coisa mutável era a memória RAM (Erasable), onde eles podiam subir pequenos "patches" via rádio para contornar problemas, mas o núcleo do sistema era imutável por meses antes do lançamento.

Referências Bibliográficas e Leitura Adicional

1. Don Eyles. "Sunburst and Luminary: An Apollo Memoir". O relato em primeira pessoa do homem que escreveu o código do P63/P64.
2. Mindell, David A. "Digital Apollo: Human and Machine in Spaceflight". Uma análise acadêmica sobre a simbiose homem-máquina.
3. Frank O'Brien. "The Apollo Guidance Computer: Architecture and Operation". O livro técnico definitivo.
4. Google Code Archive. O código fonte completo digitalizado (Virtual AGC project).
5. NASA Mission Reports. Transcrições de áudio da missão Apollo 11.

Este artigo foi expandido em Dezembro de 2025 para incluir detalhes técnicos aprofundados sobre a arquitetura do AGC.