В субботу 15 мая компания SpaceX провела серию вопросов и ответов о разработке ПО в различных проектах компании. Я выделил и перевёл самые интересные из них.
В интервью участвовали:
-
Джарретт Фарнитано — работает над программным обеспечением корабля Dragon, включая дисплеи для экипажа.
-
Кристин Хуанг — ведет прикладное программное обеспечение для спутникового созвездия Starlink.
-
Жанетт Миранда — разрабатывает встроенное программное обеспечение для лазерной связи.
-
Ашер Данн — ведет программное обеспечение для Starship.
-
Натали Моррис — ведет инфраструктуру тестирования программного обеспечения для спутников.
Вопросы о ПО в целом
В: Я пишу программное обеспечение для вещей, которые не связаны с вопросом жизни и смерти. Из-за этого мне удобно угадывать и проверять, копипастить, не иметь полного тестового покрытия и т.д., и, следовательно, ошибки проскакивают очень часто. Насколько отличается работа над критически важным программным обеспечением?
О: Работая [в SpaceX] как над критическим, так и над некритическим к безопасности программным обеспечением, вам абсолютно необходимо иметь другой менталитет. Самое главное — убедиться, что вы знаете, как поведет себя ваше программное обеспечение во всех различных сценариях. Это влияет на весь процесс разработки, включая проектирование, реализацию и тестирование. Проектирование и реализация будут иметь тенденцию к созданию более мелких компонентов с четкими границами. Это позволяет полностью протестировать эти компоненты, прежде чем они будут встроены в более широкую систему. Однако полная система все равно должна быть протестирована, что делает сквозное тестирование и наблюдаемость важной частью процесса. Выдавая информацию о решениях, которые принимает программное обеспечение, в виде телеметрии, мы можем автоматизировать мониторинг программного обеспечения. Эта автоматизация может быть использована при разработке, регрессионном тестировании, а также при тестировании программного обеспечения, работающего на реальных аппаратах во время полетов. Это позволяет нам быть уверенными в том, что программное обеспечение работает так, как ожидается, на протяжении всего жизненного цикла, особенно когда на борту находится экипаж. — Джаретт
В: Какие проблемы необходимо преодолеть, чтобы реализовать непрерывную развёртку и доставку для встроенных, орбитальных систем, таких как Starlink? Развертываете ли вы свое программное обеспечение в контейнерах? Какие трудности возникают при тестировании такой обширной сети? Продолжайте в том же духе!
О: Чтобы управлять большой спутниковой группировкой без необходимости привлечения сотен операторов-людей, мы полагаемся на автоматизацию программного обеспечения, работающего на земле и на спутниках. Для того чтобы полностью протестировать наши системы в сквозной конфигурации, это означает, что мы должны встроить сотни различных программных сервисов в среду разработки.
Еще одна проблема тестирования заключается в том, что не всегда возможно проверить все возможности одним тестом. Например, нам нужны автоматизированные тесты, которые проверяют каналы связи между спутниками и землей. У нас есть испытательные стенды HITL (hardware in the loop) для спутников, и мы можем установить макет наземной станции с фиксированной антенной. Мы можем провести тест, в котором имитируем пролет спутника над наземной станцией, но мы должны изменить программное обеспечение, чтобы спутник думал, что он всегда находится в контакте с нашей стационарной антенной. Это позволит нам протестировать весь радиочастотный и сетевой стек, но не позволит проверить логику наведения антенны. В качестве альтернативы мы можем запустить чисто программное моделирование для тестирования наведения антенны. Мы должны убедиться, что у нас достаточно поэтапного тестирования всех важных аспектов системы. — Натали
В: Насколько сильно любят Python в SpaceX? Очевидно, что он не может быть в роли пассажира первого класса, но развернут ли он где-нибудь в значительном объеме?
О: У нас в SpaceX очень много Python! Многие из наших наземных инструментов имеют значительные аспекты Python — такие системы, как наши службы анализа данных, инфраструктура тестирования и система CI/CD. Он не используется для управления космическими аппаратами, но мы очень часто обращаемся к Python для создания многих других систем. Одним из уникальных аспектов Python является то, что это отличный язык для изучения и работы на нем инженеров, не являющихся программистами (механики, двигателисты…). Мы добились больших успехов, используя его для написания тестовых примеров для программного и аппаратного обеспечения, автоматизированных конвейеров анализа данных и других подобных областей, где требуется вклад инженеров с различным образованием. — Кристин
В: Каков ваш стек решений? Языки, фреймворки, библиотеки и т.д…. Какие инструменты/редакторы/IDEs вы используете в повседневной работе? Как QA проверяет работу разработчиков, ведь вы не можете просто слетать туда и протестировать её?
О: В SpaceX мы не отделяем QA от разработки — каждый инженер, пишущий программное обеспечение, также должен участвовать в его тестировании. Как правило, мы стараемся проводить как можно больше испытаний до слияния на наших высокоточных аппаратных стендах. Наш тестовый код и результаты тестирования проходят экспертную оценку наряду с летным кодом, чтобы убедиться, что мы тестируем все правильные вещи. У нас также есть независимые инженеры, разрабатывающие сквозные тесты, которые подвергают нагрузке всю систему. Уникальность тестирования для большой спутниковой группировки заключается в том, что мы можем использовать некоторые спутники для тестирования новых функций. Мы проводим регрессионные тесты программного обеспечения, чтобы убедиться, что оно не нарушит критически важные функции, но затем мы можем выбрать спутник, развернуть новую функцию и наблюдать за ее поведением с минимальным риском для группировки. — Натали
В: Какой подход лучше для программного обеспечения полета ракеты — асинхронный или синхронный с большим количеством потоков? При выборе инструментов, стандартов, придерживаетесь ли вы консервативных решений (C++ pre ’11 rev) или готовы пробовать новое (новые стандарты C++17/20, Rust)?
О: Самое главное — гарантировать стабильную производительность. Вы не можете летать на ракете, если она работает как лагающая видеоигра! Мы используем сочетание синхронных и асинхронных методов, в зависимости от конкретной задачи. Мы не боимся пробовать новые системы, стратегии, стандарты или языки, особенно на ранних этапах разработки новой программы. Тем не менее, успех миссии имеет первостепенное значение, и нам необходимо следить за сохранением работоспособности кода в будущем, поэтому мы держимся немного в стороне от передовых технологий по сравнению с обычными стартапами. — Ашер
В: Как SpaceX удается использовать Linux вместо настоящей операционной системы реального времени на своих транспортных средствах? Я знаю, что патч PREEMPT_RT делает Linux более годящимся для realtime, но все же не полностью. Кажется, что полеты на ракетах и космических кораблях с экипажем — это то место, где жесткие гарантии реального времени необходимы постоянно.
О: Хотя я не могу вдаваться в подробности, мы разрабатываем наше программное обеспечение для работы без ОС реального времени. Мы также используем пользовательскую сборку Linux и полностью понимаем среду, в которой работает наше программное обеспечение и ОС. Работа в гораздо более ограниченной среде (по сравнению, скажем, с открытым интернетом) в сочетании с обширным инструментарием и тестированием аппаратного обеспечения в цикле означает, что мы можем быть уверены, что ОС будет вести себя на орбите так, как мы ожидаем». -Джарретт
В: Вы внедряете алгоритмы управления во встроенные системы?
О: Мы всегда ищем подходящее место для запуска процесса управления. Иногда лучшим местом для размещения алгоритма управления является встраиваемая система, расположенная близко к управляемому объекту. В других случаях процесс должен быть более централизованным. Если вы подумаете о таком сложном транспортном средстве, как Starship, то там нет единственного процесса управления, поскольку вам нужно управлять двигателями, закрылками, радиосистемами и т.д. — Ашер
В: Как выглядит ваш конвейер CI/CD? Устанавливаются ли новые сборки на «производственную» или «похожую на производственную» плату, подключенную к автоматизированной тестовой стойке, которая обеспечивает симулированные входы для датчиков, или все автоматизированные тесты проводятся в полностью симулированной среде?
О: У нас есть много различных типов тестовых сред. Некоторые из них являются чисто моделируемыми средами, которые мы называем HOOTL. Они могут работать в CI/CD, а также на рабочем столе разработчика для локальной проверки. В других случаях используются аппаратные средства, приближенные к реально летающим, которые мы называем HITL (Программно-аппаратные). Наши установки Starlink HITL — это просто спутники, которые мы снимаем с производства и встраиваем в наши системы CI. Мы настраиваем наши CI-конвейеры так, чтобы начать с быстрых, недорогих тестов для выявления основных ошибок. Затем, если они проходят, мы запускаем более длинные и сложные тесты. У нас также есть разные конвейеры для разных частей системы. Например, в Starlink у нас есть конвейер для тестирования программного обеспечения пользовательского терминала в изоляции. Если эти тесты пройдут, они будут включены в другие конвейеры, тестирующие интерфейс между программным обеспечением пользовательского терминала и спутниками». -Натали
В: Какие инструменты вы используете для тестирования и непрерывного развёртывания? И как вы моделируете оборудование ракеты и спутника?
О: Многое из этого создаётся самостоятельно. У нас есть целая команда, занимающаяся созданием инструментов CI/CD, а также основной инфраструктуры для тестирования и моделирования, которую используют наши транспортные средства. Запуск высокоточных физических симуляторов вместе с нашим программным обеспечением для его тестирования ставит перед нами интересные задачи, с которыми большинство готовых инструментов CI/CD справляются не очень хорошо. Моделирование не только требует много вычислений, но и может быть очень длительным (вспомните полет Dragon от взлета до стыковки), и нам нужно иметь возможность запускать как чисто программные, так и аппаратно-программные симуляции, когда мы загружаем программное обеспечение на тестовые стенды с копиями реальных компьютеров и электроники. Мы проделали большую работу, чтобы разработчики могли легко запускать эти тесты во время своей повседневной работы — мы можем запускать те же виды тестов на наших рабочих станциях, что и в кластере CI, и мы можем запускать примеры на тестовых стендах с аппаратным обеспечением в контуре еще до объединения изменений. Это позволяет нам быть уверенными в коде, который мы пишем. Мы также используем некоторые готовые решения; например, мы широко используем Bazel для сборки и модульного тестирования — Натали.
На этом заканчиваю первую часть, во второй части будут ответы на вопросы о Старшипе, Драконе и Старлинке.
