Прибыла последняя часть ответов члена команды полётного ПО Алексея Пахунова на многочисленные вопросы. В основном тут более технические вопросы. Здесь можно найти первую часть, а здесь вторую.
❓Вопросы про используемые языки программирования, операционные системы, железо и т.п.
->См. AMA. Вкратце, в полёте и системах, обслуживающих полёт, используется С++ и Linux. В менее критичных системах — широко используется Python и другие языки.

Ред.: в 2013 году команда Алексея рассказала, что код ракеты составляет примерно 200-300 тысяч строк, весь на C++. Команда очень довольна получившимся кодом. В наземной инфраструктуре много используется LabVIEW, Matlab для анализа. Самым большим достижением тогда команда назвала стыковку с МКС, отметив большую сложность этого процесса. Кроме того, они рассказали, что проектируют свои ракеты в KSP.

❓В чем главное отличие программ такого уровня, от обывательских? Есть ли сильные ограничения в производительности кода, или это не на первом/втором плане?
->Основное отличие от “обычных” программ — высокие требования к надёжности кода и предсказуемости поведения. Если Word или страница в браузере могут упасть с минимальными последствиями, то на ракете это чревато многомиллионными потерями и возможными человеческими жертвами. Это влияет на архитектуру, способы обработки данных и стиль написания кода. К примеру, абсолютная производительность кода менее важна, чем стабильное время выполнения. Приветствуется простой код — его легче проверить и легче протестировать. В код встраивается много диагностики. И т.д.

❓Ну и если можно бонусом, парочку жаргонных терминов из повседневного общения программистов в SpaceX.
-> Словарь

❓Какой размер вашей команды и сколько всего программистов?
Как много наших (русских/соотечественников/индусов) ребят там?
->Непосредственно в моей команде (Falcon Software) — чуть больше десятка человек. Сколько всего программистов — сложно посчитать. Офис в Сиэтле подрос заметно. Многих коллег оттуда я в живую ещё не видел. Выходцев из СНГ хватает. Я, наверное, смогу человек десять насчитать. Иммигрантов довольно много, хотя из-за ограничений ITAR разнообразия меньше, чем в обычных IT компаниях.

❓Насколько отличается работа в SpaceX от Google и Microsoft? И в чём именно?
->В Google и Microsoft, куда ни плюнь, — в программиста попадёшь. Там всё крутится вокруг софта. В SpaceX софт — это важная, но не единственная часть процесса. Мы много общаемся с не-разработчиками и стиль мышления и решения проблем у них отличается от привычного. Приходится отказываться от привычных шаблонов и учить новые. Кроме этого, в Google и Microsoft дедлайны “мягче”. Если какая фича не готова, её можно относительно легко перенести на следующий релиз. У нас же это сложнее. Бывает так, что определённая функциональность нужна под конкретный полёт, скажем, нужно добавить поддержку нового железа. Бывает, что анализ показывает, что новый код увеличит вероятность успеха миссии на X%. А бывает так, что находится баг, который обязательно нужно исправить до следующего полёта.

❓Как в SpaceX тестируют написанный код?
-> Очень тщательно. 🙂 Если серьёзно (и не углубляясь в детали, так как ITAR) — код проверяется множеством разных способов, включая юнит тесты и интеграционное тестирование. Последнее весьма разнообразно и наиболее затратно по времени. В дополнению к этому, процесс разработки построен так, что каждое решение принимается более чем одним человеком.

❓Насколько часто приходится изобретать велосипед? Как относятся к хардкоду и есть ли у вас код ревью в команде?
-> Всякое бывает, при необходимости можно и велосипед изобрести. Мы стараемся использовать минимум сторонних библиотек в коде. Дело в том, что любой критичный код должен соответствовать нашему стандарту качества. Сторонние библиотеки по определению следуют своему собственному стандарту — в результате нам приходится затыкать дырки самостоятельно. Приходится весь код просмотреть, а бывает, — и юнит тесты дописать.

Ред.: код ревью, естественно, есть.

❓Почему при предстартовой подготовке часто идут сдвиги сроков вправо (кроме погодных причин)? Почему предстартовая подготовка занимает так много времени?
-> Подготовка к запуску — это сложный процесс. Ракета — это сложное устройство, которое состоит их множества разных систем, каждую из которых нужно проверить. Пусковой стол — это сложное устройство, и далее по тексту. В запуске участвует множество заинтересованных и не очень сторон — компания заказывающая пусковые услуги, провайдер пусковых услуг, range (слежение и телеметрия), управление безопасностью полётов и судоходства, и десятки других компаний и организаций. Иными словами, всё упирается в сложность процедуры запуска. Со временем процедуры оптимизируются и автоматизируются; проверки оборудования переносятся ближе к производству — запуск становится рутинной (и не очень сложной) операцией. Хорошая аналогия — запуск ВАЗ 2101 (AKA Fiat 124) и Toyota Camry в мороз. Первый требует сноровки и неких манипуляций с подсосом. Вторая — просто повернуть ключ. В ракетостроении мы ещё не доросли до Fiat 124.

❓Почему в период неготовности пускового комплекса 39а, не осуществляются пуски с Ванденберга? (при их наличии в манифесте на 2017 год)

->Я понятия не имею, почему, соответственно могу поспекулировать на эту тему. Во-первых из Ванденберга и с мыса Канаверал осуществляются запуски на разные орбиты. Из Калифорнии запускают на полярные орбиты. Траектория идет над Тихим океаном прямо на юг. Из Флориды запускают на меньшие наклонения — траектория идет над Атлантическим океаном на восток. Во-вторых, у заказчика могут быть свои ограничения на запуск: готовность спутника, ресурсы на его сопровождение, и т.д. В-третьих, разные пусковые столы получают ракеты из одного источника. Соответственно, производство ракет планируется наперед с учетом факторов, влияющих на запуск. Я уверен ограничения, прописанные в контрактах на запуск, учитываются тоже.

❓Почему между пусками ракет такой большой срок (не менее 2 недель)?

-> Я уже говорил, что запуск это сложный процесс? 🙂

❓Увеличится ли количество запусков в месяц, если оба стола будут в готовности к пускам?

-> Я, конечно, не Кассандра, но я думаю, что идея увеличить пропускную способность, запуская с двух столов параллельно, обсуждалась.


Мы вновь выражаем огромную благодарность Алексею Пахунову за ответы на ваши вопросы! На этом мы завершаем нашу серию вопросов и ответов. Читайте личный блог Алексея.

Источник

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: