Чи мали ви справу з космічним загартуванням?

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

Я дивився на деякі проекти, пов’язані з Google Lunar Challenge, і цікавився, що буде відчувати код на Місяці чи навіть просто у космосі. Я знаю, що загартовані космічні дошки пропонують певну розумність у такому суворому середовищі, проте мені цікаво (як програмісту на C), як мені потрібно було б налаштувати своє мислення та код, якщо я писав би щось, що буде працювати у просторі?

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

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

Крім того, якщо рада підтримує якусь критичну систему, ранні попередження здаються першорядними.

Як можна набути досвіду в цьому шляхом тестування, проб і помилок (заборона запуску вашого особистого супутника?)

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

Деякі незначні відмінності, які приходять на думку на даний момент, є:

• Надзвичайно орієнтований на процес.
• Космічне програмне забезпечення завжди матиме як програмні, так і апаратні таймери сторожового догляду.
• Кожна космічна система, над якою я працював, була важкою системою реального часу.
• Ви імітуєте (з великою точністю) кожного зовнішнього актора до системи. Зазвичай це стосується побудови (іноді дійсно дорогого) спеціального обладнання, яке використовується виключно для тестування.
• Ви витрачаєте величезні зусилля та витрати на тестування.
• Замовник (як правило, JPL) надзвичайно залучений до тестового процесу.
• Зазвичай ви використовуєте старі та відомі компілятори та середовища розробки, а не нові.
• Огляди коду, огляди коду та огляди коду.
• Вам краще бути дуже зручним перемикатися між апаратним та програмним світом. Вам не потрібно знати, як проектувати обладнання, але ви повинні знати, як воно працює.
• Широке використання тестового обладнання, наприклад осцилоскопів, логічних аналізаторів, синтезаторів та спектральних аналізаторів.
• Принаймні 3 місця для зберігання прикладної програми. За замовчуванням записано в ПЗУ. Це ніколи не зміниться. Інші 2 - для поточної та наступної / останньої версій.
• Аналіз відмов (MTBF) дійсно важливий.
• Надлишкові системи та відмовні плани критичних компонентів.

Я просто натрапив на ваше цікаве запитання.

Я був у лабораторії приладів під час «Аполлона», і знову пізніше, коли його називали «Лабораторією драперів» під час «холодної війни».

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

Я не працював безпосередньо над ракетами «Мінутеман», але знав деякі проблеми. Якщо ядерна боєголова вилітає поблизу якоїсь електроніки, вона в основному коротшає. Керівний комп'ютер мав датчик випромінювання, який миттєво відключав Vc, щоб нічого не вигорало. Тоді комп'ютер перезапуститься, видаливши його регістри.

Щоб вирішити це, комп'ютер періодично знімав свої регістри в ядро, а при перезапуску він запускався з цієї контрольної точки. Щоб зробити цю роботу, програмне забезпечення (все в ASM) довелося проаналізувати, щоб переконатися, що воно може приймати будь-яку кількість таких звернень будь-якої частоти, не отримуючи неправильних відповідей. Це називалося "перезапущеним захищеним". Дуже цікава проблема, враховуючи, що (слава богу) її ніколи не потрібно було використовувати.

Щоб отримати жорстку надійність навколишнього середовища конкретно в С, ось кілька дійсно конкретних речей, які я бачив.

MISRA-C: Автомобільний підмножина C Трохи схожий на Ravenscar ADA / Java.

сторожові собаки: переконайтеся, що програма не блокується

пам'ять ecc (іноді)

контрольні суми: шукають гортаючі шматочки. Я бачив усі три в одній системі:

1) контрольна сума програми постійно (вона була в EPROM, але все-таки отримала перевернуті біти).

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

3) Періодично перевіряється надійність процесора.

4) перевірити, чи є в реєстрах IO те, що вони повинні мати в них.

4b) зчитувати виходи на незалежні входи та перевіряти.

Набагато важливіші, ніж мова програмування, - це вимоги до базової системи (ОС та апаратного забезпечення). В основному, вам потрібно забезпечити (і довести) детерміновану та передбачувану поведінку загальної системи. Багато спільних досліджень було проведено у спільноті в реальному часі. Я настійно рекомендую прочитати дві книги, якщо ви дійсно хочете вивчити цю тему: Системи в режимі реального часу Джейн Лю та книгу з такою ж назвою Германна Копеца . Перший планує планувати дуже теоретично, тоді як другий повертає ваші ноги на землю і в значній мірі охоплює всі пов'язані з цим аспекти системи (в режимі реального часу) системи, наприклад, відмовостійкість.

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

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

Я знайшов цей документ (приблизно у 2009 році) для Інституційного стандарту кодування JPL для мови програмування на C в Лабораторії надійного програмного забезпечення (LaRS) на сайті "Лабораторія реактивного руху" .

Ось короткий виклад правил, задокументованих:

1. Мовна відповідність

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

2. Передбачуване виконання

   • Використовуйте перевірені межі циклу для всіх циклів, які мали на увазі завершення.
   • Не використовуйте пряму чи непряму рекурсію.
   • Не використовуйте динамічний розподіл пам'яті після ініціалізації завдання.
   • * Використовуйте IPC-повідомлення для спілкування із завданнями.
   • Не використовуйте затримки завдань для синхронізації завдань.
   • * Явно передайте дозвіл на запис (право власності) на спільні об'єкти даних.
   • Поставити обмеження щодо використання семафорів та замків.
   • Використовуйте захист пам’яті, запаси безпеки, схему бар'єрів.
   • Не використовуйте goto, setjmp або longjmp.
   • Не використовуйте вибіркові присвоєння значень для елементів списку перерахувань.

3. Захисне кодування

   • Декларуйте об’єкти даних на мінімально можливому рівні сфери застосування.
   • Перевірте значення повернення недійсних функцій або явно передайте (void).
   • Перевірте достовірність значень, переданих функціям.
   • Використовуйте статичні та динамічні твердження в якості перевірок здоровості.
   • * Використовуйте U32, I16 і т.д. замість заздалегідь визначених типів C, таких як int, short та ін.
   • Зробіть чіткий порядок оцінювання у складених виразах.
   • Не використовуйте вирази з побічними ефектами.

4. Чіткість коду

   • Використовуйте попередньо процесор С дуже обмежено.
   • Не визначайте макроси в межах функції або блоку.
   • Не визначайте та не визначайте макросів.
   • Помістіть #else, #elif і #endif в той самий файл, що і відповідні #if або #ifdef.
   • * Розміщуйте не більше одного твердження або декларації на рядок тексту.
   • * Використовуйте короткі функції з обмеженою кількістю параметрів.
   • * Використовуйте не більше двох рівнів непрямості на декларацію.
   • * Використовуйте не більше двох рівнів перенаправлення на посилання на об'єкт.
   • * Не ховайте операції з перенапруженням всередині макросів або typedefs.
   • * Не використовуйте непостійні покажчики функцій.
   • Не перекидайте функціональні вказівники на інші типи.
   • Не ставте код або декларації перед директивою #include.

*) Всі правила повинні правила, за винятком тих , позначені.

Космічні системи обчислювальної техніки залежать від надійності. Глибоке знайомство з цим полем можна знайти у Фундаментальних концепціях надійності Альгерда Авіжієніса, Жана-Клода Лапрі та Брайана Ренделла.

У режимі реального часу також є ключовою концепцією космічних обчислень. Як Панкрат я рекомендував би системи реального часу Германна Копеца.

Для того, щоб дати прагматичне розуміння викликів космічних обчислень, подумайте про:

• екстремальні умови в космосі: дуже спекотно, коли орієнтується на сонце, дуже холодно з іншого боку, багато космічних променів, які можуть перевернути шматочки пам’яті, величезні прискорення та вібрації при запуску, ... Обладнання для космосу повинно бути набагато міцнішим, ніж апаратне для військових.

• Коли відбувається помилка, окрім Міжнародної космічної станції або космічного телескопа Хаббла, ніхто не приходить і замінює несправну систему. Все має бути зафіксовано від землі за допомогою максимальної спостережливості та керованості та через запасні системи для переходу. Це суттєво для супутників Землі. Це складніше з космічними зондами, для яких затримка зв'язку може бути однією годиною. Дійсно, в першу чергу все повинно бути максимально надійним.

Що я дізнався з одного проекту, в якому я брав участь як стажист:

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

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

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

Отже, спробуйте залишити деякі додаткові ресурси, доступні в оригінальному дизайні, і намагайтеся не використовувати весь доступний процесор і пам'ять.

З точки зору програмного забезпечення, напишіть привілейоване завдання, яке періодично, випадковим чином, перевертає біти у вашому коді, і подивіться, як він з цим справляється. Це ваш тренажер.

Апаратурно-розумний, деталі будуть старими, тому що потрібно тривати багато часу, щоб отримати щось, що має космічну оцінку. Крім того, нові деталі постійно зменшуються в розмірах, і чим менша функція (думаю, комірка пам'яті на ІС), тим вона більш чутлива до корупції від радіаційної події.

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

У нас були критичні змінні щодо безпеки. Була копія зворотної змінної. Після кожного циклу змінну перевіряли на її зворотну.

У нас проходили тестування з нулями та ВСІ регістри. Це включало лічильник програм!

Ми провели тест всіх опкодів набору мікроінструкцій. Ми повинні були бути впевнені, що якщо ви додали 2 регістри, то були додані регістри.

Дещо з цього, ймовірно, не пов’язане з програмами в космосі, але це дає відчуття масштабу перевірки, яке можливо.

Я вважаю, що чим гірше середовище, тим більше використовуються коди для виправлення помилок , і є ECC-пам'яті, які можна певною мірою використовувати.

Якщо можна оцінити рівень помилок, можна побудувати код виправлення помилок, який може обробляти введені помилки.

• Так, основна пам'ять знаходиться на наукових дошках.
• Динамічна пам'ять не корисна для вбудованих систем. Питання надійності.

Я б здогадався, що програмне забезпечення ECC даних та використання теорії інформації та користувальницький лодер для розповсюдження даних по системі для управління помилками пам'яті було б початком. Але я не вивчаю рад-жорстке програмне забезпечення, тому я не знайомий з ним, це лише здогадка.