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

Сателит Meteor M1
Източник: vladtime.ru

въведение

Работата на космическите технологии е невъзможна без радиокомуникации и в тази статия ще се опитам да обясня основните идеи, които са в основата на стандартите, разработени от Международния консултативен комитет за системи за космически данни (CCSDS. Това съкращение ще бъде използвано по-долу) .

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

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

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

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

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

архитектура

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

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

Физически слой

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

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

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

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

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

Ако се използва конволюционно кодиране, битовият поток влиза в декодера от самото начало. Резултатът от неговата работа (всичко това, разбира се, се случва непрекъснато) са блокове данни CADU (channel access data unit). Тази структура е необходима за кадрова синхронизация. В края на всеки CADU има прикрепен синхронизатор (ASM). Това са предварително известни 4 байта, по които синхронизаторът намира началото и края на CADU. Така се постига кадрова синхронизация.

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

След това блоковите кодове се декодират и остава крайният продукт от нивото на синхронизация и кодиране - рамка.

Слой за връзка с данни

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

телеметрия

Просто казано, това са данните, които наземната станция получава от космическия кораб. Цялата предадена информация се разделя на малки фрагменти с фиксирана дължина - рамки, които съдържат предадени данни и служебни полета. Нека разгледаме по-отблизо структурата на рамката:

И нека започнем нашето разглеждане с главния хедър на телеметричния кадър. Освен това ще си позволя просто да преведа стандартите на някои места, давайки някои разяснения по пътя.

Полето Master Channel ID трябва да съдържа номера на версията на рамката и идентификатора на устройството.

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

Полето Virtual Channel ID трябва да съдържа VCID на канала, от който идва пакетът. Няма ограничения за избора на VCID; по-специално, виртуалните канали не са непременно номерирани последователно.

Много често има нужда от мултиплексиране на предадени данни. За целта има механизъм на виртуални канали. Например сателитът Meteor-M2 предава цветно изображение във видимия диапазон, като го разделя на три черно-бели - всеки цвят се предава в собствен виртуален канал в отделен пакет, въпреки че има известно отклонение от стандартите в структурата на неговите рамки.

Полето за флаг за оперативен контрол трябва да бъде индикатор за наличието или отсъствието на полето за оперативен контрол в телеметричната рамка. Тези 4 байта в края на рамката служат за осигуряване на обратна връзка при контролиране на доставката на рамки за телекоманда. Ще говорим за тях малко по-късно.

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

Състоянието на данните на рамката на телеметрията е още два байта флагове и данни, от които ще разгледаме само няколко.

Полето за флаг за вторичен хедър трябва да бъде индикатор за наличието или отсъствието на вторичен хедър в телеметричния кадър.

Ако желаете, можете да добавите допълнителен хедър към всеки кадър и да поставите там всякакви данни по ваша преценка.

Полето First Header Pointer, когато флагът за синхронизация е зададен на "1", трябва да съдържа двоично представяне на позицията на първия октет на първия пакет в полето за данни на телеметричния кадър. Позицията се брои от 0 във възходящ ред от началото на полето с данни. Ако няма начало на пакета в полето с данни на телеметричния кадър, тогава указателят към първото заглавно поле трябва да има стойността в двоично представяне "11111111111" (това може да се случи, ако един дълъг пакет е разпръснат върху повече от един кадър ).

Ако полето с данни съдържа празен пакет (неактивни данни), тогава указателят към първото заглавие трябва да има стойност в двоично представяне „11111111110“. Използвайки това поле, приемникът трябва да синхронизира потока. Това поле гарантира, че синхронизацията се възстановява, дори ако кадрите са изпуснати.

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

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

телевизионни екипи

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

1. Различна структура на заглавието
2. Динамична дължина. Това означава, че дължината на рамката не е твърдо зададена, както се прави в телеметрията, а може да варира в зависимост от предаваните пакети.
3. Гаранционен механизъм за доставка на пакети. Тоест космическият кораб трябва, след като го получи, да потвърди правилността на приемането на кадър или да поиска препращане от кадър, който може да е получен с непоправима грешка.

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

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

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

Флагът за контролна команда трябва да се използва, за да се разбере дали полето за данни транспортира команда или данни. Ако флагът е "0", тогава полето за данни трябва да съдържа данни. Ако флагът е "1", тогава полето с данни трябва да съдържа контролна информация за FARM.
FARM е краен автомат, чиито параметри могат да бъдат конфигурирани.

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

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

Полето за дължина на рамката трябва да съдържа число в битово представяне, което е равно на дължината на рамката в октети минус едно.

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

• цяло число октети на потребителски данни
• заглавка на сегмента, последвана от цял ​​брой октети на потребителски данни

Ако има заглавка, тогава блокът с данни трябва да съдържа пакет, набор от пакети или част от пакет. Блок от данни без заглавка не може да съдържа части от пакети, но може да съдържа блокове с данни в частен формат. От това следва, че заглавието е необходимо, когато предаваният блок от данни не се побира в един кадър. Блок от данни, който има заглавка, се нарича сегмент

Полето с двубитови флагове трябва да съдържа:

• "01" - ако първата част от данните е в блока с данни
• “00” - ако средната част на данните е в блока с данни
• "10" - ако последната част от данните е в блока с данни
• “11” - ако няма разделение и един или повече пакети се побират изцяло в блока с данни.

Полето MAP ID трябва да съдържа нули, ако не се използват MAP канали.
Понякога 6 бита, разпределени за виртуални канали, не са достатъчни. И ако е необходимо да се мултиплексират данни върху по-голям брой канали, се използват още 6 бита от заглавката на сегмента.

FARM

Нека разгледаме по-подробно механизма на функциониране на системата за контрол на доставката на персонал. Тази система осигурява работа само с кадри от телекоманди поради тяхната важност (телеметрията винаги може да бъде поискана отново и космическият кораб трябва да чува ясно наземната станция и винаги да се подчинява на нейните команди). И така, да предположим, че решим да презаредим нашия сателит и да му изпратим двоичен файл с размер 10 килобайта. На ниво връзка файлът се разделя на 10 кадъра (0, 1, ..., 9), които се изпращат нагоре един по един. Когато предаването приключи, сателитът трябва да потвърди правилността на приемането на пакета или да докладва на кой кадър е възникнала грешката. Тази информация се изпраща до оперативното контролно поле в най-близкия телеметричен кадър (Или космическият кораб може да инициира предаване на неактивен кадър, ако няма какво да каже). Въз основа на получената телеметрия ние или се уверяваме, че всичко е наред, или пристъпваме към повторно изпращане на съобщението. Да приемем, че сателитът не е чул рамка #7. Това означава, че му изпращаме кадри 7, 8, 9. Ако няма отговор, целият пакет се изпраща отново (и така няколко пъти, докато разберем, че опитите са напразни).

По-долу е структурата на полето за оперативен контрол с описание на някои полета. Данните, съдържащи се в това поле, се наричат ​​CLCW - Control Word за комуникационна връзка.

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

Обяснение на полетата CLCWТип контролна дума:
За този тип контролната дума трябва да съдържа 0

Версия на контролната дума (Номер на версията CLCW):
За този тип контролната дума трябва да е равна на "00" в битовото представяне.

Поле за състояние:
Използването на това поле се определя за всяка мисия поотделно. Може да се използва за локални подобрения от различни космически агенции.

Виртуална идентификация на канала:
Трябва да съдържа идентификатора на виртуалния канал, към който е свързана тази контролна дума.

Флаг за достъп до физически канал:
Флагът трябва да предоставя информация за готовността на физическия слой на приемника. Ако физическият слой на приемника не е готов да получава кадри, тогава полето трябва да съдържа „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 — Преглед на протоколите за космически комуникации
CCSDS 131.0-B-2 – TM синхронизация и кодиране на канали
CCSDS 132.0-B-2 - TM Space Data Link Protocol
CCSDS 133.0-B-1 - Протокол за космически пакети
CCSDS 133.1-B-2 - Услуга за капсулиране
CCSDS 231.0-B-3 - TC синхронизация и кодиране на канали
CCSDS 232.1-B-2 Комуникационна оперативна процедура-1
CCSDS 401.0-B-28 Радиочестотни и модулационни системи - Част 1 (Земни станции и космически кораби)
CCSDS 702.1-B-1 - IP през CCSDS пространствени връзки

PS
Не удряйте твърде силно, ако откриете някакви неточности. Докладвайте ги и ще се оправят :)

Източник: www.habr.com