⇡#Часть 1: Пролог и японский «Кайрос»
В космической отрасли существуют термины, которые не принято произносить вслух до тех пор, пока телеметрические данные не подтвердят успешный выход на заданную орбиту. К таким словам относится «триумф». Это особенно справедливо для сферы частного ракетостроения в Японии, где изысканное название Kairos, отсылающее к древнегреческому понятию «благоприятного мгновения», продолжает обманывать возложенные на него надежды. Парадокс заключается в том, что 5 марта 2026 года это божество подходящего момента вновь потерпело неудачу — и причиной стали не прогоревший композитный сопловой насадок или капризный топливный клапан, а обычные строки программного кода. Алгоритмы, созданные для мгновенного реагирования на опасность, в третий раз подряд устроили для инженеров компании Space One цифровой саботаж.
Сначала — огненный взрыв спустя пять секунд после запуска в марте 2024 года, затем — полная потеря управления в декабре. А теперь — аварийное прекращение полёта, потому что автономная система прекращения полёта (FTS) внезапно решила, что лёгкая вибрация при наборе высоты является достаточным основанием для самоуничтожения. Кажется, в современной «ракетно-космической криминалистике» усталость металла окончательно уступила место нехватке простой человеческой логики. Мы привыкли искать причину в обломках двигателей, однако Kairos в очередной раз продемонстрировал: сегодня миллиарды долларов могут обратиться в прах из-за единственной ошибочной строки в конфигурационном файле, которую кто-то счёл «несущественной».
Запуск ракеты-носителя Kairos (Space One) со стартовой площадки космодрома Кии (5 марта 2026 года). Момент, когда «удачное мгновение» оборачивается дорогостоящим фейерверком. Самоуничтожение как наивысшее выражение программного пессимизма. Фото агентства Kiodo
⇡#Часть 2. Грамматика катастроф: сложности пересчета
В летописи космических исследований есть монумент человеческой ошибке, возведенный на фундаменте абсолютной самонадеянности — автоматическая станция Mars Climate Orbiter (MCO). В 1999 году этот зонд стоимостью 327,6 миллиона долларов того времени должен был стать ключевым элементом масштабной программы Mars Surveyor '98. Задачи стояли грандиозные: детальное изучение атмосферы Марса, наблюдение за динамикой ледяных покровов и, что не менее важно, функция высокоскоростного ретранслятора для своего компаньона — спускаемого аппарата Mars Polar Lander.
Трагедия произошла 23 сентября 1999 года, как раз в момент выполнения главного маневра — выхода на орбиту вокруг Марса. Через пять минут после запуска двигателей MCO скрылся за диском Красной планеты. По плану, связь должна была прерваться и восстановиться после завершения операции. Однако в назначенное время эфир встретил их безмолвием. Давящей, бесконечной тишиной, которая для специалистов в центре управления звучит оглушительнее любого катаклизма.
Телеметрические данные, успевшие поступить до разрыва связи, открыли ужасающую картину: аппарат пролетел над Марсом на высоте всего 57 километров вместо запланированных 140–150. Оказавшись в относительно плотных слоях атмосферы, MCO либо мгновенно разрушился от аэродинамических и тепловых перегрузок, либо, совершив эффектный «блинчик», срикошетил и отправился в вечное странствие по гелиоцентрической орбите.
Когда первая волна эмоций схлынула, Следственная комиссия NASA (Mars Climate Orbiter Mishap Investigation Board) представила отчет, способный ввергнуть в уныние любого преподавателя точных наук. Оказалось, что аппарат в глубинах космоса погубила банальная путаница в наземном программном обеспечении. На протяжении всего девятимесячного полета малые двигатели ориентации MCO периодически включались для коррекции траектории. Программное обеспечение от компании Lockheed Martin записывало эти импульсы в старых добрых имперских единицах — фунт-силах на секунду. Между тем навигационная система Лаборатории реактивного движения JPL (Jet Propulsion Laboratory) считывала те же файлы, будучи непоколебимо уверенной, что имеет дело с метрическими ньютон-секундами.
Расхождение в коэффициентах (почти в 4.45 раза) стало причиной того, что в то время, как специалисты по баллистике на Земле восхищались «идеальной» моделью полета, фактическая траектория неуклонно, момент за моментом, увлекала станцию в гибельные слои атмосферы. В техническом задании на интеграцию программных блоков попросту упустили условие об автоматической верификации единиц измерения. Система оперировала «чистыми» числовыми значениями, не имея никакой возможности идентифицировать в них иную систему мер. Комплексные наземные испытания взаимодействия этих модулей полностью отсутствовали. Космос вновь продемонстрировал: он не терпит халатности в вопросах измерения, даже если вы — общепризнанный флагман отрасли.
Расчетная и фактическая траектория атмосферного маневра зонда MCO. Именно та ситуация, когда «имперские амбиции», заложенные в код, встретились с непреклонной метрической действительностью. MCO оказался самой затратной потерей из-за отсутствия конвертера между английской и универсальной системами. Источник: Wikimedia
⇡#Часть 3. Наследственный изъян Ariane 5
Первый квалификационный запуск нового европейского тяжелого носителя Ariane 5 (известный также как Flight 501 или V88 в каталоге Arianespace), состоявшийся 4 июня 1996 года, должен был ознаменовать начало новой эпохи в коммерческом освоении космоса. На его борту находились четыре ценных научных спутника проекта Cluster, созданных для исследования земной магнитосферы. Общий бюджет миссии, включая создание самой ракеты-носителя, по самым осторожным оценкам, превышал 370–500 миллионов долларов.
Запуск с космодрома Куру во Французской Гвиане начался как по учебнику: ракета устремилась ввысь, плавно набирая высоту, а её ровное пламя выглядело безупречно. Однако на 37-й секунде полёта, после преодоления рубежа в 3,5 километра, случилось нечто неожиданное. Огромная конструкция внезапно совершила резкий, почти хаотичный манёвр по тангажу и рысканью, отклонившись от расчётной траектории более чем на 20 градусов. Развязка наступила мгновенно: система аварийного прекращения полёта (FTS), зафиксировав критические отклонения по углам, немедленно привела в действие механизм самоуничтожения. Ракета вспыхнула ослепительным огненным шаром, а её уникальная научная аппаратура обрушилась на прилегающие болотистые земли в виде дождя из обломков.
Причина аварии оказалась одновременно и курьёзной, и поучительной. Это был классический случай «экономии на спичках», но в данном контексте — на программном обеспечении. Инженеры просто перенесли фрагмент кода инерциальной системы наведения с ракеты-носителя Ariane 4 — аппарата надёжного, но обладающего куда более скромными динамическими характеристиками. На 36-й секунде бортовой компьютер попытался записать значение горизонтальной скорости в ячейку памяти, имевшую жёсткое ограничение: она физически не могла принять число, превышающее 32 767. Однако Ariane 5 была не старой «четвёркой»; её скоростные параметры оказались на порядок выше. Как только скорость перешагнула этот критический порог, произошло так называемое целочисленное переполнение (integer overflow).
Для простоты понимания этот эффект можно сравнить со стрелкой спидометра, которая, дойдя до максимума, сбрасывается на ноль: процессор попросту «не справился» с числом. Вместо реальных данных о скорости модуль выдал диагностический код ошибки, который главный вычислитель, по роковому стечению обстоятельств, воспринял как фактический угол отклонения. Система управления тут же развернула сопла двигателей на максимальный угол, пытаясь «скомпенсировать» несуществующий занос, что в итоге и привело к разрушению ракеты.
Независимая следственная комиссия (Ariane 501 Inquiry Board) позднее охарактеризует эту ситуацию как неоправданную веру в «программное наследие». Разработчики были свято убеждены, что модуль, безукоризненно работавший в десятках запусков предыдущей модели, не требует дополнительной проверки. В результате критически важный элемент информационного обмена превратился в «спящую» уязвимость, которая проявила себя лишь тогда, когда новая ракета вышла на режимы, недоступные её предшественнице. Это хрестоматийный пример того, как попытка сэкономить на комплексном моделировании превращает проверенное временем решение в роковой недостаток.
Момент разрушения ракеты Ariane 5 (полёт 501) в небе над Куру. Ярчайшая иллюстрация того, как 16-битное значение способно перевесить сотни тонн горючего. Самый дорогой урок по работе с унаследованным кодом в истории космических исследований. Изображение предоставлено Европейским космическим агентством
Часть 4. Зловещий таймер и «воображаемый грунт»
Нынешняя фаза покорения космоса, при всей её технологической изощрённости, оказалась столь же безжалостна к программным ошибкам, как и времена перфокарт и дискет. В декабре 2019 года новейший американский аппарат CST-100 Starliner от авторитетной компании Boeing (миссия OFT-1) вместо запланированной встречи с МКС разыграл в космосе напряжённую драму собственного спасения. Роковая неполадка проявила себя сразу после отстыковки от носителя: корабль, вместо плавного выхода на орбиту, неожиданно начал совершать серию беспорядочных и энергичных манёвров двигателями.
Специалисты в Хьюстоне с тревогой наблюдали, как «Старлайнер» стремительно расходует топливо на действия, совершенно излишние для данного этапа полёта. К тому моменту, когда инженерам удалось прервать этот цифровой хаос, ресурсы были практически исчерпаны, а стыковка со станцией стала технически неосуществимой.
Причиной инцидента стал бортовой компьютер, некорректно интерпретировавший данные от вычислительного модуля ракеты-носителя. В результате внутренние часы аппарата получили невероятное смещение на одиннадцать часов вперёд. Сразу после отделения система «решила», что находится в полёте уже полдня и пора активно корректировать положение у самой станции. Как установила специальная комиссия NASA, эта авария (пусть и без человеческих жертв) стала следствием системного провала в процедурах проверки: в погоне за сокращением расходов и сроков Boeing пренебрег полным циклом комплексного моделирования взаимодействия программ носителя и корабля. Подобная «экономия» стоила корпорации свыше 1,5 миллиардов долларов.
Однако манипуляции со временем — лишь одна грань проблемы. Гораздо опаснее ситуации, когда программная логика заставляет аппарат безоговорочно «поверить» в несуществующую действительность. 19 октября 2016 года европейский спускаемый модуль «Скиапарелли» миссии ExoMars-2016 успешно преодолел атмосферу и готовился к мягкой посадке на марсианскую поверхность. Но на высоте около 3,7 километров бортовой компьютер внезапно дал сбой: отбросил парашют, кратковременно активировал и отключил тормозные двигатели. Система была абсолютно «уверена», что уже находится на твёрдой почве, и даже продолжила передавать телеметрию, в то время как сам модуль в полной тишине просто падал вниз.
Причина этой катастрофы заключалась в мгновенном сбое: во время раскрытия парашюта датчик вращения зафиксировал аномально высокое, «зашкаливающее» значение. Навигационный компьютер, обработав эту информацию, пришёл к нелепому умозаключению: высота стала отрицательной. Система буквально «увидела» себя под марсианской поверхностью и немедленно прекратила все операции по управляемому спуску.
Почти идентичная ситуация «виртуального касания» повторилась 11 апреля 2019 года с израильским зондом «Берешит» в Море Ясности на Луне. Отказ одного из инерциальных датчиков и последующий сброс системы привели к полной блокировке основного двигателя программным обеспечением на критическом этапе снижения. К моменту восстановления работоспособности системы, расстояние до лунной поверхности стало уже слишком мало.
Как следует из заключений расследований, в обоих инцидентах коренной причиной стала недостаточная алгоритмическая проработка аварийных сценариев. Автоматика не была способна корректно обрабатывать конфликтующие показания с приборов. К сожалению, аналогичный недостаток «защитных контуров» в программной логике проявился и в недавней миссии «Луна-25», где автоматика не остановила работу двигателя при явном отклонении от заданных параметров. Это лишний раз доказывает: роковая «упёртость» программ, продолжающих выполнять ошибочную команду, остаётся ключевой уязвимостью современных систем автономной посадки.
Художественное представление посадочного модуля «Скиапарелли» на Марсе. Программное обеспечение ошибочно решило, что аппарат уже находится под поверхностью, хотя до неё оставалось около четырёх километров. Марсианская пыль — лучший индикатор для выявления изъянов в управляющих алгоритмах. Фото Reuters
⇡#Часть 5. Молоток против интерфейса: когда сила заменяет логику
Если прежние инциденты напоминали изящное противостояние вычислительных систем и параметров, то события 2 июля 2013 года на космодроме Байконур предстают настоящим триллером, где грубая сила одержала верх над инженерным расчетом. Ракета-носитель «Протон-М» с разгонным блоком ДМ-03 и тремя аппаратами «Глонасс-М» должна была пополнить орбитальную навигационную группировку. Однако вместо этого она разыграла в прямом эфире свой собственный трагический балет. Вспомните тот момент, когда голос комментатора внезапно прервался: «Похоже, что-то пошло не так... Похоже, это авария»? Через мгновение мощная ракета почти перевернулась в небе и врезалась в землю в полутора километрах от стартовой площадки, обратив сотни тонн ядовитого гептила и амила в исполинское огненное облако.
Добравшись до места падения, члены аварийной комиссии испытали шок. Три из шести датчиков угловых скоростей были смонтированы с поворотом на 180 градусов — попросту говоря, «вверх тормашками». Парадоксально, но конструкция «Протона» изначально включала стандартную защиту от ошибок: расположение фиксирующих штифтов на посадочных местах физически исключало возможность неправильной установки прибора.
Расследование выявило пугающую картину на производстве. Столкнувшись с затруднением при монтаже, сборщик не стал сверяться с документацией или вызывать специалиста. Он приложил значительное усилие, буквально «вбив» датчики на место, проделав в корпусах новые, не предусмотренные конструкцией отверстия. Положение усугублялось крайне неудобным, стесненным расположением узла на приборной раме. После окончания работ визуально проверить ориентацию стрелок на корпусах было почти нереально. Контролеры и представитель заказчика, по сути, «вслепую» поставили подписи в документах, подтвердив корректность монтажа. В итоге система управления получила инвертированные сигналы и на 17-й секунде полета усердно «загнала» ракету в почву. Это тот самый случай, когда кувалда победила самый продуманный интерфейс.
Не менее красноречивы и ситуации, где причиной гибели аппарата становится «цифровая слепота» — неспособность системы адекватно воспринять внешнее воздействие. В 2011 году амбициозная миссия «Фобос-Грунт», направленная к спутнику Марса, даже не смогла покинуть околоземное пространство из-за серьезного программного сбоя. Авария случилась на этапе формирования траектории перелета: маршевая двигательная установка попросту не запустилась, и аппарат остался на низкой опорной орбите.
Согласно официальному заключению, причиной стала перезагрузка двух из трех бортовых компьютеров под влиянием космической радиации. В программном коде возникла ошибка, приведшая к бесконечному циклу перезапусков. Аппарат перешел в энергосберегающий режим, безучастно игнорируя команды с Земли, и через несколько месяцев после старта сгорел в плотных слоях атмосферы.
Порой подобная «недальновидность» проявляется на фоне кажущегося триумфа, как произошло в 1985 году со станцией «Вега-1». Во время снижения аппарата в ядовитой атмосфере Венеры неожиданно активировалась программа забора образцов почвы — на высоте 18 километров! Причина сбоя оказалась почти нелепой: мощный вертикальный порыв венерианского ветра был интерпретирован бортовым компьютером как механический удар о поверхность. Поскольку в программном коде отсутствовала строгая проверка по данным барометрического высотомера, автоматика «поверила» ложному сигналу от датчика посадки. В итоге, дорогостоящий бур с энтузиазмом вгрызался в венерианские небеса за двадцать километров от грунта, а бесценные данные о составе почвы оказались утрачены навсегда.
Взрыв упавшей ракеты-носителя «Протон-М». Тот самый случай, когда стрелка «Вверх» — это лишь рекомендация, которую можно оспорить с помощью хорошей кувалды. Фото Reuters
⇡#Часть 6. Выход из пике: диктатура математики
Японский Kairos, американские аппараты серии «Орбитер» и европейские ракеты «Ариан» гибнут по различным сценариям, однако их заключения словно списаны под копирку. Коренная причина неизменно одна: роковая неполнота цикла наземных испытаний и самонадеянное пренебрежение сквозной проверкой алгоритмов. Мы по-прежнему по старинке тестируем системы на расчётные режимы «А» и «Б», наивно полагая этого достаточным, и полностью игнорируем коварные «сценарии Г», которые лишь и ждут момента, чтобы вцепиться в космический аппарат во время реального полёта.
Выходом из этого стремительного падения сегодня считается применение методов математического подтверждения безошибочности программного обеспечения, или так называемая формальная проверка. В отличие от стандартного тестирования, которое отыскивает ошибки практически наугад, данный подход воспринимает программу как точное, исключающее неоднозначность математическое выражение. Применение особых языков — допустим, ограниченного Ada/SPARK или микроядра seL4 — даёт возможность ещё на стадии разработки раз и навсегда устранить целые категории критических недочётов: от переполнения буферов до конфликтов в параллельных вычислениях.
В нынешних проектах уровня космического телескопа «Джеймс Уэбб» (JWST) или в программном обеспечении новейших многоразовых аппаратов уже используются системы, которые попросту останавливают компиляцию кода при малейшем несовпадении форматов данных. Будь у создателей злополучного MCO подобный защитный механизм, система управления категорически отклонила бы пакет, в котором «фунты» пытаются подменить ожидаемые «ньютоны». Алгоритм идентифицировал бы это как попытку соединения несовместимых компонентов и сигнализировал бы об ошибке задолго до того, как станция достигла марсианской атмосферы.
Кроме того, современная цифровая документация и полное видеонаблюдение за скрытыми операциями позволяют отслеживать даже те компоненты, куда не проникнет взгляд самого скрупулёзного инспектора ОТК. Это формирует двойную защиту: математическую «непогрешимость» в коде и технологический контроль на этапе сборки.
⇡#Итог
Сегодня в ракетно-космической отрасли систему подводит не нехватка технологий (их как раз предостаточно), а недостаток строгой типизации и вопиющее пренебрежение математической проверкой логики на начальных стадиях. В космической гонке в конечном итоге победит не тот, у кого сильнее двигатель или больше финансирование, а тот, кто полностью устранил случайность и пресловутый «человеческий фактор» из уравнений. Власть математики — это, пожалуй, единственный надёжный способ уловить тот самый изменчивый «момент истины» и превратить его из мгновения провала в триумф проекта.
Зеркала космического телескопа имени Джеймса Уэбба (JWST) в стерильной камере — олицетворение победы передовых испытательных технологий. Когда программный код превращается в безупречное уравнение. Этот телескоп служит наглядным подтверждением: власть математики приносит неоценимые плоды
