Sistemas críticos: quando o software precisava nascer certo

Eu nasci em 1971, praticamente no eco da última década dos primeiros passos da humanidade no espaço. A missão Apollo 11 havia pousado na Lua em 1969, e o mundo ainda vivia sob o impacto daquela conquista. Para quem nasceu nesse período, é curioso perceber que a computação que hoje carregamos no bolso, atualizamos pela internet e corrigimos com um simples patch, um dia foi parte de uma engenharia quase irreversível, construída para funcionar longe da Terra, sem segunda chance, sem manutenção presencial e sem a tranquilidade de “corrigir depois”.

Quando falamos em sistemas críticos, falamos exatamente desse tipo de ambiente. Um sistema crítico é aquele em que uma falha pode causar perda de vidas, prejuízos enormes, danos ambientais, falhas de missão ou colapso de uma operação essencial. Na exploração espacial, essa definição aparece em sua forma mais extrema. Uma nave em órbita, um módulo lunar descendo em direção à superfície da Lua ou uma sonda viajando por milhões de quilômetros não permite o mesmo tipo de improviso que aceitamos em uma aplicação web, em um aplicativo de celular ou em um sistema administrativo.

Nas primeiras explorações espaciais, o software ainda estava se separando conceitualmente do hardware. Hoje pensamos em software como algo flexível, editável, versionável, distribuído em arquivos, repositórios e pipelines de integração contínua. Mas, naquele contexto, parte do software era literalmente incorporada ao hardware. No caso do Apollo Guidance Computer, o computador de orientação usado nas missões Apollo, grande parte do programa era armazenada em uma memória chamada core rope memory, uma memória somente leitura na qual os bits eram definidos por fios tecidos através ou ao redor de núcleos magnéticos. Em outras palavras, uma parte do código era fisicamente “costurada” no sistema. O AGC possuía memória RAM de núcleo magnético para dados variáveis, mas seu software principal ficava gravado nessa memória fixa, o que tornava a alteração em voo praticamente impossível. (Wikipedia)

Esse contexto muda completamente a forma como pensamos sobre desenvolvimento de software. Quando não existe a possibilidade de atualização posterior, cada decisão passa a carregar um peso diferente. O código deixa de ser algo provisório e passa a ser uma peça final, imutável, parte integrante de um sistema que não admite revisões após o lançamento. O programador, nesse cenário, não está apenas escrevendo instruções para uma máquina. Ele está participando da construção de uma estrutura física, lógica e operacional que será colocada em um ambiente hostil, isolado e sem suporte técnico direto.

Isso explica o nível de disciplina adotado pelas equipes envolvidas. O processo de desenvolvimento era acompanhado por revisões minuciosas, simulações extensivas e uma preocupação constante com cenários extremos. Não se tratava apenas de fazer o sistema funcionar em condições ideais, mas de garantir que ele continuaria operando mesmo diante de situações inesperadas. A própria área de engenharia de software ganhou força nesse período, com nomes como Margaret Hamilton, que liderou a divisão de software de voo embarcado no MIT Instrumentation Laboratory para o programa Apollo e ajudou a consolidar a ideia de tratar software como uma disciplina de engenharia, e não como uma atividade secundária diante do hardware.

Margaret Hamilton é uma cientista da computação, engenheira de software e empresária norte-americana, reconhecida principalmente por sua atuação no Programa Apollo da NASA. Ela liderou a equipe de desenvolvimento do software de voo embarcado do Apollo Guidance Computer, usado nas missões que levaram o ser humano à Lua. Seu trabalho foi essencial para demonstrar que o software deveria ser tratado como uma disciplina de engenharia, com métodos rigorosos de projeto, teste, revisão e tolerância a falhas. Durante a missão Apollo 11, o sistema desenvolvido por sua equipe ajudou o computador a priorizar tarefas críticas durante os alarmes inesperados na descida lunar, contribuindo para o sucesso do pouso. Margaret Hamilton também é frequentemente associada à popularização do termo “engenharia de software” e se tornou uma referência histórica para a computação, os sistemas críticos e o desenvolvimento de software confiável.

É importante lembrar que o ambiente espacial não perdoa descuidos. Há radiação, vibração, variação térmica, limitação extrema de energia, peso e processamento. Os computadores da época eram muito menos potentes do que qualquer dispositivo comum atual. O Apollo Guidance Computer operava com frequência de cerca de 2,048 MHz e tinha poucos milhares de palavras de memória apagável, além da memória fixa onde ficava a maior parte do software. Ainda assim, ele precisava orientar a nave, interpretar sensores, conversar com os astronautas por meio do DSKY, controlar tarefas em tempo real e responder a eventos críticos.

Nessa época, também existiam computadores analógicos em várias aplicações de engenharia, simulação, controle e instrumentação. Diferente dos computadores digitais, que operam com números discretos e instruções lógicas, os computadores analógicos representavam grandezas físicas por sinais contínuos, como tensões e correntes. Eles eram úteis para simular sistemas dinâmicos, equações diferenciais, trajetórias e comportamentos físicos. Essa mentalidade mostra como a computação ainda estava muito próxima da eletrônica pura. Programar, em muitos casos, não era apenas escrever código; era configurar circuitos, ajustar parâmetros, definir conexões e transformar uma equação em comportamento elétrico.

O software, portanto, não era algo separado do hardware. Era parte dele. Em muitos sistemas críticos, essa separação era mais conceitual do que prática. O algoritmo podia aparecer como código em assembly, como memória fisicamente tecida, como circuito lógico, como malha de controle analógica ou como uma combinação de tudo isso. Para quem trabalha hoje com sistemas embarcados, essa história é especialmente importante, porque nos lembra que firmware não é apenas “software pequeno”. Firmware é software que toca o mundo físico. Ele aciona motores, lê sensores, controla energia, interpreta sinais, abre válvulas, estabiliza voo, protege baterias, evita sobrecorrente e toma decisões em tempo real.

Essa mentalidade contrasta fortemente com a forma como muitos sistemas são desenvolvidos hoje. Em ambientes onde a atualização contínua é possível, é comum aceitar imperfeições iniciais com a expectativa de melhoria ao longo do tempo. Aplicações modernas podem ser lançadas em versões beta, receber correções diárias, ativar funcionalidades por feature flags, coletar telemetria e ajustar comportamento após o uso real. Essa flexibilidade é poderosa, mas também pode criar um vício perigoso: a ideia de que sempre haverá tempo para corrigir depois.

No contexto da Apollo, essa abordagem simplesmente não existia. O sistema precisava ser confiável desde o primeiro instante, porque não haveria um segundo. A impossibilidade de manutenção direta impunha uma cultura de desenvolvimento mais severa. Cada rotina precisava ser revisada, cada cenário precisava ser simulado, cada falha precisava ser considerada. O objetivo não era apenas evitar erros, mas construir mecanismos para sobreviver a erros inevitáveis.

Um dos exemplos mais conhecidos dessa filosofia apareceu durante o pouso da Apollo 11. O computador começou a emitir os alarmes 1201 e 1202 durante a descida lunar. Esses alarmes estavam ligados a sobrecarga de execução, mas o sistema foi projetado para priorizar tarefas críticas, descartar ou adiar tarefas menos importantes e continuar mantendo as funções essenciais de navegação e controle. Ou seja, a missão não foi salva porque o computador nunca falhou; ela foi salva porque o sistema foi projetado para falhar de forma controlada, preservando o essencial.

Essa é uma das maiores lições dos sistemas críticos: confiabilidade não significa ausência absoluta de falhas. Significa capacidade de continuar operando, degradar com segurança, preservar prioridades e impedir que um erro local se transforme em colapso total. Em sistemas embarcados modernos, isso aparece em watchdogs, redundância, particionamento, verificação formal, testes automatizados, modos seguros, logs persistentes, bootloaders confiáveis, atualizações atômicas e estratégias de rollback. A diferença é que hoje temos mais recursos, mas nem sempre temos mais disciplina.

O que impressiona não é apenas o fato de que conseguiram, mas como conseguiram. A combinação de engenharia rigorosa, processos bem definidos e um respeito profundo pelas limitações técnicas criou um ambiente onde a qualidade não era negociável. A limitação, nesse caso, não foi apenas um obstáculo; ela foi uma professora. Pouca memória obrigava clareza. Pouco processamento obrigava eficiência. Impossibilidade de atualização obrigava revisão. Ambiente hostil obrigava resiliência. Distância da Terra obrigava autonomia.

Hoje, vivemos o outro extremo. Temos processadores poderosos, internet permanente, computação em nuvem, integração contínua, deploy automatizado, telemetria, inteligência artificial auxiliando programação e bibliotecas prontas para quase tudo. Isso é extraordinário, mas também pode nos tornar menos atentos ao peso real das decisões técnicas. Em muitos projetos, a facilidade de atualizar virou desculpa para lançar cedo demais, testar pouco demais e pensar superficialmente nas consequências de uma falha.

Esse contraste não significa que devemos rejeitar os métodos modernos. Pelo contrário. Atualizações remotas, observabilidade, testes automatizados e entrega contínua são conquistas importantes. O problema está em confundir flexibilidade com descuido. Em sistemas comuns, talvez um erro gere apenas desconforto. Em sistemas críticos, um erro pode derrubar um satélite, comprometer um equipamento médico, parar uma linha industrial, danificar uma rede elétrica ou colocar vidas em risco.

Por isso, a história das primeiras explorações espaciais ainda tem muito a ensinar aos desenvolvedores atuais. Ela nos lembra que o software não é apenas texto. Em sistemas embarcados, industriais, aeroespaciais, automotivos e médicos, o software se transforma em comportamento físico. Um ponteiro errado, uma condição de corrida, uma interrupção mal tratada, um estouro de pilha ou uma falha de temporização não são apenas problemas abstratos. Eles podem virar movimento errado, leitura falsa, aquecimento indevido, comando indevido ou perda de controle.

A pergunta que fica é inevitável: em um mundo onde tudo pode ser atualizado a qualquer momento, será que não perdemos parte dessa disciplina? Será que a possibilidade de corrigir depois não nos torna, em alguns casos, menos cuidadosos agora?

Talvez uma boa forma de recuperar essa mentalidade seja imaginar que nosso código será transformado em algo físico, impossível de alterar depois de pronto. Se cada linha fosse tecida em uma memória, soldada em uma placa ou enviada para um lugar onde ninguém poderá alcançá-la, como escreveríamos? Como testaríamos? Como documentaríamos? Como revisaríamos? Como lidaríamos com os casos extremos?

Essa reflexão é especialmente importante para quem trabalha com sistemas embarcados e IoT. Mesmo quando existe atualização remota, ela nem sempre é simples, segura ou garantida. Um dispositivo pode estar em campo, sem conexão estável, alimentado por bateria, instalado em local remoto, preso a uma máquina industrial ou dependente de uma janela curta de manutenção. Na prática, muitos sistemas modernos ainda carregam o mesmo desafio das missões espaciais: depois que o produto sai do laboratório, corrigir pode ser caro, difícil ou impossível.

No próximo artigo, vamos acompanhar o momento em que todo esse esforço foi colocado à prova. Durante o pouso da missão Apollo 11, o computador começou a emitir alarmes inesperados, e a forma como o sistema reagiu se tornaria um dos maiores exemplos de engenharia resiliente da história.