Немного о стандартах космической связи

image
Спутник Метеор М1
Источник: vladtime.ru


Введение


Эксплуатация космической техники невозможна без радиосвязи, и в этой статье я постараюсь объяснить основные идеи, которые легли в фундамент стандартов, разработанных Международным Консультативным Комитетом по космическим системам передачи данных (Consultative Committee for Space Data Systems – CCSDS. Далее будет использоваться эта аббревиатура).

Эта публикация будет посвящена в основном канальному уровню, однако основные понятия для других уровней тоже будут введены. Статься ни коим образом не претендует на доскональное и полное описание стандартов. С ним вы можете ознакомиться на сайте CCSDS. Однако они очень тяжелы для восприятия, и чтобы в них разобраться мы потратили немало времени, поэтому здесь хочу привести базовую информацию, обладая которой разобраться со всем остальным будет гораздо легче. Итак, начнём.

Благородная миссия CCSDS


Возможно, у кого-то возник вопрос: зачем всем придерживаться стандартов, если можно разработать свой проприентарный стек протоколов радиосвязи (или свой стандарт, с блэк-джеком и новыми фичами), повысив тем самым безопасность системы?

Как показывает практика, выгоднее придерживаться стандартам CCSDS по следующему ряду причин:

  1. В комитет, отвечающий за публикацию стандартов, вошли представители всех крупных аэрокосмических агентств мира, привнеся свой бесценный опыт, полученный на протяжении многих лет проектирования и эксплуатации различных миссий. Было бы очень нелепо игнорировать данный опыт и снова наступать на их грабли.
  2. Данные стандарты поддерживаются уже имеющимся на рынке оборудованием наземных станций.
  3. В ходе устранения каких-либо неполадок всегда можно обратиться за помощью к коллегам из других агентств, чтобы они провели сеанс связи с аппаратом со своей наземной станции.

Архитектура


Стандарты представляют собой совокупность документов, отражающих самую обычную модель OSI (Open System Interconnection), за исключением того, что на канальном уровне общность ограничивается разделением на телеметрию (канал «вниз» — космос – Земля) и телекоманды (канал «вверх»).



Рассмотрим некоторые уровни подробнее, начиная с физического, и двигаясь вверх. Для большей наглядности будем рассматривать архитектуру принимающей стороны. Передающая представляет собой её зеркальное отражение.

Физический уровень


На данном уровне происходит преобразование модулированного радиосигнала в битовый поток. Стандарты здесь носят в основном рекомендательный характер, так как на этом уровне сложно абстрагироваться от конкретной реализации железа. Здесь ключевая роль CCSDS – определить допустимые модуляции (BPSK, QPSK, 8-QAM и т.д.) и дать некоторые рекомендации по реализации механизмов символьной синхронизации, компенсации доплеровского сдвига и т.п.

Уровень синхронизации и кодирования


Формально является подуровнем канального уровня, однако очень часто выделяется в отдельный уровень ввиду своей важности в рамках стандартов CCSDS. Данный уровень преобразует битовый поток в так называемые кадры (телеметрии или телекоманд), о которых мы поговорим позже. В отличие от символьной синхронизации на физическом уровне, которая позволяет получить корректный битовый поток, здесь выполняется кадровая синхронизация. Рассмотрим путь, который данные проходят на данном уровне (снизу вверх):



Однако перед этим стоит сказать пару слов о кодировании. Эта процедура необходима чтобы находить и/или исправлять битовые ошибки, неминуемо возникающие при отправке данных по радиоканалу. Здесь мы не будем рассматривать процедуры декодирования, а только получим сведения, необходимые для понимания дальнейшей логики работы уровня.

Коды бывают блоковые и непрерывные. Стандарты не вынуждают использовать конкретный тип кодирования, однако оно как таковое должно присутствовать. К непрерывным относятся свёрточные (colvolutional) коды. С помощью них кодируется непрерывный битовый поток. В отличие от блочных кодов, где данные делятся на кодовые блоки (codeblock), и могут быть декодированы только в рамках цельных блоков. Кодовый блок представляет собой передаваемые данные и присоединённую избыточную информацию, необходимую для проверки правильности получения данных и исправления возможных ошибок. К блочным кодам относятся знаменитые коды Рида-Соломона.

Если используется свёрточное кодирование, битовый поток с начала поступает на декодер. Результатом его работы (всё это, разумеется, происходит непрерывно) становятся блоки данных CADU (channel access data unit). Данная структура необходима для кадровой синхронизации. В конце каждого CADU присоединено синхронизационный маркер (ASM – attached synch maker). Это известные заранее 4 байта, по которым синхронизатор находит начало и конец CADU. Так и достигается кадровая синхронизация.

Следующий опциональный этап работы уровня синхронизации и кодирования связан с особенностями работы физического уровня. Это дерандомизация. Дело в том, что для достижения символьной синхронизации необходимы частые переключения между символами. Так, если мы будем передавать, предположим, килобайт данных, состоящих исключительно из единиц, синхронизация будет потеряна. Поэтому при передаче входные данные смешиваются с периодичной псевдослучайной последовательностью, чтобы плотность нулей и единиц была равномерной.

Далее происходит декодирование блоковых кодов, и то, что осталось будет конечным продуктом уровня синхронизации и кодирования – кадром.

Канальный уровень


С одной стороны обработчик канального уровня получает кадры, а с другой стороны выдаёт пакеты. Так как формально размер пакетов не ограничен, для их надёжной пересылки необходимо разбивать их на более мелкие структуры – кадры. Здесь мы рассмотрим два подраздела: отдельно для телеметрии (TM) и телекоманд (TC).

Телеметрия


Проще говоря, это те данные, которые наземная станция получает от КА. Вся передаваемая информация делится на небольшие фрагменты фиксированной длины – кадры, которые содержат передаваемые данные и служебные поля. Рассмотрим структуру кадра подробнее:



И начнём рассмотрение с основного заголовка кадра телеметрии. Далее позволю себе в некоторых местах просто переводить стандарты, попутно давая некоторые разъяснения.



Поле идентификатора главного канала (Master Channel ID) должно содержать в себе номер версии кадра и идентификатор аппарата.

Каждый КА, по стандартам CCSDS должен иметь свой уникальный идентификатор, по которому можно, имея кадр, определить, какому аппарату он принадлежит. Формально необходимо подавать заявку на регистрацию аппарата, и его название, вместе с идентификатором, будет опубликовано в открытых источниках. Однако часто Российские производители игнорируют данную процедуру, присваивая аппарату произвольный идентификатор. Номер версии кадра помогает определить какая версия стандартов используется, чтобы правильно прочитать кадр. Здесь мы рассмотрим только самый консервативный стандарт с версией «0».

В поле идентификатора виртуального канала (Virtual Channel ID) должен содержаться VCID того канала, с которого поступил пакет. Никаких ограничений на выбор VCID нет, в частности виртуальные каналы не обязательно нумеруются последовательно.

Очень часто возникает необходимость мультиплексировать передаваемые данные. Для этого существует механизм виртуальных каналов. Например, спутник Метеор-М2 передаёт цветное изображение в видимом диапазоне, разделяя его на три чёрно-белых – каждый цвет передаётся в своём виртуальном канале отдельным пакетом, хотя в структуре его кадров есть некоторое отклонение от стандартов.

Поле флага Operational Control должен быть индикатором наличия или отсутствия поля Operational Control в кадре телеметрии. Эти 4 байта в конце кадра служат для поддержания обратной связи при контроле доставки кадров телекоманд. О них мы поговорим чуть позже.

Счётчики кадров главного и виртуального канала – это поля, увеличиваемые на единицу при отправке каждого кадра. Служат индикатором того, что ни один кадр не был потерян.

Статус данных кадра телеметрии – это ещё два байта флагов и данных, из которых мы рассмотрим лишь некоторые.



Поле флага дополнительного заголовка (Secondary Header) должно быть индикатором наличия или отсутствия дополнительного (Secondary Header) в кадре телеметрии.

При желании можно добавить к каждому кадру дополнительный заголовок и размещать там любые данные на своё усмотрение.

Поле указателя на первый заголовок (First Header Pointer), при значении флага синхронизации «1», должен сдержать бинарное представления позиции первого октета первого Пакета в поле данных (Data Field) кадра телеметрии. Позиция отсчитывается с 0 в возрастающем порядке от начала поля данных. Если нет начала пакета в поле данных кадра телеметрии, тогда поле указателя на первый заголовок должно иметь значение в бинарном представлении «11111111111» (такое может происходить, если один длинный пакет распространяется более чем на один кадр).

Если же в поле данных содержится пустой пакет (Idle Data), то указатель на первый заголовок должен иметь значение в бинарном представлении «11111111110». По данному полю приёмник должен осуществлять синхронизацию потока. Данное поле гарантирует восстановление синхронизации даже в случае пропуска кадров.

То есть пакет может, предположим, начинаться в середине 4-го кадра, и заканчиваться в начале 20-го. Чтобы найти его начало, как раз служит это поле. У пакетов тоже есть заголовок, в котором прописана его длина, поэтому при нахождении указателя на первый заголовок обработчик канального уровня должен его прочитать, тем самым определив, где закончится пакет.
Если поле контроля ошибок представлено, то оно должно содержаться в каждом кадре телеметрии для определённого физического канала на протяжении всей миссии.

Данное поле вычисляется применением CRC метода. Процедура должна принять n-16 бит кадра телеметрии и вставить результат вычисления в последние 16 бит.

Телекоманды


Кадр телекоманд имеет несколько существенных отличий. Среди них:

  1. Другая структура заголовков
  2. Динамическая длина. Это значит, что длина кадра не задана жёстко, как это сделано в телеметрии, а может изменяться в зависимости от передаваемых пакетов.
  3. Механизм гарантии доставки пакетов. То есть КА должен после получения подтвердить корректность приёма кадров, либо запросить пересылку с того кадра, который мог быть принят с некорректируемой ошибкой.





Многие поля уже знакомы нам из заголовка кадра телеметрии. Они имеют такое же назначение, поэтому здесь рассмотрим только новые поля.

Один бит флага обхода должен использоваться для контроля проверки кадров на приёмнике. Значение «0» данного флага должно указывать, что данный кадр является кадром типа А и его проверка должна осуществляться согласно FARM. Значение «1» данного флага должно указывать приёмнику, что данный кадр является кадром типа Б и должен обойти стороной проверку согласно FARM.

Этот флаг информирует приёмник, нужно ли использовать механизм подтверждения доставки кадров, который называется FARM — Frame Acceptance and Reporting Mechanism.

Флаг команды управления должен использоваться для понимания, транспортирует ли поле данных команду или данные. Если флаг равен «0», то поле данных должно содержать данные. Если флаг равен «1», то поле данных должно содержать контрольную информацию для FARM.
FARM представляет собой конечный автомат, параметры которого можно настраивать.

RSVD. SPARE – зарезервированные биты.

Похоже, у CCSDS есть на них планы в будущем, и для обратной совместимости версий протокола они зарезервировали эти биты уже в нынешних версиях стандарта.

Поле длины кадров должно содержать число в битовом представлении, которое равно длина кадра в октетах минус один.

Поле данных кадра должно следовать после заголовка без пропусков и содержать целое число октетов, которое может быть длиной максимально 1019 октетов. Данное поле должно содержать либо блок данных кадра, либо информацию команды управления. Блок данных кадра должен содержать в себе:

  • целое число октетов пользовательских данных
  • заголовок сегмента и следующие за ним целое число октетов пользовательских данных

Если заголовок представлен, то блок данных должен содержать в себе Пакет, множество Пакетов или его часть. Блок данных без заголовка не может содержать в себе части Пакетов, но может содержать блоки данных частного формата. Из этого следует, что заголовок требуется тогда, когда передаваемый блок данных не умещается в один кадр. Блок данных имеющий заголовок, называется сегментом



Поле флагов размером два бита должно содержать:

  • «01» — если первая часть данных находится в блоке данных
  • «00» — если средняя часть данных находится в блоке данных
  • «10» — если последняя часть данных находится в блоке данных
  • «11» — если нет деления и в блоке данных помещается целиком один или несколько пакетов.

Поле идентификатора MAP должно содержать нули, если MAP каналы не используются.
Иногда 6 бит, отведённых на виртуальные каналы, бывает недостаточно. И если необходимо мультиплексировать данные на большее число каналов, в ход идут ещё 6 бит из заголовка сегмента.

FARM


Рассмотрим подробнее механизм функционирования системы контроля доставки кадров. Данная система предусматривает только работу с кадрами телекоманд ввиду их важности (телеметрию всегда можно запросить снова, а КА должен слышать наземную станцию отчётливо, и всегда подчиняться её командам). Итак, предположим, мы решили перепрошить наш спутник, и отправляем на его борт бинарный файл размером 10 килобайт. На канальном уровне файл разбивается на 10 кадров (0, 1, …, 9), которые поочерёдно отправляются наверх. Когда передача закончена, КА должен подтвердить корректность приёма пакета, или сообщить на каком кадре произошла ошибка. Эта информация отправляется в поле оперативного контроля в ближайшем кадре телеметрии (Либо КА может инициировать передачу пустого кадра (idle frame), если ему нечего сказать). По полученной телеметрии мы либо убеждаемся, что всё хорошо, либо приступаем к перепосылке сообщения. Предположим, спутник не услышал кадр №7. Значит, отправляем ему кадры 7, 8, 9. В случае если ответа не последовало, пакет отправляется целиком ещё раз (и так несколько раз, пока не поймём, что попытки тщетны).

Ниже приведена структура поля оперативного контроля с описанием некоторых полей. Данные, содержащиеся в этом поле, называются CLCW – Communication Link Control Word.



Так как по картинке вполне можно догадаться о назначении основных полей, а на другие смотреть скучно, прячу детальное описание под спойлер

Расшифровка полей CLCW
Тип контрольного слова (Control Word Type):
Для данного типа контрольного слова должен содержать 0

Версия контрольного слова (CLCW Version Number):
Для данного типа контрольного слова должно равняться «00» в битовом представлении.

Поле статуса (Status Field):
Использование данного поля определяется для каждой миссии отдельно. Может использоваться для локальных улучшений разными космическими агентствами.

Идентификатор виртуального канала (Virtual Channel Identification):
Должен содержать идентификатор виртуального канала, с которым связано данной контрольное слово.

Флаг доступа к физическому каналу:
Флаг должен предоставлять информацию о готовности физического уровня приёмника. Если физический уровень приёмника не готов для приёма кадров, то поле должно содержать «1», иначе «0».

Флаг сбоя синхронизации:
Флаг может сообщать о том, что физический уровень работает при плохом уровне сигнала и количество отклоненных кадров слишком высоко. Использование данного поля опционально, если используется, то должно содержать «0» при наличии синхронизации, и «1» при её отсутствии.

Флаг блокировки:
Данный бит должен содержать статус блокировки FARM для каждого виртуального канала. Значение «1» в данном поле должно указывать на то, что FARM заблокирован и кадры будут отбрасываться для каждого виртуального уровня, иначе «0».

Флаг ожидания:
Данный бит должен использоваться для индикации того, что приёмник не может обработать данный на указанном виртуальном канале. Значение «1» указывает на то, что все кадры будут отбрасываться на данном виртуальном канале, иначе «0».

Флаг перепосылки:
Данный флаг должен содержать «1» если один или больше кадров типа А были отброшены или найдены пропуски, поэтому необходима перепосылка. Флаг «0» указывает, что не было отброшенных кадров и пропусков.

Значение ответа:
Номер кадра, который не был принят. Определяется по счётчику в заголовке кадра телекоманд

Сетевой уровень


Немного коснёмся и этого уровня. Здесь возможны два варианта: либо использовать протокол космического пакета, либо инкапсулировать любой другой протокол в CCSDS пакет.

Обзор протокола космического пакета – тема для отдельной статьи. Он создан для того, чтобы так называемые приложения могли бесшовно обмениваться данными. У каждого приложения есть свой адрес, и базовый функционал для обмена данными с другими приложениями. Также есть сервисы, выполняющие маршрутизацию трафика, выполняющие контроль доставки и т.п.

С инкапсуляцией всё проще и понятнее. Стандарты дают возможность инкапсулировать в CCSDS пакеты любые протоколы, добавив дополнительный заголовок.



Где заголовок имеет различные значения в зависимости от длины инкапсулируемого протокола:



Здесь основное поле – длина длины. Она может варьироваться от 0 до 4 байт. Также в этом заголовке необходимо указать тип инкапсулированного протокола, с помощью таблицы отсюда.

При инкапсуляции IP используется ещё одна надстройка, чтобы определить тип пакета.
Необходимо добавить ещё один заголовок, длиной от одного октета:



Где PID – ещё один идентификатор протокола, взятый отсюда

Заключение


С первого взгляда может показаться, что заголовки CCSDS крайне избыточны, и некоторые поля можно было бы отбросить. Действительно, эффективность результирующего канала (до сетевого уровня) составляет порядка 40%. Однако, как только возникает необходимость реализации данных стандартов, становится понятно, что у каждого поля, у каждого заголовка есть своя важная миссия, игнорирование которой приводит к целому ряду неоднозначностей.

Если хабраобщество проявит интерес к этой теме, буду рад опубликовать ещё целый ряд статей, посвящённый теории и практике космической связи. Спасибо за внимание!

Источники


CCSDS 130.0-G-3 — Overview of the space communications protocols
CCSDS 131.0-B-2 — TM synchronization and channel coding
CCSDS 132.0-B-2 — TM Space Data Link Protocol
CCSDS 133.0-B-1 — Space packet protocol
CCSDS 133.1-B-2 — Encapsulation Service
CCSDS 231.0-B-3 — TC Synchronization and Channel Coding
CCSDS 232.1-B-2 Communications Operation Procedure-1
CCSDS 401.0-B-28 Radio Frequency and Modulation Systems — Part 1 (Earth Stations and Spacecraft)
CCSDS 702.1-B-1 — IP over CCSDS space links

P.S.
Не бейте сильно, если найдёте неточности. Сообщите о них, и они будут исправлены :)
Поделиться публикацией

Комментарии 18

    0
    У меня есть изобретение Изобретение: «Способ приема информации и устройство для его осуществления». А.с. 1182562 от 1 июня 1985г.… «псевдокорреляционная обработка применительно к ДИМ сигналу».
    Вряд ли оно явно используется какой либо страной, но может вам встречалось что-то похожее? Нами до сих пор не внедрено, но может другие украли «внедрили». Я, когда отписал министру по поводу падения очередного спутника из-за плохой телеметрии и до сих пор не внедренного этого изобретения (НИОКР выполнена официально в НИИ и протоколы испытаний в ЦУП имеются), получил ответ из Роскосмоса (куда видно переслали мое письмо) — «Внедрить это изобретение не представляется возможным, так как нам непонятно, как оно работает». (По смыслу ответа).
    Вообще, в этой связи хочется поинтересоваться, на физическом уровне используется корреляционная обработка сигнала?
      0

      Это уже каждый производитель решает сам, но лично я о таких методах обработки сигналов никогда не слышал

        0
        Надо же, 40 лет прошло, но до сих пор не используется, хотя ракеты падают, падаю,…
        Мне, конечно, лестно, что я на 40 лет опередил чего-то там…, но за державу обидно!
        Как показали испытания в спутниковой системе связи,
        после «ухода» спутника за радиогоризонт телеметрическая информация продолжает приниматься данным устройством в течении 5-15 минут с постепенным падением достоверности и с индикацией степени достоверности принимаемого сигнала, в то время как обычные системы просто перестают вообще принимать. Нет никаких препятствий для применения данного способа в отношении других видов модуляций. Например в сотовых или спутниковых информационных системах. «Изюминка» заключается в алгоритме обработки принятого сигнала.
        Применение этого способа в сотовых системах связи, позволило бы расширить зону охвата и, значит, ставить меньше вышек связи. Заодно снизить мощность сотовых телефонов, а это значит, повысить продолжительность работы аккумулятора между зарядками.
          0

          Очень интересно! Обязательно ознакомлюсь.

        0
        «Внедрить это изобретение не представляется возможным, так как нам непонятно как оно работает»

        может быть в школе надо было лучше учиться? ))))
          0
          Нет, это не школа виновата. Корреляционные функции в институте преподают. Конечно, «дожили, инженеры не понимают, что такое корреляционная обработка сигнала». Но есть же протоколы испытаний, а я не как частное лицо делал свою работу. В конце концом, мы много чего используем, не понимая до конца явления, лежащие в основе устройства. Но это же нам не мешает использовать. Так и тут — есть протоколы испытаний — внедряйте.
          Но «загвоздка в другом». Генерал, принимающий испытания, на вопрос, будут ли внедрять, ответил лаконично — «Нет, не будем. За внедрение вашей системы мы ничего не получим, так как оно идет по линии Минсвязи, а не Минобороны. Нам не светят ни зарплаты. ни премии. Так что, нет»!
          Вот и сейчас, в Роскосмосе понимают, что это не их разработка и им за чужую работу не заплатят как за НИОКР. Да еще и авторам надо платить. А там, где «надо платить чужим», возникает уйма причин-аргументов, почему «платить не надо»!
            0
            «дожили, инженеры не понимают, что такое корреляционная обработка сигнала»

            Я уже ничему не удивляюсь… После того как при запуске с Восточного ввели координаты для Байконура и когда неправильно расчитали количество необходимого горючего, удивляться уже ничему не приходится… По моему этот космос никому из руководства России не нужен… Иначе бы не фигурировали зарплаты в районе 10000 руб при приеме в новый космический центр в Миассе… Отсюда и вопиющая безграмотность инженеров…

            m.jobinmoscow.ru/rab.php?id=423625
              0
              Напомнил. Как-то очередная ракета рухнула по причине перегруза, заправили больше рассчитанного. Я в рамблере написал стишок по этому поводу. После этого мне было запрещено писать комменты в рамблере. "«Политика»" везде!
              Примерно такой.
              На космодроме ракета стояла,
              Машина заправки к ней подъезжала.
              «Сколько залить?» — заправщик сказал,
              «Лей полный бак» — отвечал генерал.
                0
                Значит это другой случай… Я помню когда недолили...)))
                И ракета не долетела до расчетной орбиты…
                  +2
                  10 дек. 2010 г. — Причиной падения трех спутников ГЛОНАСС стал перелив топлива во время заправки ракеты-носителя «Протон-М». В ракету-носитель для выведения спутников на орбиту налили две лишние тонны топлива.
        +2
        Каждый КА, по стандартам CCSDS должен иметь свой уникальный идентификатор, по которому можно, имея кадр, определить, какому аппарату он принадлежит

        10 бит на уникальный идентификатор КА — это как-то имхо маловато… они там еще не размышляли над следующей версией протокола?
          +1

          Идентификатор присваивается лишь на некоторое время, так как активный срок существования миссии небольшой, поэтому потребность в большей разрядности пока не возникает.
          Хотя с появлением больших орбитальных группировок для спутникового интернета всё может измениться.

          0
          Насколько этот протокол распространен? Периодически слежу за развитием сети SatNOGS, но не видел упоминания этого протокола и о существовании программ для его декодирования.
            +1

            Используется этот протокол в основном в командной радиолинии КА. Точно знаю, что современные миссии NASA и ESA, в том числе межпланетные его используют. Также имел дело с инженерами из РКК Энергия. На всех их аппаратах для связи используются именно CCSDS.


            Есть протокол Proximity-1, также относящийся к этим стандартам, описывающий порядок взаимодействия ровера и орбитального КА на другой планете.

              0
              Т.е. кубсаты используют что-то попроще самописное?
                +2

                Не обязательно. Если они хотят положиться на инфраструктуру существующих наземных станций, то следовать стандартам гораздо удобнее.
                Очень часто вижу в описании кубсатовских миссий упоминание модемов Cortex от французской компании Zodiac aerospace (Мы тоже такой используем). Он хорошо заточен на работу по CCSDS. Это значит, что с большой долей вероятности они этих стандартов придерживаются.

                  0
                  Теперь понятно, что предлагает Amazon
                  image
            0
            Поискал Mars в их списке аппаратов и там почти все. Т.е. похоже марсианские аппараты используют одни и те же ретрансляторы и протоколы. В списке есть арабский и китайский аппараты, которые видимо рассчитывают использовать существующие на орбите Марса ретрансляторы.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое