С самого своего начала полёты в космос зависели от компьютеров, как на земле, так и в самом космическом аппарате; SpaceX поднял этот принцип на новый уровень. Недавно мы поговорили с руководителем разработки ПО Dragon Стивеном Гердингом о сложных особенностях разработки программного обеспечения для различных миссий SpaceX.
23 апреля SpaceX и НАСА запустили на Международную космическую станцию вторую миссию Dragon (Crew-2), ставшую первой космической миссией на проверенных лётными испытаниями Falcon 9 и Dragon. Примерно 24 часа спустя Dragon автономным образом состыковался с МКС, благодаря чему к орбитальной лаборатории впервые оказались пристыкованными два Crew Dragon. Это ознаменовало начало новой эры SpaceX, теперь цель компании заключается в регулярной отправке астронавтов на МКС.
Работа Гердинга и других инженеров-ракетчиков над разработкой ПО в основном выполняется на языке C++, который является главной опорой для кода компании со времён её основания. Программное обеспечение считывает текстовые конфигурационные файлы. «Мы изобрели простые специализированные языки для описания такой информации, чтобы их могли настраивать другие инженеры компании, не занимающиеся разработкой ПО».
Лётное ПО для ракет SpaceX построено на концепции цикла управления. «Мы считываем все входящие данные: информацию счётчиков, поступающую через АЦП, пакеты из сети, данные от инерциального измерительного блока (IMU), обновления от прибора ориентации по звёздам или датчика системы наведения, команды с земли», — рассказывает Гердинг. «Затем выполняем их обработку, чтобы определить состояние аппарата, например, местоположение или состояние системы жизнеобеспечения. Это определяет выходные данные — мы записываем их, ждём до следующего такта часов, а затем повторяем всё заново».
Цикл управления определяет часть требований к производительности ПО. «На Dragon некоторые компьютеры выполняют цикл управления с частотой 50 Гц, другие — с частотой 10 Гц. Основной компьютер выполняет цикл с частотой 10 Гц. Он управляет всей миссией в целом и отправляет команды другим компьютерам. Некоторые из них должны реагировать на определённые события быстрее, поэтому они работают с частотой 50 Гц».
С центральной системой управления полётом взаимодействует множество разнотипных механизмов. «Мы получаем входящие данные от всевозможных датчиков, размещённых по всему аппарату». Многие из них замеряют внутренние значения, критически важные для состояния корабля и экипажа. «Важно отслеживать температуры. На пилотируемых аппаратах есть датчики кислорода и двуокиси углерода, датчики давления в кабине и тому подобное».
Другой набор датчиков отслеживает внешние показатели и способствует навигации и телеметрии. «К ним относятся IMU, GPS и приборы ориентации по звёздам». Когда корабль оказывается достаточно близко к космической станции, применяются лазерные дальномеры.
Другой стороной цикла управления являются выходные данные. «Существует два типа выходных данных. Первый — это команды типа „открыть/закрыть клапан“ или „включить/отключить переключатель“. Ко второму относится телеметрия, по сути являющаяся потоком пар „ключ-значение“, каждые 20-100 миллисекунд сообщающих значение определённого параметра».
Иногда результаты поступают напрямую от датчиков как сырые данные. В других случаях используется предварительная обработка. «Это может быть некое вычисленное в ПО значение, например, текущее значение для машины состояний или результат выполнения алгоритма, который будет управлять выходными данными».
Когда космический аппарат находится на земле, данные передаются по жёстко установленным соединениям, обеспечивающим высокую скорость передачи данных. «После взлёта используются различные коммуникационные системы, способные передавать различные подмножества телеметрических данных на землю».
После попадания на землю их используют системы, позволяющие операторам изучать мгновенные значения и принимать решения об управлении кораблём. Также существует система, сохраняющая критически важные данные на будущее, что достаточно важно, ведь мы планируем в дальнейшем многократно использовать ракеты-носители и шаттлы для новых миссий.
На данный момент Dragon умеет автономно пристыковываться к МКС, и в конечном итоге наша цель заключается в полной автономности корабля. «У астронавтов есть возможность брать контроль на себя и при необходимости управлять аппаратом — эту функцию мы продемонстрировали в миссии Dragon Demo-2», — говорит Гердинг.
Мы задали вопрос: что произойдёт в случае неисправности? «Думаю, более очевидно, что нужно делать в случае аппаратных сбоев. У нас есть дублирующее оборудование, будь то компьютерное „железо“, датчики или приводы, поэтому мы можем обнаруживать такие неисправности и перенаправлять управление в обход них».
Гердинг сообщил нам, что нет никакой возможности защититься от произвольного программного бага. «Мы стремились спроектировать ПО так, чтобы в случае сбоя воздействие этой неисправности было бы минимальным». Например, если программная ошибка проявится в двигательной системе, она не повлияет на систему жизнеобеспечения или способность системы наведения к управлению космическим кораблём, и наоборот. «Самое важное — это изолирование различных подсистем».
ПО спроектировано на принципах защиты, так что даже внутри компонента SpaceX стремится изолировать влияние ошибок. «Мы всегда проверяем коды ошибок и возвращаемые значения. Также операторы и экипаж имеют возможность коррекции различных аспектов алгоритма».
Важной частью всего процесса разработки ПО является верификация и проверка. «Само написание ПО составляет небольшой процент всего того, что необходимо для подготовки космического аппарата к полёту».
Для первой демонстрационной миссии (Demo-1), отправившейся к МКС, НАСА требовалось ПО, устойчивое к любым двум сбоям в системе. «Мы реализовали компьютерную архитектуру из трёх цепей и нам требовалась система для управления ею». У Гердинга был опыт работы с распределёнными системами на его предыдущей должности в Google, благодаря чему он хорошо подошёл для этой задачи. «В то время в отделе разработки ПО было всего десять человек. Я стал её руководителем и мы продолжили работу. Распределённые системы — очень интересная для меня тема».
В Google требования к аптайму были совсем другими. «Если происходило что-то аномальное, нам требовалось, чтобы процесс завершался сбоем. Ведь он был одним из тысяч похожих процессов, который можно перезапускать. Если таких сбоев возникало слишком много, то они фиксировались, после чего мы разбирались в проблеме и создавали её решение».
В Google подобные аварии являлись полезным сигналом посреди шума. Но такой подход не годится для пилотируемых ракет. «В SpaceX мы стремились к тому, чтобы сбой процесса не стал результатом программного сбоя. Мы предпочли бы просто продолжить работу с оставшейся частью ПО, на которое не повлиял этот сбой. Нам всё равно нужно знать об этом сбое, и для этого нам пригождается телеметрия, но всё остальное должно продолжать работать, а мы должны иметь над процессами максимально возможный контроль».
На правах рекламы
Эпичные серверы — это виртуальные серверы с процессорами от AMD, частота ядра CPU до 3.4 GHz. Максимальная конфигурация позволит получить космическую производительность — 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe. Поспешите заказать!
Подписывайтесь на наш чат в Telegram.
