Программисты SpaceX рассказали, каково это — писать ПО для спутников, ракет и космических кораблей

Несколько дней назад SpaceX в твиттере анонсировала мероприятие в формате AMA («спроси меня о чем угодно») с участием своих программистов на просторах Reddit. В официальном сообществе компании на крупнейшем англоязычном интернет-форуме ее сотрудники удовлетворяли любопытство пользователей в самых разных темах — от разработки пользовательских интерфейсов для кораблей Crew Dragon и Starship до условий работы и тестирования ПО спутников Starlink.

На вопросы отвечали: специалист по разработке ПО для корабля Dragon Джарретт Фарнитано (Jarrett Farnitano), глава группы прикладного ПО Starlink Кристин Хуан (Kristine Huang), разработчик низкоуровневого ПО для системы лазерной связи Жанетт Миранда (Jeanette Miranda), глава группы, занимающейся ПО для Starship Эшер Данн (Asher Dunn) и начальница команды по созданию тестовых систем для спутников Натали Моррис (Natalie Morris).

Помимо удовлетворения любопытства гиков и фанатов космонавтики, сотрудники SpaceX, разумеется, призывали всех желающих ответить на вакансии компании. При наличии необходимых навыков, конечно. Одно радует — опыт в ракетно-космической отрасли не требуется. Полное собрание всех вопросов и ответов доступно здесь, а сама ветка обсуждения с вопросами, ответами и уточнениями расположена тут. По этим ссылкам можно найти уйму технических подробностей, а мы отметим наиболее примечательные детали.

Разработка ПО для космонавтики в целом

Наиболее очевидный вопрос, который задали сотрудникам SpaceX — чем отличается разработка программного обеспечения для ракет и космических кораблей от аналогичного труда в «обычной» IT-компании. Для Жанетт главным сюрпризом было две вещи. Во-первых, в общих чертах отличий мало. А во-вторых, при написании ПО для спутников ты очень часто упираешься в ограничения, которые диктуют физика и математика. Когда пишешь код для приложений, работающих на Земле, таких проблем почти никогда не возникает.

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

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

Чтобы минимизировать возможность отказов на уровне программной инфраструктуры применяется специальный подход. Все компоненты ПО создаются небольшими и отдельными — с четкими границами применения и «ответственности». Это позволяет каждый фрагмент кода проверять в самых разных условиях перед внедрением в системы. Которые, в свою очередь, уже тестируются целиком множество раз. Главная задача — сделать так, чтобы поведение программного обеспечения в любых возможных ситуациях было предсказуемым, понятным и знакомым для разработчика.

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

Кроме того, широко применяется автоматизация тестирования и контроля. Благодаря большому объему телеметрических данных от каждого компонента программной системы получается отслеживать параметры всех ее компонентов. Это помогает не только на этапе разработки ПО для ракет или кораблей, но и в эксплуатации огромного «созвездия» спутников Starlink. А оно растет каждый месяц и станет еще в несколько раз больше через пару лет. Натали добавляет, что автоматизация позволяет не заводить сотни операторов, чтобы контролировать орбитальную группировку.

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

Симуляции, тесты, стенды, лаборатории

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

С кораблями и ракетами такой подход, по понятным причинам, неприменим, поэтому приходится тестировать все узлы и компоненты множество раз на Земле. В SpaceX создали несколько программно-аппаратных комплексов для этой задачи. На первом этапе каждый программист прогоняет свой код через простенькие симуляции прямо на рабочем компьютере. Если никаких ошибок не выявлено, программа отправляется на мощный вычислительный кластер. Там она проверяется сначала в условиях более подробной симуляции сама по себе, а потом в составе всей системы, частью которой является.

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

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

Dragon

С самых первых фотографий пилотируемой версии этого космического корабля в сторону SpaceX посыпались претензии в излишней «гламурности» интерьера. Напомним, инженеры компании практически полностью отказались от «традиционных» кнопок, приборов и рычажков, разместив в капсуле три огромных сенсорных панели с небольшим количеством самых важных кнопок под ними. Для чек-листов и дополнительной информации в комплект оборудования добавили несколько планшетов Apple iPad (распространенная практика в авиации). По мнению многих комментаторов такой подход ставит во главу угла дизайн, а не надежность и отказоустойчивость.

Рассказывая о пользовательском интерфейсе Crew Dragon Джарретт объясняет, что во-первых, корабль полностью автономный и может выполнять все операции в полете самостоятельно. Для этого не требуется никаких действий от команды. А во-вторых, даже такую «гламурную» систему в SpaceX сделали максимально отказоустойчивой. При неполадке с любым дисплеем, оставшиеся компенсируют его функции. А если выйдут из строя все сразу, у астронавтов остаются аппаратные кнопки, на которые выведены ключевые функции.

Создавая интерфейс программного обеспечения для сенсорных дисплеев специалисты SpaceX изрядно поломали голову над тем, как его сделать удобным и функциональным для людей во всех режимах полета. Например, самые востребованные сенсорные кнопки, связанные с навигацией размещены снизу экрана. Потому что при перегрузках астронавтам будет трудно поднимать руки вверх. А наиболее важные функции отделены большими пробелами и выведены за пределы часто используемых областей дисплея, где возможно случайное нажатие. То есть, если человек на них нажал, он наверняка сделал это осмысленно и с определенной целью.

Отдельное внимание уделялось тестированию удобства использования сенсорных дисплеев в условиях сильных вибраций. Причем дело не только в управлении (нажатии на них), но и в восприятии информации. Чтобы проверить последний момент проводилась серия экспериментов, в которых подопытные должны были играть в специально созданную игру при помощи контроллера от приставки Xbox. Их успех зависел от того, насколько быстро и точно люди считывали с экрана формы, размеры и цвета фигур, а также текст. При этом весь испытательный стенд находился на виброплите, имитирующей условия при старте ракеты. В этом месте Джаретт пошутила — «что мы узнали наверняка, так это полную нереалистичность любых интерфейсов космической техники в фантастических фильмах».

Ну и немаловажным элементом удобства для астронавтов стал подход разработчиков SpaceX, который они называют «quiet-dark» (что-то вроде «тихо-темно»). Пока космический корабль работает штатно, интерфейс выглядит минималистично, показывая ключевые параметры всех систем. Но если автоматика фиксирует какие-то отклонения от нормы, проблемные показатели выделяются особым образом, подчеркивая самую важную информацию. Наконец, в интерфейс регулярно вносятся усовершенствования, основанные на реальном опыте работы астронавтов на борту Crew Dragon.

Starship

Отдельной бомбардировке вопросами подвергся Эшер, отвечающий за разработку ПО для самого амбициозного проекта Илона Маска. По словам программиста, подход в написании кода для космического корабля из нержавейки не сильно отличается от того, что делают инженеры SpaceX в Бока-Чика. То есть — сделал, проверил, запустил (взорвал), собрал данные, проанализировал, вернулся в начало цикла. В отличие от команд, занимающихся Falcon 9 и Dragon, у Эшера с коллегами есть больше свободы в действиях. Например, они могут внедрить какое-то программное улучшение за считанные часы до испытаний Starship. Если уверены, что это поможет, конечно.

Обновление программного и аппаратного обеспечения для этого космического корабля идет постоянно. И хотя Starship использует немало оборудования и кода, отработанного на Falcon 9, для него приходится создавать много новых систем. Работа идет непрерывно и вместе с инженерами, занимающимися «железом». Что самое важное, каждое новое испытание (необязательно даже полет), приносит массу информации, специалисты постоянно учатся. И могут сразу же внедрять совершенно новые идеи, быстро получая ответ — работает или нет.

Технологии, которых не ждешь в ракетно-космической отрасли

Помимо сенсорных экранов в космическом корабле, SpaceX использует множество не менее спорных на первый взгляд технологий, которые не заметны со стороны. Очень любопытный с технической точки зрения вопрос задали по поводу отказа от систем реального времени (real-time operating system, RTOS). Упрощенно говоря, работающее в ней программное обеспечение всегда и в любых условиях реагирует на события не дольше строго определенного времени. Если задача не успевает выполниться, система ее сбрасывает, чтобы не занимать ресурсы. В авиации, ракетостроении, а также прочих сфокусированных на безотказности, надежности и безопасности отраслях RTOS считаются стандартом.

А программисты SpaceX написали весь софт для своих ракет на базе специализированного Linux-дистрибутива. Да, к этому семейству операционных систем существуют расширения, дающие функционал, необходимый для работы в режиме реального времени. Однако это половинчатое решение и полноценной RTOS не получается. Почему так — вопрос спорный и дискутировать можно долго. Скорее всего, дело в ограниченности функционала RTOS и сложности разработки ПО для них. Джарретт рассказал, как программисты компании решили проблему реального времени.

Что самое главное — SpaceX почти все программное обеспечение создает самостоятельно. В результате компоненты всех систем протестированы любым возможным способом и разработчики точно знают, как они себя поведут в разных условиях. То есть время выполнения каждой операции не ограничено сверху, а просто известно заранее. Если что-то идет не так, срабатывают защитные компоненты. Выглядит похоже, но разница в механизмах контроля — в RTOS они встроены в ядро, а в решении SpaceX реализованы отдельными программами. Как показывает многолетний опыт успешных полетов, работает надежно.

Отдельный сюрприз — широкое использование веб-интерфейсов. По словам Эшера, с их помощью сделано все, что видят астронавты на экранах в капсуле Crew Dragon и большая часть информационных панелей для операторов центра управления полетами. Абсолютно «не-космическая» технология оказалась невероятно надежной, быстрой и, что немаловажно, гибкой для таких целей. Естественно, Starship тоже получит дисплеи управления, на которые будет выводиться веб-интерфейс, только его существенно доработают, по сравнению с тем, что используется в «Драконе». Задачи у кораблей все-таки разные.

Немного юмора и недомолвок

Некоторую информацию сотрудники SpaceX, конечно же, не смогли раскрыть. В частности, отвечая на вопрос про передачу технических данных между спутниками Starlink и наземной станцией Кристин выдала максимально обтекаемый ответ. Несмотря на то, что ее спрашивали про объем информации и количество потоков, она лишь сказала, что данных много и они представлены в проприетарном формате. Также Эшер либо забыл, либо просто не стал показывать актуальную версию пользовательского интерфейса Crew Dragon.

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

Ну и не забыли про развлечения. Когда у ребят из SpaceX спросили, сколько времени они проводят в популярной игре Kerbal Space Program (симулятор космической программы с хорошей физической моделью), они ответили «INT_MAX». Учитывая, что это параметр из заголовочного файла стандартной библиотеки общего назначения, написанной на языке программирования C, понимать такую реакцию можно двояко. Либо очень много, поскольку его значение может превышать два миллиарда, либо что время в игре приходится жестко лимитировать (INT_MAX — это ограничитель).

Василий Парфенов

554 статей

mostly harmless Есть телега: https://t.me/tempest_exults

Показать больше

Закладка

Скопировать ссылку

Email

Печать

Twitter

VK

Telegram