Уровень абстракции сообщений
Рабочая группа по мониторингу и управлению космическими аппаратами (SM&C) Консультативного комитета по системам космических данных ( CCSDS ), в которой активно участвуют 10 космических агентств и Целевая группа по космической области Группы управления объектами ( OMG ), определяет сервис-ориентированная архитектура, состоящая из набора стандартных сквозных услуг между функциями, находящимися на борту космического корабля или базирующимися на земле, которые отвечают за операции миссии.
Уровень абстракции сообщений CCSDS (MAL) обеспечивает абстракцию сообщений и общие шаблоны обслуживания для служб Mission Operation (MO), определенных в концепции CCSDS Mission Operations Services. [1]
Многоуровневое обслуживание
[ редактировать ]
Ключевая особенность MO Service Framework [1] это многоуровневое обслуживание. Несмотря на то, что существует ряд потенциальных услуг, соответствующих различным типам информации об операциях миссии, которой обмениваются внутри системы (параметры состояния, управляющие действия, орбитальные данные, сроки миссии и т. д.), эти услуги прикладного уровня реализуются с точки зрения меньший набор общих шаблонов взаимодействия, которые позволяют наблюдать текущий статус, вызывать операции и передавать большие объемы данных. Это имеет два ключевых преимущества: оно по своей сути расширяемо, поскольку новые услуги могут накладываться на существующие общие службы; а инвестиции в приложения МО еще больше изолированы от технологии внедрения. Технологические адаптеры позволяют изменять (или соединять) базовую коммуникационную инфраструктуру с минимальным влиянием на сами приложения. Это улучшает долгосрочную ремонтопригодность, поскольку миссии часто переживают наземные технологии, использованные для их первоначального развертывания.
Уровни структуры обслуживания операций миссии [1] являются:
- Уровень операций миссии (MO)
- Уровень общих служб
- Уровень абстракции сообщений (MAL)
- Транспортный уровень сообщений
Интерфейс между каждым уровнем определен в стандартах CCSDS, и поэтому реализации каждого уровня могут быть заменены без внесения изменений в другое программное обеспечение.
Абстракция сообщений
[ редактировать ]Чтобы обеспечить независимость языка реализации и транспорта сообщений, все операции службы должны определяться независимой спецификацией языка/платформы/кодирования. MAL определяет этот набор базовых типов данных и то, как их следует использовать для создания сообщений, составляющих операции службы. Только тогда это необходимо один раз сопоставить в стандарте MO с конкретным языком реализации или транспортной кодировкой, чтобы применить ко всем службам, которые определены в терминах MAL.Помимо шаблонов взаимодействия и абстрактного API, MAL обеспечивает поддержку следующего:– общие понятия, такие как домен, сеанс и зона;– общие средства, такие как контроль доступа (аутентификация и авторизация) и качество обслуживания.
Паттерны взаимодействия
[ редактировать ]Работу службы можно разложить на набор сообщений, которыми обмениваются поставщик службы и потребитель, и сформировать шаблон взаимодействия. Анализ услуг, приведенных в справке [1] показывает, что существует ограниченное количество таких шаблонов взаимодействия, которые можно применить ко всем выявленным в настоящее время услугам.Стандартизация шаблона взаимодействия, определяющего последовательность сообщений, передаваемых между потребителем и поставщиком, позволяет определить общий шаблон для работы службы.MAL определяет этот ограниченный набор общих шаблонов взаимодействия (шаблонов), которые должны использоваться службами, определенными в структуре службы MO. Каждая операция службы определяется с точки зрения одного из шаблонов взаимодействия MAL.Определив шаблон и заявив, что данная операция является примером этого шаблона, определение операции может сосредоточиться на особенностях этой операции и полагаться на стандартный шаблон для облегчения этого.Например, может быть определена операция doFoo, которая является примером шаблона под названием SUBMIT. Эта операция состоит из двух частей: шаблон сообщений, которыми обмениваются (шаблон «SUBMIT»), а также значение этих сообщений и то, что делает «doFoo». Определив шаблон как стандарт («SUBMIT»), спецификация сервиса, определяющая «doFoo», должна только определить значение сообщений и то, что делает операция. MAL определяет этот набор шаблонов.
Преимущества
[ редактировать ]Преимущество реализации нескольких сервисов на уровне абстракции сообщений заключается в том, что их легче привязать к различным базовым технологиям и кодировкам протоколов. Все, что требуется, — это уровень «адаптера» между MAL и базовым протоколом, чтобы обеспечить работу всех служб по этой технологии. Следовательно, та же услуга может быть реализована с помощью наземных сетевых технологий и промежуточного программного обеспечения или даже может передаваться по самой космической линии связи.Сами службы обеспечивают интерфейс «включай и работай» для приложений, что позволяет их интегрировать и развертывать там, где это необходимо для миссии.
Накладные расходы на производительность отсутствуют, поскольку уровень MAL является концептуальным и может быть оптимизирован с помощью генераторов кода. [2]
Недостатки
[ редактировать ]MAL не будет поддерживать функции базового протокола, выходящие за рамки «наименьшего общего знаменателя», определенного в MAL. Функции обмена сообщениями (например, модель потоков, качество обслуживания и т. д.) ограничены более простым подмножеством, которое представляет собой пересечение всех базовых опций промежуточного программного обеспечения. Однако функцию базового протокола можно выбрать посредством конфигурации.
По-прежнему требуется уровень адаптера между MAL и базовым протоколом, а также спецификации для привязки языков. Реализации должны соответствовать этим спецификациям для обеспечения совместимости. Таким образом, MAL сам по себе приобретает характеристики нового стандарта промежуточного программного обеспечения.
Адаптеры MAL и спецификации привязки языка MAL должны поддерживаться по мере развития базовых стандартов промежуточного программного обеспечения для подключаемых модулей. Однако использование MAL устраняет любую прямую зависимость приложения от технологий протокола, и, следовательно, можно изолировать любое развитие на нижних уровнях адаптера.
MAL исключает использование контрактов на обслуживание в качестве центрального элемента, определяющего архитектуру обслуживания, управляемого данными.
Реализации
[ редактировать ]Для процедур CCSDS требуются две независимые реализации, они были реализованы ESA и CNES . Оба агентства работают над выпуском под лицензиями с открытым исходным кодом.
Ссылки
[ редактировать ]- ^ Jump up to: а б с д Концепция обслуживания миссий. Архивировано 31 мая 2013 г. в Wayback Machine , CCSDS 520.0-G-3. Зеленая книга. Выпуск 3. Декабрь 2010 г.
- ^ Будущие тенденции операций миссии [ постоянная мертвая ссылка ]