Тематическое исследование: Создание пользовательской операционной системы для спутниковой системы

Создание космической операционной системы: уроки спутниковой разработки

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

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

Почему именно спутниковая система?

Коммерческие операционные системы реального времени (RTOS), такие как VxWorks, RTEMS и FreeRTOS, широко используются во встроенных аэрокосмических приложениях. Однако многие спутниковые программы, особенно те, которые имеют уникальные требования к миссии, выбирают создание пользовательской ОС для достижения точного контроля за использованием ресурсов, безопасностью и восстановлением неисправностей.

Фаза 1: Определение требований к спутниковой системе

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

Обработка данных в реальном времени

Спутники работают по строгим временным линиям. петли управления положением часто требуют показаний датчиков и команд привода со скоростью от 10 Гц до 100 Гц, при этом джиттер измеряется в микросекундах. ОС должна обеспечивать детерминированное планирование задач и обработку прерываний для выполнения этих сроков. Например, обновление звездного трекера, которое прибывает на 5 мс позже, может привести к неправильному наведению антенны спутником, что приведет к отключению связи.

Виноваты толерантность и автономия

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

Силовые и тепловые ограничения

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

Безопасное командование и телеметрия

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

Долгосрочная надежность в суровых условиях

Пространство — это враждебная среда. Излучение может вызывать расстройства одного события (переворачивания битов) и защелки. ОС должна включать драйверы памяти с исправлением кода ошибки (ECC), периодические самотесты и возможность сбрасывать компоненты, которые вошли в застрявшее состояние. Компоненты также сталкиваются с экстремальными температурными циклами — от —100°C при затмении до +120°C при прямом солнечном свете — требуя от ОС управлять тепловыми датчиками и регулировать тактовую частоту, чтобы оставаться в безопасных эксплуатационных пределах.

Фаза 2: Разработка пользовательской архитектуры ОС

С учетом требований команда переходит к архитектурному проектированию. Цель состоит в том, чтобы создать модульную, проверяемую и адаптируемую к различным спутниковым автобусам систему.

Выбор ядра и планирование в реальном времени

Ядро является ядром ОС. Для спутниковых систем инженеры обычно выбирают одно из двух семейств: небольшое микроядро или исполнительное устройство в реальном времени. Микроядра, такие как RTEMS с открытым исходным кодом, обеспечивают эффективную связь между процессами и защиту памяти, в то время как пользовательское руководство может быть еще проще. Алгоритм планирования почти всегда является приоритетной превентивной схемой (например, скоростное монотонное планирование), поскольку он обеспечивает предсказуемое поведение и позволяет статически выполнять анализ времени выполнения в худшем случае (WCET).

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

Управление памятью

Конструкции спутниковых ОС обычно избегают виртуальной памяти, поскольку накладные расходы на таблицы страниц и промахи TLB добавляют непредсказуемость. Вместо этого они используют статическое распределение памяти, где каждой задаче дается фиксированный пул физической памяти во время загрузки. Этот подход устраняет ошибки из памяти и делает анализ WCET тягостным. Блоки защиты памяти (MPU) используются для изоляции задач, но они устанавливаются один раз во время инициализации и редко меняются.

Механизмы обнаружения и восстановления ошибок

Пользовательская ОС для спутника включает в себя несколько уровней защиты:

Модульность и обновление

Спутниковые миссии могут длиться годами, а дефекты программного обеспечения могут быть обнаружены после запуска. ОС должна поддерживать обновления по воздуху (OTA), но с особой осторожностью. Как правило, ОС разбивается на «золотой» загрузчик, который никогда не меняется, ядро, которое можно заменить полностью, и модули приложений, которые можно загрузить самостоятельно. Пакеты обновлений аутентифицируются, суммируются и применяются к резервной копии программного обеспечения, чтобы неудавшееся обновление не запирало спутник.

Фаза 3: Реализация и тщательное тестирование

Внедрение спутниковой ОС следует строгим стандартам кодирования, таким как MISRA-C или DO-178C для систем, имеющих критически важное значение для безопасности, чтобы минимизировать ошибки программирования. Каждая функция документирована, а код рассматривается несколькими инженерами. Процесс тестирования намного более обширный, чем при разработке типичных встроенных систем.

Симулированные испытания окружающей среды

Прежде чем ОС когда-либо коснется реального оборудования, она работает в программном моделировании, которое моделирует датчики спутника, исполнительные механизмы и орбитальную динамику. Эта среда позволяет разработчикам тестировать крайние случаи, которые было бы опасно воспроизводить в лаборатории, такие как отказ двигателя во время критического ожога или внезапная потеря мощности. Тысячи часов смоделированного времени миссии накапливаются, чтобы убедиться, что ОС обрабатывает номинальные и неноминальные сценарии правильно.

Тестирование Hardware-in-the-Loop

После того, как ОС стабильна в моделировании, она загружается на фактическое аппаратное обеспечение полета - обычно закаленный радиацией процессор, такой как микроконтроллер серии LEON3, RAD750 или Cortex-R. Испытание аппаратного обеспечения в цикле (HIL) соединяет летный компьютер с реальными или эмулированными периферийными устройствами: инерционные единицы измерения, звездные трекеры, реакционные колеса и радиосвязи. ОС должна продемонстрировать, что она может управлять этими устройствами с требуемым временем и точностью. Тестирование HIL также проверяет код водителя и обработчики прерываний.

Радиационные и экологические испытания

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

Интеграция и тестирование систем

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

Фаза 4: Преодоление ключевых проблем

Каждый проект спутниковой ОС сталкивается с рядом известных проблем. Вот как они решаются с помощью конкретных инженерных решений.

Ограничения ресурсов: CPU, память и мощность

Квалифицированные в космосе процессоры часто отстают от передовых коммерческих частей по производительности на 10-20 лет. Например, RAD750 НАСА, основанный на PowerPC 750, работает на частоте 200 МГц с 256 МБ оперативной памяти. Каждый байт памяти и каждый цикл процессора должны быть распределены с умом. Инженеры используют инструменты статического анализа для измерения времени выполнения в худшем случае и использования памяти до уровня бита. Неиспользуемые функции, такие как стек TCP / IP, удаляются из ядра. Управление питанием обрабатывается путем перехода процессора в режим простоя между периодическими задачами, при этом ОС измеряет напряжение и ток для оптимизации рабочего цикла.

Радиационное затвердевание без аппаратного обеспечения

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

Задержка и безопасность связи

Ссылки команд и управления имеют присущие задержки (от миллисекунд до нескольких секунд). ОС должна буферизировать команды, проверять их на временной шкале миссии и выполнять их в точное время. Протоколы безопасности, такие как CCSDS Space Data Link Security (SDLS), интегрированы в сетевой стек ОС. Все входящие команды аутентифицируются с использованием методов симметричного ключа или открытого ключа перед передачей на прикладной уровень. Телеметрия шифруется для предотвращения перехвата конфиденциальных данных несанкционированными наземными станциями.

Надежность в многолетних миссиях

ОС, которая работает без сброса в течение 10 лет, требует необычайной надежности. Команда разработчиков впитывает «избыточность сторожевых псов» в систему: если задача мониторинга первичной медико-санитарной помощи не справляется, вторичная независимая система мониторинга здоровья берет на себя управление. ОС также поддерживает «личность», которая может реконструировать состояние системы после перезагрузки, сводя к минимуму потерю данных. Счетчики для неисправимых ошибок запускают полную рутину очистки памяти, и система регистрирует все аномалии для анализа нисходящей линии связи, позволяя наземным контроллерам точно настраивать поведение ОС в течение жизненного цикла миссии.

Перспектива реального мира: построение на проверенных шаблонах

Хотя каждая спутниковая ОС уникальна, многие проекты строятся на системах с открытым исходным кодом или наследственном наследии. Например, основной исполнительный директор НАСА (cFE) и операционный уровень абстракции системы (OSAL) обеспечивают основу, которая использовалась во многих миссиях, включая лунный разведывательный орбитальный аппарат и научную лабораторию Марса. Аналогичным образом, Европейское космическое агентство стандартизировало на RTEMS для нескольких миссий по наблюдению Земли и науке. Использование такой структуры не препятствует настройке - она обеспечивает прочную, хорошо проверенную базу, на которой добавляются специфические функции миссии.

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

Для тех, кто хочет продолжить изучение, следующие внешние ресурсы предлагают подробную техническую информацию:

Заключение

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

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