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


62

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

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

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

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

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

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


3
Я отправил электронные письма Space-X и другим, прося их присоединиться к SO и помочь ответить на это. Если кто-то знает кого-то в НАСА, сейчас самое время отправить его по электронной почте. Точно так же, может быть, вы знаете отставного прохожего? Я не собираюсь закрывать это в ближайшее время.
Тим Пост

7
Стоит отметить, что «запрещенное динамическое выделение памяти» не является уникальным для космических зондов, но на самом деле довольно распространено для любого жестко ограниченного встроенного оборудования (даже портативных видеоигр).
Crashworks


@ Марк, достаточно ли юмора, чтобы удалить ответы?

5
Это не может быть так сложно, это не ракетостроение. Ой, подождите ...
Марк Рэнсом

Ответы:


52

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

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

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

До сих пор, но подождите, пока не появится мемристор!
lsalamon

Вы говорите кодовые обзоры три раза, как будто они отрицательные.
Кортук

4
@Kortuk: Это должно было подчеркнуть, что вы будете делать рецензии кода ЧАСТО чаще, чем большинство других типов проектов, поскольку следствием сбоя является потеря всего лишь нескольких сотен миллионов долларов. И лично я считаю, что это определенно негативное, но необходимое зло. Я ненавижу проводить обзоры, и я ненавижу выполнять обзоры, но они имеют свою ценность, поскольку они находят проблемы, как никакой другой метод.
Данк

100% согласились. Необходимое зло - приемлемое описание.
Кортук

9
«Космическое программное обеспечение - это не тайная магия», однако, если оно является достаточно продвинутым космическим программным обеспечением, оно будет неотличимо от тайной магии.
Роберт

29

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

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

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

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

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


21

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

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

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

ecc memory (иногда)

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

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

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

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

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

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


И тщательно спланируйте все ответы на ошибки, убедившись в их необходимости.
Майк Данлавей

Ответы о сбоях лучше всего помещать в код. Ошибка возникает в момент ее выбора. Необходимо сообщать о неисправностях, особенно при их устранении. Машина должна справиться сама до тех пор, пока не сработает сигнализатор «сбой компьютера».
Тим Уиллискрофт

9

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

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


Марс Полярный Ландер. (неадекватное тестирование)
Тим Виллискрофт

1
Космический орбитальный аппарат Марс: путаница единиц. Просто используйте СИ и покончите с этим.
Тим Виллискрофт

6

Я нашел этот документ (около 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.

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


5

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

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

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

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

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


3

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

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

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

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

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


3

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

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


2

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

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

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

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

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


1

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

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


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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.