🥇 Малко за стандартите на космическите комуникации

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

Въведение

Експлоатацията на космическа техника е невъзможна без радиосвръзка, и в тази статия ще се опитам да обясня основните идеи, които легнаха в основата на стандартите, разработени от Международния консултативен комитет по космически системи за предаване на данни (Consultative Committee for Space Data Systems – CCSDS. По-нататък ще използваме тази абревиатура).

Тази публикация ще бъде основно посветена на канала, но основните понятия за другите нива също ще бъдат представени. Статията по никакъв начин не претендира за изчерпателно и пълно описание на стандартите. Можете да се запознаете с тях на сайта CCSDS. Въпреки това, те са много трудни за възприемане, и за да ги разберем, ние вложихме значителен труд, така че тук ще предоставя основна информация, с която е много по-лесно да се разбере всичко останало. Да започнем.

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

Възможно е някой да се запита: защо всички трябва да се придържат към стандартите, след като може да се разработи собствен проприетарен стек протоколи за радиосвръзка (или свой стандарт, с черен джек и нови функции), повишавайки по този начин сигурността на системата?

Както практиката показва, по-изгодно е да се придържаме към стандартите на CCSDS по следните причини:

В комисията, отговорна за публикуването на стандартите, влязоха представители от всички основни космически агенции по света, носещи своя безценен опит, придобит през години на проектиране и експлоатация на различни мисии. Беше много нелепо да игнорираме този опит и отново да стъпваме на техните грабли.
Тези стандарти се поддържат от вече наличното на пазара оборудване на наземните станции.
В процеса на отстраняване на всякакви неизправности винаги можем да се обърнем за помощ към колеги от други агенции, за да проведат сесия на връзка с апарата от тяхната наземна станция. Както виждате, стандартите са изключително полезни, така че нека разгледаме техните ключови моменти.

Архитектура

Стандартите представляват съвкупност от документи, отразяващи най-обичайната модел на OSI (Open System Interconnection), с изключение на това, че на канала общността е ограничена до разделението на телеметрия (канал "надолу" — космос – Земя) и телеконструкции (канал "нагоре").

Нека разгледаме някои нива по-подробно, започвайки от физическото и преминавайки нагоре. За по-добро представяне ще разгледаме архитектурата на приемащата страна. Предаващата представлява нейното огледално отражение.

Физическият ниво

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

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

Формално е подуровен на каналното ниво, обаче често се отделя в самостоятелно ниво поради своята важност в рамките на стандартите CCSDS. Това ниво преобразува битовия поток в така наречените кадри (телеметрия или телекомуникации), за които ще говорим по-късно. За разлика от символната синхронизация на физическото ниво, която позволява получаването на коректен битов поток, тук се извършва кадровата синхронизация. Нека разгледаме пътя, който данните преминават на това ниво (отдолу нагоре):

Въпреки това преди това е необходимо да кажем няколко думи за кодиране. Тази процедура е необходима, за да се открият и/или коригират битови грешки, които неизбежно възникват при изпращането на данни по радиоканала. Тук няма да разглеждаме процедурите за декодиране, а просто ще получим информацията, необходима за разбирането на по-нататъшната логика на работа на нивото.

Кодовете могат да бъдат блокови и непрекъснати. Стандартите не налагат използването на конкретен тип кодиране, обаче то трябва да присъства. К непрекъснатите спадащи кодове (convolutional codes). С тях се кодира непрекъснатият битов поток. За разлика от блоковите кодове, където данните се разделят на кодови блокове и могат да бъдат декодирани само в рамките на цялостни блокове. Кодният блок представлява предавани данни и присъединена излишна информация, необходима за проверка на правилността на получените данни и коригиране на възможни грешки. К блоковите кодове спадат известните кодове на Рийд-Соуломон.

Ако се използва свиване на код, битовият поток постъпва на декодера от началото. Резултатът от неговата работа (всичко това, разбира се, става непрекъснато) са блокове от данните CADU (единица за достъп до канал). Тази структура е необходима за кадрова синхронизация. В края на всеки CADU е прикрепен синхронизационен маркер (ASM – прикрепен синхронизатор). Това са известни предварително 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 бита.

Телеманеври

Кадърът на телеманеври има няколко съществени различия. Сред тях:

Различна структура на заглавията
Динамична дължина. Това означава, че дължината на кадъра не е зададена жестоко, както е направено в телеметрията, а може да се променя в зависимост от предаваните пакети.
Механизъм за гарантиране на доставката на пакети. Тоест, КА трябва след получаване да потвърди коректността на приема на кадрите или да изиска повторно предаване от кадъра, който може да е получен с некоригируема грешка.

Много полета вече са ни познати от заглавието на кадъра за телеметрия. Те имат същото предназначение, затова тук ще разгледаме само новите полета.

Единствен бит на флага за заобикаляне трябва да се използва за контрол на проверката на кадрите на получателя. Стойността "0" на този флаг трябва да показва, че кадърът е от тип А и проверката му трябва да бъде извършена според FARM. Стойността "1" на този флаг трябва да сигнализира на получателя, че кадърът е от тип Б и проверката му трябва да бъде пропусната според FARM.

Този флаг информира получателя дали да използва механизма за потвърдително предаване на кадри, наречен FARM – Механизъм за приемане и отчитане на кадри.

Флагът за управление трябва да се използва, за да се разбере дали полето с данни предава команда или информация. Ако флагът е равен на "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%. Въпреки това, когато възникне необходимостта от реализиране на тези стандарти, става ясно, че всяко поле, всяко заглавие има своя важна мисия, игнорирането на която води до редица неясноти.

Ако общността на Хабра прояви интерес към тази тема, ще се радвам да публикувам още серия от статии, посветени на теорията и практиката на космическите комуникации. Благодаря за вниманието!