Os sistemas operacionais espaciais

O recém lançado Orbitador Solar da ESA, vai estar por anos em uma missão solar. Durante esse período, o Solar Orbiter chegará 10 milhões de quilômetros mais perto do Sol do que Mercúrio. Vale ressaltar que, Mercúrio está perto o suficiente do Sol para atingir até 450 ° C de temperatura em sua superfície.

Para resistir a temperaturas tão elevadas, o Solar Orbiter terá um escudo térmico elaborado, protegendo a espaçonave enquanto estiver direcionada ao Sol. Entretando, as partes laterais e traseira não possuem proteção suficiente. Por isso, o sistema operacional RTOS foi desenvolvido, podendo atuar sob requisitos muito rígidos.

O desvio máximo permitido do Sol é de apenas 6,5 graus. Qualquer desvio superior a 2,3 graus é aceitável apenas por um breve período de tempo. Quando algo der errado e um desvio perigoso for detectado, o Solar Orbiter terá apenas 50 segundos para reagir.

A missão Solar Orbiter da Enlarge / ESA enfrentará o Sol de dentro da órbita de Mercúrio na sua aproximação mais próxima.
Crédito: ESA

Sistemas operacionais em tempo real

Os sistemas operacionais em tempo real se fazem necessários em casos de espaçonaves como a Solar Orbiter, levando em conta a complexidade dos prazos com os quais se deve lidar. Diferente dos critérios tradicionais que conhecemos com o Windows e MacOS, neste um cálculo precisa ser feito corretamente dentro de um prazo estritamente especificado. Quando um prazo não é cumprido, a tarefa é considerada falha e encerrada.

E em voos espaciais, um prazo perdido geralmente significa que sua espaçonave já se transformou em uma bola de fogo ou se desviou para uma órbita incorreta, tornando desnecessário qualquer esforço adicional.

Em resumo, os sistemas operacionais espaciais são na maioria das vezes projetados de modo que cada tarefa seja executada dentro de um determinado número de ticks alocados. O upload de dados de sensores pode levar três ticks; quatro outros ticks são dedicados a dar partida nos motores e assim por diante. Cada tarefa possível é atribuída a uma prioridade específica, portanto, uma tarefa de prioridade mais alta pode ter precedência sobre a tarefa de prioridade mais baixa. E, dessa forma, um designer de software sabe exatamente qual tarefa será executada em qualquer cenário, assim como quanto tempo levará sua execução.

O Sistema VxWorks

No passado, em tempos da Missão Apollo, os sistemas eram desenvolvidos especificamente pra cada missão, ainda que com parte de seus códigos reutilizados, como foi o com o Skylab, por exemplo. Atualmente, a solução de sistema operacional mais utilizada pela NASA é o VxWorks. O sistema foi lançado em 1987 pela empresa norte-americana WindRiver.

O desenvolvimento exigia rapidez e o orçamento era apertado. Com o sucesso do desempenho, o VxWorks também foi selecionado para a missão posterior, a Mars Pathfinder.

Entretanto, um bug causou uma série de problemas à agência espacial. Logo após o pouso, o sistema do Pathfinder começou a reiniciar sem motivo aparente, o que atrasou a transmissão dos dados coletados de volta para a Terra. Foram necessárias 3 semanas para que o problema fosse identificado e 18 horas para que fosse finalmente solucionado.

Representação artística da missão BepiColombo, um projeto conjunto ESA / JAXA, que levará duas espaçonaves até Mercúrio.
Crédito: ESA

VxWorks VS RTEMS

Nos últimos 10 anos, o panorama dos sistemas operacionais espaciais se mostrava estável. Nos EUA, a NASA determinou a utilização do VxWorks em suas missões mais importantes. Porém, na UE, a ESA investiu no desenvolvimento do RTEMS de código aberto. O RTEMS não foi inicialmente criado para voar em naves espaciais europeias. Sua história teve início com um estudo realizado no Centro de Pesquisa, Desenvolvimento e Engenharia do Comando de Mísseis do Exército dos EUA em 1988. Os pesquisadores do Exército concluíram que o uso de sistemas operacionais proprietários em tempo real causava vários problemas.

O governo não era o proprietário do código, portanto, não poderia modificá-lo de forma alguma. Além disso, o estudo afirmava que a responsabilidade por falhas de software parecia um pouco obscura, e os RTOS daquela época eram lentos demais para sistemas de mísseis. Por todas essas razões, o Exército decidiu construir seu próprio RTOS, denominado Real-Time Executive for Missile Systems. O objetivo era fazer um RTOS que fosse rápido o suficiente para guiar mísseis, pertencente ao governo, fácil de operar em diferentes famílias de processadores e sem licença.

À medida que o RTEMS estava tomando forma, as Forças Armadas dos Estados Unidos começaram a perceber que suas possíveis aplicações iam muito além do lançamento de foguetes. Consequentemente, o nome do sistema evoluiu rapidamente para o Real-Time Executive para Sistemas Militares. E desde 4 de maio de 1995, quando o RTEMS foi lançado como código aberto, ele se tornou conhecido como Real-Time Executive for Multiprocessor Systems.

Os motivos pelos quais o sistema ganhou destaque pela Agência Europeia foram a facilidade de transporte para novas famílias de processadores e seu alto teor de personalização, permitindo maior liberdade aos programadores. A ESA estava totalmente livre para mexer no código.

RTOS em missão

Os sistemas vêm sendo utilizados por décadas e apresentando ótimo desempenho, sendo estes tão similares a ponto de ser quase impossível identificar sua diferença. A ESA utilizou o VxWorks algumas vezes, e a NASA optou por RTEMS em mais de uma ocasião. Sendo assim, os dois principais sistemas operacionais de voo funcionaram em paralelo na mesma espaçonave gerenciando instrumentos diferentes.

Todavia, em 2013 um dos desenvolvedores do bitcoin, Jeff Garzik postou uma ideia humilde no Fórum de Discussão sobre Bitcoin: que tal construir alguma resiliência de bitcoin no espaço? Esse segundo caminho, no entanto, era explorar a revolução dos nanosatélites em andamento. Garzik previu colocar um anel de microssatélites na órbita da Terra, e esses satélites poderiam ser conectados por meio de um link entre satélites que armazenaria e transmitiria os dados do blockchain.

A ideia de Garzik foi rapidamente forjada na fundação SpaceChain, e a fundação SpaceChain rapidamente se ocupou no desenvolvimento do SpaceChain OS, que deveria rodar em todos esses satélites.

A missão de longo prazo do Enlarge / SpaceChain OS foi lançado em um Falcon 9 uma vez.
Crédito: SpaceX

Crowdfunding de Naves Espaciais

O SpaceChain OS é composto por 2 componentes principais. Um RTOS típico baseado em um kernel Sylix de código aberto e uma tecnologia blockchain incluída para executar a rede da constelação. Este componente blockchain é também o que possibilita o lançamento de satélites com financiamento coletivo.

A ideia é que várias empresas, instituições ou até mesmo indivíduos possam contribuir para financiar um satélite que execute o SpaceChain OS. Enquanto a parte Sylix é responsável por operar a espaçonave da mesma forma que RTEMS ou VxWorks executa o hardware de espaçonaves modernas, o componente blockchain está lá para compartilhar os recursos da espaçonave entre vários investidores.

A SpaceChain colocou vários nós de bitcoin no espaço: em 2018 com a ajuda de um foguete CZ-4B Y34 e em 2019 na parte de trás de um foguete Falcon 9 da SpaceX. E seu trabalho tem sido intrigante o suficiente para angariar investimentos de empresas, assim como a Agência Espacial Europeia.

A resposta da Velha Guarda

O desenvolvimento de novos sistemas operacionais espaciais, embora seja empolgante, ainda sofre grande resistência com o ceticismo sobre as ideias da SpaceChain.

De todo modo, qualquer novo produto de software que a ESA queira implementar em sua espaçonave precisa passar por um longo período de testes e certificação. É por este motivo que as agências espaciais tendem a reutilizar o que já possuem, uma vez que isso encurta o processo de desenvolvimento geral.

Além disso, os sistemas operacionais espaciais antigos estão se vêm apresentando desempenho acima do esperado. Os esforços no desenvolvimento de diversos produtos de software pra esse tipo de arquitetura multiusuário em espaçonaves continuam sendo arduamente realizados.

Esta matéria é uma tradução livre do artigo original publicado na Ars Technica.

  • Post last modified:07/10/2020
  • Reading time:8 min(s) read