Espaço, a Fronteira Final dos SOs de tempo-real

O sistema operacional de tempo-real (RTOS) embarcado no satélite espacial Solar Orbiter da ESA é um primor de engenharia de software: ele foi projetado para manter a integridade da sonda, que passará os próximos anos estudando o Sol a uma distância ridícula, 10 milhões de quilômetros mais próximo do que a órbita de Mercúrio.

• Von Braun vs Korolev: um nazista e um traidor soviético na Corrida Espacial
• Como é a roupa de um astronauta?

Por estar tão próximo, o satélite conta com escudos especiais que evitem que ele frite, mas eles só estão dispostos na parte frontal; a taxa de tolerância é de um ângulo de 2,3 graus até um máximo de 6,5º, e mesmo assim por no máximo 50 segundos; esse é o tempo máximo que o RTOS tem para corrigir o ângulo antes que sonda frite, literalmente.

A parte divertida é que nenhum sistema operacional comum, seja ele Windows, macOS, Linux, iOS ou Android seria capaz de trabalhar com um tempo de reação fixo, tal qual sistemas de tempo-real, que continuarão a dominar o espaço por muito, muito tempo.

O que é um sistema de tempo-real?

Um sistema operacional de tempo-real é focado principalmente na realização de tarefas, assim como um SO comum mas diferente deste, um RTOS trabalha com prazos pré-definidos e precisa cumpri-los; em resumo, o tempo de resposta para cada evento que ele precisa resolver é fixo e ao não cumpri-lo, resulta em uma falha.

Tome como exemplo o seu celular, iPhone ou Android, não importa. Se você desliga-lo completamente e religa-lo, o cache estará novamente limpo e a tarefa de abrir 10 apps será mais demorada, em torno de 2 minutos. Feche todos e abra novamente, e graças ao cache, o tempo caiu para segundos.

Se você perguntar para Andy Rubir, criador do Android, ou para Craig Federighi, SVP de Software da Apple, o quão exatamente rápido os respectivos sistemas são, ambos não saberão responder. Há inúmeros fatores que influem no tempo de resposta dos SOs mobile, que alteram os resultados mesmo sendo sempre a mesma tarefa.

Um sistema operacional de tempo-real não pode se dar a esse luxo.

Em 2012, quando a Curiosity chegou à Marte muita gente reclamou que os sistemas da sonda não rodavam Linux, mas mesmo o pinguim não é confiável para tarefas críticas, que podem significar a perda de equipamentos de bilhões de dólares. Ademais, não há suporte em Marte ou na órbita solar, então (ainda) não dá para mandar o estagiário.

Ao mesmo tempo, os sistemas embarcados em missões de exploração são normalmente bem modestos, porque passam por averiguações, homologações, testes de estresse e etc. por anos, e o hardware é projetado para aguentar as piores intempéries possíveis, de tempestades solares a variações insanas de temperatura.

Como resultado, os dois computadores da Curiosity (um é backup) contam com um processador RAD750, uma versão à prova de radiação do PowerPC 750, que embora conte com um clock de "incríveis" 133 MHz, é capaz de rodar 400 MIPS (milhões de instruções por segundo), o que é um número bem alto para a aplicação destinada.

Some-se a isso uma EEPROM de 256 kB, 256 MB de DRAM e 2 GB de memória Flash, e temos a sonda móvel mais poderosa que já rodou em Marte. É pouco talvez para quem pensa em rodar Crysis, mas é mais do que o suficiente para fazer experimentos no solo do planeta vermelho.

Um RTOS possui em seu código o tempo de resposta específico para cada evento que precise executar, desde os rotineiros a procedimentos de emergência, e ele TEM QUE resolver cada ação dentro do prazo especificado, sem exceções; o sistema de tempo-real não pode criar lixo que influencie o tempo de execução, que deve sempre ser o mesmo, e as especificações só permitem erros catastróficos (como uma tela azul) com espaços de tempo gigantescos entre si.

No caso da Curiosity, uma vez a cada 15 anos; já a Solar Orbiter nem isso, ou vira torrada.

Da Apollo ao roteador

No passado, durante as missões Apollo, o sistema que operava as cápsulas era completamente específico, um para cada lançamento, ainda que todos seguissem as normas e diretrizes talhadas na pedra por Margaret Hamilton.

A NASA hoje não chega a tanto, preferindo contar com um sistema de tempo-real desenvolvido por uma empresa externa, no caso a Wind River: o VxWorks é um sistema de micro-kernel de código fechado lançado originalmente em 1987, está atualmente na 7ª versão e suporta diversas arquiteturas, de AMD/Intel e ARM, PowerPC e RISC-V.

Tudo o que a agência espacial norte-americana manda para o espaço roda VxWorks, principalmente por ele atender às especificações nazistas cobradas, de tempo de resposta e estabilidade.

A primeira missão espacial a usar o VxWorks foi a da sonda lunar Clementine em 1995, como uma solução experimental (ele já estava na versão 5.1), e desde então a Wind River e a NASA são boas amigas: as sondas Sojourner, Spirit e Pathfinder, a missão Deep Impact enviada para analisar o cometa 9P/Tempel, a sonda Juno mandada para Júpiter, todos rodaram ou rodam VxWorks.

A SpaceX também faz uso do sistema da Wind River em suas cápsulas Dragon, por mais que elas pareçam seguir o design interno Apple-like, porque Elon Musk pode ser meio desbocado e doido, mas não é burro de não adotar uma solução que funciona muito bem.

O telescópio James Webb também vai usar o SO, quando for lançado... um dia.

Só que o VxWorks funciona também na Terra, em uma infinidade de sistemas embarcados: aviões comerciais e de combate (Boeing 787, Airbus A400M, Northrop Grumman X-47B), sistemas automotivos, automação industrial, transporte, sistemas médicos, infraestrutura e até produtos de consumo.

O AirPort Extreme, roteador da Apple voltado para seus produtos (hoje descontinuado) rodava o VxWorks, assim como o ASIMO, o robô doméstico da Honda, e os roteadores da linha WRT54G da Linksys.

Por mais que o VxWorks seja um SO proprietário, troca-lo pelo firmware Linux DD-WRT não é o ideal, porque o usuário estará preterindo uma solução de tempo-real homologada pela principal agência espacial, por outra que sequer trabalha no mesmo nível, apenas por ser código aberto.

Isso não quer dizer que um sistema de tempo-real é imune a falhas: um bug de inversão de prioridade (onde uma tarefa de prioridade alta é sobreposta por uma mais baixa) fez com a Pathfinder entrasse em loop e boot tão logo aterrissou em Marte; levou três semanas até encontrarem o problema, e mais 18 horas para corrigi-lo.

ESA e o RTEMS

A Agência Espacial Europeia não usa o VxWorks, mas sim um sistema de tempo-real de código aberto chamado RTEMS (Real-Time Executive for Multiprocessor Systems), desenvolvido pelo Departamento de Pesquisa e Desenvolvimento do Centro de Controle de Mísseis do Exército dos Estados Unidos.

Originalmente o "M" significava "missile", visto que o RTEMS foi criado para ser o sistema operacional do sistema de navegação dos mísseis norte-americanos, mas em 1995, ele foi liberado como código aberto e renomeado, permitindo que qualquer um possa usa-lo.

A ESA adotou o RTEMS por três motivos: primeiro, por ser livre não há a necessidade de pagar por taxas de licenciamento; segundo, ele foi desenvolvido para suportar tecnologias mais recentes desde a base de seu código, o que facilita a adoção de soluções do bloco europeu, como os chips LEON de arquitetura SPARC V8 próprios para resistir a altos níveis de radiação; terceiro, o sistema em si é customizável, que o torna flexível para múltiplos usos.

Missões recentes da ESA, como a sonda lunar Artemis, a Solar Dynamic Observatory e a Solar Orbital usam o SO de código aberto, e pouca gente sabe é que a Curiosity TAMBÉM roda RTEMS, além do VxWorks. Por outro lado, a agência europeia usa o sistema fechado vez ou outra, como no satélite de monitoramento ambiental Sentinel-1, lançado em 2014.

Na prática, o VxWorks e o RTEMS são muito parecidos entre si, com a principal diferença sendo apenas que um é fechado e o outro é aberto, e ambas agências espaciais, americana e europeia, fazem uso de ambas soluções de tempo-real de acordo com a necessidade (a ESA no entanto prioriza o RTEMS, e não usa o VxWorks a anos).

Há outras soluções correndo por fora, como o SpaceChain OS, que combina um RTOS baseado em kernel Sylix com blockchain (?!), para criar uma rede de satélites lançados via financiamento coletivo, ideia de Jeff Garzik, um dos desenvolvedores originais do Bitcoin.

Hoje ele é visto com certa desconfiança (não é para menos), mas é um indício de que grupos externos ao desenvolvimento governamental estão começando a se interessar por sistemas operacionais de tempo-real, na esperança de um futuro de exploração comercial do espaço.

De qualquer forma, nossas naves definitivamente não rodarão Windows, macOS, Linux ou coisa que o valha.