Вы имели дело с космической закалкой?

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

Я смотрел на некоторые из проектов, связанных с Google Lunar Challenge, и задавался вопросом, каково это - получить код на Луне или даже просто в космос. Я знаю, что закаленные в космосе доски предлагают некоторую здравомыслие в такой жесткой среде, однако мне (как программисту на Си) интересно, как бы мне пришлось корректировать свое мышление и код, если бы я писал что-то, что будет работать в космосе?

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

Что происходит с программой, если радиация, холод или жара бомбардируют плату, которая нанесла ущерб ее изоляции? Я думаю, что цель состоит в том, чтобы держать людей внутри космического корабля (вплоть до исправления или обмена вещами) и избегать миссий, чтобы исправить вещи.

Кроме того, если доска поддерживает какую-то критическую систему, ранние предупреждения кажутся первостепенными.

Как можно получить опыт в этом посредством тестирования и проб и ошибок (за исключением запуска собственного персонального спутника?)

Космическое программное обеспечение не таинственная магия. Вы по-прежнему используете 0 и 1, а не 1 и 3. Так что, вероятно, нет ничего удивительного в описании того, что входит в разработку программного обеспечения.

Некоторые небольшие различия, которые приходят на ум в данный момент:

• Чрезвычайно ориентирован на процесс.
• Космическое программное обеспечение всегда будет иметь как программные, так и аппаратные сторожевые таймеры.
• Каждая космическая система, над которой я работал, была сложной системой реального времени.
• Вы моделируете (с большой точностью) каждого внешнего участника системы. Обычно это включает создание (иногда очень дорогое) нестандартного оборудования, которое используется исключительно для тестирования.
• Вы тратите огромные усилия и затраты на формальное тестирование.
• Заказчик (обычно JPL) чрезвычайно вовлечен в процесс тестирования.
• Обычно вы используете старые и известные компиляторы и среды разработки, а не новые.
• Кодовые обзоры, кодовые обзоры и кодовые обзоры.
• Вам лучше будет очень удобно переключаться между аппаратным и программным миром. Вам не нужно знать, как спроектировать оборудование, но вы должны знать, как оно работает.
• Широкое использование испытательного оборудования, такого как осциллографы, логические анализаторы, синтезаторы и анализаторы спектра.
• Как минимум 3 места для хранения прикладной программы. По умолчанию записывается в ПЗУ. Это никогда не изменится. Другие 2 для текущей версии и следующей / последней версии.
• Анализ отказов (MTBF) действительно важен.
• Резервные системы и планы аварийного переключения для критических компонентов.

Я просто наткнулся на ваш интересный вопрос.

Я был в Лаборатории Инструментовки во время Аполлона, и снова позже, когда это назвали Лабораторией Драпировщика во время "холодной войны".

Для компьютера управления Apollo ядро ​​использовалось для оперативной памяти, а специальное плетеное ядро ​​использовалось для ROM. Сама машина была сделана полностью из ворот NOR и работала довольно медленно, для надежности.

Я не работал непосредственно над ракетами Minuteman, но я знал о некоторых проблемах. Если ядерная боеголовка сработает в непосредственной близости от какой-либо электроники, она в основном ее закроет. Направляющий компьютер имел датчик излучения, который мгновенно отключал бы Vc, чтобы ничего не сгорело. Затем компьютер перезагружался, стирая свои регистры.

Чтобы справиться с этим, компьютер периодически снимал свои регистры в ядро, и после перезапуска запускался с этой контрольной точки. Чтобы это работало, нужно было проанализировать программное обеспечение (все в ASM), чтобы убедиться, что оно может принимать любое количество таких обращений с любой частотой, не получая неправильных ответов. Это называлось «защита от перезапуска». Очень интересная проблема, учитывая, что (слава богу) ее никогда не приходилось использовать.

Чтобы получить жесткую надежность среды, особенно в C, вот некоторые действительно конкретные вещи, которые я видел, сделал.

MISRA-C: Подгруппа автомобилей Automotive. Немного похоже на Ravenscar ADA / Java.

сторожевые таймеры: убедитесь, что программа не заблокирована

ecc memory (иногда)

контрольные суммы: поиск битов Я видел все три из них в одной системе:

1) непрерывно проверяет сумму программы (она была в СППЗУ, но все равно получала перевернутые биты).

2) периодически проверять контрольные суммы определенных структур данных.

3) Периодически проверяется работоспособность процессора.

4) проверьте, есть ли в регистрах ввода-вывода то, что они должны иметь.

4b) зачитать выходные данные на независимые входы и проверить.

Гораздо важнее языка программирования являются требования к базовой системе (ОС и аппаратному обеспечению). По сути, вам необходимо обеспечить (и доказать) детерминистическое и предсказуемое поведение всей системы. Много исследований было сделано в сообществе в реальном времени. Я настоятельно рекомендую прочитать две книги, если вы действительно хотите изучать эту тему: «Системы реального времени » Джейн Лю и одноименную книгу Германа Копца . Первый из них охватывает планирование в очень теоретической форме, а второй возвращает вас на землю и в значительной степени охватывает все связанные аспекты (в реальном времени) проектирования системы, например отказоустойчивость.

Кроме того, следующие два инцидента прекрасно иллюстрируют качество проблем, с которыми сталкиваются разработчики программного обеспечения при отправке чего-либо в космос:

• Ariane 5 (Повторное использование проверенного программного обеспечения при различных ограничениях)
• Перезагрузка Mars Rover Pathfinder (приоритетная инверсия)

Я нашел этот документ (около 2009 г.) для стандарта институционального кодирования JPL для языка программирования C в лаборатории надежного программного обеспечения (LaRS) на сайте Лаборатории реактивного движения .

Вот краткое изложение документированных правил:

1. Языковая совместимость

   • Не отклоняйтесь от определения языка.
   • Компилировать со всеми включенными предупреждениями; использовать статические анализаторы исходного кода.

2. Предсказуемое исполнение

   • Используйте проверяемые границы цикла для всех циклов, которые должны заканчиваться.
   • Не используйте прямую или косвенную рекурсию.
   • Не используйте динамическое распределение памяти после инициализации задачи.
   • * Используйте сообщения IPC для связи задач.
   • Не используйте задержки задач для синхронизации задач.
   • * Явно передать разрешение на запись (владение) для общих объектов данных.
   • Установите ограничения на использование семафоров и замков.
   • Используйте защиту памяти, границы безопасности, барьерные схемы.
   • Не используйте goto, setjmp или longjmp.
   • Не используйте выборочные присвоения значений элементам списка enum.

3. Оборонительное кодирование

   • Объявите объекты данных с минимально возможным уровнем области видимости.
   • Проверьте возвращаемое значение не пустых функций или явно приведите к (void).
   • Проверьте правильность значений, переданных в функции.
   • Используйте статические и динамические утверждения как проверки работоспособности.
   • * Используйте U32, I16 и т. Д. Вместо предопределенных типов данных C, таких как int, short и т. Д.
   • Сделайте порядок вычисления в составных выражениях явным.
   • Не используйте выражения с побочными эффектами.

4. Ясность кода

   • Используйте только очень ограниченное использование препроцессора C.
   • Не определяйте макросы внутри функции или блока.
   • Не отменяйте или не определяйте макросы.
   • Поместите #else, #elif и #endif в тот же файл, что и соответствующие #if или #ifdef.
   • * Не более одного заявления или декларации в строке текста.
   • * Используйте короткие функции с ограниченным количеством параметров.
   • * Используйте не более двух уровней косвенности на одну декларацию.
   • * Используйте не более двух уровней разыменования для каждой ссылки на объект.
   • * Не скрывайте операции разыменования внутри макросов или typedefs.
   • * Не используйте непостоянные указатели на функции.
   • Не приводите указатели функций в другие типы.
   • Не размещайте код или объявления перед директивой #include.

*) Все правила должны правила, за исключением тех , отмеченные звездочкой.

Космические вычислительные системы - это надежность. Глубокое знакомство с этой областью можно найти в « Основополагающих концепциях надежности » Альгирдаса Авижиениса, Жан-Клода Лапри и Брайана Рэнделла.

В реальном времени также является ключевым понятием для космических вычислений. Как Pankrat, я бы порекомендовал системы реального времени Германа Копца.

Чтобы дать прагматическое представление о проблемах космических вычислений, подумайте о:

• экстремальные условия в космосе: очень жарко при обращении к солнцу, очень холодно с другой стороны, много космических лучей, которые могут инвертировать биты в памяти, огромные ускорения и вибрации при запуске ... Аппаратные средства для космоса должны быть гораздо более надежными, чем аппаратные для военных.

• Когда происходит сбой, за исключением Международной космической станции или космического телескопа Хаббла, никто не приходит и не заменяет неисправную систему. Все должно быть исправлено с нуля через максимальную наблюдаемость и управляемость и через запасные системы для переключения. Это легко для спутников Земли. Это сложнее с космическими зондами, для которых задержки связи могут составлять один час. Действительно, все должно быть максимально надежным, в первую очередь.

Что я узнал из одного проекта, в котором я участвовал как стажер:

Ваши технические характеристики будут меняться, как правило, в худшую сторону!

Например, космический процессор повышенной прочности, который использовался в проекте, обещал, обещал , имейте в виду, что он будет работать на частоте 20 МГц.

Окончательный результат побежал на 12 МГц. Старший программист проекта потратил много времени на перепроектирование алгоритмов, чтобы удовлетворить жесткие требования систем управления в реальном времени, и большая часть программного обеспечения телеметрии была выгружена во вторую систему вместо того, чтобы работать на основном ЦП.

Поэтому постарайтесь оставить некоторые дополнительные ресурсы доступными в оригинальном дизайне и постарайтесь не использовать весь доступный процессор и память.

С точки зрения программного обеспечения, напишите привилегированную задачу, которая случайным образом случайным образом отображает биты в вашем коде и посмотрите, как она справляется с этим. Это твой симулятор.

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

Я работал над устройством, критичным для безопасности, и нам пришлось пройти через несколько подобных обручей.

У нас были критические переменные безопасности. Была копия обратной переменной. После каждого цикла переменная сверялась с обратным.

У нас был тест на ходьбу и нули ВСЕХ регистров. Это включает в себя счетчик программ!

У нас был тест всех кодов операций набора микрокоманд. Мы должны были быть уверены, что если вы добавили 2 регистра, регистры были добавлены.

Часть этого, вероятно, не связана с программами в космосе, но дает представление о масштабах возможных проверок.

Я считаю, что чем хуже среда, тем больше кодов, исправляющих ошибки , и есть память ECC, которую можно использовать до некоторой степени.

Если можно оценить уровень ошибок, можно построить код с исправлением ошибок, который может обрабатывать введенные ошибки.

• Да, память ядра находится на исследовательских досках.
• Динамическая память не подходит для встраиваемых систем. Вопросы надежности.

Я бы предположил, что программный ECC данных и использование теории информации и пользовательский загрузчик для распространения данных по системе для управления сбоями памяти были бы началом. Но я не изучаю программное обеспечение Rad Hard, поэтому я не знаком с ним, это всего лишь предположение.