6 июня 2020 года представители SpaceX ответили на вопросы своих подписчиков на канале Reddit. На вопросы отвечали:
Джефф Декстер – менеджер программного обеспечения и кибербезопасности в SpaceX
Джош Салкин - ведущий дизайнер программного обеспечения для Crew Dragon
Венди Шимата – менеджер команды разработчиков программного обеспечения Dragon, работала над отказоустойчивостью и безопасностью на Dragon
Джон Дитрик - возглавляет работу по разработке программного обеспечения для Demo-2
Софиан Хнайде - работал над программным обеспечением Crew Displays для Demo-2
Мэтт Монсон - работал над Dragon, а сейчас возглавляю программное обеспечение Starlink
Преимущественно вопросы касались программного обеспечения на Crew Dragon и ракет SpaceX. Подписчики пытались узнать поподробнее об уже известных деталях: о С++, кодах, библиотеках, Starlink и тп., однако команда SpaceX дала максимально общую информацию, близкую к формальным источникам. Увы, инсайда не получилось. Кроме этого, подписчики задали вопрос о непогашенном техническом долге SpaceX по причине пренебрежения к качеству разработки программного обеспечения. Вот наиболее популярные вопросы, поддержанные самим подписчиками:
Вопрос 1
1.Пожалуйста, дайте обзор наивысшего уровня управляющей программы Falcon9 и Dragon. Какие виды связи используются между Dragon и Falcon9?
2. Является ли управляющее программное обеспечение, работающее на Falcon9, специальной сборкой, предназначенной для миссии (запуск спутника LEO, доставка на МКС и т. д.)? Или это одна и та же базовая программа с другим набором параметров / целей / сценариев?
3. Как работает программное обеспечение AFTS?
4. Назовите несколько программ с открытым исходным кодом, используемых для Falcon / Dragon, кроме ядра Linux и Chromium.
6. Играют ли команды разработчиков программного обеспечения Falcon / Dragon какую-либо роль в день запуска?
Ответ SpaceX
1. На наивысшем уровне у нас есть много компьютеров, каждый из которых построен и настроен так, чтобы наилучшим образом соответствовать поставленной задаче. Все они синхронизированы по времени, а бортовой компьютер контролирует все действия. Почти все можно выразить в виде цикла управления в режиме реального времени: вы считываете данные некоторых датчиков, вы принимаете решение (комбинация ваших датчиков и прошедшее состояние), а затем выдаете результаты этого решения обратно аппаратному обеспечению. Это происходит множество раз в секунду. - Дитрик
2. Мы используем один и тот же исходный код для Falcon для каждой миссии, хотя мы все еще регулярно обновляем это программное обеспечение и обычно добавляем новый код в каждую миссию. У нас также есть конфигурации для программного обеспечения, предоставляемые другими инженерными группами, которые обычно меняются каждую миссию. Они вносят изменения в такие вещи, как конечный автомат, пороги отказоустойчивости, ветры в день запуска и т. д., используемое программным обеспечением для управления транспортным средством. - Джефф
3 Программное обеспечение Автономной системы безопасности полетов (AFSS - это все о безопасности) работает на множестве микроконтроллеров, независимых от бортового компьютера. Она получает входные сигналы от датчиков (например, измерения IMU), а также некоторые вычисленные входные данные от бортового компьютера. Загрузка данных миссии настраивает AFSS, для каких условий может потребоваться прекращение полета, например, когда ракета отклоняется от курса, теряет все ускорение и т. д. - Джефф
4. Das U-Boot, Buildroot, MUSL. За пределами операционной системы и программного обеспечения Crew Displays мы не используем столько внешнего программного обеспечения, сколько вы думаете - мы стараемся сделать наши программы простыми, компактными и основанными на коде, который мы понимаем. - Дитрик
5. Однозначно, хотя номинально в качестве поддержки/ перепроверки. Мы проводим много времени, изучая данные с живого транспортного средства, прежде чем миссия начнется, и у нас есть специалисты по программному обеспечению в Центре управления полетами на всех важных этапах полета, на случай, если что-нибудь случится. У нас есть отличная команда по обучению миссии, которая испытывает наших операторов управления полетами различным сценариям моделирования перед полетом, и мы надеемся, что реальный день запуска намного скучнее, чем у этих симуляторов! Я счастлив сказать, что для Demo 2 это было так! – Дитрик
Вопрос 2
1.Какой язык программирования наиболее часто используется для разработки программного обеспечения F[alcon]9 и Dragon? Это C или C ++?
2. Какую парадигму программирования вы используете для разработки программного обеспечения для F9 и Dragon? Процедурный, объектно-ориентированный, функциональный, сочетание?
3. Используете ли вы какое-либо программное обеспечение с открытым исходным кодом (я в основном имею в виду библиотеки)? Если ответ «да», какой из них используется наиболее часто (или самый важный / актуальный)? Если ответ «нет», вы хотя бы используете стандартную библиотеку, предоставляемую языком (например, C ++ STL), или все реализовано собственными силами?
4. Как вы выполняете обнаружение и исправление ошибок во время полета?
5. Программное обеспечение состоит из небольших (иногда независимых) модулей или все объединено в один большой модуль? Например, насколько тесна интеграция модуля Crew Dragon GNC с модулем, который управляет средой Crew Dragon (давление, уровень кислорода, температура и т. Д.)?
6. Если бы вы удалили всю кодовую базу, сколько времени, по вашим оценкам, потребовалось бы, чтобы переопределить все с нуля (имея текущую команду и накопленное ноу-хау)? 1 год? 5 лет? 10 лет? Как вы думаете, результат будет лучше, чем текущая реализация? Что бы вы сделали отличным от того, что в настоящее время делается?
7. Может быть, немного связано с #6: как часто вы полностью переопределяете модуль, чтобы сделать его лучше (быстрее / чище / безопаснее и т. д.) вместо рефакторинга существующего кода?
Ответ
Все автономное программное обеспечение прикладного уровня написано на C ++. Мы обычно используем методы объектно-ориентированного программирования из C ++, хотя нам нравится делать вещи максимально простыми. Мы используем библиотеки с открытым исходным кодом, в первую очередь стандартную библиотеку C ++, а также некоторые другие. Однако мы ограничиваем наше использование библиотек с открытым исходным кодом только очень высококачественными библиотеками и часто предпочитаем разрабатывать наши собственные библиотеки, когда это возможно, чтобы мы могли сами контролировать качество кода. С точки зрения обработки ошибок, есть много разных аспектов. Радиационные ошибки в компьютерах обрабатываются наличием множества компьютеров и выборкой их результатов. Ошибки в датчиках обрабатываются наличием нескольких разных датчиков. Ошибки при передаче данных обрабатываются с помощью кодов обнаружения или исправления ошибок, прикрепленных к полезной нагрузке. Программное обеспечение определенно состоит из нескольких небольших модулей, дизайн которых был одним из главных, над которыми я работал. Существует иерархия дизайна от низкоуровневого компонента до подсистемы и всего транспортного средства. Различные подсистемы обычно изолированы друг от друга, иногда на одном компьютере, иногда на разных компьютерах, с узкими интерфейсами между ними. Я не уверен, сколько времени нам потребуется, чтобы переписать код с нуля. Мы не планируем удалять его в ближайшее время. Джош
Вопрос 3
SpaceX известен своим аппаратным тестированием в цикле:
Какая доля (примерно) человеко-часов разработки программного обеспечения идет на разработку этих систем?
Как выглядит цикл разработки симуляторов полета (скажем, для систем Falcon)? Как часто они обновляются на основе телеметрии? Что самое сложное в цикле запуска модели?
С несколькими сотнями спутников Starlink на орбите, есть ли такие части индивидуального или группового функционирования, которые, как вы поняли, недостаточно хорошо проработаны в тестировании?
Как далеко вглубь физики идут тесты спутников Starlink? Например, если вы пытаетесь оценить задержки для межспутниковой или спутниковой наземной связи, можете ли вы рассматривать радиоканалы как черный ящик, или вы также пытаетесь смоделировать работу фазированной антенной решетки?
Мне также интересно компьютерное оборудование-SpaceX славится тем, что создает компоненты внутри компании. С учетом того, что Starlink наблюдает за десятками тысяч спутников на околоземной орбите, есть ли какие-либо области, где пользовательские ASIC были бы дешевле, чем решения COTS? Существуют ли примеры компонентов, которые "перепроектированы" на срок службы Starlink ~< 10 лет (возможно, для радиационной устойчивости), которые можно было бы перестроить для значительной экономии затрат?
Ответ
При внесении изменений мы ожидаем, что наши инженеры будут критически думать (и расспрашивать друг друга) о функциональном тестировании (как я узнаю, что мои изменения работают?) и регрессионном тестировании (как я узнаю, сломал ли я что-то еще, или если это сломается в будущем?). Создание тестовых примеров, которые мы можем запустить на месте, - это отличный способ ответить на эти вопросы, и мы делаем много этого, но это не единственный способ.
Что касается Starlink, нам нужно думать о наших спутниках больше как о серверах в центре обработки данных, чем о специальных уникальных транспортных средствах. Есть некоторые вещи, в которых мы должны быть абсолютно уверены (командование, обновление программного обеспечения, энергопотребление и безопасность оборудования), и, следовательно, заслуживаем наличия конкретных тестовых примеров. Но есть также много вещей, к которым мы можем проявить гибкость - для этих вещей мы можем использовать подход, более похожий на способ разработки веб-сервисов. Мы можем развернуть тестовую сборку для небольшого подмножества наших транспортных средств, а затем сравнить ее эффективность с остальной частью парка. Если оно не делает то, чего мы хотим, мы можем настроить его и попробовать еще раз, прежде чем объединить его с остальным парком. Если мы увидим проблему при развертывании Starlink, мы можем сделать паузу, откатиться назад и повторить попытку. Это чрезвычайно мощное изменение в нашем мышлении о космических аппаратах, и абсолютно важно для того, чтобы иметь возможность быстро повторять нашу систему.
Мы определенно нашли места, где в наших тестах были дыры. Имея сотни спутников в космосе 24/7, вы найдете крайние случаи в каждой системе и это будет означать, что вы видите безумные края колоколообразной кривой. Важно быть уверенным в ядре, которое обеспечивает безопасность оборудования, сообщает о проблеме, а затем дает время для восстановления. У нас было много случаев, когда у спутника на орбите произошел сбой, о котором мы никогда даже не задумывались, но у него была возможность достаточно долго находиться в безопасности для, чтобы мы могли отладить его, найти способ исправления или обходной путь, а также запустить обновление программного обеспечения.
И да, мы много работаем над разработкой ASIC для проекта Starlink. – Мэтт
Вопрос 4
1. Известно, что на экранах Crew Dragon работают Chromium и JS. Используете ли вы реактивную библиотеку, и если да, то это разработано собственными силами или это уже существующая библиотека / фреймворк
2. Был ли симулятор стыковки, разработанный самой командой разработчиков Crew Displays, или это был отдельный проект?
3. В некоторых кадрах управления полетами я заметил, что интерфейс очень похож на дисплеи в Crew Dragon. Может ли то же самое программное обеспечение для отображения экипажа быть подано с сервера на земле, передавая прямую телеметрию от Dragon во время полета? Если да, может ли / будет ли это программное обеспечение использоваться для мониторинга Cargo Dragon также на будущих рейсах?
4. Есть ли шанс получить снимки экрана экипажа в высоком разрешении?
5. Один из вопросов касается Starlink: как создание программного обеспечения Crew Display повлияло на разработку интерфейса Starlink для операций SpaceX (представления карт, визуализация данных и т. д.)?
Ответ
1. Да, мы используем Chromium и мы используем реактивную библиотеку, которую мы разработали сами. - Софиан
2. Симулятор стыковки - это совершенно отдельный код от того, что есть на экранах Crew, хотя он был разработан нашей командой Crew Display. Он начался как забавный проект Шейна Мильке и Майка Вестенхавера, прежде чем мы решили закончить его и разместить в Интернете перед демонстрацией. - Джефф
3. Мы можем запустить – и действительно тот же код, который есть на экранах экипажа на земле. Единственное ограничение заключается в том, что мы не обязательно получаем всю ту же телеметрию на земле, что и в кабине, из-за ограничений нашего бюджета. Мы могли бы, но мы обобщаем приоритеты, вместо этого получая другую критическую телеметрию. Джефф.
4. Мы определенно хотим поделиться кадрами высокого разрешения Crew. Мы посмотрим, сможем ли получить одобрение, чтобы показать вам Боба (Бенкена) и Дуга (Херли) близко. - Джефф
5. Технология Crew (особенно карта и оповещения) легла в основу нашего пользовательского интерфейса для первой пары спутников Starlink (Tintin). С тех пор он вырос на тонну, но было здорово, что Боб и Дуг использовали что-то, что нам тоже казалось знакомым. – Мэтт
Вопрос 5
1. Я учусь в средней школе, и что я могу сделать, если когда-нибудь в будущем захочу получить работу программиста в SpaceX?
2. Я живу не совсем близко от Хоторна. Есть ли у SpaceX рабочие места на восточном побережье, и если нет, то будет ли SpaceX рассматривать такую возможность в будущем?
3. (для Джеффа Декстера) можете ли вы раскрыть некоторые детали планов действий на случай непредвиденных обстоятельств во время полета? (например, отказ двигателя во время подъема, что-то идет не так во время посадки и т. д.)
4. (для Джоша Салкина) принимала ли команда разработчиков программного обеспечения обратную связь от Боба и Дуга во время обучения?
5. (для Венди Шимата) как вы вычисляете номера LOM (потеря миссии) и LOCV (потеря экипажа/транспортного средства) для Dragon?
6. (Джон Дитрик) Использует ли SpaceX ИИ в каком-либо программном обеспечении?
7. (для Софиана Хнайда) какой тип технологии отображения использует Дракон? (например, ЖК-дисплей, IPS, OLED и т. д.)
8. (для Мэтта Монсона) Когда вы ожидаете, появление лазерной связи на спутниках Starlink?
Ответ
1. Получите степень бакалавра компьютерных наук (или что-то) похожее. Потратьте время, чтобы по-настоящему убедиться, что вы знаете, как все работает - инженеры, хорошо работающие в SpaceX, тщательно разобрались в том, как работает их код, как работает сеть, как работает Linux, как работает оборудование и т. д. Получите реальный опыт создания вещей и решения сложных проблем, либо через хобби-проекты, либо на стажировках (в SpaceX!) - Джефф
2. Наши инженеры-программисты в основном находятся в Сиэтле и Хоторне, хотя некоторые из них также работают с техасских сайтов. Если вы серьезно заинтересованы в присоединении к SpaceX, мы всегда ищем замечательных инженеров, поэтому обращайтесь - никогда не помешает пообщаться и посмотреть, сможем ли мы из этого что-то сделать. – Джефф
3. В нашем программном обеспечении непредвиденные обстоятельства бывают разных форм. Как уже отмечалось, мы дублируем почти все, поэтому мы можем допустить потерю одного летного компьютера, датчика, привода и т. д. на Falcon и на Dragon. На уровне системы Falcon и Dragon спроектированы таким образом, что потери таких вещей, как движки, могут быть допустимы, а наши алгоритмы компенсируют это. Сюда также можем добавить определенные непредвиденные обстоятельства с нашими конечными автоматами. Например, конечный автомат Dragon предназначен для автономного переключения с подхода на прорыв, если наблюдаются определенные сбои. – Джефф
4. Да, вся команда разработчиков программного обеспечения получила отзывы от Боба и Дуга по всем аспектам программного обеспечения. Хотя Боб и Дуг были в основном сфокусированы на дисплеях, кнопочных панелях и аудиосистеме, они также интересовались тем, как работает программное обеспечение в целом, особенно возможностями резервного копирования, которые могут быть необходимы в чрезвычайных ситуациях. Их отзывы были неоценимыми для улучшения системы. – Джош
5. Я на самом деле не знаю! У нас есть отличная команда по надежности полетов, основная задача которой - рассчитать эти цифры и обеспечить их актуальность с учетом различных изменений в оборудовании и конфигурации. – Венди
6. Дракон не использует ИИ. – Дитрик
7. Тем не менее, Dragon использует компьютерное зрение для навигации. – Джош
8. ЖК - Софиан
Вопрос 6
1. Как вы решаете технические проблемы в вашей организации? Помогает ли постоянное давление, которое оказывает компании Илон тем, что вы возвращаетесь к прошлым проектам?
2. Отслеживаете ли вы производительность своего кода? Я предполагаю, что это критический параметр проектирования для встроенной программной системы с критическими временными ограничениями, подобными вашему, поэтому мне интересно, как ваш подход сравнивается с чем-то вроде индустрии видеоигр, где такая практика является распространенной, но, вероятно, не такой строгой, как для космического полета.
3. Какой уровень строгости используется в безопасности Starlink? Как мы, обычные граждане, сможем чувствовать себя комфортно при мысли о том, что частная компания будет управлять тысячами интернет-спутников таким образом, чтобы они были достаточно безопасны и их нельзя было контролировать плохим деятелем? Это может иметь последствия для нескольких поколений, если ваша команда ошибается, поэтому было бы здорово, если бы вы могли публично рассказать о стратегии.
Ответ
1. Мы учитываем непогашенный технический долг, и поскольку мы небольшая команда, любая неэффективность очень заметна. Говоря о многих наших транспортных средствах, часто нами запускаемых, мы стремимся инвестировать в оперативную команду, чтобы гарантировать, что мы сможем сократить этот технический долг и сделать каждый последующий полет максимально безболезненным. Тем не менее, всегда много чего происходит, поэтому при любом решении о том, как тратить наше время, мы должны думать о правильном балансе между возможностями и погашением существующего долга. – Венди
2. Мы используем систему непрерывной интеграции, так что наш код всегда тестируется, но мы также анализируем эти данные в режиме реального времени, чтобы убедиться, что наши показатели производительности находятся в ожидаемых пределах. Кейсы настроены таким образом, что, если мы нарушаем какие-либо ключевые показатели эффективности, кейс «проваливается», и инженер перепроверяет. - Венди
3. В общем, что касается безопасности, то здесь есть много уровней. Для начала мы разработали систему применения сквозного шифрования данных наших пользователей, чтобы сделать взлом спутника или шлюза бесполезным для злоумышленника, пытающегося перехватить связь. Каждый элемент оборудования в нашей системе (спутники, шлюзы, пользовательские терминалы) предназначен для запуска только программного обеспечения, подписанного нами, поэтому даже если злоумышленник взломает его, он не сможет получить постоянную точку опоры. А затем мы ужесточаем внутреннюю часть системы (включая службы в наших центрах обработки данных), чтобы затруднить использование уязвимости. Мы продолжаем усердно работать, чтобы гарантировать, что наша система в целом должным образом укреплена, и у нас впереди еще много работы (мы нанимаем специалистов!), но к этому мы относимся очень серьезно. - Мэтт
