Войти
Мониторинг космических аппаратов и управления (SM amp; C) Рабочая группа Консультативного комитета по системам космических данных ( CCSDS ), который видит активное участие 10 космических агентств и Целевой группы Space Доменное объект группы управления ( OMG ), является определение сервисно-ориентированная архитектура, состоящая из набора стандартных сквозных сервисов между функциями, находящимися на борту космического корабля или на земле, которые отвечают за выполнение операций миссии.
Уровень абстракции сообщений CCSDS (MAL) обеспечивает абстракцию сообщений и общие шаблоны услуг для сервисов Mission Operation (MO), определенных в концепции CCSDS Mission Operations Services.
Ключевой особенностью MO Service Framework является многоуровневость сервисов. Несмотря на то, что существует ряд потенциальных услуг, определенных в соответствии с различными типами оперативной информации, которой обмениваются в системе (параметры состояния, управляющие действия, орбитальные данные, сроки выполнения задач и т. Д.), Эти услуги на уровне приложений реализуются в виде меньший набор общих шаблонов взаимодействия, которые позволяют наблюдать за текущим статусом, вызывать операции и массовую передачу данных. Это дает два ключевых преимущества: он изначально расширяемый, поскольку новые службы могут накладываться на существующие общие службы; а инвестиции, сделанные в MO-приложения, дополнительно изолированы от технологии реализации. Технологические адаптеры позволяют изменять (или объединять) базовую коммуникационную инфраструктуру с минимальным влиянием на сами приложения. Это улучшает долгосрочную ремонтопригодность, поскольку миссии часто переживают наземные технологии, используемые для их первоначального развертывания.
Уровни структуры обслуживания операций миссии следующие:
Интерфейс между каждым уровнем определен в стандартах CCSDS, и поэтому реализации каждого уровня могут быть заменены без изменений в другом программном обеспечении.
Чтобы обеспечить независимость от языка реализации и транспорта сообщений, все операции службы должны определяться спецификацией, не зависящей от языка / платформы / кодирования. MAL определяет этот набор основных типов данных и то, как они должны использоваться для создания сообщений, составляющих операции службы. Только в этом случае его нужно один раз отобразить в стандарте MO на конкретный язык реализации или транспортную кодировку, чтобы применить ко всем услугам, которые определены в терминах MAL. В дополнение к шаблонам взаимодействия и абстрактному API MAL обеспечивает поддержку следующего: - общие концепции, такие как домен, сеанс и зона; - общие средства, такие как контроль доступа (аутентификация и авторизация) и качество обслуживания.
Операция службы может быть разложена на набор сообщений, которыми обмениваются поставщик службы и потребитель, и сформировать шаблон взаимодействия. Анализ сервисов, приведенных в справочнике, показывает, что существует ограниченное количество этих шаблонов взаимодействия, которые могут быть применены ко всем в настоящее время идентифицированным сервисам. Стандартизация шаблона взаимодействия, который определяет последовательность сообщений, передаваемых между потребителем и поставщиком, позволяет определить общий шаблон для работы службы. MAL определяет этот ограниченный набор общих шаблонов взаимодействия (шаблонов), которые должны использоваться службами, определенными в структуре обслуживания MO. Каждая операция службы определяется с помощью одного из шаблонов взаимодействия MAL. Определяя шаблон и заявляя, что данная операция является примером этого шаблона, определение операции может сосредоточиться на специфике этой операции и полагаться на стандартный шаблон для облегчения этого. Например, может быть определена операция «doFoo», которая является примером шаблона под названием «ОТПРАВИТЬ». Эта операция состоит из двух частей: шаблона сообщений, которыми обмениваются (шаблон «SUBMIT») и значения этих сообщений, а также того, что делает «doFoo». Определив шаблон как стандартный («ОТПРАВИТЬ»), спецификация службы, определяющая «doFoo», должна только определять значение сообщений и то, что делает операция. MAL определяет этот набор шаблонов.
Преимущество реализации нескольких сервисов на уровне абстракции сообщений состоит в том, что их легче связать с различными базовыми технологиями и кодировками протоколов. Все, что требуется, - это уровень «адаптера» между MAL и нижележащим протоколом, чтобы включить все службы по этой технологии. Следовательно, одна и та же услуга может быть реализована с использованием наземных сетевых технологий и промежуточного программного обеспечения или даже может быть передана через саму космическую связь. Сами сервисы предоставляют интерфейс «plug-and-play» для приложений, что позволяет их интегрировать и развертывать там, где это подходит для миссии.
Нет никаких накладных расходов на производительность, поскольку уровень MAL концептуален и может быть оптимизирован с помощью генераторов кода.
MAL не будет поддерживать функции базового протокола, выходящие за рамки «наименьшего общего знаменателя», определенного в MAL. Функции обмена сообщениями (например, потоковая модель, QoS и т. Д.) Ограничены более простым подмножеством, которое представляет собой пересечение всех базовых опций промежуточного программного обеспечения. Однако функция нижележащего протокола может быть выбрана посредством конфигурации.
Уровень адаптера между MAL и базовым протоколом, плюс спецификации языковых привязок, по-прежнему необходимы. Реализации должны соответствовать этим спецификациям для взаимодействия. Таким образом, MAL сам по себе становится новым стандартом промежуточного программного обеспечения.
Адаптеры MAL и спецификации привязки языка MAL должны поддерживаться по мере развития основных стандартов промежуточного программного обеспечения для подключаемых модулей. Однако использование MAL устраняет любую прямую зависимость приложения от технологий протокола, и, следовательно, можно изолировать любое развитие до более низких уровней адаптеров.
MAL исключает использование сервисных контрактов в качестве центрального элемента, определяющего сервисную архитектуру, управляемую данными.
Процедуры CCSDS требуют двух независимых реализаций, они были реализованы ESA и CNES. Оба агентства работают над выпуском под лицензиями с открытым исходным кодом.
