Você já lidou com o endurecimento do espaço?

O software espacial não é uma magia arcana. Você ainda está usando 0 e 1, não 1 e 3. Portanto, provavelmente não há nenhum fator relevante na descrição do que está acontecendo no desenvolvimento de software.

Algumas pequenas diferenças que vêm à mente no momento são:

• Extremamente orientado a processos.
• O software espacial sempre terá cronômetros de watchdog de software e hardware.
• Todo sistema espacial em que trabalhei era um sistema de tempo real difícil.
• Você simula (com grande precisão) cada ator externo ao sistema. Isso geralmente envolve a construção de hardware personalizado (às vezes realmente caro) que é usado apenas para testes.
• Você gasta enormes esforços e gastos fazendo testes formais.
• O cliente (geralmente JPL) está extremamente envolvido no processo de teste.
• Você geralmente usa compiladores e ambientes de desenvolvimento antigos e conhecidos, em vez de novos.
• Codifique resenhas, revisões de código e revisões de código.
• É melhor você se sentir confortável em alternar entre os mundos de hardware e software. Você não precisa saber como projetar o hardware, mas precisa saber como ele funciona.
• Uso extensivo de equipamentos de teste, como osciloscópios, analisadores lógicos, sintetizadores e analisadores de espectro.
• Pelo menos 3 locais para armazenar o programa de aplicativo. O padrão é gravado na ROM. Isso nunca vai mudar. Os outros 2 são para a versão atual e a próxima / última versão.
• A análise de falhas (MTBF) é realmente importante.
• Sistemas redundantes e planos de failover para os componentes críticos.

Eu acabei de encontrar sua pergunta interessante.

Eu estava no Instrumentation Lab durante o Apollo, e novamente mais tarde, quando foi chamado Draper Lab durante a "guerra fria".

Para o computador de orientação Apollo, o núcleo foi usado para RAM e um núcleo trançado especial foi usado para ROM. A própria máquina foi feita inteiramente fora dos portões NOR e foi cronometrada bem devagar, por confiabilidade.

Eu não trabalhei diretamente nos mísseis Minuteman, mas estava ciente de alguns dos problemas. Se uma ogiva nuclear dispara na vizinhança de alguns eletrônicos, ela basicamente se cala. O computador de orientação tinha um sensor de radiação que desligaria instantaneamente Vc para que nada se queimasse. Em seguida, o computador seria reiniciado, tendo seus registros apagados.

Para lidar com isso, o computador periodicamente faria um snapshot de seus registradores no núcleo e, quando reiniciado, inicializaria a partir desse ponto de verificação. Para fazer isso funcionar, o software (todo em ASM) teve que ser analisado para ver se ele poderia receber qualquer quantidade de tais acessos, em qualquer frequência, sem obter respostas erradas. Isso foi chamado de "reiniciar protegido". Problema muito interessante, dado que (graças a Deus) nunca teve que ser usado.

Para obter uma confiabilidade de ambiente difícil, especificamente em C, aqui estão algumas coisas realmente concretas que já vi.

MISRA-C: O subconjunto automotivo. Um pouco como Ravenscar ADA / Java.

memória ecc (às vezes)

somas de verificação: procurando por bits invertidos. Eu vi todos os três em um sistema:

1) verifica o programa continuamente (ele estava na EPROM, mas ainda tem bits invertidos).

2) soma de verificação de certas estruturas de dados periodicamente.

3) Verificações de integridade da CPU periodicamente.

4) verifique se os registros IO têm o que eles deveriam ter neles.

4b) leia as saídas de retorno em entradas independentes e verifique.

Muito mais importante que a linguagem de programação são os requisitos do sistema subjacente (sistema operacional e hardware). Basicamente, você precisa garantir (e provar) um comportamento determinístico e previsível do sistema geral. Muita pesquisa relacionada foi feita na comunidade em tempo real. Eu recomendo strongmente a leitura de dois livros, se você realmente quiser estudar este assunto: Sistemas em Tempo Real por Jane Liu e um livro com o mesmo nome de Hermann Kopetz . O primeiro cobre o agendamento de uma maneira muito teórica, enquanto o segundo recoloca os pés no chão e cobre praticamente todos os aspectos relacionados ao design do sistema (em tempo real), e. tolerância a falhas.

Além disso, os dois incidentes a seguir ilustram bem a qualidade dos problemas que os engenheiros de software precisam enfrentar ao enviar algo para o espaço:

• Ariane 5 (Reutilização de software comprovado sob diferentes restrições)
• Reinicialização do Pathfinder da Mars Rover (inversão de prioridade)

Eu encontrei este documento (por volta de 2009) para o Padrão de Codificação Institucional JPL para a Linguagem de Programação C no Laboratório de Software Confiável (LaRS) no site do Laboratório de Propulsão a Jato .

Aqui está um resumo das regras documentadas:

1. Conformidade de idioma

   • Não se desvie da definição de idioma.
   • Compilar com todos os avisos ativados; usar analisadores de código-fonte estático.

2. Execução previsível

   • Use limites de loop verificáveis para todos os loops destinados a terminar.
   • Não use recursão direta ou indireta.
   • Não use a alocação dinâmica de memória após a inicialização da tarefa.
   • * Use mensagens IPC para comunicação de tarefas.
   • Não use atrasos de tarefa para sincronização de tarefas.
   • * Explicitamente transfira permissão de gravação (propriedade) para objetos de dados compartilhados.
   • Coloque restrições no uso de semáforos e bloqueios.
   • Use proteção de memória, margens de segurança e padrões de barreira.
   • Não use goto, setjmp ou longjmp.
   • Não use atribuições de valores seletivos para elementos de uma lista enum.

3. Codificação defensiva

   • Declare objetos de dados no menor nível possível de escopo.
   • Verifique o valor de retorno de funções não vazias ou explique explicitamente para (void).
   • Verifique a validade dos valores passados para as funções.
   • Use asserções estáticas e dinâmicas como verificações de integridade.
   • * Use U32, I16, etc, em vez de tipos de dados C predefinidos, como int, short, etc.
   • Torne explícita a ordem de avaliação em expressões compostas.
   • Não use expressões com efeitos colaterais.

4. Claridade do código

   • Faça apenas um uso muito limitado do pré-processador C.
   • Não defina macros dentro de uma função ou bloco.
   • Não indefinir ou redefinir macros.
   • Coloque #else, #elif e #endif no mesmo arquivo que o #if ou #ifdef correspondente.
   • * Não coloque mais de uma declaração ou declaração por linha de texto.
   • * Use funções curtas com um número limitado de parâmetros.
   • * Não use mais do que dois níveis de indireção por declaração.
   • * Não use mais que dois níveis de desreferenciação por referência de objeto.
   • * Não oculte operações de remoção de referência dentro de macros ou typedefs.
   • * Não use ponteiros de função não constantes.
   • Não insira ponteiros de função em outros tipos.
   • Não coloque código ou declarações antes de uma diretiva #include.

*) Todas as regras são devem regras, exceto aquelas marcadas com um asterisco.

Sistemas de computação à prova de espaço são todos sobre confiabilidade. Uma introdução profunda ao campo pode ser encontrada em Conceitos fundamentais de confiabilidade por Algirdas Avižienis, Jean-Claude Laprie & Brian Randell.

O tempo real também é um conceito-chave para a computação espacial. Como Pankrat, eu recomendaria Real-Time Systems por Hermann Kopetz.

Para dar uma ideia pragmática dos desafios da computação espacial, pense em:

• condições extremas no espaço: muito quente quando orientado ao sol, muito frio no outro lado, muitos raios cósmicos que podem inverter bits na memória, grandes acelerações e vibrações ao serem lançadas, ... Hardware para o espaço deve ser muito mais robusto do que o hardware para militares.

• Quando ocorre uma falha, exceto na Estação Espacial Internacional ou no Telescópio Espacial Hubble, ninguém vem e substitui o sistema com falha. Tudo deve ser corrigido do solo através da máxima observabilidade e capacidade de comando e através de sistemas de reposição para mudar para. Isso é fácil para os satélites da Terra. Isto é mais difícil com sondas espaciais para as quais os atrasos de comunicação podem durar uma hora. De fato, tudo deve ser o mais confiável possível em primeiro lugar.

O que eu aprendi com o único projeto em que estive envolvido como estagiário:

Suas especificações de hardware mudarão, geralmente para pior!

Por exemplo, o CPU endurecido pelo espaço que estava sendo usado no projeto foi prometido, prometido , lembre-se de que ele rodaria a 20 MHz.

O resultado final foi executado em 12 MHz. O programador sênior do projeto passou muito tempo reprojetando algoritmos para atender aos rígidos requisitos de tempo real dos sistemas de controle, e grande parte do software de telemetria acabou sendo descarregada para um segundo sistema, em vez de ser executado na CPU principal.

Portanto, tente deixar alguns recursos extras disponíveis no design original e tente não usar toda a CPU e memória disponíveis.

Para uma perspectiva de software, escreva uma tarefa privilegiada que ocasionalmente, aleatoriamente, vira bits em seu código e veja como ele lida com isso. Esse é o seu simulador.

Hardware-wise, as partes serão antigas, porque leva muito tempo para conseguir algo para ser avaliado pelo espaço. Além disso, as novas peças estão continuamente diminuindo de tamanho, e quanto menor a característica (pense na célula de memória em um I.C.), mais suscetível está a corrupção de um evento de radiação.

Eu trabalhei em um dispositivo de segurança crítica e tivemos que passar por alguns obstáculos semelhantes.

Tivemos variáveis críticas de segurança. Havia uma cópia do inverso da variável. Após cada loop, a variável foi verificada em relação ao seu inverso.

Tivemos testes de zeros e zeros de TODOS os registros. Isso incluiu o contador do programa!

Nós tivemos um teste de todos os opcodes do micro conjunto de instruções. Nós tínhamos que ter certeza que se você adicionasse 2 registradores, os registradores seriam adicionados.

Alguma coisa provavelmente não está relacionada a programas no espaço, mas dá uma ideia da magnitude da verificação que é possível.

Acredito que, quanto pior, um ambiente é o mais Códigos de correção de erros é usado, e há < href="http://en.wikipedia.org/wiki/Dynamic%5Frandom%5Faccess%5Fmemory#Errors%5Fand%5Ferror%5Fcorrection"> memórias ECC que podem ser usadas até certo ponto.

Se alguém puder estimar o nível de erros, pode-se construir um código de correção de erros que possa manipular os erros introduzidos.

• Sim, a memória principal está nos quadros de pesquisa.
• A memória dinâmica não é boa para sistemas incorporados. Problemas de confiabilidade.

Eu diria que o software ECC de dados e o uso de teoria da informação e um loder personalizado para espalhar os dados em torno do sistema para gerenciar as falhas de memória seriam um começo. Mas eu não estudo softwares rad-hard, então não estou familiarizado com isso, é só um palpite.