[Перевод] Интервью с разработчиками SpaceX20.10.2021 19:17

Год назад на Reddit прошла серия вопросов и ответов с разработчиками из SpaceX и Starlink

На вопросы отвечали:

• Jeff Dexter — руководитель Flight Software and Cybersecurity в SpaceX
• Josh Sulkin — software design lead в Crew Dragon
• Wendy Shimata — отказоустойчивость и безопасность для Dragon
• John Dietrick — разработчик софта для Demo-2
• Sofian Hnaide — Crew Displays software для Demo-2
• Matt Monson — работал для Dragon, а теперь разработчик софта для Starlink

Какую самую безумную/невозможную вещь руководство (ака Илон) просило вас сделать?

Jeff Dexter: Я помню, как я был в кабинете Илона и сообщил ему новость о том, что мы никак не сможем реализовать весь новый код для посадки S1 вовремя для предстоящего запуска через 2 недели. После некоторого раздумья он посмотрел на Ларса Блэкмора, который был там с нами, и спросил, если мы внедрим этот код, какова вероятность посадки. Ларс ответил, что около 90%. Перефразируя, Илон посмотрел на нас и, по сути, сказал: «Вы можете дать мне 50%». Я сказал, что за 2 недели мы точно сможем написать достаточно логики, чтобы вероятность посадки составила 50%! Мы не посадили F9–14 (вы можете увидеть это в нашем ролике), но мы многому научились, и это помогло нам в конечном итоге посадить F9–21. Важнейшей частью нашего успеха является наша готовность к неудачам, которые не ставят под угрозу миссию, при условии, что мы постоянно учимся на наших неудачах.

вопрос удалён

Josh Sulkin: Все автономное программное обеспечение прикладного уровня написано на C++. Мы обычно используем методы объектно-ориентированного программирования на C++, хотя нам нравится делать все как можно более простым. Мы используем библиотеки с открытым исходным кодом, в основном стандартную библиотеку C++, а также некоторые другие. Однако мы ограничиваемся только очень качественными библиотеками, и часто предпочитаем разрабатывать собственные библиотеки, когда это возможно, чтобы иметь возможность самим контролировать качество кода. Что касается обработки ошибок, то здесь существует множество различных аспектов. Ошибки в компьютерах, вызванные радиацией, обрабатываются с помощью нескольких дублирующих компьютеров и сравнением их результатов. Ошибки в датчиках устраняются путем использования нескольких различных датчиков. Ошибки при передаче данных обрабатываются с помощью кодов обнаружения или исправления ошибок, прикрепленных к полезной нагрузке. Программное обеспечение состоит из множества небольших модулей, разработка которых была одной из основных задач, над которыми я работал. Существует иерархия проектирования от низкоуровневого компонента, подсистемы и до всего транспортного средства. Различные подсистемы обычно изолированы друг от друга, иногда в одном компьютере, иногда в разных компьютерах, с узкими интерфейсами между ними. Я не уверен, сколько времени нам потребуется, чтобы переписать кодовую базу с нуля. Мы не планируем удалять ее в ближайшее время.

SpaceX известна своим программно-аппаратным тестированием (hardware-in-the-loop testing):

• Какая доля (примерно) человеко-часов уходит на разработку этих систем?
• Как выглядит цикл разработки симуляторов полета (скажем, для систем Falcon)? Как часто они обновляются на основе телеметрии? Какую часть цикла запуска труднее всего смоделировать?
• При наличии нескольких сотен спутников Starlink на орбите, есть ли детали отдельных спутников или созвездия, которые, как вы поняли, недостаточно хорошо охвачены при тестировании?
• Насколько глубоко в физику уходят тесты Starlink? Например, если вы пытаетесь оценить задержки для межспутниковой связи или связи спутник-земля, вы можете рассматривать радиоканалы как черный ящик, или вы также пытаетесь моделировать работу фазированной антенной решетки?

Мне также интересно узнать о вычислительном оборудовании — SpaceX известна тем, что создает компоненты своими силами. Учитывая, что Starlink рассчитывает на десятки тысяч спутников на околоземной орбите, есть ли области, где заказные ASIC будут дешевле, чем решения COTS? Есть ли случаи, когда компоненты, «перепроектированные» под срок службы Starlink ~< 10 лет (возможно, для обеспечения устойчивости к радиации), могут быть переделаны с существенной экономией средств?

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

Заранее большое спасибо!

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

Для Starlink мы должны думать о наших спутниках скорее как о серверах в центре обработки данных, чем как о специальных уникальных транспортных средствах. Есть некоторые вещи, в которых мы должны быть абсолютно уверены (управление, обновление программного обеспечения, безопасность питания и аппаратного обеспечения), и поэтому они заслуживают того, чтобы вокруг них были созданы специальные тестовые примеры. Но есть также много вещей, в отношении которых мы можем быть более гибкими — для этих вещей мы можем использовать подход, более схожий с тем, как разрабатываются веб-сервисы. Мы можем развернуть тестовую сборку на небольшом подмножестве наших транспортов, а затем сравнить ее работу с работой остального парка. Если она не делает то, что мы хотим, мы можем подправить ее и попробовать еще раз, прежде чем мержить ее в мастер. Если при внедрении возникнут проблемы, мы можем сделать паузу, откатиться назад и попробовать снова. Это очень мощное изменение в том, как мы думаем о космических аппаратах, и оно абсолютно необходимо для того, чтобы иметь возможность быстро итерировать нашу систему.

Мы определенно нашли места, где в наших тестовых примерах были дыры. Наличие сотен спутников в космосе 24/7 позволяет обнаружить крайние случаи в каждой системе и будет означать, что вы увидите сумасшедшие грани колоколообразной кривой. Важно быть уверенным в том, что ядро обеспечивает безопасность оборудования, сообщает вам о проблеме, а затем дает вам время для восстановления. У нас было много случаев, когда у спутника на орбите случался сбой, о котором мы даже не подозревали раньше, но он мог оставаться в безопасности достаточно долго, чтобы мы могли его отладить, найти исправление или обходной путь и загрузить обновление программного обеспечения.

И да, мы много занимаемся разработкой ASIC на заказ в рамках проекта Starlink.

Привет! Поздравляю с идеальным запуском Боба и Дага!

Известно, что дисплеи Crew Dragon работают под управлением Chromium и JS. Используете ли вы реактивную библиотеку, и если да, то разработана ли она собственными силами или это уже существующая библиотека/фреймворк?

Симулятор стыковки был разработан командой разработчиков программного обеспечения Crew Displays или это был отдельный проект?

На некоторых снимках управления полетами я заметил пользовательский интерфейс, очень похожий на дисплеи в Crew Dragon. Может ли точно такое же программное обеспечение для дисплеев экипажа обслуживаться с сервера на земле, питаясь живой телеметрией от Dragon во время полета? Если да, то может ли/будет ли это программное обеспечение использоваться для мониторинга грузового Dragon также в будущих полетах?

Есть ли возможность получить скриншоты дисплеев экипажа в высоком разрешении? Это, несомненно, самый красивый пользовательский интерфейс, который я когда-либо видел в аэрокосмической отрасли.

И еще один вопрос относительно Starlink: как создание программного обеспечения для дисплеев экипажа повлияло на разработку интерфейса Starlink для операций SpaceX (просмотр карт, визуализация данных и т.д.)?

Спасибо за AMA!

1. Sofian Hnaide: Да, мы используем Chromium, и мы используем реактивную библиотеку, которую мы разработали сами.
2. Jeff Dexter: Симулятор стыковки — это совершенно отдельный код от того, что на самом деле находится в дисплеях экипажа, хотя он был разработан нашей командой Crew Displays. Он начинался как забавный проект Шейна Миелке и Майка Вестенхавера, прежде чем мы решили закончить его и выложить в сеть перед Demo-2.
3. Jeff Dexter: Мы можем запускать и запускаем точно такой же код, который находится на дисплеях экипажа на земле. Единственное ограничение заключается в том, что мы не обязательно получаем всю ту же телеметрию, что и в кабине экипажа на земле из-за ограничений в нашем бюджете на радиочастоты. Мы могли бы, но мы отдаем приоритет получению другой критически важной телеметрии.
4. Jeff Dexter: Мы определенно хотим поделиться некоторыми скриншотами дисплеев экипажа в высоком разрешении. Мы посмотрим, сможем ли мы получить разрешение на это, чтобы показать вам то, что Боб и Даг смогли увидеть вблизи.
5. Matt Monson: Технологии с дисплеев экипажа (особенно карта и оповещения) легли в основу нашего пользовательского интерфейса для первой пары спутников Starlink (Tintin). С тех пор он сильно изменился, но было здорово видеть, как Боб и Даг используют что-то, что кажется знакомым и нам.

Как вы решаете проблему технического долга в вашей организации? Не мешает ли вам постоянное стремление к достижению результата, которым славятся компании Илона, вернуться назад и пересмотреть прошлые проекты?

Отслеживаете ли вы производительность вашего кода? Я полагаю, что это критически важный параметр проектирования для встроенной программной системы с критическими временными ограничениями, как у вас, поэтому мне интересно, как ваш подход сопоставим с чем-то вроде индустрии видеоигр, где такая практика распространена, но, вероятно, не так строга, как в космических полетах.

Какой уровень строгости обеспечивается в безопасности Starlink? Как мы, обычные граждане, можем спокойно относиться к тому, что частная компания управляет тысячами интернет-спутников достаточно безопасным способом, чтобы ими не могли дистанционно управлять злоумышленники? Если ваша команда ошибется, это может иметь последствия для многих поколений, поэтому было бы здорово, если бы вы могли публично рассказать о стратегии.

Wendy Shimata: Мы помним о техническом долге, и поскольку мы маленькая команда, любая неэффективность очень заметна на каждом полете. Для многих наших аппаратов, на которых мы часто летаем, мы стремимся инвестировать в операционную команду, чтобы обеспечить устранение этого технического долга и сделать каждый последующий полет как можно более безболезненным. Однако всегда происходит много событий, поэтому при принятии любого решения о том, как потратить свое время, мы должны думать о правильном балансе между продвижением вперед в плане функционала и устранением существующего долга.

Wendy Shimata: Мы так и делаем — мы используем систему непрерывной интеграции, чтобы наш код постоянно тестировался, но мы также анализируем эти данные в режиме реального времени, чтобы убедиться, что наши показатели производительности находятся в пределах ожидаемых границ. Кейсы настроены таким образом, что если мы нарушаем какие-либо ключевые показатели производительности, кейс «проваливается», и инженер смотрит на него.

Matt Monson: Как правило, в вопросах безопасности существует множество уровней. Для начала мы разработали систему, использующую сквозное шифрование данных наших пользователей, чтобы сделать взлом спутника или шлюза менее полезным для злоумышленника, который хочет перехватить коммуникации. Каждый элемент оборудования в нашей системе (спутники, шлюзы, пользовательские терминалы) предназначен для работы только с программным обеспечением, подписанным нами, так что даже если злоумышленник проникнет в систему, он не сможет закрепиться в ней. Затем мы усиливаем внутренние компоненты системы (включая сервисы в наших центрах обработки данных), чтобы уязвимость в одной области не могла быть использована где-то еще. Мы продолжаем упорно работать над тем, чтобы наша система в целом была должным образом укреплена, и у нас впереди еще много работы (мы нанимаем сотрудников!), и мы относимся к этому очень серьезно.

Не могли бы вы рассказать о том, как в сенсорных экранах Crew Dragon использовался Chromium и какие проблемы это создавало? Какие меры по обеспечению отказоустойчивости были приняты (при такой большой кодовой базе) и какие усилия были направлены на усиление защиты? Был ли это хороший выбор в ретроспективе, и будет ли такой же веб-подход использован в Starship в будущем? Каким был процесс создания дизайна и тестирования пользовательского опыта (UX)?

(Я фронтенд веб-разработчик/UX дизайнер/графический программист/3D художник/графический дизайнер, совмещающий дизайн и инженерные дисциплины, и это была моя мечта — работать в SpaceX, когда я закончу университет в августе этого года. Пользовательский интерфейс корабля Crew Dragon был мне по душе, хотя текущие объявления о вакансиях в SpaceX в основном касаются встроенных систем. Как мне найти подходящий проект по графическому программному обеспечению, чтобы подать заявку? У меня есть несколько знакомых в SpaceX, есть ли какие-нибудь подходящие команды или проекты, в которые я мог бы попросить их отправить мое резюме? Графическое моделирование для Starship? Что-то связанное с клиентами для Starlink?)

Sofian Hnaide: Использование Chromium и Javascript в критически важных средах — популярный вопрос. Для того чтобы я мог четко ответить на этот вопрос, мы должны понимать, что Chromium в данном контексте используется только как движок рендеринга пользовательского интерфейса. Уровень взаимодействия летного ПО с дисплеями и отказоустойчивость хорошо определены и находятся за границами дисплеев. При этом мы следуем одному и тому же процессу разработки для всего кода транспорта, независимо от технологического стека. Мы проводим перекрестное обучение наших разработчиков написанию кода транспортного средства на C++ и придерживаемся того же менталитета в написании надежного программного обеспечения. Мы очень серьезно относимся к надежности и производительности, и, как и в случае с другим программным обеспечением для транспорта, мы проводим обширное тестирование в различных условиях, чтобы понять все варианты отказов. У нас есть предупреждения и процедуры для принятия мер в случае возникновения таких сбоев. Все это дополняется сотнями часов симуляций, которые мы проводим на летном оборудовании для обучения экипажа.

Хотя мы столкнулись со многими трудностями на этом пути, мы очень довольны нашими дисплеями и, что самое главное, наши 2 клиента (пока) тоже довольны. Наземное программное обеспечение Starship уже использует технологический стек дисплеев экипажа, и пройдет совсем немного времени, прежде чем мы начнем разрабатывать человеческие интерфейсы для Starship. Обязательно отправляйте резюме!

Wendy Shimata: На некоторых изображениях также можно заметить, что в капсуле, прямо под дисплеями, по-прежнему есть аппаратные кнопки; это сделано для того, чтобы в случае, если дисплеи по какой-либо причине выйдут из строя, астронавты могли использовать аппаратные кнопки для инициирования критически важных действий, например, реагирования на пожар в кабине.

Привет, большое спасибо за организацию этого классного AMA и поздравляю с DM-2!

У меня есть пара вопросов:

• Используете ли вы оборудование/тачскрины Tesla на Crew Dragon?
• Ходили слухи о том, что пользовательский интерфейс Crew Dragon работает в Chromium (обернутый в Qt), это правда? Если да, то почему вы выбрали веб-технологии, а не натив/Qt UI?
• На каких процессорах работает Crew Dragon по сравнению с обычными десктопными процессорами? Я знаю, что есть несколько процессоров для резервирования, но как один из них сравнится, скажем, с i9 9900k?
• И самое главное, играете ли вы в KSP?
• Вы когда-нибудь думали о том, чтобы добавить несколько игр в Dragon?

Sofian Hnaide:

• Нет, наше оборудование не такое же, как у Tesla.
• Верно, мы используем Chromium в качестве движка рендеринга для пользовательского интерфейса дисплеев. Этот проект начался как прототип симулятора, чтобы продемонстрировать NASA видение дизайна. Затем мы попытались запустить его на летательном оборудовании, и с модификациями он работал довольно хорошо. По мере развития прототипа мы все больше доверяли этому стеку, а затем разработали на его основе программное обеспечение для полетов. Нам понравились все современные функции, которые поставляются с браузерами из коробки, нам также понравилось иметь доступ к талантливым специалистам, которые уже обучены работе с этим стеком. Возможно, мы не боимся делать вещи немного по-другому здесь, в SpaceX. Нам нравится применять подход, основанный на первых принципах, к решению проблем, а не просто полагаться на отраслевые стандарты.
• Мы используем специализированный четырехъядерный процессор, по мощности сравнимый с телефоном пятилетней давности.
• Конечно, мы играем в KSP:)
• У нас их пока нет, но я вижу, что это произойдет в будущем. Проголосуйте за свою любимую игру!

• Насколько нам известно, ваши ракеты работают на Linux —, но какой «мейнстримовый» дистрибутив наиболее близок к вашему ядру?
• Есть ли какие-то причудливые изменения, которые вы сделали, о которых вы можете рассказать нам больше?
• Какую архитектуру процессора вы используете? ARM, MIPS или что-то другое?

Josh Sulkin: Да, мы используем Linux с патчем PREEMPT_RT, чтобы получить лучшую производительность в реальном времени. Мы не используем дистрибутивы сторонних разработчиков, а поддерживаем собственную копию ядра и сопутствующих инструментов. За прошедшие годы мы внесли небольшие изменения в ядро, хотя в основном оно остается неизменным. Единственным исключением является добавление нескольких пользовательских драйверов для взаимодействия с нашим оборудованием. Мы используем различные аппаратные архитектуры. Я не могу вдаваться в подробности, кроме как сказать, что это распределенная система, состоящая из множества отдельных компьютеров.

Matt Monson: Для понимания масштаба Starlink, каждый запуск 60 спутников содержит более 4 000 компьютеров Linux. Сейчас в космосе находится более 30 000 узлов Linux (и более 6000 микроконтроллеров). И поскольку мы разделяем большую часть нашей инфраструктуры платформы Linux с Falcon и Dragon, они получают преимущества наших более чем 180 лет испытаний на орбите».

С какими самыми странными ошибками вы столкнулись во время разработки и тестирования программного обеспечения для Crew Dragon?

John Dietrick: Я не могу слишком подробно рассказать о конкретных проблемах, но ошибки ядра определенно самые «веселые» и запоминающиеся. Большая часть нашего управляющего программного обеспечения является однопоточным, чтобы избежать недетерминированности, которую могут вызвать проблемы синхронизации, но, конечно, в ОС в любой момент времени происходит много вещей. Мы приложили много усилий, чтобы превратить Linux в надежную платформу для управления в реальном времени, которая имеет гораздо более высокую степень детерминизма, чем в десктопной ОС. Как уже упоминалось, мы используем патч CONFIG_PREEMPT_RT, который очень помогает. Но даже несмотря на это, в ранних разработках мы иногда видели систему, работающую не так в реальном времени, как хотелось бы, и копание в этих проблемах — это всегда приключение.

Я инженер-программист, и моя жена не разрешает отправлять мне резюме в SpaceX, потому что она говорит, что никогда больше меня не увидит. Или у вас действительно может быть баланс между работой и жизнью?

Jeff Dexter: В SpaceX вы определенно можете иметь хороший баланс между работой и личной жизнью. SpaceX — это определенно не работа с 9 до 5, и у нас бывают случаи, когда для поддержки миссии требуются вечера и выходные, как это было в преддверии Demo-2 и в нашей кампании Starship в Южном Техасе (помимо многих других наших усилий). Нашим сотрудникам определенно удается совмещать работу и семейную жизнь — у Джоша и Венди только что родились дети! Это определенно то, на чем мне и моей команде приходится много фокусироваться, потому что мы небольшая (но растущая) команда и перед нами стоят масштабные цели, которые мы должны достичь.

© Habrahabr.ru