Во что встроено программное обеспечение Mars Curiosity Rover?

Марс Curiosity марсоход успешно приземлился, и один из промо - видео «7 минут ужаса» хвастается там быть 500000 строк кода. Это сложная проблема, без сомнения. Но это много кода, конечно, за этим стоит довольно большое программирование. Кто-нибудь знает что-нибудь об этом проекте? Я могу только представить, что это какой-то встроенный C.

Он работает 2,5 миллиона строк C на процессоре RAD750 производства BAE . В JPL есть немного больше информации, но я подозреваю, что многие детали не разглашаются. Похоже, что сценарии тестирования были написаны на Python.

Базовая операционная система - это ОСРВ Wind River VxWorks . Рассматриваемая ОСРВ может быть запрограммирована на C, C ++, Ada или Java. Тем не менее, только C и C ++ являются стандартными для ОС, Ada и Java поддерживаются расширениями. Wind River предоставляет огромное количество деталей о том, как и почему VxWorks .

Базовый чипсет почти абсурдно устойчив . На первый взгляд его характеристики могут показаться не такими уж большими, но разрешается иметь один и только один «синий экран» каждые 15 лет. Имейте в виду, это подвергается бомбардировке радиацией, которая много раз убивает человека. В космосе надежность выигрывает у скорости. Конечно, такая надежность имеет свою цену. В данном случае это круто от 200 000 до 500 000 долларов.

Программист Erlang рассказывает об особенностях компьютеров и кодовой базе на Curiosity.

Код основан на коде MER ( Spirit and Opportunity ), основанном на их первой платформе MPF ( Sojourner ). Это 3,5 миллиона строк C (большая часть из которых сгенерирована автоматически), работающих на процессоре RA50 производства BAE и операционной системе VxWorks . Более миллиона строк были закодированы вручную.

Код реализован в виде 150 отдельных модулей, каждый из которых выполняет свою функцию. Сильно связанные модули организованы в компоненты, которые абстрагируют содержащиеся в них модули и «задают конкретную функцию, действие или поведение». Эти компоненты далее организованы в слои, и в них «не более 10 компонентов верхнего уровня».

Источник: основной доклад Бенджамина Сичи на семинаре 2010 года по программному обеспечению полетов космических аппаратов (FSW-10) , слайдам, аудио и видео (начинается с обзора миссии, обсуждения архитектуры на слайде 80).

Кто-то из Hacker News спросил: «Не уверен, что означает, что большая часть кода C генерируется автоматически. Из чего?»

Я не уверен на 100%, хотя, вероятно, в этом году или в другом году есть отдельная презентация, описывающая процесс их автоматической генерации. Я знаю, что это была популярная тема в целом на конференции FSW-11.

Simulink это возможность. Это компонент MATLAB, популярный среди инженеров-механиков и, следовательно, большинства инженеров по навигации и управлению, который позволяет им «кодировать» и моделировать объекты, не думая, что они кодируют.

Программирование на основе моделей - это определенно то, о чем индустрия постепенно начинает осознавать, но я не знаю, насколько хорошо он завоевал популярность в JPL или если бы они решили использовать его в начале проекта.

Третья и наиболее вероятная возможность для кода связи. Для всех космических систем вам необходимо отправлять команды программному обеспечению полета из наземного программного обеспечения, получать телеметрию от программного обеспечения полета и обрабатывать ее с помощью наземного программного обеспечения. Каждый пакет команд / телеметрии представляет собой гетерогенную структуру данных, и необходимо, чтобы обе стороны работали с одинаковым определением пакета, и отформатировали пакет так, чтобы он был правильно отформатирован на одной стороне и проанализирован на другой стороне. Это включает в себя правильное получение множества вещей, включая тип данных, размер и порядок байтов (хотя последний, как правило, глобален; у вас может быть несколько процессоров на борту с разными порядками байтов).

Но это только поверхность. Вам нужно много повторяющегося кода с обеих сторон для обработки таких вещей, как ведение журнала, проверка команд / телеметрии, проверка пределов и обработка ошибок. И тогда вы можете делать более сложные вещи. Скажем, у вас есть команда для установки значения аппаратного регистра, и это значение отправляется обратно в телеметрии в конкретном пакете. Вы можете создать наземное программное обеспечение, которое отслеживает эту точку телеметрии, чтобы гарантировать, что при установке этого значения регистра в конечном итоге телеметрия изменится, чтобы отразить изменение. И, конечно, некоторые точки телеметрии более важны, чем другие (например, ток главной шины), и предназначены для обработки в виде нескольких пакетов, что включает дополнительное копирование на стороне полета и дедупликацию данных на земле.

При этом гораздо проще (на мой взгляд) написать одну коллекцию статических текстовых файлов (в XML, CSV или некоторых DSL / что-у-вас-вы), запустить их через скрипт на Perl / Python и сделать это! Код!

Я не работаю в JPL, поэтому не могу предоставить какие-либо подробности, которых нет в видео, за одним исключением. Я слышал, что автоматически сгенерированный код C написан скриптами Python, и объем автокодирования в проекте сильно варьируется в зависимости от того, кто является руководителем FSW.