Pessoal,
Há alguns dias eu estava conversando com um amigo sobre a missão Artemis e comecei a pensar sobre os desafios que os equipamentos eletrônicos enfrentam fora do campo magnético da Terra. Assim, complementando (e aprofundando) os posts em que citei os processadores utilizados nas missões robóticas da NASA (aqui e aqui), resolvi escrever este post mais amplo.
Vou deixar um índice caso queira ler algo em particular, mas recomendo ler tudo porque o texto está bem legal!
-
O Desafio da Radiação Espacial: O Inimigo Invisível dos Circuitos Eletrônicos
-
Processadores Rad-Hard: Especificações Técnicas e Arquiteturas
-
Linguagens de Programação: C/C++ versus Ada e os Critérios de Escolha
1. A Computação no Vácuo Hostil do Espaço
A exploração espacial é um dos maiores desafios da engenharia atualmente. Ao contrário dos computadores na Terra, onde falhas podem ser corrigidas por patches remotos ou manutenção presencial, os processadores e softwares presentes nas sondas espaciais operam em um ambiente implacável e inacessível. Uma falha catastrófica em um rover marciano ou em um orbitador lunar não pode ser resolvida com uma visita técnica. O custo de uma missão perdida não se mede apenas em bilhões de dólares, mas também em anos de pesquisa científica desperdiçados e oportunidades únicas de exploração perdidas para sempre.
Como já abordei em posts anteriores aqui no blog (aqui e aqui), o processador RAD750 da BAE Systems é um exemplo dessa engenharia extrema. Baseado no antigo PowerPC 750 dos iMacs G3 dos anos 1990, esse chip opera a modestos 200 MHz em um momento em que processadores comerciais alcançam 5 GHz. No entanto, enquanto um processador de smartphone moderno morreria em minutos sob radiação cósmica, o RAD750 acumula décadas de operação contínua em ambientes onde prótons energéticos, íons pesados e raios cósmicos bombardeiam incessantemente seus circuitos.
Vou tentar explicar um pouco sobre as razões técnicas, históricas e econômicas por trás das escolhas de processadores e linguagens de programação das principais agências espaciais do mundo. Por que a NASA continua usando PowerPC enquanto a Europa prefere SPARC? Por que Ada persiste na ESA quando C e C++ dominam na NASA? Quais são os custos reais de desenvolvimento e os compromissos de performance versus confiabilidade? Como a radiação espacial destrói circuitos eletrônicos e quais tecnologias de hardware e software existem para mitigar esses efeitos? E qual é o futuro dessa computação extrema com a chegada de arquiteturas abertas como RISC-V e linguagens modernas como Rust?
Em um curtíssimo resumo, a escolha de um processador rad-hard ou de uma linguagem safety-critical é ditada por física brutal, matemática de confiabilidade e análise de custo-benefício rigorosa. Cada decisão carrega o peso de missões bilionárias e a responsabilidade de expandir o conhecimento humano sobre o universo.
2. O Desafio da Radiação Espacial
2.1. Tipos de Radiação e Seus Efeitos Devastadores
O espaço, ao contrário do que a maioria das pessos pensa, não é um vácuo inerte. É um ambiente cheio de partículas energéticas e radiação eletromagnética que interagem e destroem semicondutores. A radiação espacial pode ser classificada em três categorias principais, cada uma delas com mecanismos de dano distintos.
A primeira é a Total Ionizing Dose (TID) ou dose ionizante total acumulada. Elétrons aprisionados nos cinturões de radiação de Van Allen, prótons solares e raios gama depositam carga elétrica nas camadas isolantes de óxido dos transistores MOS (Metal-Oxide-Semiconductor). Com o tempo, essas cargas aprisionadas alteram as características elétricas dos dispositivos.

Em transistores MOSFET, por exemplo, o acúmulo de carga positiva no óxido de porta reduz a tensão de limiar, aumenta correntes de fuga e degrada a mobilidade dos portadores (carriers). Estudos mostram que doses acima de 100 krad(Si) são suficientes para causar falhas funcionais em chips comerciais COTS (Commercial Off-The-Shelf). Processadores rad-hard como o RAD750 são projetados para suportar até 1 Mrad(Si), mil vezes mais que um chip comum. Para colocar em contexto: uma radiografia de tórax entrega cerca de 0,1 mrad ao paciente!!! Ou seja, para danificar um chip comercial, seria necessários de 50 a 100 milhões de RX e para danificar o RAD750 é necessário algo próximo a 10 bilhões de RX!!!
Aqui cabe uma explicação um pouco mais detalhada: 50 milhões de radiografias num chip comum parece muito, mas no espaço a dose acumula de forma contínua e ao longo de anos. Em órbita baixa terrestre (LEO, onde fica a ISS), um chip comum recebe o equivalente a esse total em poucas semanas de exposição dependendo da altitude e da atividade solar. O RAD750 aguenta 200 vezes mais que um chip comum. Em termos práticos, isso significa que ele sobrevive a missões de 10 a 20 anos em ambientes de radiação intensa, como a órbita de Júpiter (onde o Juno opera), que é substancialmente mais hostil que LEO.
Vale mais um adendo: o número de 0,1 mrad por radiografia é a dose absorvida pelo paciente como média do corpo inteiro. A dose na pele e nos tecidos diretamente expostos é maior. Para o chip, o que conta é a dose absorvida diretamente no silício, então a analogia com o RX é ilustrativa, não um cálculo rigoroso de engenharia.
O segundo fenômeno é o Displacement Damage (DD) ou dano por deslocamento atômico. Prótons de alta energia e nêutrons colidem com átomos de silício na rede cristalina do semicondutor, deslocando-os de suas posições e criando defeitos estruturais permanentes. Esse tipo de dano afeta especialmente dispositivos optoeletrônicos (componentes que convertem luz em sinal elétrico ou sinal elétrico em luz) como células solares, fotodetectores e CCDs (Charge-Coupled Devices). Em painéis solares, o DD reduz a eficiência de conversão fotovoltaica ao longo dos anos, exigindo superdimensionamento inicial da capacidade energética. A sonda Voyager 2, lançada em 1977, ainda opera com seus geradores termoelétricos de radioisótopos (RTGs, mais detalhes aqui também!) precisamente porque painéis solares degradariam além da viabilidade após quase 50 anos de exposição.
O terceiro e mais imprevisível são os Single Event Effects (SEE) ou efeitos de evento único. Uma única partícula de alta energia, como um íon pesado de ferro (gerado em explosões de supernovas, pulsares, magnetares, núcleos ativos de galáxias ou fusões de estrelas de nêutrons) pode depositar energia suficiente ao atravessar um transistor para ionizar trilhões de átomos ao longo de seu caminho. Isso resulta em vários subtipos de falhas. O Single Event Upset (SEU) inverte o estado lógico de um bit em memória ou flip-flop, transformando um zero em um sem dano físico permanente. A taxa de SEU é medida em upsets por bit-dia. O RAD750 tem uma taxa de aproximadamente 10-11 upsets/bit-dia em órbita baixa terrestre, enquanto chips comerciais podem sofrer taxas 1000 vezes maiores (10-11 upsets/bit-dia correspondem em um sistema com 256MB de RAM a 0,02 upsets/dia, em média, ou 1 bit corrompido a cada 50 dias; chips comerciais tem, em média, para os mesmos 256MB de RAM, 20 upsets/dia ou 1 bit corrompido a cada 72 minutos!). O Single Event Latchup (SEL) é mais grave: cria um caminho de baixa impedância entre alimentação e terra, similar a um curto-circuito, que pode queimar o dispositivo se não for rapidamente interrompido por circuitos de proteção. O Single Event Burnout (SEB) e o Single Event Gate Rupture (SEGR) causam dano permanente em transistores de potência e óxidos de porta, respectivamente. Assim, o SEU pode ser corrigido por software e o SEL pode ser corrigido por reset de alimentação. O SEB e SEGR geram danos físicos irrecuperávies e devem ser tratados ainda na fase de projeto, escolhendo criteriosamente os componentes e com margens de tensão bem conservadoras.
Exemplos históricos ilustram esses perigos. Em 1997, a sonda Cassini-Huygens sofreu múltiplos SEUs durante a passagem pelos cinturões de Van Allen terrestres, exigindo resets automáticos do sistema de navegação. A missão russa Phobos-Grunt de 2011 falhou após o lançamento devido a SEE em chips não adequadamente protegidos contra radiação, causando reboots infinitos que impediram a ignição dos motores para deixar a órbita terrestre (a investigação russa apontou a falha do software possivelmente como SEE, mas nunca confirmou oficialmente). A Mars Climate Orbiter da NASA em 1999 foi perdida por erro de software (confusão entre unidades métricas e imperiais), mas especulaçoes sobre SEUs intermitentes em sistemas de navegação ganharam força para justificar alguns desvios de trajetória não corrigidos adequadamente.
2.2. Mitigação por Hardware: Processos e Tecnologias de Endurecimento
A mitigação de radiação começa no nível mais fundamental: o design e a fabricação do silício. Processadores rad-hard empregam múltiplas técnicas especializadas que aumentam drasticamente os custos de produção mas são essenciais para sobrevivência espacial.
A primeira técnica é o uso de processos de fabricação especializados. A maioria dos chips rad-hard é fabricada em processos de Silicon-On-Insulator (SOI), onde uma fina camada de óxido de silício isola o silício ativo da base do wafer. Isso reduz a coleta de carga durante eventos únicos porque os transistores são fisicamente isolados do substrato, diminuindo a probabilidade de latchup. Além disso, os nós de fabricação são intencionalmente antigos. Enquanto processadores comerciais modernos usam processos de 3 nm ou 5 nm, chips rad-hard são fabricados em 150 nm, 180 nm ou até 250 nm. Transistores maiores têm volume ativo maior, o que significa que a mesma quantidade de carga depositada por uma partícula representa uma perturbação percentual menor, reduzindo a sensibilidade a SEUs.
A segunda técnica é o Triple Modular Redundancy (TMR), ou redundância modular tripla. A lógica crítica é replicada três vezes, e um circuito votador determina a saída correta por maioria e, na prática, é constituído por 4 portões NAND (Not AND gate).

Se um módulo sofre um SEU e produz resultado errado, os outros dois módulos votam para corrigi-lo. Essa redundância pode ser representada pela tabela booleana abaixo:

O RAD750 implementa TMR extensivamente em registradores, unidades aritméticas e controladores de cache. O custo é aumento de área de silício (até 3x em algumas seções) e consumo de energia, mas a confiabilidade resultante justifica o trade-off.
A terceira técnica é o uso de Error Detection and Correction (EDAC) em memórias. Códigos de Hamming ou códigos BCH (Bose-Chaudhuri-Hocquenghem) adicionam bits de paridade que permitem detectar e corrigir erros de 1 ou 2 bits por palavra. Memórias SRAM (Static RAM) rad-hard geralmente têm EDAC embutido. Memórias DRAM são evitadas em missões críticas devido à maior sensibilidade a SEE. O GR740 da ESA implementa EDAC em todos os níveis de cache e memória principal, reduzindo a taxa de erros não corrigidos para valores desprezíveis.
A quarta abordagem é o shielding passivo, ou blindagem física. Camadas de alumínio, tântalo ou polietileno absorvem parte da radiação antes que ela atinja os chips. No entanto, shielding tem retornos decrescentes: adicionar 10 mm de alumínio pode reduzir TID em 50%, mas cada milímetro extra aumenta massa significativamente, o que é crítico em missões espaciais onde cada quilograma custa milhares de dólares para lançar. Além disso, shielding contra íons pesados é menos eficaz porque partículas de alta energia penetram facilmente materiais leves.
A quinta técnica envolve design de layout cuidadoso. Guard rings (anéis de guarda) ao redor de transistores críticos coletam carga induzida por radiação antes que ela atinja regiões ativas. Interdigitação de fontes e drenos em transistores de potência reduz a probabilidade de latchup. Espaçamento aumentado entre trilhas reduz a chance de múltiplas células serem afetadas por uma única partícula.
Essas técnicas explicam por que o desenvolvimento de um processador rad-hard leva de 5 a 10 anos e custa centenas de milhões de dólares. O RAD750 foi desenvolvido ao longo da década de 1990 pela IBM e BAE Systems, com financiamento do Departamento de Defesa dos EUA inicialmente focado em aplicações nucleares e militares. Testes rigorosos em aceleradores de partículas, como o síncroton do Brookhaven National Laboratory, simulam décadas de exposição à radiação espacial em semanas. Cada lote de wafers é testado para SEU rate, TID tolerance e latchup threshold antes da certificação final.

2.3. Mitigação por Software: Redundância, EDAC e Estratégias de Resiliência
Enquanto o hardware fornece a primeira linha de defesa, o software implementa a segunda camada de proteção. Isso é essencial porque nenhum hardware é completamente imune a erros.
A estratégia mais comum é o memory scrubbing, ou varredura de memória. Rotinas periódicas leem todas as posições de memória, verificam bits de EDAC e corrigem erros detectados, reescrevendo os dados corretos. Isso impede acumulação de erros não corrigidos (MBUs, Multiple Bit Upsets) que poderiam ultrapassar a capacidade de correção do EDAC. No rover Perseverance, o software executa scrubbing completo da memória principal a cada poucos minutos, dependendo do nível de atividade solar e radiação ambiental.
A segunda técnica é o uso de watchdog timers e health monitoring. Watchdog timers são contadores que devem ser resetados periodicamente pelo software principal. Se o software trava devido a um SEU, o watchdog expira e força um reset do processador, restaurando o sistema a um estado conhecido. Sistemas críticos como o GR740 da ESA têm múltiplos níveis de watchdogs independentes, implementados em hardware separado do processador principal.

A terceira abordagem é redundância de processadores. Missões como Perseverance usam dois computadores RAD750 operando em paralelo, um como primário e outro como backup. Comparação periódica de resultados detecta divergências causadas por SEUs. Se o primário falha, o backup assume automaticamente. O custo é duplicação de hardware, mas a confiabilidade resultante reduz drasticamente o risco de perda de missão.
A quarta técnica é checksums e validação de dados. Dados críticos, como comandos de navegação e parâmetros de ciência, são protegidos por checksums CRC (Cyclic Redundancy Check) ou hashes criptográficos. Antes de executar um comando crítico, o software verifica a integridade dos dados. Se detecta corrupção, descarta o comando e solicita retransmissão da Terra ou usa dados de backup.
A quinta estratégia envolve safe modes e fault recovery. Se o sistema detecta anomalias persistentes, entra em modo seguro onde desliga instrumentos não essenciais, orienta painéis solares para o Sol, aponta antena para a Terra e aguarda comandos. Esse comportamento autônomo salvou inúmeras missões. A sonda New Horizons entrou em modo seguro dias antes do sobrevoo de Plutão em 2015 devido a um SEU, mas a equipe na Terra conseguiu restaurá-la a tempo.
A sexta técnica é o uso de linguagens e frameworks safety-critical. Como falarei mais pra frente, Ada e subsets restritos de C/C++ (como MISRA C) reduzem a probabilidade de bugs de software que poderiam ser agravados por radiação. Além disso, sistemas operacionais real-time (RTOS) como VxWorks (usado pela NASA) ou RTEMS (usado pela ESA) fornecem scheduling determinístico (o agendador de tarefas é desenhado para garantir que determinada tarefa aconteça dentro do planejamento previsto; por exemplo, garante que o software que lê o sensor de atitude rode precisamente rode a cada 10 ms ou que o software que calcula correção de trajetória rode exatamente a cada 100 ms) e isolamento de falhas entre tarefas.
A combinação de hardware rad-hard e software defensivo resulta em sistemas com confiabilidade extraordinária. O RAD750, por exemplo, acumulou mais de 100 anos cumulativos de operação em órbita sem uma única falha catastrófica atribuída a radiação. Essa é a razão pela qual agências espaciais pagam centenas de milhares de dólares por processador e investem anos no desenvolvimento de software crítico: a alternativa é perder missões de bilhões.
3. Processadores Rad-Hard: Especificações Técnicas e Arquiteturas
3.1. BAE RAD750: O Veterano Indestrutível da NASA
O RAD750 da BAE Systems é o processador rad-hard mais utilizado em missões espaciais americanas nas últimas duas décadas. Baseado no PowerPC 750 da IBM, arquitetura RISC de 32 bits lançada comercialmente em 1997 para o iMac G3, o RAD750 foi desenvolvido especificamente para ambientes de alta radiação. O desenvolvimento começou no final dos anos 1990 como sucessor do RAD6000 (baseado no IBM RISC System/6000) e o primeiro voo ocorreu em 2005, na missão Mars Reconnaissance Orbiter.

Especificações técnicas do RAD750 incluem clock de 110 MHz a 200 MHz (versões mais recentes alcançam até 466 MHz em variantes turbo), performance de 266 MIPS a 400 MIPS dependendo da configuração, e 10,4 milhões de transistores fabricados em processo de 150 nm ou 250 nm SOI (Silicon-On-Insulator). O chip possui cache L1 de 32 KB (16 KB para instruções, 16 KB para dados), suporte para cache L2 externa de até 2 MB, e barramento de 64 bits operando a 66 MHz ou 133 MHz. A arquitetura PowerPC inclui unidade de ponto flutuante IEEE 754 integrada, essencial para cálculos científicos de precisão.
A tolerância à radiação é impressionante: TID (Total Ionizing Dose) de até 1 Mrad(Si) para versões full rad-hard, o que significa que o chip pode acumular um milhão de rads de radiação ionizante antes de falhar. A taxa de SEU (Single Event Upset) é de aproximadamente 10-11 upsets por bit-dia em órbita baixa terrestre (LEO), cerca de mil vezes menor que chips comerciais equivalentes. O SEL (Single Event Latchup) threshold é superior a 117 MeV·cm²/mg, garantindo imunidade a latchup para praticamente todas as partículas encontradas no espaço interplanetário.
O consumo energético varia de 5 W a 10 W dependendo do clock e da atividade, operando em faixa de temperatura de -55°C a +70°C (algumas versões alcançam +125°C). A alimentação é tolerante a variações, aceitando 3,3 V ± 5% ou 5 V ± 5%. O package é cerâmico de 352 pinos (CCGA, Ceramic Column Grid Array), oferecendo robustez mecânica e dissipação térmica adequada.
Missões que utilizam o RAD750 incluem Mars Reconnaissance Orbiter (2005), Phoenix Mars Lander (2007), Mars Science Laboratory Curiosity (2011), InSight Mars Lander (2018), Mars 2020 Perseverance (2020), Juno (Júpiter, 2011), e partes do James Webb Space Telescope (JWST, 2021). No Curiosity e Perseverance, dois RAD750 operam em redundância para navegação autônoma, processamento de imagens da câmera de engenharia, controle do braço robótico e análise espectroscópica de amostras geológicas.

O custo de um RAD750 é estimado em US$ 200.000 a US$ 350.000 por unidade, dependendo do volume de compra e configuração. Esse preço reflete não apenas o hardware, mas também suporte técnico vitalício, documentação completa de design (essencial para certificação de missão), e garantias de fornecimento a longo prazo. O desenvolvimento total do RAD750 custou bilhões de dólares ao longo de uma década, financiado conjuntamente pelo Departamento de Defesa dos EUA, NASA e contratos comerciais.
3.2. CAES/Gaisler GR740: A Alternativa Europeia Multi-Core
A Europa, através da ESA (European Space Agency), desenvolveu sua própria família de processadores rad-hard para reduzir dependência tecnológica de fornecedores americanos. O GR740, fabricado pela Cobham Gaisler (agora CAES – Cobham Advanced Electronic Solutions, subsidiária da sueca CAES Group), é um processador quad-core baseado na arquitetura SPARC V8, escolhida por ser open-source e livre de royalties restritivos.

O GR740 utiliza quatro núcleos LEON4FT, uma implementação fault-tolerant da arquitetura SPARC V8 de 32 bits desenvolvida especificamente para aplicações espaciais. Cada núcleo opera a até 250 MHz, com pipeline de 7 estágios e suporte a instruções SPARC V8, incluindo multiplicação e divisão em hardware. A performance combinada é de aproximadamente 1.700 DMIPS (Dhrystone MIPS), com cada núcleo entregando cerca de 425 DMIPS. O chip possui 32 KB de cache L1 por núcleo (16 KB instruções, 16 KB dados) e até 4 MB de cache L2 compartilhado, ambos protegidos por EDAC (Error Detection and Correction).
A arquitetura multi-core do GR740 é projetada para fault-tolerance: os núcleos podem operar de forma independente ou em lockstep (sincronizados, comparando resultados para detectar erros). Além dos processadores, o chip integra periféricos essenciais como interfaces SpaceWire (rede serial padrão para comunicação espacial), Ethernet Gigabit, controladores CAN (Controller Area Network), interfaces UART, SPI e I2C, reduzindo a necessidade de chips externos e simplificando o design de sistemas.
A tolerância à radiação do GR740 é robusta: TID de mais de 300 krad(Si) para o die completo, com alguns blocos tolerando até 1 Mrad(Si). A taxa de SEU é extremamente baixa devido ao design fault-tolerant, com EDAC capaz de corrigir até 2 bits de erro por palavra em memórias. O latchup immunity é garantido por design, com guard rings e isolamento SOI. O processo de fabricação é 65 nm CMOS, mais moderno que o RAD750, oferecendo melhor eficiência energética.
O consumo energético do GR740 varia de 1,5 W (idle) a 5 W (full load), notavelmente inferior ao RAD750 apesar da performance multi-core. A faixa de temperatura operacional é de -55°C a +125°C, e a alimentação nominal é 1,5 V (core) e 3,3 V (I/O). O package é cerâmico de 576 pinos (CCGA).
Missões que utilizam o GR740 incluem JUICE (Jupiter Icy Moons Explorer, lançado em 2023), BepiColombo (missão a Mercúrio, 2018), ExoMars Rosalind Franklin rover (lançamento previsto para 2028), Hera (missão de defesa planetária, 2024), e múltiplos satélites de observação da Terra da ESA. No JUICE, o GR740 gerencia navegação autônoma durante os 8 anos de viagem até Júpiter, processamento de imagens científicas e controle de instrumentos em um ambiente de radiação extremo.
O custo estimado do GR740 é de US$ 100.000 a US$ 250.000 por unidade, ligeiramente inferior ao RAD750 devido à fabricação europeia e ausência de royalties de IP (Intellectual Property) da arquitetura SPARC, que é open-source desde que a Sun Microsystems liberou as especificações. O desenvolvimento foi financiado pela ESA ao longo de uma década, com investimentos totais estimados em centenas de milhões de euros.
3.3. BAE RAD5545 e o Futuro Próximo
O RAD5545, também da BAE Systems, representa a próxima geração de processadores rad-hard da NASA. Lançado comercialmente em 2017, o RAD5545 é um quad-core baseado no PowerPC e5500, arquitetura de 64 bits com performance significativamente superior ao RAD750.
Especificações incluem quatro núcleos operando a até 466 MHz, cada um com performance de aproximadamente 1.398 DMIPS, totalizando cerca de 5.592 DMIPS no chip completo, mais de 10 vezes a performance do RAD750 single-core. Cada núcleo possui cache L1 de 64 KB (32 KB instruções, 32 KB dados) e cache L2 privado de 512 KB, com cache L3 compartilhado de até 2 MB. A arquitetura e5500 suporta instruções AltiVec (SIMD, Single Instruction Multiple Data), úteis para processamento de imagens e operações vetoriais.
A tolerância à radiação é comparável ao RAD750: TID superior a 1 Mrad(Si) e taxa de SEU inferior a 2×10-9 upsets/bit-dia. O processo de fabricação é 45 nm SOI, mais moderno, oferecendo maior densidade de transistores e eficiência energética. O consumo é de aproximadamente 20 W em carga máxima, maior que o RAD750, mas justificável pela performance multiplicada.
Missões planejadas incluem componentes do programa Artemis (retorno à Lua), Gateway (estação orbital lunar), e futuros rovers marcianos. O RAD5545 é especialmente adequado para aplicações que exigem processamento intensivo, como navegação visual autônoma, SLAM (Simultaneous Localization and Mapping), e análise científica em tempo real.
O custo estimado é superior a US$ 500.000 por unidade, refletindo a complexidade adicional e menor volume de produção até o momento.
3.4. Comparação Técnica Detalhada
Para facilitar a comparação, apresento uma tabela consolidada dos principais processadores rad-hard discutidos:
Tabela 1: Comparação de Processadores Rad-Hard (2026)
|
Especificação |
RAD750 |
GR740 |
RAD5545 |
|---|---|---|---|
|
Arquitetura |
PowerPC 750 (RISC 32-bit) |
LEON4FT / SPARC V8 (RISC 32-bit) |
PowerPC e5500 (RISC 64-bit) |
|
Núcleos |
1 |
4 (fault-tolerant) |
4 |
|
Clock Máximo |
200-466 MHz |
250 MHz |
466 MHz |
|
Performance Total |
266-400 MIPS |
~1.700 DMIPS |
~5.592 DMIPS |
|
Cache L1 |
32 KB |
32 KB por núcleo |
64 KB por núcleo |
|
Cache L2 |
Até 2 MB (externa) |
Até 4 MB (integrada) |
512 KB por núcleo + 2 MB L3 |
|
Processo de Fabricação |
150-250 nm SOI |
65 nm CMOS |
45 nm SOI |
|
TID Tolerance |
Até 1 Mrad(Si) |
>300 krad(Si) |
>1 Mrad(Si) |
|
SEU Rate |
~10-11 upsets/bit-dia |
Muito baixa (FT) |
<2×10-9 upsets/bit-dia |
|
Consumo Energético |
5-10 W |
1,5-5 W |
~20 W |
|
Temperatura Operacional |
-55°C a +70°C |
-55°C a +125°C |
-55°C a +125°C |
|
Missões Principais |
Curiosity, Perseverance, Juno, JWST |
JUICE, BepiColombo, ExoMars |
Artemis, Gateway (futuro) |
|
Custo Estimado (US$) |
200.000 – 350.000 |
100.000 – 250.000 |
>500.000 |
|
Ano de Introdução |
2001 (primeiro voo 2005) |
~2015 |
2017 |
A escolha entre esses processadores depende dos requisitos específicos da missão. Para missões com restrições severas de energia, como sondas alimentadas por RTGs distantes do Sol, o GR740 é vantajoso pelo baixo consumo. Para missões que exigem processamento intensivo, como rovers autônomos que devem analisar terreno e planejar rotas sem assistência terrestre devido a delays de comunicação de minutos, o RAD5545 oferece performance necessária. Para missões onde confiabilidade comprovada é prioritária e performance moderada é suficiente, o RAD750 continua sendo a escolha segura, com mais de duas décadas de histórico de voo bem-sucedido.
4. Linguagens de Programação: C/C++ versus Ada e os Critérios de Escolha
A escolha de linguagem de programação para o software de voo (software embarcado que controla a sonda) é tão crítica quanto a escolha do processador. Uma linguagem inadequada pode introduzir bugs difíceis de detectar, aumentar custos de desenvolvimento e certificação, ou resultar em performance insuficiente. As duas linguagens dominantes em missões espaciais são C/C++ e Ada, cada uma com vantagens e desvantagens pragmáticas.
4.1. C e C++: Performance e Controle Absoluto
C, desenvolvida por Dennis Ritchie na Bell Labs entre 1969 e 1973, é uma linguagem procedural de baixo nível que oferece controle direto sobre hardware e memória. C++ é uma extensão orientada a objetos de C, criada por Bjarne Stroustrup em 1985. Ambas são linguagens compiladas que produzem código de máquina altamente eficiente, essencial em ambientes com recursos computacionais limitados.
A NASA adotou C e C++ como linguagens primárias para flight software nas últimas décadas. O rover Curiosity, por exemplo, tem mais de 2,5 milhões de linhas de código C/C++ controlando navegação, instrumentos científicos e comunicação. A escolha de C/C++ é motivada por vários fatores técnicos. Primeiro, performance: C gera código muito próximo ao assembly, com overhead mínimo de runtime. Operações críticas como leitura de sensores, cálculo de trajetórias e controle de atuadores exigem execução determinística em tempo real, o que C oferece naturalmente. Segundo, controle de memória: C permite gerenciamento manual de memória através de ponteiros, essential em sistemas embarcados com RAM escassa (o RAD750 em missões típicas opera com 128 MB a 256 MB de DRAM). Terceiro, portabilidade: compiladores C/C++ maduros existem para virtualmente todas as arquiteturas de processadores, incluindo PowerPC e SPARC. Quarto, ecossistema: bibliotecas, ferramentas de debug e sistemas operacionais real-time como VxWorks têm suporte robusto para C/C++.
Um adendo sobre o VxWorks: é um sistema Real-Time OS (RTOS), projetato em 1987 para garantir que tarefas críticas sejam executadas dentro de prazos determinísticos rígidos. O sistema é um microkernel com arquitetura modular, onde o kernel central é pequeno e faz apenas o essencial (scheduling, gerenciamento de memória básico e comunicação entre tarefas), sendo as funcionalidades adicionais (drivers, protocolos de rede, sistemas de arquivos) carregadas como módulos separados. A latência de interrupção do VxWorks é abaixo de 10 microssegundos, ou seja, quando um sensor gera um sinal de interrupção, o software começa a processar esse sinal em menos de 10 µs. Licenças custam dezenas a centenas de milhares de dólares dependendo da configuração.
A NASA desenvolveu o Core Flight System (cFS), um framework open-source em C para reutilização de software entre missões. O cFS fornece abstrações para comunicação inter-processos, gerenciamento de comandos e telemetria, e scheduling de tarefas, reduzindo o esforço de desenvolvimento de novas missões. Missões como Van Allen Probes, LADEE, Global Precipitation Measurement e Orion utilizam cFS.
No entanto, C e C++ têm desvantagens significativas em sistemas safety-critical. A primeira é a fraqueza de tipagem e verificação: C permite conversões implícitas de tipos que podem esconder bugs, e o compilador aceita código inseguro sem avisos. Por exemplo, C não verifica bounds de arrays automaticamente, permitindo buffer overflows que podem corromper memória e causar crashes. Segundo, undefined behavior (UB): o padrão C tem centenas de casos onde o comportamento do código é indefinido (por exemplo, dereferencing null pointers, signed integer overflow, acesso a memória liberada), e diferentes compiladores podem gerar resultados imprevisíveis. Terceiro, gerenciamento manual de memória é propenso a erros: memory leaks (vazamentos), dangling pointers (ponteiros para memória liberada) e use-after-free são bugs comuns que podem ser catastróficos em sistemas espaciais.
Para mitigar esses riscos, a NASA impõe subsets restritos de C/C++ através de padrões como MISRA C (Motor Industry Software Reliability Association C) e as Power of 10 Rules. MISRA C:2012, por exemplo, define 143 regras e 16 diretivas que proíbem construções perigosas de C, como goto, recursion, dynamic memory allocation (malloc/free), e uso de ponteiros de função. As Power of 10 Rules, criadas por Gerard Holzmann do Jet Propulsion Laboratory (JPL), incluem restrições adicionais: loops devem ter bounds fixos e verificáveis, funções não devem exceder 60 linhas, uso de assertions em todas as condições críticas, e zero warnings de compilação. Essas regras são verificadas por ferramentas de análise estática como Polyspace, Coverity e PC-lint, que custam dezenas a centenas de milhares de dólares por licença.
Apesar dessas mitigações, o desenvolvimento em C/C++ para missões espaciais exige disciplina extrema e testes exaustivos. O custo total de desenvolvimento de software para o Curiosity foi estimado em mais de US$ 100 milhões, incluindo design, implementação, testes de unidade, integração, testes de sistema em hardware-in-the-loop, e simulações de missão completa.
4.2. Ada: Segurança em Tempo de Compilação
Ada é uma linguagem projetada explicitamente para sistemas safety-critical, desenvolvida entre 1977 e 1983 sob contrato do Departamento de Defesa dos EUA para unificar as centenas de linguagens usadas em sistemas militares. O nome honra Ada Lovelace, pioneira da computação do século XIX. Ada foi padronizada pela ANSI/MIL-STD-1815 e ISO (ISO/IEC 8652) e passou por revisões em 1995 (Ada 95), 2005 (Ada 2005), 2012 (Ada 2012) e 2022 (Ada 2022).
<span class="kn">with</span> <span class="n">Ada.Text_IO</span><span class="p">;</span> <span class="kn">use</span> <span class="n">Ada.Text_IO</span><span class="p">;</span>
<span class="kd">procedure</span> <span class="nf">Hello</span> <span class="kr">is</span>
<span class="kr">begin</span>
<span class="n">Put_Line</span> <span class="p">(</span><span class="s">"Hello, world!"</span><span class="p">);</span>
<span class="kr">end</span><span class="p">;</span>
A ESA adotou Ada como linguagem primária para flight software em missões críticas. A sonda Rosetta, que orbitou o cometa 67P/Churyumov-Gerasimenko entre 2014 e 2016, utilizou Ada extensivamente. Mars Express, BepiColombo, JUICE e o rover ExoMars também empregam Ada.
A escolha é justificada pelas características de segurança intrínsecas da linguagem. Ada possui tipagem forte e estática: o compilador verifica rigorosamente tipos de dados e não permite conversões implícitas inseguras. Por exemplo, se uma função espera um inteiro no range 0..100, passar um valor fora desse range causa erro de compilação ou, se detectado em runtime, uma exceção controlada (não um crash silencioso). Arrays têm bounds checking automático: tentar acessar um elemento fora dos limites de um array levanta uma exceção imediatamente, evitando buffer overflows. Essas verificações podem ser desabilitadas em código otimizado após validação, mas por padrão fornecem rede de segurança essencial.
Ada suporta programação concorrente nativa através de tasks e protected objects. Tasks são threads gerenciadas pela runtime da linguagem, com sintaxe clara para sincronização e comunicação. Protected objects garantem acesso mutuamente exclusivo a dados compartilhados sem deadlocks acidentais. O Ravenscar Profile é um subset de Ada projetado para sistemas real-time determinísticos, restringindo features não-determinísticas como dinamic task creation e select statements, garantindo comportamento previsível em tempo de execução.
Ada também suporta Design by Contract através de pré-condições e pós-condições: contratos especificam formalmente o que uma função espera na entrada e garante na saída, verificáveis em compile-time ou runtime. Isso documenta implicitamente o código e facilita verificação formal.
SPARK é um subset de Ada desenvolvido pela AdaCore e Altran (agora Capgemini) especificamente para verificação formal. SPARK restringe features de Ada que dificultam prova matemática (como acesso dinâmico a memória e exceções arbitrárias) e adiciona anotações para especificar propriedades como ausência de overflow, ausência de race conditions, e correção funcional. Ferramentas como o SPARK prover podem provar matematicamente que um programa SPARK está livre de certos tipos de erros, um nível de garantia impossível com testes convencionais. Missões críticas da ESA usam SPARK para componentes ultra-críticos, como sistemas de controle de atitude e engines de propulsão.
Desvantagens de Ada incluem curva de aprendizado mais íngreme devido à sintaxe verbosa e conceitos avançados como generics e tasking. O pool de desenvolvedores Ada é menor que C/C++: enquanto milhões de programadores conhecem C, apenas dezenas de milhares dominam Ada. Isso aumenta custos de contratação e treinamento. Além disso, o ecossistema de bibliotecas é menor, embora suficiente para aplicações espaciais. Ferramentas de desenvolvimento Ada comerciais, como GNAT Pro da AdaCore, são caras (licenças custam dezenas de milhares de dólares anuais), mas versões open-source gratuitas (FSF GNAT) existem.
Estudos comparativos de custo-benefício mostram que Ada reduz significativamente bugs de software. Um estudo da NASA nos anos 1990 comparando projetos Ada e C/C++ encontrou que projetos Ada tinham 60-90% menos bugs por linha de código em testes finais. Outro estudo europeu (GNAT Pro case studies) indicou que o custo total de ciclo de vida de software safety-critical em Ada é 20-40% menor que em C/C++ devido a menos tempo gasto em debug e rework. No entanto, o desenvolvimento inicial pode ser ligeiramente mais lento devido à curva de aprendizado.
4.3. Comparação Pragmática: Vantagens, Desvantagens e Custos
A tabela abaixo resume as diferenças pragmáticas entre C/C++ e Ada para flight software espacial:
Tabela 2: Comparação C/C++ versus Ada para Flight Software
|
Critério |
C / C++ |
Ada (incluindo SPARK) |
Vantagem |
|---|---|---|---|
|
Segurança de Tipos e Memória |
Fraca: permite ponteiros selvagens, overflows, conversões inseguras. Depende de disciplina do programador e ferramentas externas (MISRA, analyzers). |
Forte: bounds checking automático, range constraints, type safety rigorosa. Verificação em compile-time previne muitos bugs. |
Ada (reduz 70-90% de bugs comuns) |
|
Prevenção de Erros Concorrentes |
Threads via POSIX/std::thread propensos a race conditions, deadlocks. Exige expertise e ferramentas de detecção. |
Tasks e protected objects nativos, Ravenscar profile para determinismo. Menos propenso a erros. |
Ada |
|
Certificação e Provabilidade Formal |
Difícil e caro. Muitos undefined behaviors. Exige subsets como MISRA e ferramentas caras (Polyspace). |
Fácil conformidade DO-178C nível A. SPARK permite provas formais de correção. |
Ada (menor custo de qualificação) |
|
Performance Bruta |
Excelente. Código próximo a assembly, zero overhead de runtime (sem checks por padrão). |
Boa. Checks podem adicionar 5-15% overhead (desligáveis após validação). |
C/C++ (leve vantagem) |
|
Controle de Hardware |
Direto. Acesso a registradores, I/O mapeado em memória, inline assembly. |
Bom. Ada tem representação clauses para controle preciso de layout de dados e acesso a hardware. |
C/C++ (mais natural) |
|
Ecossistema e Ferramentas |
Gigantesco. GCC, Clang, LLVM, IDEs abundantes, bibliotecas imensas. |
Menor. GNAT Pro (comercial) e FSF GNAT (gratuito). Bibliotecas suficientes mas não abundantes. |
C/C++ |
|
Disponibilidade de Desenvolvedores |
Altíssima. Milhões de desenvolvedores. Custo de contratação baixo. |
Baixa. Dezenas de milhares. Custo de contratação e treinamento alto. |
C/C++ |
|
Custo Inicial de Desenvolvimento |
Menor. Prototipagem rápida. |
Maior. Curva de aprendizado e desenvolvimento inicial mais lento. |
C/C++ |
|
Custo Total de Ciclo de Vida |
Maior em projetos safety-critical devido a bugs, debug, testes extensivos, e rework. |
Menor em long-duration missions devido a menos bugs e manutenção mais fácil. Estudos indicam 20-40% economia. |
Ada (em missões longas) |
|
Exemplos de Missões |
Curiosity, Perseverance, Van Allen Probes, JWST (partes), New Horizons. |
Rosetta, Mars Express, JUICE, BepiColombo, ExoMars, Ariane 5/6 (lançadores). |
Empate (preferências regionais) |
É interessante saber que a escolha entre C/C++ e Ada não é puramente técnica, mas também cultural e histórica. Nos Estados Unidos, a herança do DoD e NASA favoreceu C/C++ após o mandato Ada ser relaxado em 1997, quando a indústria reclamou de custos e falta de flexibilidade. A explosão do ecossistema C/C++ nos anos 2000 (Linux, frameworks open-source) consolidou a posição. Na Europa, a ESA manteve investimentos em Ada porque prioriza independência tecnológica, redução de riscos em missões de bilhões de euros com orçamentos menores que a NASA, e conformidade com padrões safety-critical rigorosos. Além disso, empresas europeias como Airbus e Thales mantêm expertise em Ada herdada da aviação civil (Airbus A320, A380 usam Ada em fly-by-wire systems).
5. Razões das Escolhas por Agência Espacial
5.1. NASA (Estados Unidos): PowerPC, C/C++ e a Herança do DoD
A NASA, com orçamento anual de aproximadamente US$ 25 bilhões, é a maior agência espacial do mundo. Suas escolhas tecnológicas são influenciadas por herança militar, ecossistema de contractors e priorização de performance.
A escolha do PowerPC como arquitetura de processador remonta aos anos 1990, quando a aliança Apple-IBM-Motorola (AIM Alliance) desenvolveu PowerPC como alternativa RISC ao x86 da Intel. O DoD (Departamento de Defesa) já utilizava processadores RISC rad-hard da IBM em sistemas militares e a NASA herdou essa experiência. Quando o RAD6000 (baseado no IBM RISC System/6000) provou confiabilidade em missões como Mars Pathfinder (lançamento em 1996 e pouso em 1997), a transição para o RAD750 (PowerPC 750) foi natural. O PowerPC oferece arquitetura RISC simples e limpa, facilitando aplicação de técnicas de hardening como TMR. Além disso, a IBM licenciou a arquitetura para BAE Systems com termos favoráveis, permitindo customização para aplicações espaciais sem royalties proibitivos.

A escolha de C/C++ é pragmática. Nos anos 2000, quando missões como Mars Exploration Rovers (Spirit e Opportunity) foram desenvolvidas, o ecossistema C/C++ estava maduro com compiladores otimizados (GCC, Wind River Compiler), RTOSs robustos (VxWorks) e pool gigantesco de desenvolvedores. O JPL (Jet Propulsion Laboratory), principal centro de missões robóticas da NASA, adotou C/C++ com subsets restritos (Power of 10 Rules, MISRA C) e ferramentas de análise estática para mitigar riscos. O custo de contratar engenheiros C/C++ é menor que Ada, e a velocidade de prototipagem é maior, importante em um ambiente de desenvolvimento ágil onde requisitos mudam frequentemente durante a fase de design.
Além disso, a NASA desenvolveu o Core Flight System (cFS) em C, um framework modular e reutilizável para flight software. O cFS abstrai funcionalidades comuns como gerenciamento de comandos/telemetria, agendamento de tarefas e comunicação com o ground segment, permitindo que missões reutilizem código testado. Isso reduz custos e riscos. Mais de 20 missões NASA e comerciais usam cFS, incluindo satélites científicos, demos de tecnologia e veículos tripulados como Orion.
Missões futuras, como Artemis (retorno humano à Lua) e Mars Sample Return, continuarão usando PowerPC (RAD5545) e C/C++ por consistência com infraestrutura existente e expertise acumulada. A NASA está experimentando com Rust (falaremos mais pra frente), mas mudanças radicais são improváveis no curto prazo devido ao custo de requalificação de software e hardware.
5.2. ESA (Europa): SPARC, Ada e Independência Tecnológica
A ESA, com orçamento anual de aproximadamente €7 bilhões (cerca de US$ 7,5 bilhões), representa 22 estados membros europeus. Suas escolhas refletem prioridades de independência tecnológica, custos compartilhados entre múltiplos países, e conformidade rigorosa com padrões safety-critical.
A escolha de SPARC como arquitetura de processador foi estratégica. Nos anos 1990, quando a ESA iniciou desenvolvimento de processadores rad-hard, SPARC era uma arquitetura aberta (Sun Microsystems liberou as especificações sob licenças permissivas), eliminando dependência de fornecedores únicos. O LEON, desenvolvido pela Gaisler Research na Suécia sob contrato ESA, é uma implementação open-source SPARC V8 projetada desde o início para aplicações espaciais. Ser open-source significa que a ESA e contractors europeus podem customizar o design, auditar segurança e fabricar localmente sem royalties ou restrições de exportação. Isso é crítico para soberania tecnológica europeia: Europa não quer depender de chips americanos sujeitos a controles ITAR (International Traffic in Arms Regulations).
O GR740 exemplifica essa filosofia. Desenvolvido na Europa, fabricado por empresas (STMicroelectronics, empresa ítalo-francesa) e documentado publicamente, ele garante que missões europeias não sejam interrompidas por decisões políticas ou comerciais externas. Além disso, o design multi-core fault-tolerant do GR740 oferece confiabilidade comparável ao RAD750 a custo potencialmente menor devido à ausência de royalties de IP.
A escolha de Ada é igualmente estratégica. A ESA adotou Ada nos anos 1980 para sistemas de controle de lançadores Ariane e nunca abandonou. A razão é dupla: primeiro, missões europeias tendem a ser long-duration (JUICE levará 8 anos para alcançar Júpiter), exigindo software altamente confiável que minimize necessidade de patches complexos após lançamento. Ada reduz bugs desde a fase de design, diminuindo custos de testes e rework. Segundo, conformidade com padrões: a indústria aeroespacial europeia (Airbus, Thales, OHB) usa Ada em aviação civil (fly-by-wire de A320, A380, A350) e sistemas militares, criando pool de expertise reutilizável entre setores. Essa sinergia reduz custos de treinamento.
Além disso, a ESA financia ativamente desenvolvimento de ferramentas Ada. A AdaCore, empresa franco-americana que desenvolve GNAT Pro (compilador Ada comercial) e ferramentas SPARK, recebe contratos ESA para melhorias específicas de espaço, como suporte para Ravenscar profile em RTOSs espaciais (RTEMS, um RTOS open-source usado pela ESA, tem suporte Ada robusto). Assim, a escolha do RTEMS sobre o VxWorks reflete a mesma lógica da escolha entre GR740 e RAD750: a NASA prefere solução comercial com suporte garantido por contrato e a ESA prefere solução aberta com controle total sobre o código.
Missões emblemáticas como Rosetta ilustram o sucesso dessa abordagem. Rosetta operou por mais de 12 anos (10 anos de cruzeiro + 2 anos orbitando o cometa), grande parte do tempo em modo autônomo devido a delays de comunicação de dezenas de minutos. O software Ada controlou navegação complexa, pouso do lander Philae no cometa, e operação de 11 instrumentos científicos sem falhas críticas.
A ESA continua investindo em LEON e Ada para missões futuras, incluindo a missão Lunar Gateway (parceria internacional), missões de observação da Terra e demonstradores de tecnologia como o rover autônomo ExoMars.
5.3. JAXA (Japão): Pragmatismo e Autonomia Avançada
A JAXA (Japan Aerospace Exploration Agency), com orçamento anual de aproximadamente ¥260 bilhões (cerca de US$ 2 bilhões), combina pragmatismo tecnológico com inovação em autonomia avançada. Suas escolhas refletem balanço entre confiabilidade comprovada e desenvolvimento de capacidades únicas.
Historicamente, o Japão dependia de processadores rad-hard americanos (RAD750) e europeus (LEON) devido ao alto custo de desenvolver chips proprietários. No entanto, missões como Hayabusa (2003) e Hayabusa2 (2014), que coletaram amostras de asteroides e retornaram à Terra, demonstraram expertise japonesa em navegação autônoma e sistemas de controle robustos. O Hayabusa2, por exemplo, navegou autonomamente até o asteroide Ryugu, mapeou sua superfície com precisão de centímetros, executou múltiplos pousos de rovers e coletor de amostras e retornou à Terra em 2020, tudo isso com processadores de performance modesta (provavelmente RAD750 ou equivalentes) operando software C/C++ altamente otimizado.
A JAXA adota C/C++ como linguagem primária, similarmente à NASA, por razões de ecossistema e expertise disponível na indústria japonesa (Mitsubishi Electric, NEC, Toshiba). No entanto, a JAXA também integra componentes FPGA (Field-Programmable Gate Arrays) rad-hard para operações críticas de tempo real, como processamento de sensores LiDAR e controle de atitude. FPGAs oferecem paralelismo massivo e determinismo absoluto, complementando processadores de propósito geral.
Missões recentes como SLIM (Smart Lander for Investigating Moon, 2023), que realizou pouso lunar de precisão com tecnologia de “face recognition” para identificar crateras e ajustar trajetória autonomamente em tempo real, demonstram sofisticação de software e hardware. Embora detalhes técnicos sejam escassos publicamente (JAXA é menos aberta que NASA/ESA), é provável que SLIM utilize processadores rad-tolerant baseados em ARM ou PowerPC, possivelmente desenvolvidos domesticamente com assistência de fornecedores como Renesas Electronics (fabricante japonês de microcontroladores).
A escolha estratégica da JAXA é investir em software avançado (IA onboard, visão computacional) rodando em hardware internacional provado, enquanto desenvolve gradualmente capacidades domésticas de processadores para reduzir dependência externa. Missões como MMX (Martian Moons eXploration, prevista para 2026) e colaborações internacionais (como Gateway) continuarão essa abordagem híbrida.
5.4. Roscosmos (Rússia): Legado Soviético e Transição para C/C++
A Roscosmos, agência espacial russa com orçamento estimado entre US$ 2-3 bilhões (dados são imprecisos devido à democracia linda do tio Putin), trabalha sob legado tecnológico soviético, porém está em transição para padrões internacionais.
Durante a era soviética, missões como Venera (pousos em Vênus) e Luna (amostras lunares) usavam processadores customizados baseados em arquiteturas BESM (Bolshaya Elektronno-Schetnaya Mashina – БЭСМ – literalmente “Grande Máquina Eletro-Computacional”), desenvolvidos pelo Instituto de Precisão de Mecânica e Técnica Computacional (ITMiVT) de Moscou, liderado pelo engenheiro Sergei Lebedev, que é para a computação soviética o equivalente a Von Neumann nos EUA. O software era escrito em assembly e Fortran, com subsets restritos adaptados para embarcados. Confiabilidade era alcançada através de redundância massiva (tripla ou quádrupla) e design conservador.
O BESM-6, lançado em 1968, representou o pico dessa trajetória: clock de 10 MHz, pipeline de 14 estágios, 1 MFLOPS de performance, sendo o último computador soviético tecnicamente comparável a um equivalente ocidental, o CDC 6600 de Seymour Cray (2-3 MFLOPS). Produzidos até 1987, essa série de computadores deixou de ser desenvolvida por uma decisão “estratégica” do governo de copiar a arquitetura IBM System/360 criando a família ES EVM (EYedinaya sistema electronnykh vytchislitel’nykh mashin – ЕС ЭВМ ou Sistema Unificado de Máquina Eletro-Computacional) para aproveitar o software americano existente e poupar recursos. Só que os ES-EVM nunca alcançaram eficiência para cálculos científicos. Quando os EUA restringiram exportação de chips e tecnologia na década de 1970, os clones soviéticos ficaram permanentemente atrás da geração que copiavam. Brilhante ideia dos russos!!!
Cabe ressaltar que esses não eram computadores embarcados, mas computadores de centros de controle na Terra.

O hardware embarcado nas sondas Luna e Venera não usava derivados BESM. Adotava processadores proprietários simples baseados em transistores e circuitos integrados de primeira geração, com performance estimada em dezenas de milhares de operações por segundo, confiabilidade alcançada por triplicação de componentes críticos ao invés de sofisticação de hardware. Nesse ponto específico, o AGC (Apollo Guidance Computer) americano de 1969 era tecnicamente comparável: 40.000 instruções por segundo em 4 KB de RAM, porque ambos os lados eram limitados pelo mesmo fator físico, massa lançável pelo foguete, não pela capacidade industrial de cada país.
Após o colapso soviético, a Roscosmos enfrentou grandes restrições orçamentárias. Missões modernas como Luna-25 (2023, primeira missão lunar russa pós-soviética, falhou durante descida) e colaborações com ESA (ExoMars) utilizam processadores europeus (LEON) e, possivelmente, processadores russos modernos desenvolvidos por empresas como JSC NIIET (fabricante de microeletrônicos rad-hard russos). Modernos é modo de dizer, é claro, pois os chips da NIIET são fabricados em processos de 350 nm a 500 nm, duas a três gerações atrás do RAD750 (150 nm) e quatro gerações atrás do GR740 (65 nm), resultando em performance menor e consumo energético maior por operação.
A linguagem de programação transicionou para C/C++, alinhando-se com padrões internacionais para facilitar colaborações (a Rússia participa da ISS e de missões conjuntas ESA). No entanto, documentação pública é escassa devido à cultura de sigilo herdada da era soviética. Missões recentes falharam (Phobos-Grunt em 2011, Luna-25 em 2023), sugerindo desafios em qualidade de hardware e software, possivelmente por cortes orçamentários e sanções internacionais que limitam acesso aos componentes mais modernos e avançados.
Espera-se que missões futuras (Luna-26 orbital, Luna-27 lander, Venera-D para Vênus) continuem usando LEON europeu ou desenvolvam processadores domésticos baseados em arquiteturas russas (Elbrus, MCST), mas prazos são incertos devido a instabilidade política e econômica.
5.5. CNSA (China): Desenvolvimento Interno e Soberania Tecnológica
A CNSA (China National Space Administration), com orçamento estimado entre US$ 10-12 bilhões (mais uma vez, com dados oficiais limitados para salvar a democracia chinesa…), está rapidamente alcançando líderes tradicionais através de investimentos massivos e desenvolvimento de capacidades domésticas.
As missões lunares Chang’e (Chang’e-4 foi a primeira a pousar no lado oculto da Lua em 2019, Chang’e-5 retornou amostras em 2020, Chang’e-6 coletou amostras do lado oculto em 2024) e marciana Tianwen-1 (orbiter, lander e rover Zhurong em Marte desde 2021) indicam progresso tecnológica impressionante. A China prioriza soberania tecnológica, desenvolvendo processadores rad-hard domesticamente para evitar dependência de fornecedores ocidentais e potenciais sanções.
Detalhes técnicos públicos são limitados, pois a CNSA publica muito menos que NASA/ESA, mas evidências indiretas sugerem que a China usa processadores customizados baseados em arquiteturas PowerPC ou ARM, fabricados pelo CETC (China Electronics Technology Group) ou institutos militares ligados ao CASC. O rover Zhurong (um clone (?) dos gêmeos Spirit e Opportunity) operou em Marte por aproximadamente 358 sols (cerca de 12 meses terrestres) antes de entrar em hibernação em maio de 2022, demonstrando confiabilidade de hardware e software rad-hard em ambiente planetário real. Com base no desempenho demonstrado pelo Tianwen-1 e pela Tiangong, e considerando o investimento chinês em IA embarcada para aplicações terrestres e militares, analistas ocidentais especulam sobre capacidades multi-core e aceleração de inferência em hardware espacial futuro, mas sem evidência técnica pública que permita comparação direta com o RAD5545 ou equivalentes ocidentais.
A linguagem de programação é predominantemente C/C++, padrão global para computadores embarcados, possivelmente com subsets inspirados em MISRA C. A China também investe em RTOSs próprios, como o SpaceOS, ainda que com pouca documentação publicada, desenvolvido para missões espaciais, embora versões baseadas em VxWorks licenciado também sejam usadas.
A estratégia chinesa é de missões frequentes (Chang’e-1 a Chang’e-7 em menos de 20 anos) que permitem aprendizado e refinamento de tecnologia. Ao contrário dos países democráticos, onde as missões demoram anos de planejamento pois devem funcionar perfeitamente, já que o custo de falha é politicamente inaceitável, a CNSA aceita riscos maiores em troca de aprendizado mais rápido.
A China opera atualmente a estação espacial Tiangong com tripulação rotativa desde 2022, com cerca de um terço do tamanho da ISS. No horizonte estão missões lunares tripuladas planejadas para 2030 e uma missão de retorno de amostras de Marte, para a qual o Tianwen-3 está em desenvolvimento.
5.6. ISRO (Índia): Eficiência com Recursos Limitados
A ISRO (Indian Space Research Organisation), com orçamento anual de aproximadamente US$ 1,5 bilhão, ficou famosa por alcançar resultados notáveis com custos extremamente baixos. Missões como Chandrayaan-3 (pouso lunar bem-sucedido em 2023 no polo sul lunar) e Mangalyaan (Mars Orbiter Mission, primeira missão marciana indiana, 2013) custaram frações do que missões equivalentes NASA/ESA custariam. Entretanto, o nível de transparência da ISRO é ainda menor que o da CNSA.
A ISRO utiliza processadores rad-tolerant desenvolvidos pelo URSC (UR Rao Satellite Centre) ou versões de chips COTS (Commercial-Off-The-Shelf, chips produzidos em massa para o mercado comercial, oferecendo alto desempenho e baixo custo em comparação a soluções personalizadas) mitigados por shielding e redundância de software. O Chandrayaan-3 (2023), com custo de aproximadamente US$ 75 milhões, demonstra a viabilidade da abordagem indiana de máxima eficiência de recursos: pouso lunar bem-sucedido com hardware possivelmente baseado em arquiteturas ARM ou SPARC adaptadas, mas cujas especificações exatas a ISRO não divulga publicamente. Com a missão, a Índia tornou-se o quarto país a pousar na Lua e o primeiro a pousar próximo ao polo sul lunar, validando as escolhas de hardware e software independentemente dos detalhes técnicos não divulgados.
A linguagem de programação primária é C/C++, com ênfase em otimização agressiva para maximizar performance em hardware modesto. A ISRO também usa Ada em componentes críticos de lançadores (GSLV, Geosynchronous Satellite Launch Vehicle), herdado de colaborações com Europa.
A filosofia da ISRO é “frugal engineering” (engenharia frugal): atingir objetivos científicos com orçamentos mínimos através de design eficiente, reutilização de componentes, e aceitação calculada de riscos. Por exemplo, a missão Mangalyaan custou US$ 74 milhões, menos que o orçamento do filme “Gravity”. Isso é possível através de salários domésticos baixos, fornecedores indianos competitivos, e simplificação de requisitos (a missão Mangalyaan tinha menos instrumentos que missões NASA, mas cumpriu seus objetivos principais).
Missões futuras incluem Chandrayaan-4 (retorno de amostras lunares), Gaganyaan (primeiro voo tripulado indiano), e Aditya-L1 (observatório solar). A ISRO continuará balançando custo e confiabilidade, desenvolvendo gradualmente processadores mais avançados enquanto mantém vantagem competitiva de eficiência.
5.7. ISA (Israel): Inovação em Miniaturização
A ISA (Israel Space Agency), com orçamento modesto de aproximadamente US$ 70-100 milhões, foca em missões altamente especializadas e em tecnologias de miniaturização. Israel tem forte indústria de defesa e tech (empresas como Israel Aerospace Industries, Rafael, Elbit), que desenvolvem componentes rad-hard para satélites militares e comerciais.
A missão Beresheet (2019), lander lunar desenvolvido pela organização sem fins lucrativos SpaceIL com apoio da ISA, custou apenas US$ 100 milhões mas falhou no pouso devido a falha de sensores e software. No entanto, a missão demonstrou capacidade israelense de desenvolver sistemas espaciais miniaturizados com orçamentos limitados. Beresheet usava processadores rad-tolerant (possivelmente baseados em ARM COTS com mitigação) e software C/C++.
Missões futuras como Beresheet 2 (prevista inicialmente para 2025 mas atualmente suspensa) continuarão essa abordagem. Israel também participa de missões internacionais (instrumentos em satélites NASA/ESA) e desenvolve satélites de observação militar (Ofek series) com tecnologia avançada de processamento de imagens.
A contribuição de Israel é menos em desenvolvimento de processadores rad-hard de propósito geral (custos proibitivos para país pequeno) e mais em sensores avançados, software de IA, e miniaturização extrema, áreas onde expertise militar transfere-se para aplicações espaciais.

6. O Futuro da Computação Espacial: RISC-V, HPSC e Rust
6.1. Por Que RISC-V Está Ganhando Tração
RISC-V é uma arquitetura de conjunto de instruções (ISA, Instruction Set Architecture) aberta e livre de royalties, desenvolvida na Universidade da Califórnia, Berkeley, a partir de 2010. Diferentemente de PowerPC, SPARC, ARM ou x86, RISC-V é completamente open-source: qualquer pessoa pode implementar processadores RISC-V sem pagar licenças ou enfrentar restrições de uso.
Para missões espaciais, RISC-V oferece vantagens significativas. Primeiro, customização: agências podem adicionar instruções especializadas para suas necessidades específicas (por exemplo, instruções para criptografia, processamento de sinais, ou IA) sem negociar com proprietários de IP. Segundo, independência: países preocupados com soberania tecnológica (Europa, China, Índia) podem desenvolver processadores RISC-V domesticamente sem risco de sanções ou restrições de exportação. Terceiro, custo: eliminação de royalties reduz despesas de desenvolvimento.
A ESA já está investindo em processadores RISC-V rad-hard. O projeto NOEL-V, continuação do LEON mas baseado em RISC-V ao invés de SPARC, visa desenvolver processadores multi-core RISC-V para missões futuras. A China também está desenvolvendo processadores RISC-V para espaço, alinhados com iniciativas nacionais de adoção de RISC-V em todas as áreas (computadores, smartphones, data centers).
Desafios incluem imaturidade do ecossistema, já que ferramentas de desenvolvimento, bibliotecas e RTOSs para RISC-V ainda estão em evolução comparado a PowerPC ou ARM. No entanto, o progresso é rápido, e espera-se que até 2030 processadores RISC-V rad-hard sejam comuns em missões espaciais.
6.2. NASA HPSC: Performance Radical para Inteligência Artificial
O HPSC (High-Performance Spaceflight Computing) é um programa da NASA para desenvolver a próxima geração de processadores rad-hard, visando performance 100 vezes superior ao RAD750 para suportar aplicações de inteligência artificial, processamento de imagens em tempo real, e autonomia avançada.
O HPSC será fabricado pela Microchip Technology, baseado em uma combinação de núcleos RISC-V de propósito geral e possivelmente com aceleradores matriciais. Especificações preliminares incluem 8 a 10 núcleos operando a ~1 GHz, performance estimada em 28.000 DMIPS e suporte para operações vetoriais e matriciais essenciais para redes neurais. O chip será fabricado em processo de 12 nm ou mais moderno, com técnicas rad-hard avançadas.
O HPSC permitirá rovers marcianos analisarem imagens geológicas onboard para identificar rochas de interesse sem aguardar comandos da Terra (delays de 4-20 minutos dependendo da distância Marte-Terra), navegação visual complexa em terreno desconhecido, e análise espectroscópica em tempo real. Missões a Júpiter ou Saturno, onde delays de comunicação são de horas, se beneficiarão enormemente de autonomia baseada em IA.
O primeiro voo do HPSC está previsto para o final da década de 2020 em missões de demonstração tecnológica, com adoção mais ampla esperada na década de 2030. Candidatas naturais incluem missões a luas geladas do sistema solar externo, como eventual lander em Europa ou missão a Enceladus, onde a capacidade de processamento onboard para análise de dados científicos em tempo real justifica o hardware mais avançado. O Mars Sample Return foi citado como candidato, mas o programa está em reavaliação arquitetural pela NASA desde 2024 devido a restrições orçamentárias, com novo cronograma ainda indefinido.
6.3. Rust: Segurança de Memória sem Garbage Collection
Rust (veja mais aqui) é uma linguagem de programação moderna criada em 2006 por Graydon Hoare e mantida pela Rust Foundation (fundada em 2021 com membros como Google, Microsoft e Amazon).
O objetivo da linguagem é resolver um problema antigo de C e C++: o programador é responsável por alocar e liberar memória manualmente; erros nessa gestão são a fonte de uma classe enorme de bugs e vulnerabilidades de segurança. Um ponteiro apontando para memória já liberada, acesso além do limite de um array, duas threads modificando o mesmo dado simultaneamente sem sincronização: esses erros em C normalmente só aparecem em produção, às vezes anos depois do código ser escrito, às vezes de forma não reproduzível em testes.
Rust resolve isso não em runtime (como Java ou Python, que usam um garbage collector para monitorar memória continuamente), mas em compile-time: o compilador analisa o código e recusa compilar se detectar qualquer padrão que possa causar esses erros. O programa simplesmente não compila se houver risco de acesso inválido à memória. O resultado é que erros que seriam bugs em produção em C tornam-se erros de compilação em Rust, sem pagar o custo de performance que garbage collectors cobram em runtime.
A comparação com Ada, frequente na literatura técnica, tem um limite preciso: Rust oferece garantias de segurança de memória automáticas em compile-time comparáveis a Ada básico, com performance equivalente a C. No entanto, Rust não possui o ferramental de verificação formal que SPARK/Ada oferece: em Ada com SPARK e GNATprove, é possível provar matematicamente que uma função está correta para qualquer entrada possível. Rust previne uma classe importante de erros, mas não oferece esse nível de prova formal, o que é relevante para certificação em padrões como DO-178C nível A.
O Goddard Space Flight Center da NASA publicou experimentos com Rust em componentes não-críticos, disponíveis no repositório público da NASA no GitHub. Alguns dos desafios para adoção aeroespacial são a integração com RTOSs certificados como VxWorks e a qualificação do compilador rustc para DO-178C (em andamento). A curva de aprendizado também é importante, pois exige mudança de mentalidade considerável para programadores vindos de C/C++.
Se Rust superar essas barreiras de certificação, poderá tornar-se linguagem relevante para novas missões na década de 2030, especialmente em sistemas onde segurança de memória é crítica mas verificação formal completa não é exigida. A adoção no setor espacial privado existe, mas com detalhes de implementação não divulgados publicamente pelas empresas.
7. As Lições de Engenharia para Ambientes Extremos
A computação espacial revela princípios fundamentais de engenharia: em ambientes extremos, confiabilidade supera performance bruta, validação exaustiva supera inovação arriscada e pragmatismo supera idealismo.
Processadores como o RAD750, apesar de “lentos” comparados a chips modernos, acumulam décadas de operação sem falhas porque foram projetados para o ambiente espacial desde o início.
Linguagens de programação seguem lógica parecida: Ada persiste na Europa não por inércia, mas porque reduz custos totais de ciclo de vida em missões de longa duração. C/C++ domina nos EUA não por ser superior tecnicamente, mas porque o ecossistema e expertise acumulada compensam riscos.
As escolhas das agências refletem não apenas capacidades técnicas, mas também contextos geopolíticos e econômicos: NASA prioriza performance e ecossistema devido a orçamento maior e indústria robusta; ESA prioriza independência e segurança devido a colaborações multinacionais e orçamento menor; China e Índia balançam soberania tecnológica com eficiência de custos.
O futuro promete convergência com o uso do RISC-V (que pode unificar arquiteturas de processadores),do Rust (que pode combinar segurança e performance em linguagens) e IA onboard via HPSC (que pode revolucionar autonomia de missões). No entanto, a lição permanente é que mudanças em sistemas safety-critical são lentas e deliberadas. O RAD750 continuará voando por mais uma década, e Ada não desaparecerá enquanto missões de 30 anos como JUICE ainda estiverem em desenvolvimento (a ESA quer evitar algo como a da NASA tendo que procurar, em 2015, programadores de FORTRAN, COBOL e Assembly para as missões Voyager 1 e 2!).
Para aqueles de nós que acompanharam a evolução da computação terrestre, de Windows 98 rodando em Pentium II a smartphones com trilhões de operações por segundo, a computação espacial é um lembrete humilde: o progresso não é sempre linear e às vezes a melhor tecnologia é a que simplesmente funciona, ano após ano, em silêncio, a bilhões de quilômetros de distância, expandindo nossa compreensão do universo.
Este é mais daqueles posts pra mim, para matar minha curiosidade em algo específico. Espero que tenham gostado!
Por enquanto é isso!
