Космические звездолеты из 90-х, или почему человечество использует в космосе технологии прошлого века

В 2016 году на МКС все еще работали Intel 80386SX на 20 МГц — процессоры, которым уже четверть века. В российских модулях «Звезда» до сих пор летают приборы «Электроника», а на наземных станциях ГЛОНАСС стоят «Эльбрусы» первой версии. В «малом космосе» приоритеты другие: низкая цена, быстрая итерация и использование кубсатов на Raspberry Pi и Linux‑контейнерах.

Давайте разберем, почему в космосе ценят проверенные временем технологии — и какое место в этой истории занимают решения советской и российской школы. Детали под катом.

Используйте навигацию, если не хотите читать статью полностью

• Почему все происходит очень медленно ^[1]

• А что произойдет, если оставить на орбите аппарат слишком надолго ^[2]

• Радио‑ и термостойкость проверенных норм ^[3]

• RTOS и языки ^[4]

• Революция кубсат и COTS ^[5]

• Гибридный подход и эволюция в психологии ^[6]

Почему все происходит очень медленно

Если смотреть на космический проект глазами инженеров и менеджеров, то он напоминает не стартап, а, скорее, строительство атомной станции: все долго, многослойно и требует невероятной точности.

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

Далее следует эскизное проектирование. В ходе него создается предварительный облик аппарата, разрабатывается техническое задание для дальнейшей работы. И вот здесь начинается специфическое. В спутнике нельзя просто взять и заменить комплектующие, как в сервере в дата-центре. И уж тем более нельзя просто взять и начать использовать новый спутник, если со старым что-то пошло не так, как мы делаем это с нашими гаджетами. На его борту на весь срок эксплуатации окажется именно то, что выбрали инженеры. При этом выбрать они могли еще в начале 2010, а запуск выполнить только сейчас.

Следующий этап — детальное проектирование. В это время прорабатываются конструкции, материалы и ПО с учетом требований надежности.

Далее — сертификация. Это один из самых строгих и растянутых этапов жизненного цикла проекта. Есть международный стандарт DO‑178C — «кодекс поведения» для разработчиков космического и авиационного ПО. И вот в соответствии с ним формально нельзя одобрить ни одной строчки кода, пока не будет абсолютно доказано, что каждый элемент системы — от самой туманной идеи до кода в микропроцессоре — прослежен, описан и протестирован. Сертификация идет медленно: аудиторы проверяют планы, тесты, документацию вплоть до покрытия кода (в критичных системах по методу MC/DC — Modified Condition/Decision Coverage). Этот процесс растягивается на годы и превращает 7–10 лет подготовки к запуску в норму, а не исключение.

Аналог DO‑178C в России — стандарт КТ-178C «Квалификационные требования к программному обеспечению авиационной и космической техники». Для допуска систем к испытаниям и вводу в эксплуатацию компании обязаны подтвердить соответствие не только ПО, но и всех аппаратных компонентов.

После начинается этап испытаний: аппарат проходит проверки в условиях, максимально приближенных к космическим — вакуум, низкие температуры, вибрация, радиация. Это делается, чтобы подтвердить его работоспособность.

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

Затем идет сам запуск. После него начинается ввод аппарата в эксплуатацию и работа в космосе. В этот период поддерживается связь, загружаются обновления ПО (с большими ограничениями), контролируются и корректируются параметры орбиты. Все это делается через наземные станции, с многоступенчатой проверкой, чтобы случайный баг не вывел из строя миссию стоимостью в сотни миллионов долларов.

Инцидент с телескопом

Впрочем, в исключительных случаях ремонт и доработка прямо в космосе все же возможны. Например, в 1990 году на орбиту Земли вывели телескоп «Хаббл». За пределы нашей планеты его отправили, чтобы при сборе данных избежать искажений, вызванных атмосферой Земли. Наземные обсерватории постоянно сталкиваются с проблемами вроде турбулентности воздуха и поглощения ультрафиолетового и инфракрасного излучения. Так вот, через несколько недель после запуска оказалось, что главное зеркало телескопа имеет сферическую аберрацию — отклонение формы в 2,2 микрона (меньше толщины человеческого волоса). Из-за этого изображение становилось размытым.

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

После успеха миссии NASA провело еще четыре экспедиции.

• В 1997 году заменили спектрограф GHRS на более мощный STIS — спектрограф с высокой чувствительностью, а также добавили NICMOS — камеру для инфракрасных наблюдений, охлаждаемую жидким азотом.

• В 1999 заменили все шесть гироскопов и обновили основной бортовой компьютер.

• В 2002 году установили камеру ACS и заменили солнечные батареи на новые.

• В 2009 установили камеру WFC3, заменили все гироскопы и блоки электроники. А еще починили спектрограф STIS, который вышел из строя в 2004 году.

И все же этот кейс — именно исключение. Здесь важно помнить: если ваш спутник по цене и научной значимости не стоит в одном ряду с «Хабблом», то никто его чинить не полетит. Кстати, срок службы телескопа растянулся с плановых 15 до более чем 35 лет благодаря апгрейдам. Обычно же эксплуатация спутников длится до 20 лет.

А что произойдет, если оставить на орбите аппарат слишком надолго

Среди таких старичков — Transit 5B-5, запущенный США 21 декабря 1964 года. Он до сих пор работает. Точнее, передает сигналы — в основном в научных и тестовых целях. Эта машина эпохи первых навигационных систем работает на радиоактивном изотопе плутония-238, поэтому так долго кружит по орбите.

Любопытный факт: Transit 5B-5 — стал прямым прародителем GPS. Пример того, как простейшая электроника 60-х, обладая надежным питанием и устойчивостью к экстремальным условиям, может проработать на орбите в разы дольше большинства современных спутников. 

По окончании жизненного цикла аппарат либо выводится на «орбиту‑кладбище», либо контролируемо отправляется на дно океана. Согласно оценке ^[11] Европейского космического агентства (ESA), над нашими головами летает более 54 000 объектов размером свыше 10 сантиметров. Небольших осколков — от 1 до 10 сантиметров — уже около 1,2 млн. А число фрагментов субсантиметрового размера уже давно превышает 130 миллионов. 

К началу 2025 года на орбите Земли находилось около 40 000 спутников, и только 11 000 из них работоспособны. Если плотность космического мусора будет расти и дальше, это может вызвать эффект Кесслера, в результате чего ближний космос станет непригодным для использования. При этом даже крошечная песчинка, летящая со скоростью несколько тысяч или десятков тысяч километров в час, может непоправимо повредить тот же «Хаббл» или систему жизнеобеспечения МКС.

Ученые всерьез обеспокоены мусором на орбите. Нужно его убирать, но куда?

Сейчас для этого есть укромное местечко в Тихом океане — точка Немо. Оно расположено в южном полушарии и удалено примерно на 4 800 км от берегов Новой Зеландии и примерно на 2 700 км от ближайших островов. Это так называемое «кладбище космических кораблей», где затапливают обломки аппаратов, не сгоревшие в атмосфере.

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

Если уточнить в цифрах: время от начала эскизного проектирования до запуска обычно занимает 7–10 лет (Sentinel-1A: утверждение — 2007, запуск — 2014), затем идет эксплуатация в течение 15–20 лет (и даже больше), что хорошо коррелирует с современными программами NASA, ESA и Роскосмоса.

Получается крайне парадоксальная ситуация: на борту космических аппаратов используются технологии из прошлого века, но эта стратегия и делает космос надежным. В итоге спутник, созданный и сертифицированный по стандартам 90‑х, продолжает десятилетиями обеспечивать связь, навигацию или научные данные, в то время как наши земные гаджеты сменились уже несколько раз.

Радио‑ и термостойкость проверенных норм

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

Возьмем легендарный микропроцессор BAE RAD750, созданный на базе архитектуры IBM PowerPC 750 и разработанный по 250 нм (или 150 нм) CMOS-технологии. Он работает на частотах от 110 до 200 МГц, обеспечивает до 400 MIPS вычислительной мощности и потребляет порядка 5 Вт (или 10 Вт в составе одноплатной системы). Это одно из самых популярных и проверенных решений для космических миссий в мире. RAD750 выдерживает перепады температур от −55 до +125 градусов Цельсия. Он также устойчив к дозам ионизирующей радиации до 1 000 килорад, в то время как обычные потребительские процессоры выдерживают лишь доли максимальных значений.

Это достигается за счет специального проектирования кристалла, изоляции и повторного кодирования данных, а также тщательного отбора компонентов и тестирования на воздействие космической радиации в условиях, приближенных к реальным миссиям. RAD750 применяется в системах управления спутниками и межпланетных зондами, например в марсоходах Curiosity и Perseverance, а также в телескопах.

В СССР среди первых советских бортовых компьютеров был Argon-11S. Это была первая в мире космическая ЭВМ. Она имела трехкратное аппаратное резервирование и автоматически управляла космическим полетом по программе «Зонд» (облет Луны с возвращением посадочного модуля на Землю). Позже при длительной работе в составе систем управления космических кораблей «Союз» и «Прогресс», орбитальных станций «Салют», «Алмаз» и «Мир» применялись модели типа Argon-16, а также упрощенные версии для станций «Салют» и других строительных проектов.

Особенность этих советских и российских систем в том, что они разработаны по более консервативным технологическим нормам с использованием менее плотных технологических процессов — например 0,18 мкм. Это увеличивает их устойчивость к радиации и снижает риски отказов. Такие технологии, хотя и устаревшие по современным стандартам, проверены десятилетиями работы в космосе. Они выдерживают условия сильной радиации, экстремальных перепадов температур и длительных периодов работы без возможности обслуживания или ремонта.

RTOS и языки 

Если все так сложно, то неужели в космос можно отправить компьютер/сервер на Windows или Linux? В теории — да, но обычно для таких задач нужна RTOS — операционная система, которая гарантирует выполнение критичных функций без малейших сбоев или задержек. Одними из самых известных и заслуживших доверие RTOS являются американские VxWorks и RTEMS.

VxWorks, разработанная компанией Wind River, — коммерческая RTOS с высокой степенью надежности и многочисленными функциями. Она поддерживает многозадачность с приоритетным вытеснением и дает минимальное время отклика. ОС используется NASA, а также в европейских и американских спутниках и научных аппаратах. VxWorks обладает модульной архитектурой, сертифицирована по авиационным и космическим стандартам безопасности. В последних версиях даже интегрированы возможности для работы с ИИ и контейнеризацией сервисов.

Альтернативой с открытым исходным кодом является RTEMS (Real-Time Executive for Multiprocessor Systems). Изначально она разработана для управления ракетными системами армии США, а позже адаптирована под многопроцессорные архитектуры. Европейское космическое агентство активно использует RTEMS, так как она легко переносима на разные аппаратные платформы, в том числе радиационно-стойкие процессоры семейства SPARC LEON, широко применяемые в европейских миссиях. В RTEMS более гибкая система планирования задач и есть возможность модификаций компонентов. ОС прошла строгие тесты и получила уровень надежности «B» по классификации ЕКА, что говорит о ее пригодности для критических космических систем.

В России же с советских времен применяются отечественные RTOS, построенные на базе операционных систем МЦСТ (Московский центр SPARC-технологий) с учетом особенностей аппаратной платформы («Эльбрус»).

Эти ОС заточены под отечественные аппараты. Из более современных ОС можно вспомнить «БагрОС-4000» — POSIX-совместимый отечественный RTOS также для «Эльбрус».

Еще есть Ada95 — язык программирования, созданный в США в 1980 году для критически важного ПО в системах реального времени. Как и ОС RTEMS, изначально это была военная разработка, которую адаптировали под научные задачи. Ada95 применяется в авиации и космосе благодаря строгой типизации, поддержке параллелизма, runtime-проверкам границ массивов и обработке исключений. Специализированное ПО под названием «C» дает низкоуровневый контроль времени отклика и памяти, поэтому в safety-проектах его ограничивают профилями вроде MISRA C и дополняют строгим статическим анализом.

Для сертифицируемого real-time есть профиль Ravenscar, который урезает задачи до анализируемого подмножества. Для формальной верификации используют SPARK — подмножество Ada, совместимое с требованиями DO-178C/DO-333. На практике эти инструменты реально снижают объем верификации и эксплуатационные риски в крупных проектах, от fly-by-wire систем вроде Boeing 777 до авионики ESA.

В советских и российских научных спутниках были распространены такие «классики», как Фортран и ПЛ/1. Фортран (особенно Fortran-77/90 и более поздние ветки) до сих пор ценят за детерминированную арифметику и плотный набор численных библиотек типа BLAS/LAPACK и старых наработок LINPACK. ПЛ/1 нередко встречался в управляющем софте на мейнфреймах и контроллерах экспериментов. На практике поддержка таких стеков обеспечивается через современные компиляторы (gfortran, Intel Fortran), эмуляцию окружений, интерфейсы обертки (ISO_C_BINDING или C-shim), регрессионные тесты с золотыми наборами данных и строгую верификацию при каждом переносе. Иначе бит-совместимость и воспроизводимость научных результатов оказались бы под угрозой.

Минус очевиден: кадровый дефицит и деградация toolchain’а требуют изоляции legacy-модулей, документирования всех предположений и автоматических тестов. Это нужно, чтобы сохранить доверие к старому коду, не платя цену полного переписывания.

Революция кубсат и COTS 

В России и мире сейчас наблюдается значительный рост интереса к сфере малых спутников. Он отчасти вызван революцией, которую произвели кубсаты. Это такие спутники размером чуть больше кубика рубика. Имеют габариты 10×10×10 см при массе не более 1,33 кг. 

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

Кубсаты стали одним из драйверов массовой демократизации доступа в космос и развития современной космической индустрии. Это происходит, в том числе, благодаря запуску серийных аппаратов с  использованием коммерчески доступного оборудования (COTS). Такой подход позволяет быстро создавать модульные и недорогие спутники для научных, коммерческих и промышленных задач. Примером служат проекты ФИАН (Физического института РАН) и МГУ, где на базе широко доступных платформ Raspberry Pi Zero W и Arduino строятся малые спутники формата 2U.

ФИАН активно участвует в разработке малых спутников, таких как «Ярило». Например, на борту аппарата «Ярило №2» установлен детектор космической радиации «ДеКоР», разработанный в НИИ ядерной физики имени Д. В. Скобельцына МГУ. Также на борту имеется радиационно-стойкая бортовая цифровая вычислительная машина.

Эти спутники работают под управлением Linux и программируются на Python, что упрощает разработку и тестирование. 

Важным российским вузовским проектом является разработка гибридных вычислительных платформ на базе ARM-SoC и FPGA, реализуемых в Сколковском институте науки и технологий (Skoltech). Эта архитектура обеспечивает баланс между высокой производительностью и энергоэффективностью, что позволяет выполнять сложные вычислительные задачи и обрабатывать данные прямо на борту малых спутников. Такая гибридная платформа специально адаптируется для космических экспериментов, включая экспериментальную электронику и системы управления.

В рамках федеральных программ, таких как «Радиоастрон-мини», разрабатываются и отечественные решения — например, микропроцессор BAIKAL-М ВЛ-КТ с архитектурой ARM. Этот процессор создан для использования в малых спутниках, обеспечивая надежную вычислительную основу для задач связи, наблюдения и навигации. 

Гибридный подход и эволюция

Просто взять и отказаться от проверенных временем технологий и оборудования в пользу чего-то нового — рискованная затея. Даже производители обычных земных гаджетов не рискуют так делать, модернизируя девайсы постепенно, от поколения к поколению. Что уж говорить о космической сфере. Лучший подход здесь — интеграция нового без полного отказа от старого и полноценной замены аппаратной части.

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

На том же «Эльбрусе» развивают виртуализацию так: гибридные гипервизоры запускают нативные гостевые ОС и паравиртуальные окружения в одной системе, снижая оверхед и сохраняя совместимость с legacy-модулями. Для космоса это важно: плату на орбите не поменяешь, поэтому надо уметь безопасно вносить изменения программно.

Вторая тенденция — использование ГОСТ-сертифицированных контейнеров в малых спутниках формата кубсат. Контейнеризация изолирует процессы и упрощает среду выполнения. Если контейнеры и реестры образов адаптированы под требования ГОСТ по ИБ, это дает стандартизованный путь установки, подписи образов и защищенные обновления. При этом выгодно использовать гибридную модель: управляемый Managed Kubernetes ^[24] на земле для оркестрации жизненного цикла образов, CI/CD и политик безопасности, и легкие агентные окружения на борту — тогда можно делать контролируемые релизы, откаты и обновления. 

Управляемый Kubernetes поддерживает инфраструктуру, централизует аудит, RBAC и сеть (NetworkPolicy). А на борту легкие дистрибутивы ^[25] и контейнерные рантаймы с проверкой подписи образа обеспечивают совместимость с ограниченными ресурсами и требованиями к надежности. В сумме это снижает цикл разработки, упрощает управление поставкой ПО и уменьшает операционные риски при сохранении соответствия ГОСТ и отраслевых практик.

Что вы думаете о сочетании советского наследия и современных COTS‑решений в космосе? Делитесь в комментариях!