Мониторинг космических аппаратов и управление ( SM & C ) Рабочая группа Консультативного комитета по системам космических данных (CCSDS), который видит активное участие основных космических агентств, является определение сервиса-ориентированной архитектуры , состоящей из набора стандартного конца-to конечные службы между функциями, находящимися на борту космического корабля или на земле, которые отвечают за операции миссии.
Выявление проблемы
Наблюдается общая тенденция к увеличению сложности миссии при одновременном усилении давления, направленного на снижение стоимости операций миссии, как с точки зрения начального развертывания, так и с точки зрения текущих расходов. Архитектура закрытых или «монолитных» операционных систем не позволяет перераспределить функциональные возможности между космосом и землей или между узлами наземной системы. Отсутствие архитектурной открытости приводит к:
- отсутствие взаимодействия между агентствами;
- отсутствие повторного использования между миссиями и наземными системами;
- повышенная стоимость разработки и развертывания для конкретной миссии;
- недоступность коммерческих универсальных инструментов;
- невозможность замены технологии внедрения без серьезной модернизации системы;
- отсутствие оперативной унификации между системами миссий, увеличение затрат на обучение.
Результатом является множество параллельных системных инфраструктур, специфичных для данного семейства космических аппаратов или эксплуатирующего агентства, с небольшой перспективой взаимного обогащения между ними.
Подход, основанный на сервисе
Сервис-ориентированная архитектура (SOA) постепенно заменяет монолитную архитектуру в качестве основного принципа разработки новых приложений как в частных, так и в распределенных системах. Это один из фундаментальных принципов проектирования сетевых распределенных приложений, где интерфейсы, как операции, так и объекты данных, должны быть четко определены, поскольку клиенты часто бывают неоднородными. SOA - это подход к проектированию системы, который опирается не на спецификацию монолитной интегрированной системы, а на идентификацию более мелких модульных компонентов, которые взаимодействуют только через открытые, опубликованные сервисные интерфейсы.
Рабочая группа SM&C определяет набор стандартных сервисов, которые составляют основу, которая позволяет собрать множество подобных систем из совместимых «подключаемых» компонентов. Эти компоненты могут располагаться где угодно, при условии, что они связаны через общую инфраструктуру. Это позволяет повторно использовать компоненты в различных развертываниях для конкретных миссий: между агентствами, между миссиями и между системами.
Если услуги указаны непосредственно с точки зрения реализации конкретной инфраструктуры, они привязаны к этой технологии. Вместо этого, разделив сами сервисы на уровни, спецификации услуг можно сделать независимыми от базовой технологии. Конкретные технологические адаптеры позволяют развертывать сервисную структуру поверх этой технологии. Это, в свою очередь, позволяет заменить реализацию инфраструктуры, а также реализации компонентов. Также возможно прозрачное соединение между различными реализациями инфраструктуры, если они подходят для различных коммуникационных сред (например, космических или наземных) или просто отражают варианты развертывания различных агентств.
ПРИМЕЧАНИЕ. - Подключаемые компоненты взаимодействуют только через стандартные сервисные интерфейсы через общую инфраструктуру. Платформа сервиса сама по себе является многоуровневой и не зависит от реализации базовой инфраструктуры.
Также важно отметить, что подход не предписывает сами компоненты или их реализацию. Стандартизированы только сервисные интерфейсы между компонентами. Это позволяет внедрять инновации, специализацию и дифференциацию компонентов, обеспечивая при этом их быструю интеграцию в систему. Однако для того, чтобы сервисная структура была эффективной, она должна гарантировать, что значимая информация, связанная с операциями миссии, может передаваться через сервисные интерфейсы, а не просто данными. Инфраструктура услуг также должна уважать унаследованные системы. Если интегрированная унаследованная система выполняет функции нескольких компонентов инфраструктуры услуг, ее внутреннюю архитектуру и реализацию изменять не нужно. Только те интерфейсы, которые он предоставляет другим системам, необходимо «обернуть», чтобы сделать их совместимыми с соответствующими интерфейсами служб. Инфраструктура услуг предлагает ряд взаимодействующих интерфейсов, из которых можно выбрать наиболее подходящий: соответствие не зависит от поддержки их всех. Таким образом, унаследованные системы могут быть повторно использованы в сочетании с другими совместимыми компонентами для создания системы для конкретной задачи. Подход призван быть эволюционным, а не революционным.
Уровни обслуживания
Ключевой особенностью структуры обслуживания миссий [1] является многоуровневая структура служб. Несмотря на то, что существует ряд потенциальных услуг, определенных в соответствии с различными типами информации об операциях миссии, которыми обмениваются внутри системы (параметры состояния, управляющие действия, орбитальные данные, сроки выполнения задач и т. меньший набор общих шаблонов взаимодействия, которые позволяют наблюдать за текущим статусом, вызывать операции и массовую передачу данных. Это дает два ключевых преимущества: он изначально расширяемый, так как новые службы могут накладываться на существующие общие службы; а вложения в приложения Mission Operations дополнительно изолированы от технологии реализации. Технологические адаптеры позволяют изменять (или объединять) базовую коммуникационную инфраструктуру с минимальным влиянием на сами приложения. Это улучшает долгосрочную ремонтопригодность, поскольку миссии часто переживают наземные технологии, используемые для их первоначального развертывания.
Уровнями структуры обслуживания операций миссии [1] являются:
- Уровень служб операций миссии (MO) (который включает общие службы MO)
- Уровень абстракции сообщений (MAL)
- Уровень передачи сообщений
Интерфейс между каждым уровнем определен в стандартах 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