O que é o software do Mars Curiosity Rover embutido?

538

O rover Mars Curiosity pousou com sucesso e um dos vídeos promocionais "7 minutos de terror "Ganha cerca de 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 disso. Alguém sabe alguma coisa sobre este projeto? Eu só posso imaginar que é algum tipo de C incorporado.

    
por InfinitiesLoop 06.08.2012 / 06:04
fonte

2 respostas

499

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

O sistema operacional subjacente é Wind River's VxWorks RTOS . 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 SO, Ada e Java são suportados por extensões. A Wind River fornece uma tremenda quantidade de detalhes sobre os aspectos de como VxWorks .

O chipset subjacente é quase absurdamente "> robusto . Suas especificações podem não parecer muito a princípio, mas é permitido ter uma e apenas uma "bluescreen" a cada 15 anos. Tenha em mente, isso está sob o bombardeio da radiação que mataria um ser humano muitas vezes. No espaço, a robustez supera a velocidade. Claro que robustez como esse tem um custo. Neste caso, é legal $ 200.000 a $ 500.000.

Um debate do programador Erlang sobre os recursos dos computadores e base de código em Curiosity.

    
por 06.08.2012 / 06:30
fonte
174

O código é baseado no MER ( Spirit e Oportunidade ), que foram baseados fora de seu primeiro lander, MPF ( Sojourner ). São 3,5 milhões de linhas de C (em grande parte autogeradas), rodando em um processador RA50 fabricado por BAE e 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 abertura por Benjamin Cichy em Workshop de 2010 sobre o Software de Voo de Naves Espaciais (FSW-10) , slides, áudio e vídeo (começa com visão geral da missão, discussão de arquitetura no slide 80).

Alguém no Hacker News perguntou "Não sei o que significa que a maior parte do código C é gerada automaticamente. De que?"

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

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

A programação baseada em modelo é definitivamente uma coisa que a indústria está lentamente tomando consciência, mas eu não sei quão bem ela está se dando bem em JPL ou se eles teriam escolhido usá-lo quando o projeto começou.

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

Mas isso é apenas a superfície. Você precisa de muitos códigos repetitivos em ambos os lados para lidar com coisas como registro, 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 determinado pacote. Você pode gerar software de solo que monitora esse ponto de telemetria para garantir que quando esse valor de registro for definido, a telemetria será alterada para refletir a alteração. E, claro, alguns pontos de telemetria são mais importantes do que outros (por exemplo, a corrente do barramento principal) e são designados para descer em vários pacotes, o que envolve cópia extra no lado do voo 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 alguma DSL / what-have-you), executá-los através de um script Perl / Python e presto! Código!

Eu não trabalho no JPL, por isso não posso fornecer detalhes que não estejam no vídeo, com uma exceção. Ouvi dizer que o código C autogerado é escrito por scripts Python, e a quantidade de autocoding em um projeto varia muito dependendo de quem é o lead da FSW.

    
por 06.08.2012 / 16:34
fonte