Космос — самый дорогой стартап в истории человечества, поэтому неудивительно, что его технологии давно окупаются на Земле. И хотя мы привыкли к историям о космических материалах, беспроводных наушниках и системе навигации GPS, NASA сделала кое-что более близкое разработчикам — выложила в Open Source фреймворк, который управляет космическими миссиями.

core Flight System (cFS) зародился как инструмент для управления спутниками и марсоходами, но довольно быстро превратился в модульную платформу, которая позволяет переиспользовать код. Open Source фреймворк не просто «приземлился» и уже помогает делать дроны, промышленные контроллеры и двигать науку в университетских лабораториях, а меняет подход к разработке сложных систем.

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

С чего начинается «полёт»

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

Первый космический код писали «на коленке»: без IDE (Integrated Development Environment), систем контроля версий и даже уверенности, что он вообще запустится. Каждая миссия начиналась с чистого листа: новые задачи, команды и код. Но чем больше проектов запускала NASA, тем чаще инженеров посещало дежавю. Управление питанием, обработка телеметрии, системы команд и события повторялись, только под другими именами. Как будто каждая новая миссия начиналась с git fork вместо reuse.

Так зарождался подход, который сейчас знаком любому разработчику: сделать платформу, а не проект. NASA вынесла всё повторяющееся (телеметрию, команды, управление) в отдельный фреймворк, на который новые миссии «надевались» как модули. Так началась история core Flight System. cFS-системы, где модульность, переиспользование и открытый код стали стандартом задолго до DevOps и CI/CD.

Что такое core Flight System

К началу 2000-х у NASA появилась другая проблема: кода много, а совместимости мало. Миссии решали похожие задачи: питание, команды, телеметрия. Но у каждого проекта были свои драйверы, протоколы и операционка. Из-за этого код для одного аппарата не работал на другом, а перенос превращался в полноценную разработку. Даже похожие спутники не понимали друг друга, будто «говорили» на инопланетных языках.

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

В это время начался переход от монолитов к платформенным решениям. Уже внедряли ERP, SOA и первые веб-платформы. Наступала эра сервисных слоёв и переиспользуемых компонентов. Даже бытовая техника начинала робко коннектиться с компьютерами. NASA тоже искало свой путь: как согласовать интерфейсы, протоколы и типовые блоки, чтобы собирать аппараты быстрее. Из попыток унифицировать полётное ПО (Flight Software, FSW) выросла программная платформа для миссий. Общий каркас, где базовые функции вроде планировщика, системы событий, таблиц параметров и передачи данных стали общими, а остальное подключалось как модули.

Архитектура cFS

Core Flight System — это набор независимых слоёв, которые можно комбинировать под конкретную миссию. В основе лежит идея «общего ядра», к которому подключаются модули. Архитектура напоминает конструктор: основа остаётся, а функциональные блоки можно менять.

Внутри cFS три базовых слоя. Внизу слой абстракции Operating System Abstraction Layer (OSAL), который прячет различия между операционными системами. Благодаря ему один и тот же код можно запускать на разных платформах: от специализированных real-time ОС до обычного Linux. Для разработчика это значит, что приложение не зависит от конкретного «железа» и может быть протестировано на Земле, а потом запущено в космос без переписывания.

Между OSAL и ядром формально расположен ещё один слой — Platform Support Package (PSP). Он отвечает за взаимодействие с конкретным оборудованием: драйверы, устройства, контроллеры питания. Но в большинстве описаний, включая документы NASA GSFC и ESA, PSP объединяют с OSAL, чтобы не усложнять архитектурную схему.

Над системой абстракций находится cFE (core Flight Executive). Это ядро, которое отвечает за «логику полёта». Оно управляет всеми процессами с помощью ключевых сервисов:

• Scheduler — планировщик задач, который контролирует, когда и в каком порядке выполняются приложения.

• EVS (Event Services) — система событий, которая отслеживает ошибки и телеметрию.

• SB (Software Bus) — общий канал обмена сообщениями между приложениями. Через него модули «общаются» друг с другом.
  TBL (Table Services) — механизм для хранения и обновления параметров без перекомпиляции кода.

• ES (Executive Services) — служба, которая управляет жизненным циклом приложений: их запуском, остановкой и мониторингом состояния.

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

Механизм изоляции в cFS работает не между микросервисами в сетевом смысле, а внутри одного процесса, на уровне задач и очередей. Приложения не видят друг друга напрямую, но обмениваются сообщениями через Software Bus. Модуль может отправить сообщение через стандартный интерфейс, не зная, кто его получит. Как микросервисы, только в космосе. Такой принцип изоляции делает систему предсказуемой: сбой в одном приложении не влияет на остальные, а перенос на другую платформу не требует переписывания кода.

Почему modularity, portability, reuse важны

Конечно, в официальной документации NASA нет акронима вроде MPR (modularity–portability–reuse). В отчётах GSFC эти идеи упоминаются как свойства архитектуры (layered, component-based) и цели (reuse, portability, rapid development). Всё это отражает подход фреймворка: не писать заново, а собирать из проверенных частей, независимо от оборудования и операционной системы.

«The core Flight System enables reuse, rapid development, and portability through its layered, component-based architecture.»

— NASA GSFC, Core Flight System Overview

Эти принципы в первую очередь про отказоустойчивость. Всё-таки у кода в космосе нет второго шанса.

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

• Portability делает код независимым от железа. Стабильный API OSAL и PSP обеспечивает одинаковое поведение на разных ОС и платформах, так что логика миссии не меняется при переносе.

• Reuse сокращает стоимость и время подготовки миссий. Модули, проверенные на одной платформе, переходят в другие проекты без изменений. Единые форматы команд и телеметрии, таблицы параметров и типовые приложения позволяют переиспользовать код и конфигурации, а не писать всё с нуля.

Так постепенно сформировался общий стандарт полётного ПО: единая архитектура, повторно используемые сервисы и согласованный API между компонентами.

Космический фреймворк вне орбиты

В 2010 году core Flight System выложили в открытый доступ сначала на платформе NASA Open Source, а позже на GitHub. Так агентство проверило жизнеспособность архитектуры cFS вне своих лабораторий и миссий. Открытый код позволял внешним разработчикам искать ошибки, предлагать доработки и адаптировать систему под собственные задачи. Это давало обратную связь, тесты и оптимизацию без расширения штата и бюджета. Кроме того, открытая модель помогла решить проблему сертификации и совместимости. Когда одни и те же компоненты начали использовать университеты, подрядчики и инженеры внутри агентства, они быстро стали стандартом по факту. Что, в свою очередь, упростило интеграцию новых систем и снизило стоимость новых миссий.

Вскоре фреймворк начали использовать за пределами NASA. Сначала университеты. Команда Laboratory for Atmospheric and Space Physics (LASP) из Университета Колорадо запустила cFS на своём учебном спутнике CSSWE (Colorado Student Space Weather Experiment), который должен был измерять космические лучи и солнечные протоны. И код из миссий NASA точно так же сработал на микроспутнике, размером чуть больше тостера.

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

А после публикации cFS на GitHub граница между «космосом» и «землёй» стала ещё незаметнее. В тех же ветках, где инженеры NASA обсуждают сбои телеметрии, можно встретить комментарии студентов:

«SB message queue overflowed after 5 minutes — any tips?»
А чуть ниже инженер из Goddard отвечает, как это пофиксить.

Иногда баги, найденные студентами, совпадают с теми, что ловят в реальных полётах. А в репозитории nasa/cFS можно найти фиксы и коммиты от образовательных проектов, таких как CubeSat и OpenSatKit.

К экспериментам подключились и команды разработчиков. a.i. solutions взяла компоненты OSAL для тестирования управляющих контроллеров и симуляции полётных сценариев. На их стендах cFS вёл обмен сообщениями между подсистемами, обрабатывал события и синхронизировал с реальным оборудованием.

В отчётах GSFC есть проекты, где ядро cFE применяли для сбора телеметрии с дронов и автономных роботов. Менялось только «железо»: вместо спутника — стенд, вместо антенны — Wi-Fi. Только связь на Земле порой работала хуже, чем на орбите.

А когда к экспериментам присоединились компании-разработчики, тестовые стенды быстро превратились в коммерческие решения.

Стыковка с индустрией

В начале 2000-х в Денвере под контракты NASA и господрядчиков открыли Red Canyon Software. Они разрабатывали программное обеспечение для спутников и занималась анализом телеметрии. Проекты шли один за другим, но каждый начинался с чистого листа: новое оборудование, интерфейсы и ошибки. Разработка под каждого заказчика требовала слишком много часов НИОКР (научно-исследовательские и опытно-конструкторские работы) и времени на тесты. Поэтому когда Red Canyon Software попыталась выйти на рынок, подход пришлось менять. cFS Red Canyon создала собственный инструмент cFS Product Suite, который позволял генерировать код прямо из MATLAB / Simulink и проверять его на стендах. Вместо отдельных прошивок появились шаблоны и готовые сервисы, а таблицы параметров (Table Services) позволили обновлять настройки без перекомпиляции. Через OSAL/PSP то же приложение теперь можно было запускать и на Linux-симуляторах, и на полётной RTOS (Real-Time Operating System) без расхождений между «землёй» и «аппаратом».

cFS позволило сократить затраты на разработку до 70% и, по сравнению с созданием кода с нуля, уменьшило количество дефектов до 95%. Так коммерческое направление Red Canyon стало приносить около 20% выручки.

Почти через десять лет после появления Red Canyon в Хьюстоне заработала Intuitive Machines. Её основали бывшие инженеры NASA, которые хотели превратить космическую экспертизу агентства в коммерческий продукт. Они занялись посадочными модулями для лунных миссий и инфраструктурой будущих экспедиций.

Когда началась разработка аппарата Nova-C, команда столкнулась с типичной задачей интеграции: десятки подсистем, параллельные команды и сложная синхронизация между «железом» и софтом. С нуля писать полётную платформу было слишком дорого, поэтому за основу взяли core Flight System. Это позволило сосредоточиться на логике посадки и взаимодействии с полезной нагрузкой, а не на низкоуровневом коде. Такая стратегия уменьшила время интеграции и упростила тестирование. Отладка проходила в Linux-среде с теми же приложениями, что отправлялись в полёт, поэтому риск расхождений между наземной и полётной сборкой минимизировался.

Так, cFS позволил Intuitive Machines сократить сроки и затраты разработки.

Параллели с земным ИТ

Но не только космическая экономика выиграла от этого подхода. Если убрать из уравнения ракеты и телеметрию в core Flight System, легко увидеть знакомые паттерны. Это тот же набор принципов, на которых сегодня строятся корпоративные платформы, промышленные контроллеры и IoT-системы. Один из ключевых — Reuse.

Принцип переиспользования похож на работу памяти. Она сохраняет опыт, вложенный в старый код, и помогает строить новое на проверенной основе. Мы не переучиваемся каждый день чистить зубы или переходить дорогу, а просто повторяем отлаженные действия. Мозг переиспользует надёжные паттерны, чтобы не тратить ресурсы на лишние тесты и правки. Проверенный модуль можно использовать снова, и с каждой итерацией он будет стабильнее. NASA десятилетиями шлифовала код для автономной работы. Тот же принцип сегодня живёт в финтехе, где миллисекунда решает судьбу транзакции, и в производстве, где остановка конвейера обходится в миллионы. В транспорте, авиации и медицине — везде, где сбой стоит слишком дорого.

Modularity в cFS — не просто деление на компоненты, а культура проектирования через интерфейсы. Каждое приложение знает только свой контракт: что получает, что отдаёт, и не лезет в соседний модуль. Та же логика лежит в основе современных микросервисов и архитектур на основе плагинов. Где изоляция — не роскошь, а возможность дольше жить без катастроф.

Абстракция над платформой (OSAL и PSP) используется в кроссплатформенных фреймворках и контейнерах. Один и тот же код должен работать на разных системах, не зная, где он запущен. Разница лишь в том, что у NASA под «разными системами» не Linux и Windows, а орбитальная RTOS и наземная лаборатория.

Всё это делает cFS не просто фреймворком из NASA, а примером зрелой инженерии. Код работает без вмешательства инженеров: фиксов, обновлений и возможности откатить релиз. Поэтому такие проекты из витрины космических технологий превращаются в Open Source-проекты, полезные для стартапов. В них уже есть отказоустойчивость, модульность и изоляция, которых так не хватает ранним коммерческим разработкам.

Ограничения и вызовы

Не всё, что работает на орбите, можно перенести на Землю «один в один». Космический софт живёт по своим законам: с формальными требованиями, жёсткой сертификацией и постоянной борьбой за ресурсы. Там считают каждый байт, ватт и миллисекунду процессорного времени.

Например, бортовые компьютеры многих аппаратов NASA до сих пор используют процессоры RAD750. Это радиационно стойкие версии PowerPC с частотой 133–200 МГц и 256 МБ оперативной памяти. Меньше, чем в обычном Arduino с SD-картой. Но в космосе всё ПО должно умещаться в десятки мегабайт и годами работать без перезапуска.

Энергопотребление ограничено не меньше, чем память. Системы управления и навигации получают ~2 Вт, чтобы не обесточить научные приборы и радиосвязь. А на софт приходится не более 3–5 Вт из общего питания малых аппаратов.

Даже время в космосе — ресурс. Планировщик задач в cFS измеряет всё в тиках реального времени (RTOS ticks), и сдвиг в 10–20 мс между командами может привести к сбою синхронизации телеметрии. Поэтому там нет «асинхронных костылей», только строгий порядок выполнения.

На Земле такие ограничения выглядят анахронизмом, но когда в наличии 200 МГц и 5 Вт, модульность и переиспользование перестают быть красивыми словами.

В обычных ИТ-проектах такой уровень строгости редко оправдан. CI/CD, частые релизы и гибкие итерации плохо сочетаются с процессами, где каждая строка проходит десятки проверок и верификацию Software Assurance Engineer. Поэтому напрямую «переносить» космические практики в бизнес-разработку не получится, слишком разный контекст.

Например, в отчёте NASA за 2020 год отмечено, что reuse кода не всегда напрямую снижает стоимость верификации и валидации (V&V). Экономия появляется, только если вместе с кодом переиспользуются Verification Artifacts: тестовые сценарии, отчёты и доказательства соответствия требованиям и стандартам миссии. Без них повторное использование превращается в новую сертификацию.

Есть и другие барьеры. Документация по cFS больше похожа на учебник по системной инженерии: подробная, точная, но тяжёлая для входа. Для команды без опыта в авиакосмической отрасли это может стать реальным препятствием. Вот пример из документации «Core Flight System (cFS) Training», на котором чаще всего «спотыкаются» пользователи:

«Packet» often used instead of «message» but not quite synonymous.

No data is preserved for either a Power-On or Processor Reset — Any packet in transit at the time of the reset is discarded.

Платформа проектировалась под строгие ограничения: минимальное энергопотребление, малые объёмы памяти и специфическую среду выполнения. Запустить cFS на Raspberry Pi несложно, но использовать как основу промышленного сервиса куда труднее.

И всё же именно эти ограничения и делают cFS интересным опытом. Архитектура, вынужденная жить в условиях дефицита, становится чище, компактнее и надёжнее. И в этом «у космоса» точно есть чему поучиться.

Заключение

core Flight System хороший пример того, как технологии из космоса «приземляются» в виде архитектурных идей. В cFS нет ничего фантастического: обычные очереди, события, таблицы и планировщик, но сделанные так, чтобы работать в среде, где нельзя перезапустить процесс или подождать следующего релиза. Из-за этого платформа оказалась полезной в земных лабораториях, стартапах и промышленных системах.

Это напоминание о том, что самые отказоустойчивые инженерные решения рождаются из ограничений. Стоит смотреть не только на интерфейсы и hardware, но и на то, как условия заставляют переосмысливать архитектуру. Космос хорош тем, что не прощает ошибок и учит писать надёжный код.

Ralph Waldo Emerson:

«When it's darkest, men see the stars»