4311 1

Очередной программный сбой в Starliner мог привести к столкновению в космосе

Через семь недель после того, как капсула CST-100 Starliner не смогла добраться до Международной космической станции, как и планировалось во время первого испытания орбитального полета, представители НАСА и Boeing раскрыли предварительные результаты расследования того, что пошло не так.

Неуправляемый космический корабль Starliner, запущенный ракетой Atlas V 20 декабря 2019 года, должен был выполнить стыковку с Международной космической станцией (МКС). Миссия была разработана для демонстрации способности нового космического корабля безопасно доставлять астронавтов на МКС и обратно. Однако Starliner не удалось достичь правильной орбиты и вместо этого он провел следующие два дня, совершая полет на орбите Земли, прежде чем совершить посадку на ракетном полигоне «Белые пески» в Нью-Мексико 22 декабря.

В ходе телеконференции с журналистами в пятницу (7 февраля) администратор НАСА Джим Брайденстайн заявил, что независимая группа экспертов выявила несколько проблем во время полета с орбитальным испытанием (OFT), особенно когда речь идет о программном обеспечении космического корабля. Исследователи установили, что наряду с ранее обнаруженной ошибкой бортового таймера Starliner, вторая проблема с программным обеспечением могла потенциально привести к небольшому, но проблемному столкновению.

Первая проблема с программным обеспечением была обнаружена вскоре после запуска Starliner, когда транспортное средство не смогло выполнить запуск двигателя на орбите. Вскоре Боинг обнаружил, что бортовая система отсчета времени космического корабля, называемая «истекшим временем полета», ошибочно взяла неверное время с ракеты «Атлас V» почти за 11 часов до старта. Предполагалось, что Starliner получит это время с ракеты во время последнего периода обратного отсчета до старта, а поскольку этот шаг произошел преждевременно, внутренние часы Starliner имели неправильное время.

Затем была обнаружена вторая программная проблема до возвращения космического корабля на Землю, и этот сбой мог потенциально привести к столкновению между модулем Starliner и его сервисным модулем, который предназначен для отделения на орбите до приземления модуля.

Эта проблема, которую представители Boeing назвали «ошибкой клапана», была связана с программным обеспечением, которое приказывает разделить модуль для экипажа и сервисный модуль Starliner перед посадкой. Подруливающие устройства сервисного модуля несут ответственность за проведение торможения, которое сводит Starliner с орбиты, отправляя его обратно на Землю для посадки. После того, как двигатели отключаются, сервисный модуль отсоединяется от модуля для экипажа и благополучно падает в Тихий океан.

«Во время того, что мы называем «свободным полетом», когда модуль экипажа присоединен к сервисному модулю, бортовые компьютеры на модуле экипажа управляют всеми отдельными запусками двигателей. Но после того, как вы отделяете модуль для экипажа, двигатели управления на сервисном модуле должны вывести его с орбиты для утилизации, не допустив повторной встречи с модулем для экипажа», - заявил во время телеконференции Джон Малхолланд, вице-президент и руководитель программы Boeing Starliner.

«Эти режимы отличаются, но программное обеспечение, к сожалению, имело одинаковое отображение положения клапанов для обоих этих условий. Именно поэтому у нас было неправильное отображение положения клапанов», - сказал Малхолланд.

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

Если бы Boeing не поймал этот сбой до того, как Starliner начал возврат на Землю, эти два модуля могли «столкнуться» друг с другом после отделения, что могло дестабилизировать модуль для экипажа во время критической точки его снижения.

«Не правильная работа подруливающих устройств может привести к тому, что сервисный модуль, представляющий собой кусок цилиндра, отойдет от модуля для экипажа, а затем снова соприкоснется или столкнется с ним», - сказал Джим Чилтон, старший вице-президент Boeing Space and Launch во время телеконференции, добавив, что в результате это могут произойти "плохие вещи".

«Итак, один вопрос: вы достаточно сильно ударите по модулю для экипажа, где будет столкновение и какая у вас потом возникнет проблема? Другое дело в том , что вы не хотите повредить тепловой экран, потому что он нужен, чтобы вернуться».

«Трудно сказать, где сервисный модуль столкнулся бы с модулем для экипажа, но в результате этого столкновения ничего хорошего не получится, поэтому мы обновили программное обеспечение, чтобы убедиться, что этого не произойдет», - сказал он.

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

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

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

По словам Брайденстайна, несмотря на то, что независимый анализ проблем Starliner еще продолжается, НАСА ожидает, что окончательный отчет будет подготовлен к концу февраля. Он добавил, что НАСА еще не решило, проводить ли второе испытание орбитального полета, прежде чем использовать Starliner для полета с астронавтами на Международную космическую станцию.

«Это летное испытание научило нас многому», - сказал Чилтон. «То, что мы хотели бы сделать лучше, это программное обеспечение».

Даг Ловерро, директор Управления космических полетов НАСА, заявил во время телеконференции, что проблемы с программным обеспечением "скорее всего только симптомы. Они не являются реальной проблемой".

«Реальная проблема заключается в том, что у нас было мало времени в цикле проектирования, разработки и тестирования программного обеспечения, - сказал Ловерро, - и по мере продвижения вперед мы сосредоточимся на этом ... мы проверим все поставленное нами программное обеспечение, а не только две подпрограммы, затронутые этими проблемами".

Как мы прекрасно знаем, проблема с программным обеспечением самолетов Boeing 737 MAX до сих пор не решена, а информация о новых проблемах, связанных с ней, постоянно появляется в СМИ.

(Добавил: RoboAstroNews)

Поддержи AstroNews           Читайте AstroNews в Яндекс.Дзен