ROCKET SCIENCE

Что программисты делают
для освоения космоса?

Гагарин полетел в космос, Армстронг высадился на Луне, Маск собирается колонизировать Марс. Нет, это безусловно, феноменально.
Но как же программисты?!

Пока весь мир сосредоточен на достижениях космонавтов и следит за работами конструкторов и инженеров, разработчики пишут ПО. Без которого, между прочим, любой луноход или космический корабль – просто железяка.

Вместе с MTC Cloud мы решили разобраться, чем программисты занимаются в космонавтике. В этом материале рассказываем про софт для марсохода, алгоритмы для изучения поверхности планет и «космические» языки программирования.
Содержание

1. Золотые правила космокодинга
2. Планеты и спутники
3. Баги космического масштаба

Золотые правила космокодинга

Принципы разработки

С 1973 НАСА активно использовала HAL/S — особенно в программе полетов человека в космос Space Shuttle, 85% которой написаны именно на этом языке. Операторы в HAL/S были похожи на Fortran и PL/1, которые активно использовались для научных и инженерных задач.

Была включена функция планирования и координации процессов. Чтобы сделать язык более читабельным для инженеров, в HAL/S сохранялись некоторые традиционные научные обозначения. Еще было представлено два новых типа программных блоков: COMPOOL и TASK. Этот язык позволял осуществить нисходящее структурированное программирование. Его использование, наряду с улучшенными методами и инструментами разработки, позволило удвоить производительность ПО Shuttle по сравнению с аналогичными процессами Appolo.

С учетом специфики управления аппаратами (к ним нет непосредственного доступа) в 2006 году инженером Джерардом Хольцманом из Лаборатории реактивного движения НАСА был разработан свод принципов написания софта, состоящий из 10 основных положений. Правила определены для С, и их суть заключается в следующем:
1. Избегать сложных конструкций ветвления — не использовать goto, setjmp и longjmp, а также прямую и косвенную рекурсию;

2. Все циклы должны иметь фиксированные границы, чтобы избежать бесконтрольного разрастания кода. Конечно, это правило не применяется к итерациям без завершения (например, в планировщике процессов). В таких случаях применяется обратное правило: должно быть статистически доказано, что итерация не может завершиться;

3. Не использовать динамическое распределение памяти после инициализации;

4. Любая функция должна умещаться на стандартном листе бумаге, то есть состоять не более чем из 60 строк кода.

5. Не более двух утверждений (ассертов) на функцию. По формату они должны быть boolean тестами и не содержать сайд-эффектов;

6. Область видимости объектов с данными должна быть ограничена до минимально возможной, чтобы избежать утечки, наложения или дублирования переменных;

7. Проверять возвращаемое значений всех функций, не относящихся к типу void;

8. Ограничить использование препроцесса включением заголовочных файлов и определениями макросов. Не разрешаются вставки токена, списки аргументов переменной длины и рекурсивные вызовы макросов;

9. Использование указателей должно быть ограничено;

10. Компилировать со всеми возможными включенными предупреждениями — разбирать все предупреждения необходимо до выхода ПО.
Разработчик этих рекомендаций считает, что использование первых двух правил гарантирует создание четкой и прозрачной структуры управления, которую проще анализировать, а правила с 4 по 7 широко признаны стандартом хорошего стиля программирования.
Этими правилами, за исключением устаревших положений вроде соотнесения размера функции со стандартным листом бумаги, пользуются и в SpaceX. Об этом рассказали разработчики софта в обсуждении на Reddit после успешного запуска ракеты Falcon 9 c кораблем Crew Dragon. Ветка вопросов для них cостояла из 7402 комментариев. Стоит отметить, что большинство из них остались без ответа. Что разработчики софта в SpaceX или, по их определению, «компании, где выживут только параноики», — успели рассказать:
— Для каждой миссии Falcon используется один и тот же исходный код, в который вносятся незначительные изменения;

— Не используют много внешнего софта;

— Все программное обеспечение прикладного уровня написано на С++ (активно пользуются его техниками объектно-ориентированного программирования), Python используют для приложений, тестов и разных задач автоматизации, а JavaScript/HTML/CSS — для дисплеев.
Многие пользователи Reddit прокомментировали это как довольно странный выбор — большое количество уровней абстракции представляет высокий риск безопасности;

— Чаще всего пользуются стандартной библиотекой С++, однако из соображений контроля качества разрабатывают и собственные;

— Для систем навигации и управления полетами используют классический фильтр Калмана — алгоритм обработки данных для оценки состояния системы;

— Используют Linux в качестве системы программирования в реальном времени и хвалят патч CONFIG_PREEMPT_RT, который значительно улучшил способности ядра работать в режиме реального времени. Однако вместе с ним увеличилась сложность ядра: при росте пропускной способности под риск попадает его латентность;

— Основные баги миссий держат в тайне, однако отмечают, что все они связаны с ядром. Приложили много усилий, чтобы превратить Linux в зависимую платформу для контроля в режиме реального времени со степенью детерминизма выше, чем в обычной операционной системе;

— В каждом запуске на орбиту 60 спутников Starlink используют 4000 компьютеров с Linux — это более 30 тысяч узлов и 6000 микроконтроллеров.



Стоит отметить, что на международной космической станции Linux используется с 2017 года. Миссия новейшего марсохода Perserverance с небольшим дроном Ingenuity в виде вертолета на борту (по размеру он приблизительно равен пачке салфеток, а его вес составляет 1.8 килограммов) стала первой, в которой «Linux полетел на Марс», как отметил разрабочик его софта Тим Кэнхем. Программный фрейморк, использующийся для Ingenuity лежит в открытом доступе, и его можно использовать для частных проектов.

Планеты и спутники

МАРС

Curiosity на Марсе уже почти 9 лет. Марсоход изучает грунт и атмосферу. Изначально его отправили в центр кратера Гейл для изучения древних долин рек и проверки их на признаки ранее существовавшей жизни.

Софт для него написан на С и состоит примерно из 3.8 миллионов строк кода. Его подвергали 145 раундам ревью, окончившихся рядом оптимизаций. Однако Curiosity часто нужна помощь, например, чтобы идентифицировать песок и избежать столкновения с ним. Напомним печальный пример марсохода Spirit: его 7-летняя экспедиция закончилась именно в неравной схватке с песком. Чтобы избежать этого, этого запускаются общественные инициативы по тренировке алгоритмов классификации поверхности Марса — например, AI4Mars на платформе Zooniverse.

Юпитер

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

Луна

В 2023 НАСА планирует запуск VIPER, который будет искать на поверхности Луны водяной лед. Для этого у него будут подходящие для вращения на лунном грунте колеса, специальный бур и оборудование, способное выдержать 14 дней с понижениями температуры до -173 градусов Цельсия. Однако большая часть его программного обеспечения будет с открытым исходным кодом.

Считается, что это может стать переломным элементом для космической индустрии — опенсорс может привлечь к участию разных экспертов. Управление наземного полета будет использовать данные, собранные VIPER, для визуализации в реальном времени окружающей среды на Луне.

Другие части программного обеспечения лунохода также имеют открытый исходный код: основные функции, такие как телеметрия и управление памятью, выполняются на борту программой под названием core Flight System (cFS), разработанной самим NASA и доступной на GitHub. Операции миссии VIPER за пределами самого марсохода обрабатываются Open MCT, также созданным НАСА.

Баги космического масштаба

Луна

Программное обеспечение для управления космическими полетами совершенно настолько, насколько это под силу человечеству. По давним подсчетам, на 420 тысяч строк такого кода приходится в среднем одна ошибка. Любая неточность потенциально подвергает риску жизнеспособность дорогостоящего корабля и его команды, если она находится на борту, а также чаяния всех небезразличных к освоению космоса.

В 1962 году из-за ошибки в коде сорвалась миссия космического аппарата Маринер 1 стоимостью в 554 миллиона долларов, первого в серии одноименной программы НАСА по изучению Венеры. Официальной версией считается пропуск дефиса в одном из уравнений, который позволил передавать неверные сигналы наведения. Маринер 1 отклонился от курса после незапланированного маневра, а офицер безопасности дал приказ о разрушения аппарата через 4,8 минут после запуска.

Ариан-5

Запуск первой ракеты-носителя Ариан-5 производства Европейского космического агентства (ЕКА), предназначенной для вывода на орбиту телекоммуникационных, навигационных и погодных спутников, в 1996 году закончился ее самоуничтожением по команде инженеров через 36.7 секунд после запуска на высоте около 3700 метров.

Для Ариан-5 использовали программное обеспечение предыдущей модели, Ариан-4, несмотря на ее более медленные двигатели. Это и привело к багу – программа пыталась конвертировать данные из 64-битного числа с плавающей запятой в 16-битное целое число. Преобразованное число с плавающей запятой имело значений больше, чем могло быть представлено 16-разрядным целым числом со знаком. Это привело к ошибке операнда, а инструкции преобразования данных в коде, написанном на Ada, не были защищены от этой исключительной ситуации. Стоит заметить, что другие преобразования сопоставимых переменных в том же месте кода были защищены.

Арифметическое переполнение привело к сбою и основного, и резервного компьютеров, которые работали с одинаковым программным обеспечением. Баг, приведший к краху Ариан-5, считают одной из самых дорогостоящих компьютерных ошибок в истории – оценка материальных потерь доходит до отметки в 500 миллионов долларов, а на разработку самой ракеты потратили 8 миллиардов.

Mars Climate Orbiter

С исследованиями Марса тоже все не всегда классно. В 1998 из-за ошибки в программном обеспечении предположительно распался в атмосфере Mars Climate Orbiter (MCO), направленный на двухлетнюю миссию по изучению пыли и водяных паров в атмосфере Марса, чтобы помочь в составлении карты эволюции климатических изменений.

Команды по тяге двигателя в ПО MCO использовали международную единицу измерения силы Ньютон, а программное обеспечение для создания команд на Земле использовало часто применяющуюся в США меру: фунт — сила на квадратный дюйм. Эта ошибка привела к тому, что аппарат пропустил намеченную орбиту в 140–50 километров и упал в атмосферу Марса на высоте примерно в 57 километров, после чего и распался.

Mars Pathfinder

Иногда ошибки не фатальны, но приводят к другим проблемам — например, задержке сбора данных о планете и нарушению критически важных дедлайнов. Так произошло с Mars Pathfinder, первым аппаратом программы NASA Discovery, который изучал атмосферу и другие характеристики Марса.

После приземления аппарата на поверхность планеты он зависал и 6 раз полностью перезапускал систему из-за проблемы инверсии приоритетов — задачи синхронизации с учетом требования систем реального времени. В итоге встроенное программное обеспечение было изменено с Земли, и параметры семафора изменили, чтобы включить наследование приоритетов. Система перестала перезапускаться и стала стабильно работать после того, как на аппарат была загружена короткая программа, написанная на С, которая после интерпретации изменила флаг мьютекса для наследования приоритета с false на true. Глен Ривз, тимлид разработчиков софта для Mars Pathfinder, который и обнаружил баг, позже заметил: «Даже если вам кажется, что вы протестировали все, что только можно представить, вы ошибаетесь». В итоге аппарат собрал 2.3 миллиарда бит данных, включающих более 16500 изображений с посадочного модуля, 550 изображений с марсохода, более 15 химических анализов почвы и горных пород.

Однако в 2019 перезапуск системы оказался фатальным для израильского зонда Beresheet, который планировал совершить первую частную космическую лунную программу, но полностью разрушился в результате удара о поверхность Луны. Из-за небольшого для космического проекта бюджета в 100 миллионов долларов на Beresheet был только один компьютер. Патчи для решения проблем, возникших во время миссии, не были закодированы на его жесткий диск — только на оперативную память. В результате исправления удалялись при каждой перезагрузке системы и их нужно было загружать снова. Это привело к отключению главного двигателя, который должен был постоянно работать для замедления спуска, и последующему крушению на скорости 3000 км/ч.
Текст: Дарина Обухова
Дизайн и вёрстка: Антон Сидоров
Источник изображений: nasa.gov
Разработал комплексные решения для бизнеса на базе двух облачных платформ — VMware и Huawei. Ресурсы размещены в надежном ЦОДе класса Tier3. Сервис гарантирует уровень доступности в 99,95%. Бесплатный тестовый период 14 дней, миграция, настройка и консультации специалистов.
Совместное общество с ограниченной ответственностью «Мобильные
ТелеСистемы» УНП 800013732. Дата регистрации 04.02.2002