CCSDS Миссия Операции - CCSDS Mission Operations

В Контроль и управление космическими аппаратами (SM&C) Рабочая группа Консультативный комитет по системам космических данных (CCSDS), в которой активно участвуют основные космические агентства, определяет сервис-ориентированную архитектуру, состоящую из набора стандартных сквозных сервисов между функциями, находящимися на борту космического корабля или на земле, за которые отвечают для миссий.

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

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

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

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

Подход на основе структуры услуг

Компоненты SM&C.JPG

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

Рабочая группа SM&C определяет набор стандартных сервисов, которые составляют основу, позволяющую собирать множество подобных систем из совместимых «подключаемых» компонентов. Эти компоненты могут располагаться где угодно, если они связаны через общую инфраструктуру. Это позволяет повторно использовать компоненты в различных развертываниях для конкретных задач: между агентствами, между миссиями и между системами.

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

ПРИМЕЧАНИЕ. - Подключаемые компоненты взаимодействуют только через стандартные сервисные интерфейсы через общую инфраструктуру. Платформа сервиса сама по себе многоуровневая и не зависит от реализации базовой инфраструктуры.

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

Уровни обслуживания

CCSDS SM&C Layer diagram.png

Ключевой особенностью структуры обслуживания миссий [1] является многоуровневая структура служб. Несмотря на то, что существует ряд потенциальных услуг, определенных в соответствии с различными типами информации об операциях миссии, которыми обмениваются внутри системы (параметры состояния, управляющие действия, орбитальные данные, сроки выполнения задач и т. меньший набор общих шаблонов взаимодействия, которые позволяют наблюдать за текущим статусом, вызывать операции и массовую передачу данных. Это дает два ключевых преимущества: он по своей сути расширяемый, поскольку новые службы могут накладываться на существующие общие службы; а вложения в приложения Mission Operations дополнительно изолированы от технологии реализации. Технологические адаптеры позволяют изменять (или объединять) базовую коммуникационную инфраструктуру с минимальным влиянием на сами приложения. Это улучшает долгосрочную ремонтопригодность, поскольку миссии часто переживают наземные технологии, используемые для их первоначального развертывания.

Уровнями структуры обслуживания операций миссии [1] являются:

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

Потенциальные преимущества

Стандартизация структуры обслуживания операций миссии [1] предлагает ряд потенциальных преимуществ для разработки, развертывания и обслуживания инфраструктуры операций миссии:

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

Операции миссии

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

  • мониторинг и управление подсистемами космических аппаратов и полезными нагрузками
  • анализ характеристик космических аппаратов и отчетность
  • планирование, составление графиков и выполнение операций миссии
  • определение орбиты и ориентации, прогнозирование и подготовка к маневрам
  • управление бортовым ПО (загрузка и сброс)
  • доставка продуктов данных миссии.

Обычно они рассматриваются как функции Центра управления полетами (ЦУП) и выполняются группой операций миссии при поддержке Операционной системы миссии. MO включают в себя возможность архивировать и распространять данные операций миссии. Хотя это может включать в себя обработку продуктов данных миссии, действия, конкретно связанные с использованием данных миссии (такие как обработка, архивирование и распространение данных для конкретной миссии), считаются выходящими за рамки MO. Все чаще функции МО могут распределяться между сотрудничающими агентствами и площадками наземного сегмента или частично делегироваться автономным функциям на борту самого космического корабля. Платформа MO Service Framework занимается сквозным взаимодействием между прикладным программным обеспечением MO, где бы оно ни находилось в космической системе. Это специально не касается предоставления услуг по транспортировке или сохранению (хранению) данных. Однако он является пользователем таких услуг.

Смотрите также

использованная литература

[1] Концепция оперативных служб миссии. CCSDS 520.0-G-3. Зеленая книга. Выпуск 3. Декабрь 2010 г. https://web.archive.org/web/20130531013416/http://public.ccsds.org/publications/archive/520x0g3.pdf