Большинство космических аппаратов летает на химическом топливе. Но у такого подхода есть фундаментальная проблема: топливо тяжелое, а значит сильно ограничивает скорость и дальность полетов. Поэтому инженеры рассматривают другую идею — световые паруса.
Исследователи из Tuskegee University разработалипарус из наноструктурированного материала. Он состоит из фотонных кристаллов — с германиевыми столбиками, воздушными отверстиями и полимерной матрицей, толщиной всего 100–400 нанометров. Такое строение отражает лазерную волну нужной длины, но пропускает большую часть остального света.
В испытаниях квадратный метр такого материала отражал около 90% лазерного излучения мощностью 100 кВт. Пока это лабораторная демонстрация, но такие технологии могут стать основой для будущих проектов межзвездных миссий.
Больше интересной информации про источники энергии и энергетику в телеграм-канале ЭнергетикУм
Сегодня при обсуждении ПО следует учитывать ту высокую значимость, которую оно имеет в нынешних технологических решениях. Например, в мире аэрокосмонавтики ставки невероятно высоки, и программные сбои могут вести к катастрофическим последствиям.
В этой статье речь пойдёт о нескольких ярких случаях, когда сбои ПО серьёзно отразились на подобных критических средах, в которых ошибки недопустимы.
▍ ✈️ Кейс 1. Авария ракеты-носителя «Ариан-5»
Четвёртого июня 1996 года Европейское космическое агентство (European Space Agency, ESA) впервые запустило ракету «Ариан 5», отметив важный момент в истории исследования космоса. Однако миссия оказалась провальной, поскольку буквально одна строка кода привела к катастрофическому сбою и потере всего груза стоимостью почти полмиллиарда евро.
Ракета «Ариан 5» (фр. Ariane 5)
Эта ракета должна была доставить два спутника связи на геостационарную переходную орбиту. Запуск шёл гладко, пока ракета не отклонилась от траектории и не разрушилась на 37 секунде полёта. Было установлено, что причиной катастрофы стал программный сбой в системе наведения, которая отвечала за регулирование курса полёта ракеты. Сбой при запуске Ариан-5 был признан одним из самых дорогостоящих в истории ПО. Разрушение научных спутников привело к задержке исследований магнитосферы Земли почти на 4 года.
В чём же была причина? Мёртвая часть кода программы из последней миссии Ариан-4, которая стартовала примерно 10 годами ранее, содержала простую и вполне исправимую ошибку. Ракета определяла свою направленность движения вверх или вниз с помощью метода, известного как горизонтальное смещение, иногда также называемого «BH value». Его значение представлялось 64-битной переменной с плавающей запятой, которую система наведения использовала для преобразования в 16 16-битных знаковых целых. 64-битная переменная может представлять миллиарды значений, в то время как 16-битная может выражать лишь 65 535.
Нам известно, что в целых числах первый бит представляет знак, и что 16-битные целые могут находиться в диапазоне от -32 768 до 32 767. При этом числа с плавающей запятой создаются для отслеживания более широкого диапазона значений, используя то же количество битов между -1.8e+308 и -2.2e-308. Если вы попытаетесь сохранить такое значение в 16-битном целом числе, то оно значительно выйдет за его допустимые границы. По итогу в программном обеспечении ракеты произошло хорошо известное целочисленное переполнение.
Катастрофе поспособствовал и ещё один фактор, а именно требование операторов, чтобы Ариан-5 летела по значительно более крутой траектории в сравнении с предыдущими ракетами, что привело к невероятной высокой скорости вертикального движения.
Какие ключевые выводы можно сделать из этой катастрофы?
Копирование кода без его понимания (карго-культ) представляет серьёзную проблему.
Ещё одна проблема — это отсутствие подобающей обработки ошибок.
Пренебрежение изменениями, внесёнными по требованию операторов, и
R1 — избегать использования программ или систем, которые не являются обязательными. Во время полёта программное обеспечение не должно выполняться, если на то нет необходимости.
R2, R10, R11 — критически необходимо проводить тестирование. Организуйте тестовую среду с максимальным объёмом тестового оборудования и проводите тщательное тестирование системы в закрытом цикле. Всем миссиям должны предшествовать полноценно реализованные симуляции с обширным покрытием тестами.
R4 — проводить код-ревью. В любом языке программирования важны все детали кода.
R6, R8 и R13 — необходимо повышать читаемость за счёт обработки исключений в задачах и создания резервных механизмов для поддержания стабильной работы во время сбоев. При определении критических компонентов важно также учитывать возможные программные сбои. Организуйте команду для выработки строгих правил тестирования ПО, обеспечивающих следование высококачественным стандартам.
▍ ✈️ Кейс 2. Как неперехваченное SQLException остановило работу авиалиний
В январе 2023 года агентство Reuters поведало об интересном инциденте, произошедшем в Федеральном управлении гражданской авиации (Federal Aviation Administration, FAA). В ходе анализа происшествия специалисты управления выяснили, что работающий по контракту специалист «непреднамеренно удалил файлы», вызвав общенациональный запрет на вылеты 11 января. Если говорить точнее, в тот день оказалось отменено более 11 000 полётов. Представители управления сообщили, что этот сотрудник работал над синхронизацией основной и резервной баз данных.
Это напоминает мне о проблеме, о которой рассказывается в главе 2 книги «Release It» Майкла Найгарда. Авиалинии планировали произвести аварийное переключение кластера базы данных, выступавшего основной системой, выстроенной по принципу сервис-ориентированной архитектуры. Этот поэтапный переход был запланирован и распределён по функциональности. Названная система обрабатывала поиск, возвращая для разных запросов (дата, время, город) детали перелётов.
Программное обеспечение авиалинии работало на кластере прикладных серверов J2EE с БД Oracle, обеспечивавшей резервную избыточность данных, и аналогичными аппаратными балансировщиками нагрузки, которые на тот момент представляли распространённую высоконадёжную архитектуру. Однажды инженеры выполнили ручной аварийный переход с Database 1 на Database 2 (первый резерв). Они проделывали это много раз, и всё прошло в точности, как планировалось. Затем, спустя 2 часа, система перестала обслуживать запросы, отображавшиеся на их интерактивных терминалах. После некоторого анализа они решили перезапустить приложения, что привело к проблеме, остановив работу авиалиний примерно на 3 часа.
После аварийного анализа журналов, дампов потоков выполнения и файлов конфигурации инженеры обнаружили проблему в основной системе, а не в той, откуда поступали сообщения об ошибках. Многие потоки оказались заблокированы в ожидании ответа, который так и не поступал (в методе, выполнявшем поиск по городам). Они выяснили, что завершающая инструкция SQL, выполнявшаяся в заключительном блоке, может также выбрасывать SQLException, когда привод пытается запросить от базы освобождение ресурсов. В итоге этот его запрос не обрабатывался, приводя к исчерпанию пула доступных ресурсов.
Что ещё они могли предпринять в этой ситуации? Невозможно предотвратить все ошибки. Некоторые баги неизбежны. Мы лишь можем предотвратить влияние ошибок одной системы на другую.
Книга “Release It!”, Michael T. Nygard
▍ ✈️ Кейс 3. Катастрофа Boeing 737 MAX
В октябре 2018 и марте 2019 года потерпели крушение два Boeing 737 MAX, в результате чего погибло 364 человека. Отчасти причиной этого стала программная система, созданная для повышения безопасности полётов.
Boeing 737 MAX 9
MCAS — Maneuvering Characteristics Augmentation System (система повышения манёвренности самолёта) — стала камнем преткновения в истории с Boeing 737 MAX. Созданное из необходимости, это программное обеспечение стало решением внутреннего недочёта дизайна (а именно программным исправлением аппаратной проблемы [1]). Модель 737 MAX, оснащённая расширенными, более экономичными по топливу двигателями, имела иные аэродинамические свойства, нежели её предшественники. MCAS должна была позволить этой модели обрабатывать те же нагрузки, что обрабатывали прежние модели линейки 737, при этом обеспечивая лёгкую адаптацию пилотов к новшеству.
В теории MCAS была элегантна. Она автоматически корректировала горизонтальный стабилизатор, предотвращая сваливание самолёта при крутых поворотах и низких скоростях. На практике же эта система стала наглядным примером того, как единая точка отказа может вызвать каскадный катастрофический эффект.
Критический недочёт? MCAS опиралась на вводные данные лишь одного из двух датчиков угла атаки (angle of attack, ATA) самолёта [2], [3]. В случае передачи этим датчиком некорректных данных произошло бы ложное срабатывание MCAS, что привело бы к наклону носа самолёта вниз даже тогда, когда это не нужно. Дополнительно усложняя проблему, система бы срабатывала повторно, потенциально вводя в недоумение пилотов, которые не были в должной степени осведомлены о её существовании или поведении.
Установив более крупный двигатель, компания Boeing изменила аэродинамические характеристики модели 737. (Источник: NOREBBO.COM)
Однако история про MCAS не будет завершённой без освещения фактов, которые вскрылись после крушений. Впоследствии было заявлено, что компания Boeing поручила значительную часть разработки ПО для модели 737 MAX сторонним инженерам, которым платили всего по $9/час [4]. Как сообщили бывшие инженеры ПО этой компании, она всё больше начинала полагаться на временных сотрудников, в частности, недавних выпускников колледжей, услуги которых предоставляли зарубежные центры разработки ПО. Это решение, скорее всего принятое в свете необходимости сокращения расходов и ускорения разработки, привносит ещё один уровень сложности в историю про Boeing 737 MAX.
Что мы можем почерпнуть из этой истории как инженеры ПО:
Исключайте единую точку отказа. Случай с MCAS является острым напоминанием о важности наличия в критических системах резервных решений. Использование в качестве ориентира единственного источника данных — в описанном случае датчика AOA — создало уязвимость, которая привела к катастрофическим последствиям. В нашей работе мы всегда должны задаваться вопросом: «Что произойдёт, если этот компонент даст сбой?»
Делайте ПО и системы простыми, но не слишком простыми (принцип KISS, Keep it simple, stupid). Система MCAS стала ярким примером оверинжиниринга решения аппаратной проблемы. Вместо того чтобы устранить внутреннюю нестабильность в дизайне 737 MAX, компания Boeing решила прибегнуть к программному «исправлению», которое внесло новые уязвимости.
Отсутствие предметного опыта. Многие инженеры, нанимаемые через сторонние организации, не обладают достаточным опытом в сфере аэрокосмических технологий и критических к безопасности систем. Это привело к проблемам в коммуникации и ошибкам, которые потребовали неоднократных корректировок.
Слабое тестирование. Несмотря на обширное тестирование, фатальные сбои в MCAS не были обнаружены, пока самолёты не поступали на обслуживание. Это поднимает важные вопросы об адекватности текущего тестирования и практик симуляции, особенно для систем, в которых реальные условия сложно воссоздать полноценно.
Что мы, как программные инженеры, можем сделать для решения перечисленных проблем? Вот некоторые мысли по этому поводу:
Реализовать подобающую обработку ошибок. Проектируйте свои системы с учётом того, что их компоненты будут давать сбой. Реализуйте резервные механизмы, перекрёстные проверки и предохранительные меры.
Делать акцент на операторах. Делайте так, чтобы ваши системы отчётливо взаимодействовали с их пользователями, особенно в отношении их текущего состояния и любых автоматизированных действий. Предоставляйте операторам информацию и средства управления, нужные им для принятия взвешенных решений и в случае необходимости переопределения поведения автоматизированных систем.
Ставить в приоритет интеграционное тестирование. Несмотря на важность модульных тестов, их недостаточно. Не пожалейте времени и средств на всеобъемлющее интеграционное тестирование всей системы. Проверяйте пограничные случаи и состояния отказа.
Развивать культуру открытого взаимодействия. Создайте среду, в которой люди смогут безбоязненно высказывать свои беспокойства, а аварийные ситуации будут рассматриваться как ценные уроки, а не что-то постыдное, что хочется поскорее замять.
Отстаивать выделение необходимых ресурсов. Как инженеры ПО, мы запрашиваем те или иные ресурсы для подобающего выполнения своей работы. Это может подразумевать несогласие с нереалистичными дедлайнами, с выделением недостаточного времени на тестирование или с сокращением расходов, которое может поставить под угрозу безопасность [5].
▍ Ссылки
[1] “How the Boeing 737 Max disaster looks to a software developer”, Gregory Travis, IEEE Spectrum, 2019.↪ [2] “Killer software: 4 lessons from the deadly 737 MAX crashes”, Matt Hamblen.↪ [3] “Eight lines of code could have saved 346 lives in Boeing 737 MAX crashes, expert says.” Matt Hamblen↪ [4] “Boeing’s 737 Max Software Outsourced to $9-an-Hour Engineers“, Bloomberg, 2019.↪ [5] “The Boeing 737 MAX: Lessons for Engineering Ethics”, Herket J. et al., Sci Eng Ethics. 2020.
Более 150 работников «ЦЭНКИ» (входит в Роскосмос) и представители четырёх подрядных организаций выполнили монтажные операции в кратчайшие сроки — чуть более чем за два месяца.
Было подготовлено и покрашено 2350 кв.м. конструкций, заменены все узлы креплений на новые, полностью заменено и отлажено электрооборудование, проведены ревизия и обслуживание узлов и механизмов кабины обслуживания, выполнено более 250 погонных метров сварных швов.
▶️ Наиболее сложной задачей стал монтаж некоторых элементов кабины длиной 19 метров и массой порядка 17 тонн, которые устанавливались через огневой проём. Для этого была разработана специальная методика.
🗓 Начинается подготовка к запуску грузового корабля «Прогресс МС‑33», назначенного на 22 марта
Авария на стартовой площадке произошла 27 ноября 2025 года во время старта ракеты «Союз» с пилотируемым космическом кораблем «Союз МС-28». Хотя сама ракета успешно улетела и экипаж достиг станции, наземное оборудование было серьезно повреждено так, что пусковая площадка утратила работоспособность. Притом только этот стартовый стол обеспечивает пуски ракет с грузовыми и пилотируемыми кораблями для снабжения российского сегмента Международной космической станции.
Авария стартового стола поставила на паузу все российские пуски по программе МКС. Завершение ремонта за три месяца позволило вернуться к программе запусков и возникшая задержка несущественно повлияла на работу станции. На 22 марта запланирован запуск грузового космического корабля «Прогресс МС‑33».
Виталий Юрьевич Егоров — известный российский популяризатор космонавтики, блогер и журналист.
ссылку на его телегу не дам, ибо он иноагент (рукалицо)
40 лет назад запущена первая в истории многомодульная орбитальная станция. О рекордах и достижениях этого чуда техники - в нашем материале.
В 1980-е годы космическая гонка двух сверхдержав приобрела необычное развитие: США сделали ставку на развитие многоразовых космических кораблей, тогда как СССР сосредоточился на создании и эксплуатации орбитальных станций. Серия орбитальных станций «Салют» была создана для выполнения мирных и военных задач.
7 подобных станций было запущено к 1986 году
280 организаций под эгидой 20 министерств и ведомств СССР работало над созданием базового модуля станции «Мир». По сути, он являлся доработанной версией станции «Салют-8». Предполагалось, что к базовому блоку постепенно будут присоединяться дополнительные. Так и произошло: в течение 10 лет к нему были последовательно пристыкованы ещё 5 модулей и стыковочный отсек.
Рекорды космической станции "Мир":
5511 суток провела станция на орбите Земли, из них 4593 дней она была обитаема;
86331 оборот совершила станция вокруг Земли
104 космонавта из 13 государств побывало на борту станции, в составе 28 экспедиций;
29 космонавтов и 6 астронавтов воспользовались станцией для выхода в открытый космос.
Распад СССР привел к резкому сокращению космической программы. Это создало целый ряд проблем в поддержании работоспособности станции «Мир».
23 февраля 1997 года на станции произошло возгорание кислородной шашки регенерации атмосферы. Потребовались героические усилия экипажа, чтобы избежать полного сгорания станции.
Одним из последствий пожара стал отказ системы кондиционирования. Температура на станции повысилась до 50 °С при предельно допустимых 28 °С, началась утечка хладагента, ядовитого этиленгликоля. Утечку удалось устранить лишь несколько недель спустя.
25 июня 1997 года транспортный корабль «Прогресс М-34» при проведении ручной стыковки со станцией «Мир» столкнулся с модулем «Спектр». В результате были повреждены солнечные батареи модуля, в «Спектре» образовалась пробоина диаметром 2 метра, была утрачена герметичность всей станции.
Несколько раз «Спектр» пытались ремонтировать – но полной работоспособности так восстановить и не получилось.
Сломанный после столкновения модуль "Спектр"
В конечном итоге правительством России было принято решение о прекращении работы и затоплении станции «Мир». 23 марта 2001 года она вошла в плотные слои атмосферы, практически полностью разрушившись. Остатки станции затонули в южной части Тихого океана, на кладбище космических кораблей.
Картина А. Соколова «Гибель станции "Мир"»
Источники данных для материала:
В. Газонов, А. Железняков. "Станция «Мир»: от триумфа до...", Издательство "Система", Москва, 2006.
Инженер, который правильно выявил фатальный дефект в конструкции шаттла «Челленджер» за месяцы до катастрофы, но никому не было дела. Его точные слова жене Дарлин: «Он взорвётся» за 73 секунды до того, как это произошло...
Буажоли знал, что космический шаттл «Челленджер» в опасности, потому что он потратил годы на изучение одного упущенного из виду компонента: резиновых уплотнительных колец, которые герметизировали стыки твердотопливных ракетных ускорителей.
Буажоли работал в компании Morton Thiokol, ответственной за эти ускорители. Изучая данные испытаний и полётов он и другие инженеры обнаружили, что уплотнительного кольца становились опасно хрупкими при низких температурах. Когда они теряли гибкость, горячие газы могли просачиваться через стык во время запуска, что могло привести к разрушению шаттла.
В месяцы предшествовавшие запуску Буажоли неоднократно предупреждал руководство, что запуск в холодную погоду небезопасен. В ночь перед взлётом, когда прогнозировались температуры значительно ниже нуля, он настойчиво утверждал, что «Челленджер» не должен лететь.
Он даже изложил свои опасения в письменной форме.
Руководство проигнорировало инженеров.
Когда шаттл взлетел 28 января 1986 года, Буажоли смотрел за этим из дома. Семьдесят три секунды спустя «Челленджер» развалился, унеся жизни всех семи астронавтов на борту. Причина была именно той, о которой он предупреждал: отказ O-колец на холоде.
Позже Буажоли дал показания перед Конгрессом показав как технические предупреждения игнорировались под давлением графика и политики. Он был публично оправдан, но цена была огромной. Он никогда не вернулся к работе в аэрокосмической отрасли и жил с тяжестью знания, что катастрофу можно было предотвратить.
Трагедия «Челленджера» привела к полной переработке стыков твердотопливных ракетных ускорителей, а показания Буажоли теперь изучаются в курсах этики инженерии по всему миру как пример того, что происходит, когда руководство заставляет экспертов замолчать.
NASA не определилось с кораблем для снабжения лунной станции Gateway
NASA может изменить планы по коммерческой доставке грузов на перспективную лунную станцию Gateway. Агентство изучает возможность использования для этих целей многоразового корабля Starship от SpaceX вместо изначально предложенного Dragon XL и планирует принять решение после запуска Artemis II, сообщает SpaceNews.
На иллюстрации грузовой космический корабль SpaceX Dragon XL приближается к лунной станции Gateway. Источник: NASA
В 2020 году NASA выбрало компанию SpaceX Илона Маска для доставки грузов на станцию Gateway, аналогично тому, как это делается для МКС. Космический гигант предложил использовать для этих целей специальную версию своего «грузовика» — Cargo Dragon XL. Однако разработка шла медленно, отчасти из-за задержек в самой программе Gateway. В 2023 году NASA дало SpaceX разрешение на первый запуск, но в 2025 году компания сама предложила пересмотреть систему снабжения.
Работа над логистикой Gateway была приостановлена в прошлом году после того, как администрация президента США предложила отменить финансирование станции в бюджете на 2026 финансовый год. Однако Конгресс сохранил его в итоговом законе о бюджете, принятом в июле 2025-го.
Как заявил 29 января менеджер программы Deep Space Logistics в Космическом центре NASA им. Кеннеди Марк Визе, агентство изучало возможность использования корабля Starship вместо Dragon XL для снабжения Gateway. Сейчас NASA ожидает политических указаний о том, как действовать дальше. Эти решения, вероятно, будут приняты после запуска миссии Artemis II, старт которой запланирован в начале февраля.
Параллельно программа Gateway также фигурировала в более широких исследованиях на тему окололунных передвижений. В августе 2025 года NASA отобрало шесть компаний для краткосрочного изучения концепций орбитальных буксиров, которые могли бы работать вблизи Луны и на других «труднодоступных» орбитах. Контракты на общую сумму $1,4 млн получили Arrow Science and Technology, Blue Origin, Firefly Aerospace, Impulse Space, Rocket Lab и United Launch Alliance. Эти исследования уже завершены и проанализированы. Цель состоит в том, чтобы дать возможность нескольким компаниям обеспечивать поставки в окололунном пространстве.
NASA представило проект Lunar Gateway в 2017 году и с тех пор концепция и цели будущего комплекса несколько раз менялись. Изначально его рассматривали в качестве вспомогательного пункта, откуда можно будет совершать полеты на Луну или в другие уголки Солнечной системы. Затем, во время первого президентского срока Дональда Трампа, план пересмотрели, и станцию решили разместить на окололунной орбите, сделав ее подобием МКС.
Ранее NASA запустило конкурс на создание полноценной системы питания для людей на Луне и Марсе. Победители будут объявлены в сентябре 2026 года, а общий призовой фонд составит $750 тыс.
Опасения того, что под давлением Трампа финансирование научных программ NASA в 2026 сократится на треть, не подтвердились.
При голосовании в Сенате 15 января дисциплина республиканского большинства отошла на второй план. Все-таки сохранение рабочих мест – важный фактор для переизбрания на предстоящих выборах в ноябре.
Инфографика с распределением ассигнований на разные направления деятельности NASA в 2026
p.s. Осталось вернуть обратно тысячи уволенных за прошлый год инженеров.
