Ariane 5: o bug overflow que custou US$ 370 milhões

O lançamento histórico que virou pesadelo

A causa raiz do Ariane 5 bug overflow no SRI: horizontal bias em float de 64 bits não cabia em int16 e gerou operand error — falta de verificação formal e exception handling em sistemas críticos. Em 4 de junho de 1996, o Ariane 5 (programa europeu da ESA) decolou com satélites Cluster a bordo; cerca de 37 segundos depois, o voo 501 foi destruído e a carga (~US$ 370 milhões) se perdeu.

À medida que a contagem regressiva chegava ao fim e os motores rugiam, engenheiros e a mídia internacional celebravam antecipadamente o que seria um novo marco para a ciência europeia. Entretanto, em questão de segundos, a esperança virou tragédia. Aos 37 segundos após a ignição, tudo desabou em uma explosão devastadora que aniquilou o foguete e sua carga valiosa – resultado de um erro inesperado no coração do sistema.

Como a investigação encontrou o bug

Diante do choque, uma comissão de investigação foi criada pela ESA (Agência Espacial Europeia) para caçar as causas do desastre Ariane 5 (Ariane flight V88 / voo 501). O desafio inicial era gigantesco: os destroços estavam espalhados por quilômetros de selva fechada, e o Ariane 5 era governado por softwares com algoritmos extremamente sofisticados. Para liderar a apuração, trouxeram um matemático de peso, desses que só aceita dado e prova — nada de achismo.

Software vs hardware: onde a falha realmente estava

O time de especialistas recriou, segundo a segundo, toda a sequência do voo. Era preciso entender não apenas a física do foguete, mas cada aspecto do sistema de controle, que utilizava sensores, atuadores e lógica programada para comandar desde ajustes de direção até a separação dos estágios. Ficou rapidamente claro que fatores externos, como clima ou pane mecânica, podiam ser descartados – qualquer pista estava oculta dentro dos próprios sistemas embarcados.

A anomalia de 36,7 segundos: quando um número vira ameaça

A virada da investigação aconteceu ao se analisar o sistema de referência inercial (SRI), responsável por identificar a orientação e a posição do Ariane 5 no espaço. Uma variável central, contendo a velocidade horizontal (bias horizontal), começou a exibir valores incompatíveis logo aos 36,7 segundos do voo. O motivo? Uma conversão inesperada de um valor do tipo float 64 bits para um inteiro de 16 bits – fora do limite suportado pelo hardware.

O que é overflow de inteiro?

Overflow de inteiro ocorre quando um número maior do que o tipo comporta é forçado para aquele tipo — no Ariane 5, float de 64 bits para int de 16 bits. O resultado não “arredonda com aviso”: vira valor errado ou exceção, e no SRI isso virou perda de atitude.

No Ariane 5, a variável era um inteiro de 16 bits com sinal. Isso dá um máximo de 32.767. O valor real da velocidade horizontal era um float de 64 bits — capaz de armazenar números absurdamente grandes. A conversão faz mais ou menos isso em pseudo-código:

velocidade_horizontal: float64 = 32768.5 → variavel_sri: int16 = ??? BOOM. O número 32.768 já estoura o limite de 32.767. O sistema não tinha proteção. A exceção subiu, ninguém tratou, e o computador de bordo recebeu lixo no lugar de dados de navegação.

Cada linguagem lida com isso de um jeito. Em JavaScript, Number.MAX_SAFE_INTEGER te dá 9 quadrilhões — parece muito, mas em cálculos financeiros já deu problema. Python resolve com bigint automático: o número cresce o quanto precisar. Já em C e Ada (a linguagem do Ariane 5), a responsabilidade é toda sua. Você declara o tipo, define o tamanho, e se o valor passar do limite... boa sorte.

Ada até tem checagem de range nativa — o compilador pode barrar isso. Mas os devs do Ariane 5 desativaram a proteção naquelas três variáveis. Provavelmente por performance. Provavelmente porque 'nunca vai passar desse valor'. Deu no que deu.

Na prática, o bug ocorreu porque a variável float continha um valor maior que 32.767, o máximo absoluto que um inteiro de 16 bits pode armazenar quando possui sinal. A simples tentativa de converter esse valor excedente desencadeou o chamado erro de overflow – aquela zona onde os bits "transbordam", retornam a zero ou mudam de sinal, e todo o processo seguinte entra em colapso.

Sem tratamento de exceção, o erro paralisa o sistema inercial, paralisando também o raciocínio de navegação do foguete. O computador de bordo, percebendo dados absurdos, interpretou que precisava girar em 90 graus sua trajetória para compensar, causando desequilíbrio, fragmentação estrutural e explosão em pleno voo.

Overflow na prática: o código que explodiu o foguete

Chega de teoria. Olha o que aconteceu no Ariane 5 traduzido pra código que qualquer dev entende. O SRI recebia a velocidade horizontal como float de 64 bits e tentava converter pra inteiro de 16 bits. Em pseudo-Ada, o trecho era mais ou menos isso:

O valor 32.768,5 não cabe em 32.767. Sem a checagem de range, Ada não barra a conversão. A exceção sobe, ninguém trata, o SRI desliga, o computador de bordo recebe dados de diagnóstico no lugar de dados de navegação e interpreta como 'gire 90 graus'. Resultado: forças aerodinâmicas destroem o foguete.

Agora olha como isso se manifesta nas linguagens que você usa todo dia:

Se você escreve JavaScript sem pensar em Number.MAX_SAFE_INTEGER, você tá apostando que nenhum cálculo vai estourar. E aposta em software é bug. Em Python, o bigint nativo te salva, mas se usar NumPy ou qualquer lib C por baixo, o overflow volta silencioso. TypeScript te dá tipagem em compilação, mas em runtime os números continuam sendo floats de 64 bits.

Overflow em JS, TypeScript e Java hoje

O Ariane 5 falhou por converter um valor grande demais para um inteiro de 16 bits. O mesmo padrão aparece em stacks modernas — só muda a sintaxe.

Em JavaScript/TypeScript, Number é float64 e pode perder precisão acima de 2^53−1; use BigInt quando a magnitude importa. Em Java, cuidado com cast int/short e com APIs que silenciam overflow.

O ponto não é “nunca use int16”: é validar faixa, falhar de forma segura e retestar código reutilizado em novo envelope operacional.

Três armadilhas comuns no stack CrazyStack (JS/TS) e em backends Java:

Framework mental: (1) qual o tipo de armazenamento real? (2) qual a faixa operacional nova? (3) a falha é fail-closed (abortar) ou fail-open (seguir com lixo)? No Ariane, a exceção não tratada virou desligamento do voo.

Não invente “caso de cliente”: rode testes de fronteira no seu código — valores no limite, um acima, e o máximo histórico do sistema antigo vs o novo.

Análise técnica: onde a engenharia falhou

O relatório final detalhou que as conversões perigosas eram conhecidas por parte dos desenvolvedores. Dos sete pontos de risco detectados, apenas quatro receberam proteção no código – três foram deixados sem salvaguardas, sem justificativa aparente. Isso revela falhas de implementação, de planejamento e de validação de requisitos pra sistemas embarcados.

Origem do bug: decisões herdadas e riscos não previstos

Um aspecto surpreendente: parte do código do sistema de referência era herdada de versões anteriores do Ariane 4, onde os limites de velocidade nunca seriam atingidos. O reuso aparentemente seguro dos algoritmos, sem revalidar variáveis e limites na nova configuração do Ariane 5, tornou o bug inevitável. Mudanças em contextos de uso, mesmo em sistemas "já testados", demandam novamente análise detalhada dos riscos.

Checklist: reuso de código sem revalidação

Antes de reaproveitar módulo legado em um contexto novo, trate “já funcionava” como hipótese — não como prova.

No Ariane 5, o reuso do SRI da Ariane 4 sem revalidar o perfil de voo foi o gatilho organizacional — não só o cast em si.

Para SaaS e migrações: o checklist vale para libs internas, dump de schema, workers e qualquer “copiei do projeto antigo”. O bug caro quase sempre é organizacional (pulou revalidação), não só o cast.

Por que o Ariane 5 usava Ada e não C?

Ada não é uma linguagem que a galera aprende no bootcamp. Foi criada nos anos 80 por encomenda do Departamento de Defesa dos EUA, que estava cansado de manter software militar em dezenas de linguagens diferentes. O objetivo era criar uma linguagem única pra sistemas críticos — embarcados, tempo real, alta confiabilidade. O nome é homenagem a Ada Lovelace, a primeira programadora da história.

Ada foi desenhada pra impedir exatamente o tipo de bug que derrubou o Ariane 5. Tipagem forte com ranges declarados, checagem de overflow em tempo de execução, contratos embutidos na linguagem. Se você declara uma variável como Integer range 0..32767, o runtime barra qualquer valor fora desse intervalo. É como ter um guarda-corpo na beira do precipício — você precisa fazer esforço pra cair.

Aí vem o paradoxo. Os engenheiros do Ariane 5 desativaram a checagem de range naquelas três variáveis críticas. Em Ada, você pode usar pragma Suppress(Range_Check) pra desligar a verificação — geralmente por performance. O compilador obedece, o runtime para de checar, e o guarda-corpo some. É como colocar airbag no carro e desativar porque 'faz barulho no teste'.

Por que não usaram C? Na época, C era popular em software de sistemas, mas pra aplicações espaciais era considerada arriscada demais. C não tem checagem de bounds nativa, permite aritmética de ponteiros irrestrita e dá ao programador liberdade total pra estourar buffers sem aviso. Em software onde um bit errado significa foguete explodindo, essa liberdade é um risco que a ESA não queria correr.

Hoje, a extensão SPARK de Ada vai ainda mais longe: permite provas formais de que o código está correto antes de compilar. Não testa — prova. É a resposta direta a desastres como o do Ariane 5.

Se os devs tivessem mantido o Range_Check ativo, a exceção teria sido capturada pelo runtime de Ada, o SRI teria reportado erro de software, e o computador de bordo poderia ter ativado o backup. O foguete talvez estivesse inteiro.

Por que o Ariane 4 nunca teve esse problema?

Essa é a pergunta que todo dev faz quando ouve a história. Se o código era o mesmo, por que só deu problema no Ariane 5? A resposta é simples e assustadora ao mesmo tempo: o Ariane 4 tinha uma trajetória diferente. A velocidade horizontal do foguete durante os primeiros 40 segundos de voo era significativamente menor. O valor nunca chegava perto de 32.767. O int16 dava conta sem suar.

O Ariane 5 era maior, mais potente e seguia um perfil de voo completamente diferente. Acelerava mais rápido, em ângulos distintos. A velocidade horizontal disparava nos primeiros segundos. Ninguém recalculou se os limites das variáveis ainda faziam sentido. O código passou no teste do Ariane 4 durante anos. Isso virou a justificativa silenciosa pra não testar de novo.

Isso acontece em software o tempo todo. Pensa numa validação de email que funciona perfeitamente com 500 usuários. Aí a empresa cresce, chega em 5 milhões de contas, e aquele regex que 'sempre funcionou' começa a derrubar o servidor. Ou uma query SQL que roda em 20ms com mil registros e leva 45 segundos com dez milhões. O código não mudou — o contexto mudou.

O termo técnico pra isso é 'suposição implícita no código'. São premissas que ninguém escreve, ninguém documenta, mas todo mundo assume. 'Esse valor nunca vai passar de X'. 'Esse endpoint nunca vai receber mais de Y requests por segundo'. 'Ninguém vai colocar emoji no campo de CPF'. Até o dia que alguém faz exatamente isso.

O Ariane 4 criou uma suposição implícita: a velocidade horizontal cabe num int16. O Ariane 5 provou que suposição implícita é dívida técnica com juros compostos. Quanto mais tempo passa sem ser documentada e validada, maior o estrago quando explode.

Quanto custou o desastre do Ariane 5?

Dinheiro é o que faz gerente prestar atenção. Então vamos aos números concretos, porque o Ariane 5 foi provavelmente o bug mais caro da história da computação em termos de impacto direto.

O programa Ariane 5 consumiu cerca de US$ 7 bilhões em desenvolvimento ao longo de uma década. Dez anos de engenharia de ponta, financiados por 20 nações europeias. O Voo 501 era o primeiro lançamento operacional — a estreia. A bordo estavam quatro satélites da missão Cluster, da ESA, cada um avaliado em dezenas de milhões. No total, a carga destruída representou US$ 370 milhões em hardware científico evaporado em 37 segundos.

O atraso no programa foi de mais de um ano. O foguete em si era parte do problema. O que pesou mesmo foi refazer toda a cadeia de validação de software, revisar processos de engenharia e reconquistar a confiança de 20 governos que financiavam o projeto. O custo político é incalculável — parlamentares de vários países questionaram publicamente a competência da ESA.

Mas tem um lado bom nessa história. A missão Cluster não morreu ali. A ESA reconstruiu os quatro satélites e lançou o Cluster II em 2000, usando dois foguetes Soyuz russos. Esses satélites continuaram operando por mais de duas décadas, gerando descobertas sobre o magnetismo terrestre que justificaram o investimento. A ciência sobreviveu ao bug. Mas o custo de aprender essa lição foi alto demais.

O preço de uma falha: impacto em toda a indústria

O acidente causou perdas instantâneas de bilhões de dólares, adiou anos de pesquisa científica e expôs vulnerabilidades em processos de engenharia de software. Desde então, o rigor na validação e revisão de código se tornou obrigatório em missões espaciais e outros projetos críticos, mudando a cultura em empresas, instituições científicas e desenvolvedores do mundo todo.

Quais normas de software surgiram depois do Ariane 5?

O Ariane 5 acelerou uma conversa que já estava rolando nos bastidores: software que pode matar gente precisa de regras diferentes. Não dá pra tratar código de foguete como código de landing page. E depois de 1996, as agências espaciais e de aviação levaram isso a sério.

A DO-178C é a norma que governa software de aviação. Todo código que roda num avião comercial precisa passar por ela.

Dependendo do nível de criticidade (de A até E), o software precisa de cobertura de testes que vai de 'cada condição booleana testada individualmente' até provas formais de que o código faz exatamente o que a especificação diz. O nível A (falha causa queda do avião) exige cobertura MC/DC, que é tão rigorosa que a maioria dos devs web nem sabe que existe.

A ESA criou as normas ECSS (European Cooperation for Space Standardization) pra software espacial. Depois do Ariane 5, revisaram completamente os requisitos de validação. Hoje, qualquer reuso de software entre missões passa por revalidação obrigatória no novo contexto. O exato cenário que derrubou o Ariane 5, copiar código do 4 pro 5 sem retestar, agora é proibido por norma.

A NASA gasta mais em testes do que em desenvolvimento. Parece caro até você comparar com o preço de um foguete explodindo. O software do Space Shuttle tinha uma taxa de defeitos de 0,1 por mil linhas de código. Pra referência, software comercial típico tem entre 15 e 50 defeitos por mil linhas. A NASA consegue isso com verificação formal — provas matemáticas de que cada módulo se comporta como especificado.

Verificação formal é quando você não testa se o código funciona — você prova matematicamente. Ferramentas como SPARK (extensão de Ada), TLA+ e Coq permitem escrever especificações formais e verificar que o código satisfaz cada uma delas. É caro, demorado e impraticável pra maioria dos projetos. Mas pra sistemas onde falha significa morte ou prejuízo bilionário, é o padrão ouro.

A diferença cultural entre agências é real. A NASA opera na base do 'prove que funciona'. A indústria comercial opera na base do 'funciona até provar que não'. Depois do Ariane 5, ficou mais difícil defender a segunda opção com cara séria.

Prevenção em projetos críticos: o que mudou depois

Técnicas modernas para evitar overflow e falhas críticas

Se hoje é possível construir sistemas autônomos confiáveis para usos sensíveis (espacial, médico, aeroespacial), é porque aprendizados como o da Ariane 5 impulsionaram ferramentas, bibliotecas e processos de verificação de software embarcado.

Esse tipo de falha ainda acontece hoje?

Sim. E com mais frequência do que qualquer um gostaria de admitir. O Ariane 5 não é uma curiosidade histórica — é um padrão que se repete.

Em 2018 e 2019, dois Boeing 737 MAX caíram matando 346 pessoas. A causa? O sistema MCAS, que corrigia automaticamente o ângulo de voo, dependia de um único sensor. O software foi adaptado de versões anteriores do 737 sob a premissa de que o comportamento aerodinâmico seria similar. Som familiar? Reusar lógica de um contexto antigo num contexto novo sem revalidar as premissas. O Ariane 5 de novo, só que com passageiros.

Em julho de 2024, a CrowdStrike derrubou 8,5 milhões de máquinas Windows com uma atualização de driver defeituosa. Hospitais, aeroportos e bancos pararam. Não foi um ataque hacker — foi um update que passou pelo pipeline de QA sem testes em cenários extremos. Uma conversão de dados errada no kernel. Overflow conceitual: o sistema não aguentou um valor que o time não previu.

A Cloudflare já caiu por regex backtracking — uma expressão regular que funcionava em inputs normais mas travava com strings específicas, consumindo 100% de CPU. O código tava lá há meses. Ninguém testou com input adversarial.

Não precisa ser foguete. Seu deploy de sexta-feira às 17h pode ser o próximo Ariane 5 em miniatura. Aquele campo que 'nunca vai receber mais de 255 caracteres'. Aquele cálculo que 'sempre retorna positivo'. Aquela migração de banco que 'não vai afetar a tabela de usuários'.

O que o Ariane 5 ensina sobre code review?

Dos sete pontos de conversão arriscada no SRI, quatro foram protegidos. Três ficaram expostos. Ninguém documentou o porquê. Esse é o tipo de decisão que, num code review moderno, geraria um comentário de PR em menos de 5 minutos: 'Por que essa conversão tá desprotegida?'

Mas aqui tá o problema: a maioria dos code reviews é teatro. O dev abre o PR, o reviewer olha por cima, aprova em 3 minutos e segue a vida. Ninguém questiona premissas. Ninguém pergunta 'e se esse valor for maior do que o esperado?'. Ninguém desafia a lógica — só verifica se compila e se o lint tá passando.

O Ariane 5 pede um tipo diferente de review: adversarial. É quando o reviewer age como um atacante. Não tá ali pra confirmar que o código funciona — tá ali pra provar que ele quebra. 'Qual o maior valor possível aqui?' 'O que acontece se esse serviço cair?' 'E se a rede atrasar 30 segundos?' São as perguntas que ninguém fez no Ariane 5.

Em projetos críticos (e todo projeto que lida com dinheiro, saúde ou segurança é crítico), code review deveria ter checklist obrigatório. Conversões de tipo protegidas? Check. Limites documentados? Check. Fallback pra falha do sistema inercial? Check. Não é burocracia. É engenharia.

Como auditar código legado e conversões numéricas

90% dos devs nunca fizeram grep por conversão de tipo no próprio código. Faz agora. Sério. Abre o terminal e roda uma busca por cast, as, parseInt, Number, int(), float() — qualquer coisa que force um tipo a virar outro. Cada resultado é um ponto de risco que precisa de atenção.

Auditar código legado não é glamouroso. Ninguém posta no LinkedIn que passou a tarde revisando conversões de tipo num módulo de 2019. Mas é isso que separa o dev que previne desastres do dev que apaga incêndio todo mês.

Se o seu projeto tem mais de 2 anos e nunca passou por uma auditoria de tipos, você tem bugs de overflow esperando pra acontecer. A questão não é se, é quando. O Ariane 5 funcionou perfeitamente por anos no Ariane 4. Até que o contexto mudou e ninguém olhou de novo.

O desastre além do código: pessoas, comunicação e cultura

O caso do Ariane 5 demonstra também como a comunicação, confiança cega em processos e negligência em registrar justificativas técnicas podem ser tão destrutivos quanto código errado. Documentação ruim mata projeto. Não documenta a decisão técnica, e daqui a 2 anos ninguém lembra por quê aquele if tá ali. No Ariane 5, ninguém registrou por que 3 conversões ficaram desprotegidas. O resultado tá nos livros de história.

Fontes

Revisão técnica em agosto de 2026. Os números abaixo vêm do relatório da comissão de inquérito e de cobertura oficial do incidente (Flight 501).

<a href="https://www.esa.int/Newsroom/Press_Releases/Ariane_501_-_Presentation_of_Inquiry_Board_report">ESA — Ariane 501 (apresentação do relatório da Inquiry Board)</a>. PDF do relatório: <a href="https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf">esa-x-1819eng.pdf</a>. Para o efeito CrowdStrike de julho de 2024 citado no texto, a estimativa pública da Microsoft sobre dispositivos Windows afetados é a referência mais citada na imprensa técnica.

Perguntas frequentes

O que causou a explosão do Ariane 5?

Uma conversão de ponto flutuante de 64 bits para inteiro com sinal de 16 bits no sistema de referência inercial (SRI) estourou. O valor de viés horizontal (BH) da trajetória do Ariane 5 era maior que o previsto no código reutilizado do Ariane 4, gerando Operand Error e perda de orientação cerca de 37 segundos após a ignição.

O que é integer overflow no caso do Ariane 5?

É quando um número não cabe no tipo escolhido. No voo 501, um float64 de velocidade/viés horizontal foi convertido para int16 (faixa até 32767). O valor ultrapassou o limite, a exceção não foi tratada de forma segura e o SRI parou — inclusive o backup com o mesmo software.

Quanto custou o desastre do Ariane 5?

A perda tipicamente citada é cerca de US$ 370 milhões referentes à carga útil Cluster do primeiro voo. O programa Ariane 5 como um todo teve custo de desenvolvimento da ordem de bilhões; não confunda custo do programa com a perda daquele lançamento.

Por que o Ariane 4 não teve o mesmo bug?

O software do SRI foi reutilizado sem revalidar os limites físicos da nova trajetória. No Ariane 4 a velocidade horizontal no trecho crítico ficava dentro do int16; no Ariane 5, a aceleração horizontal maior produziu valores fora da faixa protegida.

O que o Ariane 5 ensina para software moderno?

Reuso sem revalidação é risco. Proteja conversões numéricas, teste nos limites reais do novo contexto e não assuma que redundância de hardware salva software idêntico nos dois nós.

Continue explorando

Checklist: evitando o próximo Ariane 5