Софт для звездолётов (интервью с разработчиком из SpaceX)

Космические полеты с самого начала зависели от компьютеров — как на земле, так и в космическом корабле. SpaceX вывела их на новый уровень. Недавно Stack Overflow поговорили со Стивеном Гердингом, руководителем разработки программного обеспечения для корабля Dragon, о том, какие особые задачи ставит перед собой команда разработки программного обеспечения для многочисленных миссий SpaceX.

23 апреля 2021 года SpaceX и НАСА запустили вторую оперативную миссию Dragon (Crew-2) на Международную космическую станцию, став первым пилотируемым космическим полетом, в котором астронавты будут пилотировать на проверенных полетами Falcon 9 и Dragon. Примерно через 24 часа Dragon автономно пристыковался к станции, став первым случаем одновременного пристыкования двух экипажей Dragon к орбитальной лаборатории. Это знаменует собой начало новой эры для компании SpaceX, которая будет стремиться к регулярным полетам астронавтов на МКС.

Фактическая работа по разработке программного обеспечения инженерами по транспорту, такими как Гердинг, в основном выполняется с использованием языка C++, который является основным языком программирования компании с первых дней ее существования. Программное обеспечение считывает текстовые файлы конфигурации. «Мы изобрели простые языки, специфичные для конкретной области, чтобы выразить эти вещи так, чтобы другие инженеры в компании, которые не являются инженерами-программистами, могли настроить их».



Программное обеспечение для ракет в SpaceX построено на концепции цикла управления. «Вы считываете все входные данные: датчики, которые мы считываем через АЦП, пакеты из сети, данные от IMU, обновления от звездного трекера или датчика наведения, команды с Земли», — объясняет Гердинг. «Вы выполняете определенную обработку этих данных, чтобы определить состояние, например, где вы находитесь или состояние системы жизнеобеспечения. Это определяет выходные данные — вы записываете их, ждете следующего тика часов, а затем делаете все заново».

Цикл управления подчеркивает некоторые требования к производительности программного обеспечения. «На Dragon некоторые компьютеры выполняют [цикл управления] с частотой 50 герц, а некоторые — с частотой 10 герц. Главный бортовой компьютер работает на частоте 10 герц. Он управляет общей миссией и посылает команды другим компьютерам. Некоторые из них должны быстрее реагировать на определенные события, поэтому они работают на частоте 50 герц».

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

Другой набор датчиков направлен на внешние данные, чтобы помочь в навигации и телеметрии. «Это IMU, GPS и звездные трекеры». Как только они приближаются к космической станции, они также используют лазерные дальномеры.

Другая сторона цикла управления — это выходные данные. «Есть два разных типа выходных данных. Первый — это что-то вроде „открыть или закрыть вентиль“ или „включить или выключить выключатель“. Другой — телеметрия, которая представляет собой поток пар ключ-значение, которые каждые 20-100 миллисекунд сообщают вам значение определенного параметра».

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

Когда транспорт находится на земле, данные передаются по проводному соединению, которое обеспечивает высокую скорость передачи данных. «Как только он взлетает, существуют различные системы связи, по которым мы можем передавать различные подмножества телеметрии на землю». После того, как аппарат достигает земли, существуют системы, позволяющие операторам просматривать мгновенные значения и принимать решения по управлению аппаратом. Существует также система, которая сохраняет критически важные данные на будущее, что очень важно, когда вы планируете повторно использовать ракеты-носители и шаттлы в будущих миссиях.

В настоящее время Dragon автономно пристыковывается к Международной космической станции, но в конечном итоге цель состоит в том, чтобы корабль стал полностью автономным. «У нас есть возможность когда астронавты берут на себя контроль и управление кораблем в случае необходимости — эту возможность мы продемонстрировали в ходе демонстрационной миссии Dragon Demo-2», — сказал Гердинг.

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

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

Программное обеспечение разработано по принципу защиты, поэтому даже в пределах одного компонента SpaceX пытается изолировать последствия ошибок. «Мы постоянно проверяем коды ошибок и возвращаемые значения. У нас также есть возможность для операторов или экипажа переопределять различные аспекты алгоритма».

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

В ходе первой демонстрационной миссии (Demo-1), которая отправилась на космическую станцию, NASA потребовала, чтобы программное обеспечение было устойчиво к любым двум неисправностям в системе. «Мы внедрили трехзвенную компьютерную архитектуру, и нам нужна была система для управления ею». Гердинг имел некоторый опыт работы с распределенными системами, работая ранее в Google, что сделало его подходящим специалистом для новой задачи. «В то время в команде разработчиков программного обеспечения было всего 10 человек. Я взял это на вооружение и приступил к работе. Я нахожу такие вещи как распределенные системы, действительно интересными».

Требования к безотказной работе в Google рассматривались по-другому. «Вы бы очень хотели, чтобы процесс дал сбой, если произойдет что-то аномальное. Это один из тысяч подобных процессов, которые затем перезапускаются. Если таких сбоев накапливалось достаточно много, вы могли потратить некоторое время на выяснение проблемы и создание решения для ее устранения».

В Google эти сбои были полезным сигналом среди шума. Но такой подход не подходит для ракет с экипажем. «В SpaceX мы не хотим, чтобы наши процессы не работали в результате сбоя программного обеспечения. Мы бы предпочли просто продолжать работу с остальным программным обеспечением, на которое этот сбой фактически не влияет. Нам все равно нужно знать об этом сбое, и именно в этом заключается роль телеметрии, но мы хотим, чтобы все продолжало работать, контролируя все наилучшим образом».

• Тестирование программного обеспечения для космоса (интервью с разработчиком из SpaceX)
  

---

• Первая в России серийная система управления двухтопливным двигателем с функциональным разделением контроллеров
• В современном автомобиле строк кода больше чем…
• Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
• McKinsey: переосмысляем софт и архитектуру электроники в automotive