Как НАСА создало отказоустойчивый компьютер для миссии «Артемида-2»

Чтобы вернуть человека на Луну, НАСА разработало архитектуру с «безотказным режимом», способную справляться со всем — от сбоев под воздействием космических лучей до полного отказа процессора

Компьютерная система, установленная на борту нынешней лунной миссии «Артемида-2», кардинально отличается от той, что использовалась в эпоху «Аполлона». Астронавты «Аполлона» совершали посадку на поверхность Луны с помощью компьютера, оснащённого процессором с тактовой частотой 1 МГц и примерно 4 килобайтами памяти ^[1], дополненной более объёмным массивом постоянной памяти на ферритовых кольцах. Хотя это было чудо инженерной мысли 1960-х годов, функциональный диапазон навигационного компьютера «Аполлона» был узконаправленным и не охватывал управление каждой системой. Критические системы контроля окружающей среды и питания управлялись вручную или с помощью электромеханических средств, таких как переключатели и реле.

Миссия «Артемида-2» 2026 года, в рамках которой впервые за более чем 50 лет экипаж из четырёх человек совершил облёт Луны, поддерживается одной из самых отказоустойчивых компьютерных систем, созданных для космических полётов. В отличие от «Аполлона», вычислительная архитектура капсулы «Орион» управляет практически всеми критически важными для безопасности корабля функциями — от систем жизнеобеспечения до маршрутизации связи.

Когда миссия находится в 400 000 км от Земли, сбой так просто не устранить. Там нет взлётно-посадочных полос для аварийной посадки и нет техников, которые могли бы заменить сгоревшую материнскую плату. Каждую подсистему необходимо спроектировать так, чтобы она выдерживала переключения битов под воздействием космических лучей, справлялась с вызванными радиацией замыканиями и аппаратными сбоями без единой секунды простоя.

«Мы по-прежнему разрабатываем архитектуру с учётом возможных сбоев оборудования, — говорит Нейт Уитенбрук, руководитель отдела интеграции и верификации программного обеспечения в программе „Орион“ НАСА в Космическом центре Джонсона. — Наряду с физически дублированными кабелями у нас есть логически дублированные сетевые каналы. У нас есть дублированные полётные компьютеры. Всё это предусмотрено для того, чтобы компенсировать сбой оборудования».

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

Сила восьмерых

Чтобы гарантировать, что эти неверные ответы никогда не дойдут до двигателей космического корабля, НАСА пошло дальше тройной избыточности традиционных систем. «Орион» использует два компьютера управления кораблём, каждый из которых содержит два модуля управления полётом (МУП), что в сумме даёт четыре МУП. Но избыточность идёт ещё дальше: каждый МУП состоит из пары процессоров, проверяющих друг друга.

Фактически восемь процессоров запускают программное обеспечение полёта параллельно. Инженерная философия основана на конструкции с «бесшумным отказом». Пары с функцией самопроверки гарантируют, что если процессор выполнит ошибочный расчёт из-за радиационного воздействия, ошибка ^[2] будет немедленно обнаружена, и система отреагирует.

«Неисправный компьютер перейдёт в режим „бесшумного отказа“, а не будет передавать неверный ответ», — пояснил Уитенбрук. Такой подход упрощает сложную задачу механизма голосования в триплексной системе, которая сравнивает результаты. Вместо того чтобы сравнивать три ответа для определения верного большинством голосов, система использует алгоритм выбора источника, упорядоченный по приоритету, среди исправных каналов, которые не перешли в режим «бесшумного отказа». Она выбирает выходной сигнал от первого доступного МУП в списке приоритетов; если этот модуль перестал работать из-за неисправности, она переходит ко второму, третьему или четвёртому.

Этот уровень избыточности специально рассчитан на суровые условия глубокого космоса. НАСА ожидало временные сбои во время пролёта миссии «Артемида-2» через пояса Ван Аллена с высоким уровнем радиации.

«Мы можем потерять три МУП за 22 секунды и всё равно безопасно пролететь на последнем МУП», — сказал Уитенбрук. Однако МУП, перешедший в режим «бесшумного отказа», не становится мёртвым грузом; система спроектирована так, чтобы перезагрузиться, повторно синхронизировать своё состояние с работающими модулями и вновь присоединиться к группе в полёте.

Обеспечение детерминированности

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

Эта архитектурная дисциплина становится всё более редким явлением в современной разработке. Майкл Райли, руководитель группы в Институте программной инженерии Университета Карнеги-Меллон, ранее сотрудничавший с НАСА по адаптации инструментов оценки рисков для миссии «Орион», отметил, что в то время как предыдущие поколения разработчиков работали в условиях строгих аппаратных ограничений, современная разработка критически важных систем отличается от них.

«Современные подходы Agile и DevOps отдают приоритет итерациям, что может создавать проблемы для архитектурной дисциплины», — пояснил Райли. «В результате накапливается технический долг, а это негативно сказывается на удобстве обслуживания и отказоустойчивости системы».

В «Орионе» используется сеть Ethernet с временным триггером, в которой время распределяется по всей системе. Полётное программное обеспечение работает в рамках «основных фреймов», разделённых на «второстепенные фреймы», управляемые планировщиком, совместимым со стандартом ARINC653. Эта архитектура использует разделение по времени и пространству для планирования разделов внутри этих фреймов, обеспечивая идеальное согласование входов и выходов с сетевым расписанием.

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

Само аппаратное обеспечение также усилено. В системе используется память с тройной модульной избыточностью, которая при каждом чтении самостоятельно исправляет однобитовые ошибки. Даже сетевые интерфейсные карты используют два канала передачи данных, которые постоянно сравниваются, благодаря чему переключение бита в коммуникационной структуре приводит к «бесшумному отказу», а не к повреждению команды. Сама сеть имеет тройную избыточность благодаря трём отдельным логическим уровням, а все сетевые коммутаторы используют алгоритмы самопроверки.

Крайние меры безопасности

Хотя основная система с четырьмя МУП является надёжной, НАСА всё же должно учитывать сбои общего режима — программные ошибки или катастрофические события, которые теоретически могут повлиять на все основные каналы одновременно.

Чтобы снизить эти риски, «Орион» оснастили полностью независимой системой резервного полётного программного обеспечения (РППО). Это яркий пример разнородной избыточности. Она реализована на другом аппаратном обеспечении, работает под управлением другой операционной системы и использует независимо разработанное, упрощённое полётное программное обеспечение.

«Она намеренно отличается, чтобы гарантировать, что сбой программного обеспечения в режиме общего режима в основном полётном программном обеспечении не будет продублирован в резервной системе», — сказал Уитенбрук. РППО постоянно работает в фоновом режиме и автоматически берёт на себя управление, если основные компьютеры выходят из строя. Если система переходит на РППО, она может завершить все динамические части миссии, чтобы достичь фазы покоя, после чего экипаж может попытаться восстановить основные МУП.

Райли подчеркнул, что, хотя логика ^[3] «бесшумного отказа» имеет решающее значение, она должна сочетаться с активным мониторингом, чтобы избежать катастрофических провалов.

«Если программный компонент выходит из строя без видимых признаков, сбой может остаться незамеченным, если его не отслеживает другой компонент или сторожевой таймер», — сказал он. По его словам, для обеспечения надёжности миссии механизмы обнаружения ошибок и восстановления должны быть явно спроектированы и согласованы на всех уровнях кодовой базы, чтобы гарантировать согласованное поведение ^[4].

Даже в случае полной потери питания — так называемой «мёртвой шины» — «Орион» рассчитан на выживание. При восстановлении питания космический аппарат переходит в безопасный режим: сначала он стабилизируется, затем направляет солнечные батареи на Солнце для восстановления энергии. После этого он ориентирует свой хвост в сторону Солнца для обеспечения тепловой стабильности, прежде чем пытаться восстановить связь с Землёй. Во время такой аварии экипаж также может предпринимать определённые действия вручную, настраивая системы жизнеобеспечения или надевая скафандры.

Будущее надёжности

Переход от программы «Аполлон» к программе «Артемида» представляет собой огромный скачок в сложности программного обеспечения. Хотя бортовой управляющий компьютер «Аполлона» был выдающимся достижением, наличие механических резервных систем означало, что компьютер не был единственным гарантом выживания экипажа. Сегодня, когда программное обеспечение управляет каждым термоклапаном и силовым реле, задача состоит в том, чтобы обеспечить синхронизацию и работоспособность программного обеспечения в условиях интенсивного космического излучения.

Чтобы достичь такого уровня уверенности, НАСА в настоящее время использует современные процедуры проверки. Они включают моделирование условий, приближённых к реальным, и стресс-тестирование по методу Монте-Карло для моделирования наихудших вариантов задержек и сбоев связи. Высокопроизводительные суперкомпьютеры используются для крупномасштабного внедрения ошибок, эмулируя целые этапы полёта, в которые вводятся катастрофические сбои оборудования, чтобы проверить, сможет ли программное обеспечение успешно пережить «бесшумный отказ» и восстановить работу.

Поскольку технологии космических полётов исторически способствовали коммерческому прогрессу, архитектура «Ориона» с нулевой терпимостью к ошибкам даёт представление о будущем, в котором основные вычислительные системы — от автономных транспортных средств до промышленных сетей — смогут достичь той же непрерывной отказоустойчивости, которая требуется для полётов к звёздам.