Мониторинг космических аппаратов и управления (SM & C) Рабочая группа Консультативного комитета по системам космических данных ( CCSDS ), который видит активное участие 10 космических агентств и Целевой группы Space Доменное объект группы управления ( OMG ), является определение сервисно-ориентированная архитектура, состоящая из набора стандартных сквозных сервисов между функциями, находящимися на борту космического корабля или на земле, которые отвечают за операции миссии.
Уровень абстракции сообщений CCSDS (MAL) обеспечивает абстракцию сообщений и общие шаблоны услуг для сервисов Mission Operation (MO), определенных в концепции CCSDS Mission Operations Services. [1]
Уровни обслуживания
![CCSDS SM&C layer diagram.png](http://wikiimg.tojsiabtv.com/wikipedia/en/thumb/b/bd/CCSDS_SM%26C_layer_diagram.png/400px-CCSDS_SM%26C_layer_diagram.png)
Ключевой особенностью MO Service Framework [1] является многоуровневость сервисов. Несмотря на то, что существует ряд потенциальных услуг, определенных в соответствии с различными типами информации об операциях миссии, которыми обмениваются внутри системы (параметры состояния, управляющие действия, орбитальные данные, сроки выполнения задач и т. меньший набор общих шаблонов взаимодействия, которые позволяют наблюдать за текущим статусом, вызывать операции и массовую передачу данных. Это дает два ключевых преимущества: он изначально расширяемый, так как новые службы могут накладываться на существующие общие службы; а вложения, сделанные в МО-приложения, дополнительно изолированы от технологии реализации. Технологические адаптеры позволяют изменять (или объединять) базовую коммуникационную инфраструктуру с минимальным влиянием на сами приложения. Это улучшает долгосрочную ремонтопригодность, поскольку миссии часто переживают наземные технологии, используемые для их первоначального развертывания.
Уровнями структуры обслуживания операций миссии [1] являются:
- Уровень операций миссии (MO)
- Уровень общих служб
- Уровень абстракции сообщений (MAL)
- Уровень передачи сообщений
Интерфейс между каждым уровнем определен в стандартах CCSDS, поэтому реализации каждого уровня могут быть заменены без изменений в другом программном обеспечении.
Абстракция сообщения
Чтобы обеспечить независимость от языка реализации и транспорта сообщений, все операции службы должны определяться спецификацией, не зависящей от языка / платформы / кодирования. MAL определяет этот набор основных типов данных и то, как они должны использоваться для создания сообщений, составляющих операции службы. Только в этом случае это должно быть отображено один раз в стандарте MO на конкретный язык реализации или транспортную кодировку, чтобы применить ко всем услугам, которые определены в терминах MAL. Помимо шаблонов взаимодействия и абстрактного API, MAL поддерживает следующее: - общие концепции, такие как домен, сеанс и зона; - общие средства, такие как контроль доступа (аутентификация и авторизация) и качество обслуживания.
Паттерны взаимодействия
Операцию службы можно разложить на набор сообщений, которыми обмениваются поставщик службы и потребитель, и сформировать шаблон взаимодействия. Анализ сервисов, приведенный в ссылке [1], показывает, что существует ограниченное количество этих шаблонов взаимодействия, которые могут быть применены ко всем в настоящее время идентифицированным сервисам. Стандартизация шаблона взаимодействия, который определяет последовательность сообщений, передаваемых между потребителем и поставщиком, позволяет определить общий шаблон для работы службы. MAL определяет этот ограниченный набор общих шаблонов взаимодействия (шаблонов), которые должны использоваться службами, определенными в структуре обслуживания MO. Каждая операция службы определяется в терминах одного из шаблонов взаимодействия MAL. Определяя шаблон и заявляя, что данная операция является примером этого шаблона, определение операции может сосредоточиться на специфике этой операции и полагаться на стандартный шаблон для облегчения этого. Например, может быть определена операция «doFoo», которая является примером шаблона, называемого «ОТПРАВИТЬ». Эта операция состоит из двух частей: шаблона сообщений, которыми обмениваются (шаблон «SUBMIT») и значения этих сообщений, а также того, что делает «doFoo». Определив шаблон как стандартный («ОТПРАВИТЬ»), спецификация службы, определяющая «doFoo», должна только определять значение сообщений и то, что делает операция. MAL определяет этот набор шаблонов.
Преимущества
Преимущество реализации нескольких сервисов на уровне абстракции сообщений состоит в том, что их легче привязать к различным базовым технологиям и кодировкам протоколов. Все, что требуется, - это уровень «адаптера» между MAL и нижележащим протоколом, чтобы включить все службы по этой технологии. Следовательно, одна и та же услуга может быть реализована с использованием наземных сетевых технологий и промежуточного программного обеспечения или даже может быть передана по самому космическому каналу связи. Сами сервисы предоставляют интерфейс «plug-and-play» для приложений, что позволяет их интегрировать и развертывать там, где это подходит для миссии.
Нет никаких накладных расходов на производительность, поскольку уровень MAL концептуален и может быть оптимизирован с помощью генераторов кода. [2]
Недостатки
MAL не будет поддерживать функции базового протокола, выходящие за рамки «наименьшего общего знаменателя», определенного в MAL. Функции обмена сообщениями (например, потоковая модель, QoS и т. Д.) Ограничены более простым подмножеством, которое представляет собой пересечение всех основных опций промежуточного программного обеспечения. Однако функция нижележащего протокола может быть выбрана посредством конфигурации.
Уровень адаптера между MAL и базовым протоколом, а также спецификации языковых привязок по-прежнему необходимы. Реализации должны придерживаться этих спецификаций для взаимодействия. Таким образом, MAL сам по себе приобретает характеристики нового стандарта промежуточного программного обеспечения.
Адаптеры MAL и спецификации привязки языка MAL должны поддерживаться по мере развития базовых стандартов промежуточного программного обеспечения для подключаемых модулей. Однако использование MAL устраняет любую прямую зависимость приложения от технологий протокола, и, следовательно, можно изолировать любое развитие до более низких уровней адаптеров.
MAL исключает использование контрактов на обслуживание в качестве центрального элемента, определяющего архитектуру услуг, управляемую данными.
Реализации
Процедуры CCSDS требуют двух независимых реализаций, они были реализованы ESA и CNES . Оба агентства работают над выпуском под лицензиями с открытым исходным кодом.
Рекомендации
- ^ a b c d Концепция оперативных служб миссии. Архивировано 31 мая 2013 г. на Wayback Machine , CCSDS 520.0-G-3. Зеленая книга. Выпуск 3. Декабрь 2010 г.
- ^ Тенденции будущих операций миссий [ постоянная мертвая ссылка ]