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

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

Въведение

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

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

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

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

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

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

Архитектура

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

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

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

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

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

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

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

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

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

Полето на флага на Оперативния контрол трябва да бъде индикатор за наличието или отсъствието на полето на Оперативния контрол в кадъра на телеметрията. Тези 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%. Но когато възникне необходимостта от прилагане на тези стандарти, става ясно, че всяко поле, всяко заглавие има важна мисия, чийто игнорирането води до редица неясноти.

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