Em que o software do Mars Curiosity Rover está incorporado?

O veículo espacial Mars Curiosity pousou com sucesso, e um dos vídeos promocionais "7 minutos de terror" se gabava de haver 500.000 linhas de código. É um problema complicado, sem dúvida. Mas isso é muito código, certamente houve um grande esforço de programação por trás dele. Alguém sabe alguma coisa sobre este projeto? Só posso imaginar que seja algum tipo de C. incorporado

Está executando 2,5 milhões de linhas de C em um processador RAD750 fabricado pela BAE . O JPL tem um pouco mais de informação, mas suspeito que muitos dos detalhes não foram divulgados. Parece que os scripts de teste foram escritos em Python.

O sistema operacional subjacente é o VxWorks RTOS da Wind River . O RTOS em questão pode ser programado em C, C ++, Ada ou Java. No entanto, apenas C e C ++ são padrão para o sistema operacional, Ada e Java são suportados por extensões. Wind River fornece uma quantidade enorme de detalhes sobre os comos e porquês do VxWorks .

O chipset subjacente é quase absurdamente robusto . Suas especificações podem não parecer muito no começo, mas é permitido ter uma e apenas uma "tela azul" a cada 15 anos. Tenha em mente que isso está sendo bombardeado por radiação que mataria um humano muitas vezes. No espaço, a robustez vence com a velocidade. Obviamente, robustez como essa tem um custo. Nesse caso, são de US $ 200.000 a US $ 500.000.

Um programador Erlang fala sobre os recursos dos computadores e da base de código no Curiosity.

O código é baseado no MER ( Spirit and Opportunity ), que foi baseado em seu primeiro lander, MPF ( Sojourner ). São 3,5 milhões de linhas de C (muitas delas geradas automaticamente), rodando em um processador RA50 fabricado pela BAE e pelo sistema operacional VxWorks . Mais de um milhão de linhas foram codificadas manualmente.

O código é implementado como 150 módulos separados, cada um executando uma função diferente. Módulos altamente acoplados são organizados em componentes que abstraem os módulos que contêm e "especificam uma função, atividade ou comportamento específico". Esses componentes são organizados em camadas e "não há mais de 10 componentes de nível superior".

Fonte: Palestra de Benjamin Cichy no Workshop de Software de Voo Espacial (FSW-10) de 2010 , slides, áudio e vídeo (começa com a visão geral da missão, discussão de arquitetura no slide 80).

Alguém no Hacker News perguntou: "Não tenho certeza do que significa que a maioria do código C é gerado automaticamente. De quê?"

Não tenho 100% de certeza, embora provavelmente exista uma apresentação separada naquele ano ou em um ano diferente que descreva o processo de geração automática. Eu sei que esse era um tópico popular em geral na conferência FSW-11.

Simulink é uma possibilidade. É um componente do MATLAB popular entre os engenheiros mecânicos e, portanto, a maioria dos engenheiros de navegação e controle, e permite que eles 'codifiquem' e simulem coisas sem pensar que estão codificando.

A programação baseada em modelo é definitivamente algo que a indústria está lentamente se conscientizando, mas eu não sei o quão bem ela está pegando no JPL ou se eles escolheriam usá-lo quando o projeto foi iniciado.

A terceira e mais provável possibilidade é para o código de comunicação. Em todos os sistemas espaciais, você precisa enviar comandos para o software de vôo a partir do software de solo e receber telemetria do software de vôo e processá-lo com o software de solo. Cada pacote de comando / telemetria é uma estrutura de dados heterogênea e é necessário que os dois lados trabalhem exatamente da mesma definição de pacote e formate o pacote para que seja formatado corretamente de um lado e analisado do outro lado. Isso envolve acertar várias coisas, incluindo tipo de dados, tamanho e endianness (embora o último seja geralmente algo global; você pode ter vários processadores integrados com endianness diferente).

Mas isso é apenas a superfície. Você precisa de muito código repetitivo de ambos os lados para lidar com coisas como log, validação de comando / telemetria, verificação de limite e tratamento de erros. E então você pode fazer coisas mais sofisticadas. Digamos que você tenha um comando para definir um valor de registro de hardware e esse valor seja enviado de volta na telemetria em um pacote específico. Você pode gerar software de solo que monitora esse ponto de telemetria para garantir que, quando esse valor de registro for definido, eventualmente a telemetria seja alterada para refletir a alteração. E, é claro, alguns pontos de telemetria são mais importantes que outros (por exemplo, a corrente principal do barramento) e são designados para descer em vários pacotes, o que envolve cópias extras no lado do vôo e desduplicação de dados no lado do solo.

Com tudo isso, é muito mais fácil (na minha opinião) escrever uma coleção de arquivos de texto estáticos (em XML, CSV ou algum DSL / o que você tem), executá-los através de um script Perl / Python e pronto! Código!

Como não trabalho na JPL, não posso fornecer nenhum detalhe que não esteja no vídeo, com uma exceção. Ouvi dizer que o código C gerado automaticamente é escrito por scripts Python, e a quantidade de codificação automática em um projeto varia muito, dependendo de quem é o líder do FSW.