AMA с разработчиками из SpaceX (часть 2)

19.05.2021

Продолжение перевода AMA от SpaceX.

AMA с разработчиками из SpaceX (часть 2) — Экран корабля Crew Dragon

В субботу 15 мая компания SpaceX провела серию вопросов и ответов о разработке ПО в различных проектах компании. Я выделил и перевёл самые интересные из них.

В интервью участвовали:

Джарретт Фарнитано — работает над программным обеспечением корабля Dragon, включая дисплеи для экипажа.
Кристин Хуанг — ведет прикладное программное обеспечение для спутникового созвездия Starlink.
Жанетт Миранда — разрабатывает встроенное программное обеспечение для лазерной связи.
Ашер Данн — ведет программное обеспечение для Starship.
Натали Моррис — ведет инфраструктуру тестирования программного обеспечения для спутников.

Вопросы о Starship’е

В: Каков логический процесс, используемый Starship для определения валидности двигателя для переворота и посадки?

О: Как вы можете судить, посмотрев видеоролики с SN8 по SN15, в этой области мы провели много попыток! По сути, Starship разработан так, чтобы в режиме реального времени выбирать двигатель(и), наиболее подходящий(ие) для выполнения переворота и посадочного маневра. Мы обновили ПО, чтобы оно лучше определяло потенциальные проблемы с двигателями, и корректировали, какие проблемы могут быть компенсированы программно (можно использовать этот двигатель), а какие нет (RUD!), в каждом полете. -Ашер

В: Как поздно вы вносите изменения в программное обеспечение во время испытательных полетов Starship? Мы видели, как многие вещи меняются, иногда в последнюю минуту, является ли программное обеспечение одним из них? Приходилось ли вам менять стратегию флипа/посадки между первой загрузкой программного обеспечения и финальным полетом? Или это более тонкий процесс и все остается так, как было запланировано?

О: Поскольку Starship находится в стадии разработки/тестирования, мы настроены на внесение изменений в программное обеспечение гораздо позже, чем в другие наши программы. Существует множество различных типов изменений программного обеспечения — большие новые фичи или рефакторинг, вплоть до изменения одного числа. Ключевой вопрос для каждого изменения — как мы узнаем, что это изменение правильное? Какие тесты нам нужно провести, прежде чем мы полетим? Если мы можем быть уверены, что внесение изменений в последнюю минуту повышает вероятность успешного тестирования, мы не уклоняемся от этого (хотя, конечно, мы предпочитаем, чтобы все было готово заранее, когда это возможно). — Ашер

В: Каким будет пользовательский интерфейс звездолета, будет ли он основан на Crew dragon? Или это будет новый дизайн? Если это так, то будет ли он больше? И какие функции потребуют наибольших изменений?

О: Технология, скорее всего, будет похожа на Dragon, но дизайн, использование и цели бортового пользовательского интерфейса звездолета значительно отличаются от Dragon. Дисплеи экипажа Dragon — это три сенсорных экрана в небольшом транспортном средстве с единственным пунктом назначения, обслуживающем небольшую группу пассажиров и их груз. Starship будет осуществлять полеты в разные точки мира, на Луну, Марс и далее. Пользовательский интерфейс Starship должен быть удобным для использования на устройствах и сенсорных экранах всех размеров по всему кораблю (общие помещения, жилые отсеки, погрузочные зоны и мостик) и должен поддерживать пользователей с совершенно разными профессиями и навыками. Короче говоря, это гораздо более сложная задача, чем Dragon! — Ашер

В: Не могли бы вы уточнить, что такое «быстрая итерация… пользовательского интерфейса Starship»?

О: Мы используем ту же архитектуру внешнего интерфейса на основе веб-компонентов, что и в Dragon Crew Displays, но мы сделали все настраиваемым пользователем. Это позволяет инженерам и операторам непосредственно настраивать представления, необходимые им для работы, а нам, команде разработчиков программного обеспечения, сосредоточиться на совершенствовании основного интерфейса и платформы UI. Работа с веб-системой означает, что мы можем быстро создавать прототипы, тестировать и поставлять новые возможности пользовательского интерфейса. В процессе разработки мы можем направить локально размещенный экземпляр пользовательского интерфейса на работающую симуляцию или даже на реальные данные автомобиля и воспользоваться такими функциями, как горячая загрузка, чтобы обновлять пользовательский интерфейс в режиме реального времени. Сложность заключается в том, чтобы обеспечить такой уровень гибкости и одновременно развиваться в направлении улучшения, фокусировки и качества дисплеев экипажа Dragon. Как правило, это проблема всего стека — во многих случаях интерфейс становится сложным и уродливым, когда саму систему трудно понять или использовать. По мере созревания Starship мы тесно сотрудничаем с контроллерами и инженерами, чтобы выяснить, где находятся эти болевые точки и как мы можем их устранить. В конечном итоге мы хотим, чтобы Starship был прост в управлении и понятен во время повседневных полетов». — Ашер

В: Сколько программного обеспечения между первой ступенью Falcon 9 и первой ступенью Superheavy может быть использовано повторно или должно быть переписано? Какие новые вещи вы ожидаете узнать и понять в SuperHeavy по сравнению с тем, что вы уже знаете и можете применить в Falcon 9.

О: В Starship повторно используются многие идеи и некоторый код из Falcon. Мы всегда хотим тратить нашу энергию на решение новых проблем, которые приближают нас к Марсу. Каждый раз, когда возникает новая проблема, мы вспоминаем нашу базу кода и спрашиваем, какие инструменты у нас уже есть, которые позволят нам решить ее как можно быстрее? — Ашер

Вопросы о Crew Dragon

В: Я вижу, что экипаж на «Драконах» использует iPad и сенсорные экраны. Каков запасной вариант, если эти дисплеи выйдут из строя? Являются ли эти дисплеи «космически закаленными», или обычные дисплеи выдерживают воздействие радиации в космосе во время стыковки с МКС?

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

В: Можете ли вы показать нам фрагменты пользовательского интерфейса? Как информационный дизайн помогает решать возникающие проблемы?

О: Для интерфейсов управления мы стремимся к философии «тихий-темный» — если транспортное средство ведет себя номинально, интерфейс обтекаем и минимален, но все же показывает общее состояние системы. Таким образом, мы визуально определяем приоритетность информации, не относящейся к номинальной, позволяя операторам и экипажу сохранять системный контекст. Информационный дизайн является сложной задачей для более инженерно-ориентированных интерфейсов. Мы в значительной степени опираемся на встроенное ПО и автоматизированный анализ, чтобы определить приоритетность наиболее важных данных для отображения. — Ашер

В: Как Вы учли использование рук в перчатках/без перчаток в пользовательском интерфейсе Crew Dragon и планшетов?

О: В пользовательском интерфейсе учитываются условия эксплуатации корабля на всех этапах полета. Это включает тряску корабля при подъеме/ спуске, когда экипаж также носит шлем, скафандр и перчатки. Все кнопки в пользовательском интерфейсе имеют минимальный размер, за рамки которого мы не выходим и который все еще работает с пальцами в толстых перчатках. Кроме того, существует целый ряд решений UI/UX, которые были продиктованы фазой полета и обстановкой в кабине. Например, расположение основных элементов навигации находится в нижней части пользовательского интерфейса, поскольку экипажу приходится поднимать руки вверх, чтобы взаимодействовать с дисплеями. Мы спроектировали интерфейс с максимально возможным количеством пустого и белого пространства, чтобы дать информации возможность дышать и быть максимально читаемой. Более важные элементы пользовательского интерфейса, такие как командные кнопки, расположены в верхней части интерфейса вне зон повышенной активности, чтобы взаимодействие с ними всегда было намеренным.
Forward View представляет собой уникальный круговой контрастный фильтр, который позволяет всем цифрам в интерфейсе быть легко видимыми при различных условиях освещения. Все элементы хорошо читаются, даже если изображение за пользовательским интерфейсом чисто белое или черное. Мы также провели многочисленные вибрационные испытания с участием мужчин и женщин разного возраста и роста, которые надевали настоящие шлемы экипажа и садились в настоящие кресла экипажа. Сиденья были помещены на вибростол для имитации условий подъема/спуска. Пока кресло тряслось, участники использовали контроллер Xbox для игры в пользовательскую игру, которая проверяла читаемость последовательностей слов и цифр со случайными размерами шрифта, цветами и расположением текста, которые также произвольно тряслись в пользовательском интерфейсе. Это помогло подтвердить, что принятые нами решения по удобству чтения шрифтов, размеров, значков, интервалов и цветов выдерживают экстремальные условия окружающей среды. Это также показало нам, что практически все интерфейсы научно-фантастических фильмов нереалистичны и будут нечитабельны в экстремальных условиях. — Джарретт

В: Как работает JS в космосе на Crew Dragon? Были ли какие-либо изменения в пользовательском интерфейсе/UX, которые команда внесла в связи с опытом работы в полете?

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

Вопросы о Starlink

Антенна пользовательского терминала Starlink

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

О: Система Starlink построена так, чтобы быть очень динамичной, поскольку наши спутники движутся так быстро (>7 км/с), что пользователь не подключен к одному и тому же спутнику более чем несколько минут. Каждый пользовательский терминал может одновременно общаться только с одним спутником, поэтому наши каналы связи между пользователями и спутниками используют электрически управляемые лучи для мгновенной смены целей со спутника на спутник, и мы временно буферизируем трафик в ожидании этой «передачи». Наши каналы связи между спутниками и шлюзами используют механически управляемые антенны, таким образом, мы должны учитывать время перемещения и убедиться, что мы не » отпустили» одно соединение, пока мы надежно не установили следующее.Хорошая иллюстрация — представить себе, как спутники, летя над Землёй, «шагают» по шлюзовым соединениям. — Жанетт

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

В: В общих чертах, можете ли вы описать сложность телеметрической системы Starlink с фиксированными наземными терминалами, и насколько больше сложностей добавляется в случае использования в движении, например, на лодках или вездеходах?

О: Самая большая проблема, которую нам приходится решать, думая о стационарных наземных терминалах, — это распределение «лучей» со спутников по каждой точке Земли, которую мы хотим обслуживать. Мы должны принять во внимание, скольким пользователям нужна полоса пропускания, радиопомехи от других спутников (включая нас самих!) и ограничения по полю зрения. Движение, как правило, не добавляет особой сложности телеметрической системе. Однако оно создает некоторые интересные проблемы, когда речь идет, например, о спутниках, которые на части своей орбиты находятся вне связи с землей. Это означает, что наша телеметрическая система должна быть устойчива к выходящим из строя и/или поздно поступающим телеметрическим данным. Движущиеся цели требуют от нас быстрого и непрерывного решения проблемы определения ориентации (в какую сторону направлена «тарелка»?). Они также изменяют количество пользователей, находящихся в данном месте одновременно, что влияет на то, какая пропускная способность необходима в этом месте. — Кристин

В Как вы гарантируете выравнивание передатчика и приемника для межспутниковой лазерной связи? Достаточно ли просто рассчитать углы, исходя из ожидаемого положения спутников, или необходимо использовать какое-то активное самонаведение?

О: Допуски на наведение для межспутниковых лазерных линий довольно жесткие, поэтому вы правы, полагая, что простого расчета углов по ожидаемому положению спутников недостаточно. Чтобы помочь представить масштаб проблемы наведения в перспективе, в угловых допусках проблема, которую мы пытаемся решить, так же трудна, как попытка выстрелить лазером из Лос-Анджелеса и попасть в здание Эмпайр-Стейт в Нью-Йорке. При установлении лазерной связи мы сначала начинаем с наведения, основываясь на ожидаемом угле, а затем организуем последовательность захвата, чтобы получить согласованную мощность с обеих сторон. — Жанетт

В: Как вы управляете различными версиями программного обеспечения с различными версиями ступеней Falcon 9/спутников Starlink? Разве команды разработчиков аппаратного обеспечения не вносят постоянные обновления и изменения в конструкцию, что создало бы необходимость иметь отдельные версии кода для каждой отдельной механической итерации?

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

В: Не могли бы вы подробнее рассказать о процессах обновления программного обеспечения/прошивки для Starlink? Создаете ли вы собственный инструментарий для организации релизов или используете существующие инструменты развертывания и тестирования кода?

О: Мы стараемся выкладывать новые сборки на весь наш парк оборудования (спутники, наземные станции, пользовательские терминалы и WiFi-роутеры) раз в неделю. Каждое устройство периодически проверяет наши серверы на предмет получения новой сборки, и если она доступна, оно загружает и применяет обновление в идеальное время, чтобы минимизировать воздействие на пользователей. Это означает, что мы действительно можем легко тестировать сборки на небольшом пуле и переходить к экспоненциальному развертыванию, изменив несколько конфигураций в базе данных. Каждое устройство также сохраняет резервную копию последнего исправного программного обеспечения, поэтому если во время обновления что-то пойдет не так (например, сбой питания, вызванный радиацией), устройство автоматически восстанавливается, загружаясь с этой резервной копии. Почти все наши инструменты для развертывания и тестирования разработаны собственными силами, в основном потому, что наша архитектура настолько уникальна и различные ограничения, с которыми нам приходится работать, потребовали бы значительной адаптации готовых инструментов. Натали