Margaret Hamilton e o nascimento da engenharia de software crítica
Quando a missão Apollo foi concebida, ainda existia uma separação cultural muito forte entre aquilo que era considerado “engenharia de verdade” e aquilo que era visto como programação. O hardware tinha prestígio evidente: circuitos, módulos eletrônicos, sensores, atuadores, sistemas redundantes e estruturas mecânicas eram elementos visíveis, mensuráveis e tradicionalmente associados à engenharia. O software, por outro lado, ainda lutava para ser reconhecido como uma disciplina técnica com o mesmo grau de rigor.
Esse cenário começou a mudar de forma decisiva no Projeto Apollo. O computador de bordo não poderia ser tratado como um acessório secundário, porque ele participava diretamente das decisões de navegação, orientação e controle da espaçonave. O software não estava apenas “ajudando” a missão. Ele fazia parte da missão.
No centro dessa transformação estava Margaret Hamilton, cientista da computação que liderou a Divisão de Engenharia de Software do MIT Instrumentation Laboratory, laboratório contratado pela NASA para desenvolver o sistema de orientação do programa Apollo. A NASA registra Hamilton como uma das figuras centrais no desenvolvimento do software de voo do Apollo, especialmente por sua atuação na liderança da equipe responsável pelo software embarcado que operava nos computadores da nave. (NASA Science)
Para entender a importância desse trabalho, precisamos lembrar o ambiente técnico da época. O Apollo Guidance Computer operava com memória extremamente limitada, era programado em uma linguagem Assembly própria e precisava interagir com sensores, atuadores, sistemas de navegação, comandos dos astronautas e rotinas de controle em tempo real. A arquitetura do AGC incluía a interface DSKY, a unidade de medição inercial, controles manuais, radar de pouso, radar de acoplamento, telemetria, comando de motor e sistema de controle de reação. (Wikipedia)
Em sistemas embarcados modernos, estamos acostumados a falar de RTOS, ou Real-Time Operating System, isto é, sistema operacional de tempo real. Um RTOS não serve apenas para “rodar várias tarefas”; ele oferece mecanismos para organizar concorrência, priorizar atividades, tratar eventos e permitir que funções críticas sejam executadas dentro de limites temporais aceitáveis. Essa necessidade não é nova. Sistemas embarcados frequentemente precisam cumprir restrições severas de memória, energia, desempenho, confiabilidade e previsibilidade, especialmente quando interagem com o mundo físico.
O AGC possuía algo que podemos considerar um ancestral conceitual desses sistemas: um pequeno sistema executivo em tempo real. Segundo a descrição técnica do AGC, esse software incluía o Exec, responsável por escalonar trabalhos cooperativos, e a Waitlist, usada para tarefas associadas a temporização e interrupções. Em termos modernos, podemos enxergar essa estrutura como uma forma inicial de kernel embarcado orientado a prioridades, ainda que muito diferente dos RTOS comerciais que usamos hoje. (Wikipedia)
A questão central era simples, mas profunda: o computador não podia executar tudo ao mesmo tempo. Ele precisava decidir o que era mais importante. Essa é uma das ideias mais importantes em sistemas de tempo real. Em um sistema comum, uma sobrecarga pode significar lentidão. Em um sistema crítico, sobrecarga pode significar perda de controle, perda de estabilidade ou falha da missão. Por isso, não basta perguntar se o software funciona. É preciso perguntar como ele se comporta quando não consegue fazer tudo.
Esse ponto separa programação comum de engenharia de software crítica. Margaret Hamilton e sua equipe não projetaram o software apenas para condições ideais. Elas consideraram falhas, entradas inesperadas, erros humanos, reinicializações, sobrecarga de processamento e recuperação em tempo real. A própria NASA destaca que Hamilton trabalhou com conceitos de detecção de erros e recuperação, elementos fundamentais para que o sistema pudesse responder a condições não previstas durante a missão. (NASA Science)
Durante o pouso da Apollo 11, essa filosofia deixou de ser teoria. O computador apresentou os alarmes 1202 e 1201, relacionados a estouro de capacidade do executivo. O problema estava associado a uma carga extra provocada pelo radar de acoplamento, que gerava ciclos adicionais de processamento em um momento crítico da descida. Mesmo assim, o AGC não simplesmente travou. Ele descartou tarefas de menor prioridade e preservou as tarefas essenciais de orientação e controle. (NASA)
Essa decisão arquitetural é uma aula de engenharia. O sistema não tentou fingir que estava tudo bem. Ele sinalizou o problema, reiniciou de forma controlada quando necessário, preservou o essencial e continuou executando as funções críticas. Em linguagem moderna, diríamos que ele aplicou uma forma de degradação controlada, mantendo o núcleo da missão ativo mesmo sob sobrecarga.
A história frequentemente citada envolvendo a filha de Margaret Hamilton também reforça essa mentalidade. Durante testes em simulador, uma entrada inesperada levou o sistema a uma condição problemática. Hamilton percebeu que algo semelhante poderia ocorrer em uma missão real e defendeu a necessidade de proteções adicionais. A resposta inicial teria sido a de que um astronauta jamais cometeria aquele tipo de erro. Mas esse é justamente o tipo de frase que a boa engenharia deve questionar.
Um sistema crítico não pode depender da ideia de que “o usuário nunca fará isso”. Em firmware, essa lição continua atual. Um operador pode apertar botões em sequência inesperada. Um sensor pode retornar valor fora da faixa. Uma comunicação pode chegar truncada. Uma interrupção pode ocorrer em um instante inconveniente. Uma fonte de alimentação pode oscilar durante uma gravação. O papel da engenharia não é confiar que essas situações nunca acontecerão, mas projetar o sistema para lidar com elas da melhor forma possível.
Foi nesse contexto que a expressão engenharia de software ganhou força simbólica. Margaret Hamilton ajudou a popularizar o termo ao defender que o desenvolvimento de software deveria receber o mesmo tratamento rigoroso das demais engenharias. Isso não era apenas uma disputa de prestígio profissional. Era uma necessidade prática. Quando o software decide, calcula, controla e recupera sistemas em tempo real, ele se torna infraestrutura crítica.
Para quem trabalha hoje com microcontroladores, essa história continua extremamente relevante. Um projeto com FreeRTOS, Zephyr, bare metal, FPGA ou Linux embarcado pode não estar levando astronautas à Lua, mas muitas vezes controla motores, fontes chaveadas, equipamentos médicos, sensores industriais, redes de comunicação, drones, robôs, inversores, sistemas de segurança ou dispositivos conectados ao mundo físico. Nesses contextos, software mal projetado deixa de ser apenas um bug: ele pode se tornar uma falha de engenharia.
A grande lição deixada por Margaret Hamilton e pela equipe do Apollo não é apenas histórica. Ela nos lembra que escrever código é assumir responsabilidade sobre comportamento. Um sistema bem projetado não é aquele que funciona apenas na demonstração, no laboratório ou no cenário ideal. É aquele que preserva suas funções essenciais quando o ambiente se torna confuso, quando a carga aumenta, quando a entrada é imperfeita e quando o inesperado finalmente acontece.
Na próxima seção, vamos observar uma das partes mais impressionantes do Apollo Guidance Computer: a core rope memory, uma forma de memória permanente em que o software não era simplesmente gravado, mas literalmente tecido em hardware físico.
