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

Спутник Метеор М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.

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

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

Немного коснёмся и этого уровня. Здесь возможны два варианта: либо использовать протокол космического пакета, либо инкапсулировать любой другой протокол в 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.
Не бейте сильно, если найдёте неточности. Сообщите о них, и они будут исправлены :)

Автор: Равиль Талипов

Источник