A segunda falha no software Starliner da Boeing poderia ter levado a uma colisão no espaço

A sonda CST-100 Starliner da Boeing é retratada em casa na Unidade de Processamento de Cargas e Carga Comercial da empresa, onde está sendo inspecionada após sua missão de Teste de Voo Orbital em dezembro de 2019 (Crédito da imagem: Frank Michaux / NASA)

O módulo de tripulação da Starliner poderia “esbarrar” em seu módulo de serviço após a separação se a Boeing não tivesse detectado o erro.

Sete semanas depois que o CST-100 Starliner da Boeing não chegou à Estação Espacial Internacional, conforme planejado durante seu primeiro teste de vôo orbital, funcionários da NASA e da Boeing divulgaram os resultados preliminares de uma investigação sobre o que deu errado.

A sonda Starliner foi lançada no topo de um foguete Atlas V em 20 de dezembro de 2019, em uma missão de atracar na Estação Espacial Internacional (ISS). A missão foi projetada para demonstrar a capacidade da nova nave espacial de transportar com segurança astronautas de e para o laboratório em órbita. No entanto, a Starliner não conseguiu alcançar a órbita correta e passou os dois dias seguintes circulando a Terra sozinha antes de executar um pouso perfeito na faixa de mísseis White Sands, no Novo México, em 22 de dezembro.

Em uma teleconferência com repórteres na sexta-feira (7 de fevereiro), o administrador da NASA Jim Bridenstine disse que uma equipe de revisão independente identificou vários problemas durante a missão do Teste de Vôo Orbital (OFT), principalmente quando se trata do software da espaçonave. Juntamente com o erro divulgado anteriormente com o temporizador de bordo da Starliner, um segundo problema de software poderia ter potencialmente levado a uma colisão leve, mas problemática, de dois componentes da sonda, determinaram os investigadores.

O primeiro problema de software foi identificado logo após o lançamento do Starliner, quando o veículo não conseguiu executar uma gravação de inserção em órbita. A Boeing logo descobriu que o sistema de temporização a bordo da espaçonave, chamado de “temporizador de missão decorrida”, erroneamente retirou um tempo incorreto do foguete Atlas V quase 11 horas antes da decolagem. O Starliner deveria recuperar essas informações do foguete durante o período final da contagem regressiva antes da decolagem e, como essa etapa ocorreu prematuramente, o relógio interno da Starliner teve a hora incorreta.

Em seguida, um segundo problema de software foi descoberto antes do retorno da sonda à Terra, e essa falha poderia ter potencialmente causado uma colisão entre o módulo de tripulação da Starliner e seu módulo de serviço, que é projetado para se separar em órbita antes do módulo da tripulação pousar.

Esse problema, que os funcionários da Boeing chamaram de “erro de mapeamento de válvulas”, tinha a ver com o software que solicita que o módulo de tripulação e o serviço da Starliner se separem antes do pouso. Os propulsores do módulo de serviço são responsáveis ??por realizar a queima do déficit que leva o Starliner para fora da órbita, enviando-o de volta à Terra para o pouso. Após a queima do deorbit, o módulo de serviço se desconecta do módulo da tripulação e cai com segurança no Oceano Pacífico.

“Durante o que chamamos de ‘vôo livre’, quando o módulo de tripulação é anexado ao módulo de serviço, há um certo mapeamento de válvulas, e os computadores de vôo no módulo de tripulação comandam todas as disparagens individuais do propulsor. Mas depois que você separa o veículo de lançamento a partir do módulo de tripulação, os controladores de propulsão no módulo de serviço precisam realizar os disparos do propulsor para obter a queima adequada de separação e descarte “, disse John Mulholland, vice-presidente e gerente de programa do programa Starliner da Boeing, durante a teleconferência.

“Esse mapeamento de válvulas é diferente nesses dois casos, e o software infelizmente teve o mesmo mapeamento de válvulas para ambas as condições, então tivemos um mapeamento incorreto de válvulas para a queima de separação e descarte”, disse Mulholland.

Felizmente, a equipe detectou esse erro de software antes do Starliner iniciar seu procedimento de descida. “A equipe rapidamente decodificou o software, o reverificou nos laboratórios, e conseguimos fazer o upload dessa correção e concluir a missão com segurança”, disse Mulholland.

Ilustração de um artista da espaçonave CST-100 Starliner da Boeing em órbita. (Crédito da imagem: Boeing)

Se a Boeing não tivesse captado essa falha antes que o Starliner voltasse à Terra, os dois módulos poderiam ter “colidido” um com o outro após a separação, o que poderia ter desestabilizado o módulo da tripulação durante um ponto crítico em sua descida.

“O disparo desigual dos propulsores faria com que o módulo de serviço, que é um pedaço de cilindro, se afasta do módulo da tripulação e entre em contato novamente, ou colidir com ele”, disse Jim Chilton, vice-presidente sênior da Boeing Space and Launch, durante a teleconferência, acrescentando que “coisas ruins” podem acontecer como resultado dessa eventualidade.

“Isso significa que você cutuca o módulo da tripulação, que fica instável e precisa se estabilizar”, disse Chilton. “Então, uma pergunta é: você bate forte o suficiente onde cai ou tem algum problema? Outra coisa é que você não quer danificar esse escudo térmico, porque você precisa que ele volte.”

“É difícil dizer onde o módulo de serviço teria colidido, mas nada de bom pode vir dessas duas naves espaciais, então enviamos o software para garantir que isso não aconteça”, disse ele.

Problemas de comunicação

Um terceiro grande problema que a Starliner encontrou durante seu teste de vôo orbital não estava relacionado ao software da espaçonave, mas sim à interferência que interrompeu as comunicações entre os controladores de solo e a Starliner.

Quando os controladores de solo tentaram comandar manualmente a Starliner para realizar uma gravação de inserção em órbita após o erro de temporização impedir que isso acontecesse automaticamente, eles não conseguiram se comunicar com a sonda em tempo hábil. As comunicações entre Starliner e controle de solo são retransmitidas através da rede de satélites de rastreamento e retransmissão de dados da NASA, mas o “alto ruído” interferiu nesses sinais, disse Mulholland.

A equipe de revisão investigativa ainda está trabalhando para determinar a causa exata dessa interferência, mas parece estar associada a torres de telefonia celular, acrescentou.

Enquanto a revisão independente das questões OFT da Starliner ainda estiver em andamento, a NASA espera ter o relatório final até o final de fevereiro, disse Bridenstine. Ele acrescentou que a NASA ainda não decidiu se deve realizar um segundo teste de vôo orbital antes de usar o Starliner para voar astronautas para a Estação Espacial Internacional.

“Este teste de vôo nos ensinou muito”, disse Chilton. “O que desejamos ter feito melhor é o software”.

Doug Loverro, diretor da diretoria de operações de voos espaciais da NASA, disse durante a teleconferência que os problemas de software “provavelmente são apenas sintomas. Eles não são o problema real”.

“O verdadeiro problema é que tivemos inúmeras fugas de processo no projeto, desenvolvimento e ciclo de teste de software”, disse Loverro, “e à medida que avançamos, é nisso que vamos nos concentrar … como garantir nós mesmos que todos os softwares que fornecemos, não apenas as duas rotinas afetadas por esses problemas, foram corrigidos? “


Publicado em 08/02/2020 12h33

Artigo original:


Achou importante? Compartilhe!


Assine nossa newsletter e fique informado sobre Astrofísica, Biofísica, Geofísica e outras áreas. Preencha seu e-mail no espaço abaixo e clique em “OK”: