Serviço pós-vôo Boeing Starliner, foto NASA / Bill Ingalls
Duas vezes quase perdido
Na terminologia da NASA, a missão foi reconhecida como "quase perdida com ampla cobertura da mídia" ("chamada de alta visibilidade de perto"). O próximo termo é a perda do navio e possivelmente a perda de vidas. O status é bastante raro, e a última vez que foi designada a situação quando em 2013 o astronauta Luca Parmitano quase se afogou em um traje espacial em uma caminhada no espaço devido a um filtro entupido no sistema de refrigeração de água.
O primeiro bug apareceu 31 minutos após o início. A espaçonave não realizou a manobra esperada para mudar para a trajetória de vôo da ISS de sua órbita original. O MCC tentou retificar a situação, mas, por pior que fosse, essas tentativas foram superpostas a problemas de comunicação e, como resultado, o Starliner estava em uma órbita inadequada para encontro com a ISS e com tanques de combustível vazios. Devido a um erro no código, a espaçonave sincronizou o cronômetro do tempo de vôo com o veículo lançador, não no início da contagem regressiva, mas 11 horas antes do lançamento. Como resultado, o computador de bordo acreditou que a nave estava em um estágio de vôo diferente do que na realidade.
Separação dos compartimentos da nave Staliner, um quadro do vídeo da Boeing
O segundo bug não teve tempo de se provar. Por causa do primeiro problema, os especialistas da NASA e da Boeing começaram a analisar o código para ver se perdemos mais alguma coisa. E, como se viu, não foi em vão. Durante o pouso, depois de realizar uma manobra de frenagem, a espaçonave teve que se dividir em um veículo de descida e um módulo de serviço (mostrado na ilustração acima, quase todas as espaçonaves passam por um procedimento semelhante, por exemplo, Soyuz é dividido em três compartimentos, e a Tripulação Draron deixa cair o módulo de serviço antes travagem). Após a separação, o módulo de serviço teve que realizar uma manobra para se afastar do navio, mas devido a um erro no código, o procedimento foi transmitido incorretamente para o controlador que controla o processo. Como resultado, o módulo de serviço pode atingir o veículo de descida e causar problemas.
O terceiro problema não foi tão crítico, mas bebi muito sangue do pessoal de terra. Ao longo da missão, o navio teve problemas de comunicação com o solo, o que dificultou o controle do MCC e, no caso de um voo tripulado, dificultaria a negociação com os astronautas.
Duas questões críticas, cada uma das quais teria levado à perda do navio se não fosse a intervenção do MCC, surgiram durante a fase de projeto e desenvolvimento e conseguiram passar por várias verificações durante a fase de testes. Ambos os problemas foram detectados por meio de testes, e os processos da Boeing poderiam e deveriam tê-los encontrado e corrigido.
O que fazer?
O relatório completo contém informações proprietárias e segredos comerciais, portanto a NASA publicou apenas uma visão geral, que ainda é bastante interessante.
21 recomendações estão diretamente relacionadas aos testes. Em primeiro lugar, é necessário aprimorar os testes de integração tanto no nível de hardware quanto de software. Em meu próprio nome, observo que os erros que não foram detectados na fase de testes de integração ainda ocupam uma grande parcela das causas dos acidentes espaciais. Além disso, antes de cada voo, é necessário realizar um “ensaio geral” com o máximo envolvimento do equipamento de voo, analisar seu comportamento e limitações e atuar sobre as lacunas detectadas nas simulações.
Dez recomendações foram atribuídas a requisitos, mas na verdade elas também se relacionam a testes. Requisitos com várias condições devem ser melhor analisados e a cobertura de decisão deve ser aumentada - a cobertura de teste das condições no código. Deixe-me lembrá-lo de que 100% de cobertura de decisão significa 100% de cobertura de instrução, mas não vice-versa.
35 recomendações devem melhorar os processos. E de acordo com o que se propõe melhorar, é possível reconstruir os problemas descobertos. O fortalecimento da revisão do código e dos dados de teste deve corrigir o problema com o fato de que os erros no código não foram percebidos durante a escrita do código (para a revisão do código) ou durante o processo de teste (os dados de teste eram obviamente insuficientes). Um maior envolvimento de especialistas em áreas críticas de segurança deve eliminar lacunas de competência. E a proposta de alterações na documentação das comissões decisórias deve corrigir a situação quando falhas de desenvolvimento e testes não foram percebidas ou receberam prioridade muito baixa para eliminação.
As 7 recomendações são correções de código que irão corrigir bugs levando em consideração o tempo de vôo e o procedimento de separação do módulo de serviço, além de tornar o algoritmo de seleção de antena mais confiável.
E as últimas 7 recomendações estão relacionadas à estrutura organizacional e hardware. Mudanças aguardam a estrutura organizacional das mensagens de segurança (obviamente, para transmitir melhor as mensagens "temos um problema importante aqui"), a auditoria externa deve ser melhorada e um filtro adicional será introduzido no projeto do navio para proteção contra interferência fora da banda.
Querida lição
Apesar de não haver nada de alegre na história do vôo de emergência, ela servirá para melhorar os processos de criação de tecnologia espacial e segurança de vôo. Claro, é muito irritante não ver bugs de produção que poderiam e deveriam ter sido encontrados durante os testes muito antes do vôo. Agora, os primeiros voos de teste devem antes confirmar a correção das decisões tomadas, ao invés de detectar problemas despercebidos. O voo de teste foi muito instrutivo, mas também muito caro. A Boeing agora precisa conduzir outro lançamento de teste às suas próprias custas para garantir que o navio seja seguro e voável. Sua data exata ainda é desconhecida, enquanto novembro de 2020 está previsto.