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

Сателит Метеор М1
Извор: vladtime.ru

Вовед

Работата на вселенската технологија е невозможна без радио комуникации, а во оваа статија ќе се обидам да ги објаснам главните идеи кои ја формираа основата на стандардите развиени од Меѓународниот советодавен комитет за системи за вселенски податоци (CCSDS. Оваа кратенка ќе се користи подолу) .

Овој пост ќе се фокусира првенствено на слојот за податочна врска, но ќе бидат воведени и основни концепти за други слоеви. Овој напис во никој случај не претендира да биде темелен и целосен опис на стандардите. Можете да го погледнете на Онлајн CCSDS. Сепак, тие се многу тешки за разбирање, а ние потрошивме многу време обидувајќи се да ги разбереме, па овде сакам да дадам основни информации, со кои ќе биде многу полесно да се разбере сè друго. Значи, да започнеме.

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

Можеби некој има прашање: зошто сите треба да се придржуваат до стандардите ако можете да развиете свој сопствен пакет радио протоколи (или свој стандард, со блек џек и нови функции), а со тоа да ја зголемите безбедноста на системот?

Како што покажува практиката, попрофитабилно е да се придржувате до стандардите CCSDS од следниов број причини:

1. Комитетот одговорен за објавување на стандардите вклучува претставници од секоја голема воздухопловна агенција во светот, носејќи непроценливо искуство стекнато во текот на многу години на дизајнирање и работење на различни мисии. Би било многу апсурдно да се игнорира ова искуство и повторно да се нагази на нивното гребло.
2. Овие стандарди се поддржани од опремата на копнената станица која веќе е на пазарот.
3. Кога решавате какви било проблеми, секогаш можете да побарате помош од колеги од други агенции за да можат да спроведат сесија за комуникација со уредот од нивната приземна станица. Како што можете да видите, стандардите се исклучително корисна работа, па да ги погледнеме нивните клучни точки.

архитектура

Стандардите се збир на документи кои го одразуваат најчестиот OSI (Open System Interconnection) модел, освен што на ниво на податочна врска заедништвото е ограничено на поделба на телеметрија (downlink - space - Earth) и телекоманди (uplink).

Да разгледаме некои од нивоата подетално, почнувајќи од физичкото и напредувајќи нагоре. За поголема јасност, ќе ја разгледаме архитектурата на примачката страна. Оној што пренесува е неговата огледална слика.

Физички слој

На ова ниво, модулираниот радио сигнал се претвора во бит-стрим. Стандардите овде се главно советодавни по природа, бидејќи на ова ниво е тешко да се апстрахира од специфичната имплементација на хардверот. Овде, клучната улога на CCSDS е да ги дефинира прифатливите модулации (BPSK, QPSK, 8-QAM, итн.) и да даде некои препораки за имплементација на механизми за синхронизација на симболи, доплер компензација итн.

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

Формално, тој е подслој на слојот за податочна врска, но често се одвојува во посебен слој поради неговата важност во рамките на стандардите CCSDS. Овој слој го претвора бит-стримот во таканаречени рамки (телеметрија или телекоманди), за кои ќе зборуваме подоцна. За разлика од синхронизацијата на симболите на физичкиот слој, што ви овозможува да го добиете точниот проток на битови, овде се врши синхронизација на рамки. Размислете за патеката што ја поминуваат податоците на ова ниво (од дното кон врвот):

Сепак, пред тоа, вреди да се каже неколку зборови за кодирање. Оваа постапка е неопходна за да се пронајдат и/или да се поправат бит-грешките што неизбежно се појавуваат при испраќање податоци преку радио канал. Овде нема да ги разгледаме процедурите за декодирање, туку само ќе ги добиеме потребните информации за да ја разбереме понатамошната логика на нивото.

Кодовите можат да бидат блок или континуирани. Стандардите не принудуваат употреба на специфичен тип на кодирање, но тоа мора да биде присутно како такво. Континуираните кодови вклучуваат конволутивни кодови. Тие се користат за кодирање на континуиран проток на битови. Ова е за разлика од блок-кодовите, каде што податоците се поделени на блокови на кодови и може да се декодираат само во целосни блокови. Кодскиот блок ги претставува пренесените податоци и приложените непотребни информации потребни за да се потврди точноста на примените податоци и да се поправат можните грешки. Блок кодовите ги вклучуваат познатите шифри Рид-Соломон.

Ако се користи конволутивно кодирање, битстримот влегува во декодерот од почеток. Резултатот од неговата работа (сето ова, се разбира, се случува континуирано) се блокови на податоци CADU (единица за пристап до канали). Оваа структура е неопходна за синхронизација на рамката. На крајот од секој CADU има прикачен синхронизација (ASM). Тоа се 4 однапред познати бајти, со кои синхронизаторот го наоѓа почетокот и крајот на CADU. Така се постигнува синхронизација на рамки.

Следната опционална фаза на слојот за синхронизација и кодирање е поврзана со особеностите на физичкиот слој. Ова е дерандомизација. Факт е дека за да се постигне синхронизација на симболите, неопходно е често префрлување помеѓу симболите. Значи, ако пренесеме, да речеме, килобајт податоци што се состојат целосно од такви, синхронизацијата ќе се изгуби. Затоа, за време на преносот, влезните податоци се мешаат со периодична псевдо-случајна низа така што густината на нули и единици е униформа.

Следно, блок-кодовите се декодираат, а она што останува е финалниот производ на нивото на синхронизација и кодирање - рамка.

Слој за податочна врска

Од една страна, процесорот на слојот за врски прима рамки, а од другата страна издава пакети. Бидејќи големината на пакетите не е формално ограничена, за нивно доверливо пренесување потребно е да се разложат на помали структури - рамки. Овде ќе разгледаме две подсекции: одделно за телеметрија (TM) и телекоманди (TC).

Телеметрија

Едноставно кажано, ова се податоците што копнената станица ги добива од леталото. Сите пренесени информации се поделени на мали фрагменти со фиксна должина - рамки кои содржат пренесени податоци и полиња за услуги. Ајде внимателно да ја разгледаме структурата на рамката:

И да го започнеме нашето разгледување со главното заглавие на рамката за телеметрија. Понатаму, ќе си дозволам едноставно да ги преведам стандардите на некои места, давајќи некои појаснувања попатно.

Полето за ID на главниот канал мора да го содржи бројот на верзијата на рамката и идентификаторот на уредот.

Секое вселенско летало, според стандардите CCSDS, мора да има свој единствен идентификатор, со кој имајќи рамка може да се одреди на кој уред припаѓа. Формално, потребно е да се поднесе апликација за регистрација на уредот, а неговото име, заедно со неговиот идентификатор, ќе бидат објавени во отворени извори. Сепак, руските производители често ја игнорираат оваа постапка, доделувајќи произволен идентификатор на уредот. Бројот на верзијата на рамката помага да се одреди која верзија на стандардите се користи за правилно читање на рамката. Овде ќе го разгледаме само најконзервативниот стандард со верзија „0“.

Полето за ID на виртуелен канал мора да го содржи VCID на каналот од кој дошол пакетот. Нема ограничувања за изборот на VCID; особено, виртуелните канали не се нужно нумерирани последователно.

Многу често има потреба од мултиплексирање на пренесените податоци. За таа цел, постои механизам на виртуелни канали. На пример, сателитот Метеор-М2 пренесува слика во боја во видливиот опсег, поделувајќи ја на три црно-бели - секоја боја се пренесува во свој виртуелен канал во посебен пакет, иако има одредено отстапување од стандардите во структурата на нејзините рамки.

Полето за ознака за оперативна контрола ќе биде индикатор за присуство или отсуство на полето за оперативна контрола во телеметриската рамка. Овие 4 бајти на крајот од рамката служат за давање повратни информации при контрола на испораката на рамки за телекоманда. Ќе зборуваме за нив малку подоцна.

Бројачите на рамката на главниот и виртуелниот канал се полиња кои се зголемуваат за едно при секое испраќање рамка. Послужете како индикатор дека ниту една рамка не е изгубена.

Статусот на податоците за телеметриската рамка е уште два бајта знаменца и податоци, од кои ќе разгледаме само неколку.

Полето за знаменце за секундарно заглавие мора да биде показател за присуството или отсуството на секундарно заглавие во рамката за телеметрија.

Доколку сакате, можете да додадете дополнително заглавие на секоја рамка и да ги поставите сите податоци таму по ваша дискреција.

Полето First Header Pointer, кога знамето за синхронизација е поставено на 1, ќе содржи бинарна претстава на позицијата на првиот октет од првиот пакет во полето за податоци на телеметриската рамка. Позицијата се брои од 0 во растечки редослед од почетокот на полето за податоци. Ако нема почеток на пакетот во полето за податоци на рамката за телеметрија, тогаш полето за покажувач кон првото заглавие мора да ја има вредноста во бинарното претставување „11111111111“ (ова може да се случи ако еден долг пакет се шири на повеќе од една рамка ).

Ако полето за податоци содржи празен пакет (Idle Data), тогаш покажувачот кон првото заглавие треба да ја има вредноста во бинарното претставување „11111111110“. Користејќи го ова поле, приемникот мора да го синхронизира преносот. Ова поле осигурува дека синхронизацијата е вратена дури и ако се испуштаат рамки.

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

Ова поле се пресметува со методот CRC. Постапката мора да земе n-16 бита од рамката за телеметрија и да го вметне резултатот од пресметката во последните 16 бита.

ТВ тимови

Рамката за команда на ТВ има неколку значајни разлики. Меѓу нив:

1. Различна структура на насловот
2. Динамична должина. Ова значи дека должината на рамката не е строго поставена, како што се прави во телеметријата, но може да варира во зависност од пренесените пакети.
3. Гарантен механизам за испорака на пакети. Односно, вселенското летало мора, откако ќе го добие, да ја потврди исправноста на приемот на рамката или да побара препраќање од рамка што можела да биде примена со неисправлива грешка.

Многу полиња ни се веќе познати од заглавието на рамката за телеметрија. Тие имаат иста намена, затоа овде ќе ги разгледаме само новите полиња.

Еден дел од знамето за бајпас мора да се користи за контрола на проверката на рамката кај ресиверот. Вредноста „0“ за ова знаменце ќе означи дека рамката е рамка од типот А и мора да биде потврдена според FARM. Вредноста „1“ за ова знаме треба да му укаже на примачот дека оваа рамка е рамка од тип Б и треба да ја заобиколи проверката FARM.

Ова знаме го информира примачот дали да користи механизам за потврда за испорака на рамка наречен FARM - Механизам за прифаќање и известување рамка.

Знамето на контролната команда мора да се користи за да се разбере дали полето за податоци пренесува команда или податоци. Ако знамето е „0“, тогаш полето за податоци мора да содржи податоци. Ако знамето е „1“, тогаш полето за податоци мора да содржи контролни информации за FARM.
FARM е машина со конечни состојби чии параметри може да се конфигурираат.

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

Се чини дека CCSDS има планови за нив во иднина, а за наназад компатибилност на верзиите на протоколот тие ги резервираа овие битови веќе во тековните верзии на стандардот.

Полето за должина на рамката мора да содржи број во бит претставување што е еднаков на должината на рамката во октети минус еден.

Полето со податоци за рамка мора да го следи заглавието без празни места и да содржи цел број на октети, кој може да биде максимум 1019 октети во должина. Ова поле мора да содржи или блок податоци за рамка или информации за контролната команда. Блокот со податоци за рамка мора да содржи:

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

Ако е присутен заглавие, тогаш податочниот блок мора да содржи Пакет, множество пакети или дел од пакет. Блок на податоци без заглавие не може да содржи делови од пакети, но може да содржи блокови на податоци со приватен формат. Од ова произлегува дека заглавјето е потребно кога преносниот блок на податоци не се вклопува во една рамка. Блок од податоци што има заглавие се нарекува сегмент

Дво-битното поле за знаменца мора да содржи:

• "01" - ако првиот дел од податоците е во блокот на податоци
• „00“ - ако средниот дел од податоците е во блокот на податоци
• „10“ - ако последниот податок е во податочниот блок
• „11“ - ако нема поделба и еден или повеќе пакети целосно се вклопуваат во податочниот блок.

Полето MAP ID мора да содржи нули ако не се користат MAP канали.
Понекогаш 6 бита доделени на виртуелни канали не се доволни. И ако е потребно мултиплексирање на податоците на поголем број канали, се користат уште 6 бита од заглавието на сегментот.

ФАРМ

Да го разгледаме подетално механизмот на функционирање на системот за контрола на испорака на персонал. Овој систем овозможува работа само со рамки на телекоманди поради нивната важност (телеметрија секогаш може да се бара повторно, а леталото мора јасно да ја слуша земната станица и секогаш да ги почитува нејзините команди). Значи, да претпоставиме дека решивме да го рефлешираме нашиот сателит и да му испратиме бинарна датотека со големина од 10 килобајти. На ниво на врска, датотеката е поделена на 10 рамки (0, 1, ..., 9), кои се испраќаат нагоре еден по еден. Кога преносот е завршен, сателитот мора да ја потврди исправноста на приемот на пакетот или да пријави во која рамка настанала грешката. Оваа информација се испраќа до полето за оперативна контрола во најблиската телеметриска рамка (Или леталото може да иницира пренос на рамка во мирување ако нема што да каже). Врз основа на добиената телеметрија, или се уверуваме дека се е во ред, или продолжуваме со повторно испраќање на пораката. Да претпоставиме дека сателитот не ја слушнал рамката #7. Ова значи дека му испраќаме рамки 7, 8, 9. Ако нема одговор, целиот пакет се испраќа повторно (и така неколку пати додека не сфатиме дека обидите се залудни).

Подолу е дадена структурата на полето за оперативна контрола со опис на некои полиња. Податоците содржани во ова поле се нарекуваат CLCW - Контролен збор за комуникациска врска.

Бидејќи од сликата лесно можете да ја погодите целта на главните полиња, а другите се досадни за гледање, деталниот опис го кријам под спојлер

Објаснување на CLCW полињатаКонтролирајте го типот на зборот:
За овој тип, контролниот збор мора да содржи 0

Контролирајте ја верзијата на Word (Број на верзијата 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
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 - ИП преку CCSDS простор врски

PS
Не удирајте премногу силно ако најдете неточности. Пријавете ги и ќе се средат :)

Извор: www.habr.com