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

Сателит Метеор М1
Извор: владтиме.ру

Увод

Рад свемирске технологије је немогућ без радио комуникација, а у овом чланку ћу покушати да објасним главне идеје које су чиниле основу стандарда који је развио Међународни саветодавни комитет за системе свемирских података (ЦЦСДС. Ова скраћеница ће се користити у наставку) .

Овај пост ће се првенствено фокусирати на слој везе података, али ће такође бити представљени основни концепти за друге слојеве. Овај чланак ни на који начин не представља темељан и потпун опис стандарда. Можете га погледати на Онлине ЦЦСДС. Међутим, они су веома тешки за разумевање, а ми смо потрошили доста времена покушавајући да их разумемо, па овде желим да дам основне информације, уз које ће бити много лакше разумети све остало. Дакле, почнимо.

Племенита мисија ЦЦСДС-а

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

Као што показује пракса, исплативије је придржавати се ЦЦСДС стандарда из следећег низа разлога:

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

архитектура

Стандарди су скуп докумената који одражавају најчешћи ОСИ (Опен Систем Интерцоннецтион) модел, осим што је на нивоу везе података заједништво ограничено на поделу на телеметрију (довнлинк - спаце - Еартх) и телекоманде (уплинк).

Погледајмо неке од нивоа детаљније, почевши од физичког и напредујући. Ради веће јасноће, размотрићемо архитектуру пријемне стране. Оно које преноси је његова слика у огледалу.

Физички слој

На овом нивоу, модулисани радио сигнал се претвара у бит стреам. Стандарди су овде углавном саветодавне природе, пошто је на овом нивоу тешко апстраховати од специфичне имплементације хардвера. Овде је кључна улога ЦЦСДС-а да дефинише прихватљиве модулације (БПСК, КПСК, 8-КАМ, итд.) и да неке препоруке о имплементацији механизама синхронизације симбола, Доплерове компензације итд.

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

Формално, то је подслој слоја везе података, али се често издваја у посебан слој због свог значаја у оквиру ЦЦСДС стандарда. Овај слој претвара ток битова у такозване оквире (телеметрија или телекоманде), о којима ћемо касније говорити. За разлику од синхронизације симбола на физичком нивоу, која вам омогућава да добијете исправан ток битова, синхронизација оквира се врши овде. Узмите у обзир путању коју подаци пролазе на овом нивоу (од дна ка врху):

Међутим, пре тога, вреди рећи неколико речи о кодирању. Ова процедура је неопходна за проналажење и/или исправљање битних грешака које се неизбежно јављају приликом слања података преко радио канала. Овде нећемо разматрати процедуре декодирања, већ ћемо само добити информације неопходне за разумевање даље логике нивоа.

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

Ако се користи конволуционо кодирање, ток битова улази у декодер од почетка. Резултат његовог рада (све се то, наравно, дешава континуирано) су ЦАДУ (јединица података за приступ каналу) блокови података. Ова структура је неопходна за синхронизацију оквира. На крају сваког ЦАДУ-а налази се прикачен синхронизатор (АСМ). То су 4 унапред позната бајта по којима синхронизатор проналази почетак и крај ЦАДУ-а. Тако се постиже синхронизација оквира.

Следећа опциона фаза слоја синхронизације и кодирања повезана је са особеностима физичког слоја. Ово је дерандомизација. Чињеница је да је за постизање синхронизације симбола неопходно често пребацивање између симбола. Дакле, ако пренесемо, рецимо, килобајт података који се у потпуности састоји од јединица, синхронизација ће бити изгубљена. Због тога се током преноса улазни подаци мешају са периодичним псеудо-случајним низом тако да је густина нула и јединица уједначена.

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

Слој везе података

С једне стране, процесор слоја везе прима оквире, а са друге стране издаје пакете. Пошто величина пакета није формално ограничена, за њихов поуздан пренос потребно их је разбити на мање структуре – оквире. Овде ћемо погледати два пододељка: одвојено за телеметрију (ТМ) и телекоманде (ТЦ).

Телеметрија

Једноставно речено, ово су подаци које земаљска станица добија од летелице. Све пренете информације подељене су на мале фрагменте фиксне дужине - оквире који садрже пренете податке и сервисна поља. Хајде да ближе погледамо структуру оквира:

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

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

Свака свемирска летелица, према ЦЦСДС стандардима, мора да има свој јединствени идентификатор, по коме се, имајући оквир, може одредити ком уређају припада. Формално, потребно је поднети пријаву за регистрацију уређаја, а његово име, заједно са идентификатором, биће објављено у отвореним изворима. Међутим, руски произвођачи често игноришу ову процедуру, додељујући произвољан идентификатор уређају. Број верзије оквира помаже да се одреди која верзија стандарда се користи да би се оквир исправно прочитао. Овде ћемо размотрити само најконзервативнији стандард са верзијом „0“.

Поље ИД виртуелног канала мора да садржи ВЦИД канала са којег је пакет дошао. Не постоје ограничења у избору ВЦИД-а; посебно, виртуелни канали нису нужно нумерисани узастопно.

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

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

Бројач оквира главног и виртуелног канала су поља која се повећавају за један сваки пут када се оквир пошаље. Служи као показатељ да ниједан оквир није изгубљен.

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

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

Ако желите, можете додати додатно заглавље у сваки оквир и тамо поставити све податке по свом нахођењу.

Поље Фирст Хеадер Поинтер, када је заставица синхронизације постављена на 1, садржаће бинарни приказ позиције првог октета првог пакета у пољу података телеметријског оквира. Позиција се рачуна од 0 у растућем редоследу од почетка поља података. Ако нема почетка пакета у пољу података телеметријског оквира, онда показивач на прво поље заглавља мора имати вредност у бинарној репрезентацији „11111111111“ (ово се може десити ако је један дугачак пакет раширен на више од једног оквира ).

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

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

Ово поље се израчунава коришћењем ЦРЦ методе. Процедура мора узети н-16 битова телеметријског оквира и уметнути резултат прорачуна у последњих 16 битова.

ТВ тимови

ТВ командни оквир има неколико значајних разлика. Међу њима:

1. Другачија структура наслова
2. Динамичка дужина. То значи да дужина оквира није ригидно постављена, као што се ради у телеметрији, већ може да варира у зависности од пренетих пакета.
3. Механизам гаранције испоруке пакета. Односно, летелица мора, по пријему, потврдити исправност пријема кадра, или затражити прослеђивање из оквира који је могао бити примљен са грешком која се не може исправити.

Многа поља су нам већ позната из заглавља телеметријског оквира. Имају исту намену, па ћемо овде размотрити само нова поља.

Један бит бипасс заставице се мора користити за контролу провере оквира на пријемнику. Вредност "0" за ову заставицу означава да је оквир оквир типа А и да мора бити верификован према ФАРМ-у. Вредност "1" за ову заставицу треба да укаже примаоцу да је овај оквир оквир типа Б и треба да заобиђе ФАРМ проверу.

Ова заставица обавештава примаоца да ли да користи механизам за потврду испоруке оквира који се зове ФАРМ – механизам прихватања оквира и извештавања.

Ознака контролне команде мора да се користи да би се разумело да ли поље података преноси команду или податке. Ако је заставица "0", онда поље података мора да садржи податке. Ако је заставица "1", онда поље података мора садржати контролне информације за ФАРМ.
ФАРМ је машина коначног стања чији се параметри могу конфигурисати.

РСВД. СПАРЕ – резервисани битови.

Чини се да ЦЦСДС има планове за њих у будућности, а за повратну компатибилност верзија протокола резервисали су ове битове већ у тренутним верзијама стандарда.

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

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

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

Ако је заглавље присутно, онда блок података мора да садржи пакет, скуп пакета или део пакета. Блок података без заглавља не може да садржи делове пакета, али може да садржи блокове података приватног формата. Из овога следи да је заглавље потребно када се блок података који се преноси не уклапа у један оквир. Блок података који има заглавље назива се сегмент

Поље двобитних заставица мора да садржи:

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

Поље ИД МАП мора да садржи нуле ако се МАП канали не користе.
Понекад 6 битова додељених виртуелним каналима није довољно. А ако је потребно мултиплексирати податке на већи број канала, користи се још 6 битова из заглавља сегмента.

ФАРМА

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

Испод је структура поља оперативне контроле са описом неких поља. Подаци садржани у овом пољу називају се ЦЛЦВ – контролна реч комуникационе везе.

Пошто се са слике лако може погодити намена главних поља, а остала су досадна за гледање, детаљан опис кријем испод спојлера

Објашњење ЦЛВ пољаТип контролне речи:
За овај тип, контролна реч мора да садржи 0

Верзија контролне речи (ЦЛЦВ број верзије):
За овај тип, контролна реч мора бити једнака "00" у битском представљању.

Статус Поље:
Употреба овог поља одређује се за сваку мисију посебно. Могу се користити за локална побољшања од стране разних свемирских агенција.

Виртуелна идентификација канала:
Мора да садржи идентификатор виртуелног канала са којим је ова контролна реч повезана.

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

Ознака грешке при синхронизацији:
Ознака може указивати да физички слој ради на лошем нивоу сигнала и да је број одбијених оквира превелик. Употреба овог поља је опциона; ако се користи, мора да садржи „0“ ако је синхронизација доступна и „1“ ако није.

Ознака за блокирање:
Овај бит ће садржати статус закључавања ФАРМ за сваки виртуелни канал. Вредност "1" у овом пољу треба да указује да је ФАРМ онемогућен и да ће оквири бити одбачени за сваки виртуелни слој, у супротном "0".

Ознака чекања:
Овај бит ће се користити да означи да пријемник не може да обрађује податке на наведеном виртуелном каналу. Вредност "1" означава да ће сви оквири бити одбачени на овом виртуелном каналу, у супротном "0".

Застава напред:
Ова заставица ће садржати "1" ако је један или више оквира типа А одбачени или су пронађене празнине, па је неопходно поновно слање. Ознака "0" означава да није било испуштених кадрова или прескакања.

Вредност одговора:
Број оквира који није примљен. Одређује бројач у заглављу оквира телекоманде

Мрежни слој

Хајде да се мало дотакнемо овог нивоа. Овде постоје две опције: или користите протокол за просторни пакет, или инкапсулирајте било који други протокол у ЦЦСДС пакет.

Преглед протокола свемирских пакета је тема за посебан чланак. Дизајниран је да омогући такозваним апликацијама беспрекорну размену података. Свака апликација има своју адресу и основну функционалност за размену података са другим апликацијама. Постоје и сервиси који рутирају саобраћај, контролишу испоруку итд.

Са инкапсулацијом је све једноставније и јасније. Стандарди омогућавају да се било који протокол инкапсулира у ЦЦСДС пакете додавањем додатног заглавља.

Где заглавље има различита значења у зависности од дужине протокола који се инкапсулира:

Овде је главно поље дужина дужине. Може да варира од 0 до 4 бајта. Такође у овом заглављу морате навести тип инкапсулираног протокола користећи табелу стога.

ИП енкапсулација користи други додатак за одређивање типа пакета.
Морате да додате још једно заглавље, један октет дужине:

Где је ПИД узети још један идентификатор протокола стога

Закључак

На први поглед може изгледати да су ЦЦСДС заглавља изузетно сувишна и да би нека поља могла бити одбачена. Заиста, ефикасност резултирајућег канала (до нивоа мреже) је око 40%. Међутим, чим се укаже потреба за имплементацијом ових стандарда, постаје јасно да свако поље, сваки наслов има своју важну мисију, игнорисање које доводи до низа нејасноћа.

Ако хабрадруштво покаже интересовање за ову тему, биће ми драго да објавим читав низ чланака посвећених теорији и пракси свемирских комуникација. Хвала на пажњи!

izvori

ЦЦСДС 130.0-Г-3 — Преглед свемирских комуникационих протокола
ЦЦСДС 131.0-Б-2 – ТМ синхронизација и кодирање канала
ЦЦСДС 132.0-Б-2 - ТМ Спаце Дата Линк Протоцол
ЦЦСДС 133.0-Б-1 - Протокол за свемирски пакет
ЦЦСДС 133.1-Б-2 - Услуга енкапсулације
ЦЦСДС 231.0-Б-3 - ТЦ синхронизација и кодирање канала
ЦЦСДС 232.1-Б-2 Комуникациони оперативни поступак-1
ЦЦСДС 401.0-Б-28 Системи радио-фреквенције и модулације – 1. део (земаљске станице и свемирске летелице)
ЦЦСДС 702.1-Б-1 - ИП преко ЦЦСДС свемирских веза

ПС
Не ударајте превише ако нађете било какве непрецизности. Пријавите их и биће поправљени :)

Извор: ввв.хабр.цом