Операции миссии CCSDS
 | Эта статья включает список литературы , связанную литературу или внешние ссылки , но ее источники остаются неясными, поскольку в ней отсутствуют встроенные цитаты . ( Август 2022 г. ) |
Рабочая группа по мониторингу и управлению космическими аппаратами ( SM&C ) Консультативного комитета по системам космических данных (CCSDS), в которой активно участвуют основные http://www.space.bas.bg/bg/procurement/files/pravilnik% Агентства 20OP.PDF определяют сервис-ориентированную архитектуру, состоящую из набора стандартных сквозных услуг между функциями, находящимися на борту космического корабля или наземными, которые отвечают за операции миссии.
Выявление проблемы
[ редактировать ] |
Существует общая тенденция к увеличению сложности миссий одновременно с усилением давления с целью снижения затрат на операции миссий, как с точки зрения первоначального развертывания, так и с точки зрения текущих расходов. Закрытая или «монолитная» архитектура системы операций миссии не позволяет перераспределять функциональные возможности между космосом и землей или между узлами наземной системы. Отсутствие архитектурной открытости приводит к:
- отсутствие взаимодействия между агентствами;
- отсутствие повторного использования между миссиями и наземными системами;
- увеличение стоимости разработки и развертывания конкретной миссии;
- недоступность коммерческих универсальных инструментов;
- невозможность замены технологии внедрения без серьезной переработки системы;
- отсутствие оперативной общности между системами миссий, увеличение затрат на обучение.
В результате возникает множество параллельных системных инфраструктур, специфичных для данного семейства космических кораблей или эксплуатирующих организаций, с небольшими перспективами взаимного обогащения между ними.
Подход к инфраструктуре обслуживания
[ редактировать ] |
Сервис-ориентированная архитектура (SOA) постепенно заменяет монолитную архитектуру в качестве основного принципа проектирования новых приложений как в частных, так и в распределенных системах. Это один из фундаментальных принципов проектирования сетевых распределенных приложений, в которых интерфейсы, как операции, так и объекты данных, должны быть четко определены, поскольку клиенты часто неоднородны. SOA — это подход к проектированию системы, который опирается не на спецификацию монолитной интегрированной системы, а на идентификацию более мелких модульных компонентов, которые взаимодействуют только через открытые, опубликованные сервисные интерфейсы.
Рабочая группа SM&C определяет набор стандартных сервисов, которые представляют собой структуру, позволяющую собирать множество подобных систем из совместимых «подключаемых» компонентов. Эти компоненты могут располагаться где угодно при условии, что они связаны общей инфраструктурой. Это позволяет повторно использовать компоненты в различных развертываниях для конкретных миссий: между агентствами, между миссиями и между системами.
Если услуги указаны непосредственно с точки зрения конкретной реализации инфраструктуры, то они привязаны к этой технологии. Вместо этого, путем разделения самих сервисов, спецификации сервисов можно сделать независимыми от базовой технологии. Специальные технологические адаптеры позволяют развертывать сервисную структуру поверх этой технологии. Это, в свою очередь, позволяет заменить реализацию инфраструктуры, а также реализации компонентов. Также возможно прозрачное соединение между различными реализациями инфраструктуры, если они подходят для различных коммуникационных сред (например, в космосе или на земле) или просто отражают варианты развертывания различных агентств.
ПРИМЕЧАНИЕ. – Подключаемые компоненты обмениваются данными только через стандартные сервисные интерфейсы через общую инфраструктуру. Платформа обслуживания сама по себе является многоуровневой и независимой от реализации базовой инфраструктуры.
Также важно отметить, что подход не предписывает сами компоненты или их реализацию. Стандартизированы только сервисные интерфейсы между компонентами. Это позволяет внедрять инновации, специализировать и дифференцировать компоненты, обеспечивая при этом их быструю интеграцию в систему. Однако для того, чтобы структура обслуживания была эффективной, она должна обеспечивать обмен значимой информацией, связанной с операциями миссии, через интерфейсы обслуживания, а не просто данными. Платформа обслуживания также должна уважать устаревшие системы. Если интегрированная унаследованная система выполняет функции нескольких компонентов структуры обслуживания, ее внутреннюю архитектуру и реализацию не нужно менять. Только те интерфейсы, которые он предоставляет другим системам, необходимо «обернуть», чтобы сделать их совместимыми с соответствующими сервисными интерфейсами. Платформа обслуживания предлагает ряд совместимых интерфейсов, из которых можно выбрать наиболее подходящий: соответствие требованиям не зависит от поддержки их всех. Таким образом, устаревшие системы можно повторно использовать в сочетании с другими совместимыми компонентами для создания системы, конкретной миссии. Подход задуман как эволюционный, а не революционный.
Многоуровневое обслуживание
[ редактировать ] |
Ключевой особенностью структуры обслуживания операций миссий [1] является многоуровневое распределение услуг. Несмотря на то, что существует ряд потенциальных услуг, соответствующих различным типам информации об операциях миссии, которой обмениваются внутри системы (параметры состояния, управляющие действия, орбитальные данные, сроки миссии и т. д.), эти услуги прикладного уровня реализуются с точки зрения меньший набор общих шаблонов взаимодействия, которые позволяют наблюдать текущий статус, вызывать операции и передавать большие объемы данных. Это имеет два ключевых преимущества: оно по своей сути расширяемо, поскольку новые услуги могут накладываться на существующие общие службы; а инвестиции в приложения Mission Operations еще больше изолированы от технологии внедрения. Технологические адаптеры позволяют изменять (или соединять) базовую коммуникационную инфраструктуру с минимальным влиянием на сами приложения. Это улучшает долгосрочную ремонтопригодность, поскольку миссии часто переживают наземные технологии, использованные для их первоначального развертывания.
Уровнями структуры обслуживания операций миссии [1] являются:
- Уровень служб операций миссии (MO) (который включает общие службы MO)
- Уровень абстракции сообщений (MAL)
- Транспортный уровень сообщений
Интерфейс между каждым уровнем определен в стандартах CCSDS, и поэтому реализации каждого уровня могут быть заменены без внесения изменений в другое программное обеспечение.
Потенциальные преимущества
[ редактировать ] |
Стандартизация структуры обслуживания операций миссии [1] предлагает ряд потенциальных преимуществ для разработки, развертывания и обслуживания инфраструктуры операций миссии:
- повышенная совместимость между агентствами на уровне космических кораблей, полезной нагрузки или наземного сегмента. компонентов инфраструктуры
- стандартизация инфраструктурных интерфейсов, даже внутри агентств, что приводит к повторному использованию между миссиями и возможности создания общей инфраструктуры для нескольких миссий, что снижает затраты на обучение оперативных групп и время на подготовку новых миссий
- стандартизация операционных интерфейсов космических аппаратов разных производителей
- снижение стоимости развертывания для конкретной миссии за счет интеграции компонентов многократного использования
- возможность выбрать лучший продукт для конкретной задачи из ряда совместимых компонентов
- большая гибкость в границах развертывания: переносить между площадками наземного сегмента или даже с земли в космос функции можно легче
- стандартизация ограниченного количества сервисов , а не большого количества конкретных межкомпонентных интерфейсов
- усиление конкуренции в сфере предоставления коммерческих инструментов, что приводит к снижению затрат и независимости поставщиков.
- улучшенная долгосрочная ремонтопригодность за счет эволюции системы на протяжении всего срока службы путем замены как компонентов, так и инфраструктуры.
Операции миссии
[ редактировать ] |
Термин «миссия операций» (МО) используется для обозначения совокупности действий, необходимых для управления космическими кораблями и их полезной нагрузкой. Он включает в себя:
- мониторинг и управление подсистемами и полезной нагрузкой космического корабля
- анализ и отчетность о характеристиках космических аппаратов
- планирование, составление графиков и выполнение операций миссии
- определение орбиты и ориентации, прогнозирование и подготовка маневра
- управление бортовым ПО (загрузка и дамп)
- доставка информационных продуктов миссии.
Обычно они рассматриваются как функции Центра управления полетами (ЦУП) и выполняются оперативной группой миссии при поддержке Системы управления полетами. МО включает в себя возможность архивировать и распространять данные об операциях миссии. Хотя это может включать обработку данных миссии, деятельность, конкретно связанная с использованием данных миссии (например, обработка, архивирование и распространение данных конкретной миссии), считается выходящей за рамки МО. Все чаще функции МО могут распределяться между сотрудничающими агентствами и площадками наземного сегмента или частично делегироваться автономным функциям на борту самого космического корабля. Структура обслуживания MO обеспечивает сквозное взаимодействие между прикладным программным обеспечением MO, где бы оно ни располагалось в пределах космической системы. В частности, он не касается предоставления услуг по транспортировке или сохранению (хранению) данных. Однако он является пользователем таких услуг.
См. также
[ редактировать ]Ссылки
[ редактировать ][1] Концепция обслуживания операций миссии. CCSDS 520.0-G-3. Зеленая книга. Выпуск 3. Декабрь 2010 г. https://web.archive.org/web/20130531013416/http://public.ccsds.org/publications/archive/520x0g3.pdf .