- O computador de voo da nave lunar tripulada Orion tem uma arquitetura com resiliência e capacidade de controle automático muito superiores aos sistemas da era Apollo, gerenciando diretamente todas as funções críticas, como suporte à vida, energia e comunicações
- Para operar sem interrupções mesmo a 250 mil milhas de distância em órbita lunar, ele foi projetado para suportar falhas de hardware e efeitos da radiação por meio de redundância física e lógica, além de múltiplos computadores de voo
- Cada Flight Control Module (FCM) é composto por um par de processadores com verificação mútua, totalizando 8 CPUs executando em paralelo, com design fail-silent e algoritmo de seleção de saída baseado em prioridade para isolar erros
- O sistema mantém sincronização completa por meio de Ethernet com disparo temporal e arquitetura determinística, e corrige automaticamente até erros de um único bit com rede e memória triplicadas
- Caso todos os sistemas principais falhem, um Backup Flight Software baseado em hardware e sistema operacional independentes assume o controle, e essa estrutura é vista como um futuro modelo de resiliência always-on para sistemas autônomos
Projeto do computador tolerante a falhas da Artemis II da NASA
- O computador de voo da Artemis II tem uma estrutura com resiliência e capacidade de controle automático muito superiores ao computador de navegação da era Apollo
- O computador da Apollo usava um processador de 1 MHz e cerca de 4 KB de memória, e os controles principais eram baseados em chaves manuais ou relés
- Na cápsula Orion da Artemis II, o computador gerencia diretamente todas as funções críticas, como suporte à vida, energia e comunicações
- Como uma falha de missão a 250 mil milhas de distância em órbita lunar seria irrecuperável, o sistema precisa continuar funcionando sem interrupções mesmo diante de radiação espacial, bit flips e falhas de hardware
- A NASA se preparou para erros de hardware com cabeamento fisicamente redundante, planos de rede logicamente redundantes e múltiplos computadores de voo
-
The Power of Eight
- A Orion adotou uma arquitetura que vai além da redundância tripla (triple redundancy)
- Cada um dos dois Vehicle Management Computer (VMC) leva dois Flight Control Module (FCM), totalizando 4 FCMs
- Cada FCM é formado por um par de processadores com autoverificação (self-checking), somando 8 CPUs executando o software de voo em paralelo
- O sistema é baseado em um design fail-silent, no qual uma CPU com erro não envia saídas incorretas e passa imediatamente ao estado de silêncio
- Em vez de votação por maioria, usa-se um algoritmo de seleção de fonte baseado em prioridade para escolher a saída de um canal saudável
- A NASA prevê erros temporários durante a travessia dos cinturões de radiação de Van Allen e estima que a missão pode continuar com o último FCM mesmo após perder 3 FCMs por até 22 segundos
- Um FCM em estado de silêncio pode ser reiniciado e, depois, ressincronizado com os demais módulos para voltar a participar durante o voo
- A Orion adotou uma arquitetura que vai além da redundância tripla (triple redundancy)
-
Mantendo operação determinística
- Para manter vários computadores independentes em sincronização total (lockstep), foi aplicada uma arquitetura determinística (deterministic architecture)
- A Orion usa uma rede de Ethernet com disparo temporal (time-triggered Ethernet) para distribuir o tempo por todo o sistema
- O software de voo é executado dentro de um major frame e de minor frames gerenciados pelo escalonador ARINC653
- A divisão de tempo e espaço garante que entradas e saídas fiquem perfeitamente alinhadas com a agenda da rede
- Cada FCM recebe as mesmas entradas, executa o mesmo código e gera as mesmas saídas
- A cada segundo, o desvio de clock dos FCMs é medido e recalibrado com base no tempo de referência da rede
- Aplicações que não cumprem o prazo (deadline) entram automaticamente em estado de silêncio e depois são ressincronizadas
- O hardware usa memória com redundância modular tripla (TMR) para corrigir automaticamente erros de um único bit, e as placas de interface de rede também comparam caminhos de tráfego duplos para aplicar fail-silent em caso de erro
- A rede é triplicada em três planos independentes, e todos os switches têm capacidade de autoverificação
-
Sistema final de backup
- A NASA também se preparou para uma falha de modo comum (common mode failure) que possa afetar simultaneamente todos os canais principais
- Para isso, embarcou separadamente um sistema de Backup Flight Software (BFS)
- O BFS é composto por hardware diferente, outro sistema operacional e um software de voo simplificado desenvolvido de forma independente
- Se o sistema principal falhar, o BFS assume automaticamente o controle e pode concluir as fases dinâmicas da missão
- Depois disso, a tripulação pode tentar recuperar os FCMs principais
- A lógica fail-silent é essencial, mas, para evitar que erros permaneçam sem detecção, ela deve ser acompanhada por watchdogs e monitoramento em múltiplas camadas
- O sistema também foi projetado para sobreviver até mesmo a uma perda total de energia (dead bus)
- Quando a energia é restaurada, ele entra automaticamente em modo seguro (safe mode)
- Os painéis solares são orientados para o Sol para recuperar energia e, em seguida, a nave é posicionada com a cauda voltada para o Sol para estabilização térmica
- Depois, tenta restabelecer a comunicação com a Terra e, se necessário, a tripulação pode ajustar manualmente os dispositivos de suporte à vida
-
O futuro da confiabilidade
- A mudança da Apollo para a Artemis representa um salto enorme na complexidade do software
- Na Apollo havia backups mecânicos, mas na Artemis todo o controle é feito por software
- A NASA usa um fluxo moderno de verificação que inclui simulações de ambiente completo, testes de estresse Monte Carlo e injeção de falhas (fault injection) em larga escala
- Com supercomputadores, ela simula toda a linha do tempo do voo e verifica se o software consegue se recuperar em modo fail-silent mesmo em cenários de falha de hardware
- A arquitetura de tolerância zero da Orion é vista como um modelo de resiliência always-on que poderá ser aplicado no futuro também a carros autônomos e redes de controle industrial
- A mudança da Apollo para a Artemis representa um salto enorme na complexidade do software
1 comentários
Comentários do Hacker News
Trabalhei na Stratus de 1989 a 1995 com VOS e desempenho de banco de dados
A Stratus era uma empresa de sistemas tolerantes a falhas (fault-tolerant) baseados em hardware, enquanto a concorrente Tandem seguia uma abordagem baseada em software
A arquitetura da Stratus era de “pair and spare”, com todas as placas duplicadas e comparação da saída de cada pino a cada tick
Quando fizeram a transição de Motorola 68K para Intel, a equipe de hardware teve grande dificuldade porque alguns pinos não usados de certas instruções ficavam flutuando
Achei marcante a frase do pesquisador da CMU de que “Agile e DevOps enfraqueceram a disciplina arquitetural”
Parece que hoje esquecemos como construir sistemas determinísticos
O agendamento rígido de frames do Time-triggered Ethernet parece um mundo totalmente diferente do desenvolvimento de software atual
Algumas práticas modernas de desenvolvimento, como testes unitários e CI, ainda têm impacto positivo nesse tipo de ambiente
Hoje, com a mudança para um mercado mais voltado ao setor comercial, os investimentos diminuíram, mas ainda há muitos algoritmos interessantes
Vale consultar as pesquisas de Frank Mueller e Johann Blieberger
Em ambientes com entradas e saídas limitadas, como aeronaves, o projeto determinístico se encaixa perfeitamente
Na prática, está mais para um barramento de hardware dedicado do que para Ethernet
Ao ver o desafio de ‘radiation hardening’ do Code Golf,
fiquei me perguntando se esse tipo de abordagem teria utilidade real
Na prática, isso deve ser difícil por causa da quantidade de camadas de problema envolvidas, mas ainda assim acho uma ideia interessante
O projeto “fail-silent” descrito no artigo foi interessante
Mas fiquei pensando como detectariam o caso em que as duas CPUs fazem o mesmo cálculo errado ao mesmo tempo e produzem o mesmo resultado
A chance de ambas produzirem o mesmo erro ao mesmo tempo é muito menor do que o FIT de uma única CPU
Mesmo assim, no espaço a Lei de Murphy vale, então não dá para garantir
um “voto majoritário de 25%” ainda poderia selecionar o resultado errado
Tenho curiosidade sobre detalhes concretos como CPU, RAM, SO e linguagem desse sistema
Também gostaria de saber com que frequência o FCM entrava em modo “fail-silent”
Normalmente roda sobre FreeRTOS ou RTEMS
Pessoalmente, achei a estrutura do projeto complicada demais e difícil de lidar
A maior parte do código central da NASA não é pública, mas o cFS é um bom material para aprender projetos clássicos de software de voo
O artigo não entra em detalhes sobre o RTOS e a arquitetura reais
O controle principal de voo do Orion é uma estrutura quádrupla redundante baseada em Green Hills INTEGRITY RTOS e processadores BAE RAD750
O BFS roda em hardware completamente diferente, LEON3 + VxWorks, e usa o framework cFS da NASA
Trata-se de uma arquitetura modular reutilizável também usada no telescópio James Webb e nos Mars Rovers
Essa estrutura não é simplesmente “sistema principal + backup”, mas o conceito de redundância dissimilar (dissimilar redundancy)
Mais detalhes podem ser vistos no documento técnico da NASA 1 e no documento 2
A fabricação real foi feita pela Lockheed Martin e subcontratadas
Quando a imprensa escreve como se a NASA tivesse construído tudo diretamente, isso gera mal-entendidos
Quando eu trabalhava como desenvolvedor web, há 25 anos, perguntei a um amigo ex-NASA como eles lidavam com bugs
Ele riu e respondeu: “não havia bugs”
Os desenvolvedores de hoje estão acostumados a ambientes em que falhas não colocam vidas humanas em risco
Num serviço web, o prejuízo é perda de receita; numa nave espacial, o que está em jogo são vidas humanas
Já trabalhei no desenvolvimento de um computador resistente à radiação,
e além da simples redundância usamos também técnicas não redundantes de detecção de erros
Fiquei um pouco decepcionado por não ver esse tipo de abordagem neste sistema
também havia endurecimento físico para dispersar a seção de choque de radiação
Todas essas estruturas redundantes são excelentes, mas fiquei curioso se ainda é possível fazer controle manual (Manual Override)
Queria saber se, como no Apollo 11 e 13, ainda seria possível assumir o controle quando necessário
Como os astronautas ainda vêm da tradição de pilotos de teste, imagino que isso seja possível