Qual foi o impacto histórico do voo 501 da Ariane 5?

A desintegração do foguete Ariane 5 37 segundos após o lançamento em sua viagem inaugural ( vôo 501 ) é comumente referida como um dos bugs de software mais caros da história ¹ :

A Agência Espacial Européia levou 10 anos e US $ 7 bilhões para produzir o Ariane 5, um foguete gigante capaz de lançar um par de satélites de três toneladas em órbita a cada lançamento e com o objetivo de dar à Europa uma supremacia esmagadora nos negócios espaciais comerciais.

Tudo o que foi necessário para explodir o foguete em menos de um minuto em sua viagem inaugural em junho passado, espalhando escombros de fogo nos pântanos da Guiana Francesa, foi um pequeno programa de computador tentando inserir um número de 64 bits em um espaço de 16 bits.

Um bug, um acidente. De todas as linhas descuidadas de código registradas nos anais da ciência da computação, essa pode ser a mais devastadoramente eficiente. De entrevistas com especialistas em foguetes e de uma análise preparada para a agência espacial, surge um caminho claro desde um erro aritmético até a destruição total.

Quais as principais mudanças que a falha 501 do Flight e as investigações subsequentes inspiraram na pesquisa de sistemas críticos de segurança e testes de software?

Não estou procurando uma explicação do bug em si, mas uma explicação do impacto histórico do bug, em termos de pesquisas inspiradas ou diretamente relacionadas às investigações da falha. Por exemplo, este artigo conclui:

Usamos a análise estática para:

• verifique a inicialização das variáveis,
• forneça uma lista exaustiva de possíveis conflitos de acesso a dados para variáveis ​​compartilhadas,
• lista exaustivamente os possíveis erros de tempo de execução da semântica Ada.

Até onde sabemos, é a primeira vez que técnicas de análise estática baseadas em booleanas e não baseadas em booleanas são usadas para validar programas industriais.

Da mesma forma, este documento ^(pdf) observa:

As análises de programas estáticos baseados em interpretação abstrata foram usadas para a análise estática do software ADA incorporado do iniciador Ariane 5 e do ARD. O analisador de programa estático visa a detecção automática da indefinição, potencialidade, impossibilidade ou inacessibilidade de erros em tempo de execução, como vazamentos escalares e de ponto flutuante, erros de índice de matriz, divisões por zero e exceções aritméticas relacionadas, variáveis ​​não inicializadas, dados em execução. estruturas de dados compartilhadas etc. O analisador conseguiu descobrir automaticamente o erro de vôo do Ariane 501. A análise estática do software crítico de segurança incorporado (como o software aviônico) é muito promissora .

Eu adoraria uma explicação completa do impacto que esse evento único teve nas abordagens e ferramentas de teste de software.

_{¹ O valor de US $ 7 bilhões possivelmente se refere ao custo total do projeto Ariane 5, a Wikipedia relata que a falha resultou em uma perda de mais de US $ 370 milhões. Ainda é um fracasso bastante caro, mas nem perto dos US $ 7 bilhões.}

Tecnicamente falando, era mais um caso de " podridão de software ". O software de controle de vôo foi reciclado a partir do foguete Ariane 4 anterior, uma medida sensata, dada a custa do desenvolvimento de software, especialmente quando é um software de missão crítica que deve ser testado e verificado com padrões muito mais rigorosos do que a maioria dos softwares comerciais.

Infelizmente, ninguém se incomodou em testar o efeito que a mudança no ambiente operacional teria ou, se o fizesse, não fez esse teste com um padrão suficientemente completo.

O software foi desenvolvido para esperar que determinados parâmetros nunca excedam certos valores (empuxo, aceleração, taxas de consumo de combustível, níveis de vibração, etc.). Em um vôo normal em um Ariane 4, isso não era um problema, porque esses parâmetros nunca alcançariam valores inválidos sem que algo já estivesse espetacularmente errado. O Ariane 5, no entanto, é muito mais poderoso e faixas que pareceriam bobas no 4 poderiam acontecer com bastante facilidade no 5.

Não sei ao certo qual parâmetro foi que saiu do intervalo (pode ter sido uma aceleração, vou ter que verificar), mas quando o fez, o software não conseguiu lidar e sofreu um estouro aritmético pelo qual havia ocorrido. código de verificação e recuperação de erros insuficiente implementado. O computador de orientação começou a enviar lixo para os cardan dos bicos do motor, que por sua vez começaram a apontar o bico do motor de maneira aleatória. O foguete começou a tombar e se partir, e o sistema automático de autodestruição detectou que o foguete estava agora em uma atitude irrecuperável e insegura e terminou o trabalho.

Para ser honesto, esse incidente provavelmente não ensinou novas lições, pois os tipos de problemas já foram descobertos em todos os tipos de sistemas, e já existem estratégias para lidar com a localização e a correção de erros. O que o incidente fez foi esclarecer que o descuido em seguir essas estratégias pode ter enormes conseqüências; nesse caso, milhões de dólares em hardware destruído, alguns extremamente irritados com os clientes e um aborrecimento feio na reputação da Arianespace.

Esse caso em particular foi especialmente evidente porque um atalho usado para economizar dinheiro acabou custando uma quantia enorme, tanto em termos de dinheiro quanto de reputação perdida. Se o software tivesse sido testado com a mesma robustez em um ambiente simulado do Ariane 5, como havia sido originalmente desenvolvido para o Ariane 4, o erro certamente viria à tona muito antes de o software ser instalado no hardware de lançamento e colocado no comando da um voo real. Além disso, se um desenvolvedor de software tivesse deliberadamente jogado alguma entrada sem sentido no software, o erro poderia até ter sido detectado na era do Ariane 4, pois teria destacado o fato de que a recuperação de erros existente era inadequada.

Então, em resumo, ele realmente não ensinou novas lições, mas abalou os perigos de não se lembrar das antigas. Também demonstrou que o ambiente em que um sistema de software opera é tão importante quanto o próprio software. O fato de o software ser verificável correto para o ambiente X não significa que ele seja adequado ao objetivo em um ambiente semelhante, mas distinto Y. Finalmente, destacou a importância de um software de missão crítica ser robusto o suficiente para lidar com circunstâncias que não deveriam ter ocorrido. aconteceu.

Compare o vôo 501 com o Apollo 11 e seus problemas com o computador. Embora o software LGC sofra uma séria falha durante o pouso, ele foi projetado para ser extremamente robusto e foi capaz de permanecer em um estado operacional, apesar dos alarmes de software que foram acionados, sem colocar em perigo os astronautas e ainda poder complete sua missão.

Tratava-se principalmente de um problema de reutilização e de gerenciamento, e não de codificação. Pelas minhas lembranças (provavelmente estou interpretando algumas coisas erradas) do relatório.

• um subsistema foi projetado para o Ariane IV. As trajetórias do Ariane IV não poderiam resultar no estouro e, então, foi decidido propositadamente que, se ocorresse, era um problema de hardware; desligar o subsistema e ir para a reserva era a coisa certa a fazer.

• para Ariane V, foi decidido reutilizar esse subsistema e não revisar as suposições e o código, mas confiar nos testes.

• Além disso, foi decidido abandonar os testes completos.

Diferentes parâmetros de vôo do Ariane V fizeram o estouro ocorrer. Desligue o primário. Desligue a reposição. Autodestruição.

Coisas adicionais que eu lembro:

• o subsistema no momento do estouro não era mais útil. Alguém poderia argumentar que seu fracasso não deveria ter desencadeado a autodestruição. (Por outro lado, a complexidade adicionada pode ser uma fonte de problemas).

• houve dados de depuração enviados para um barramento quando não deveriam. Não me lembro do específico.

Como outros já mencionaram, fez com que a indústria em geral reexaminasse o conceito de reutilização e o colocasse em um quadro de referência maior, pelo qual os componentes não são avaliados isoladamente, mas no contexto de todo o sistema. Isso reduz significativamente a atratividade da reutilização, pois, mesmo que um componente possa ser reutilizado sem alterações, ele ainda precisa ser analisado com um novo conjunto de suposições. Outro corolário é que o hardware de backup executando o mesmo software não é tão atraente, pois a maioria dos hardwares modernos tem ordens de magnitude mais confiáveis ​​que os softwares modernos. Ouvi dizer que alguns contratos de defesa exigem dois sistemas de software separados, desenvolvidos por equipes diferentes, usando tecnologias diferentes que trabalham com a mesma especificação para verificar a implementação adequada.