Спадарожнік Метэор М1
Крыніца: vladtime.ru
Увядзенне
Эксплуатацыя касмічнай тэхнікі немагчыма без радыёсувязі, і ў гэтым артыкуле я пастараюся растлумачыць асноўныя ідэі, якія леглі ў падмурак стандартаў, распрацаваных Міжнародным Кансультатыўным Камітэтам па касмічных сістэмах перадачы дадзеных (Consultative Committee for Space Data Systems - CCSDS. Далей будзе выкарыстоўвацца гэтая .
Гэтая публікацыя будзе прысвечана ў асноўным канальнаму ўзроўню, аднак асноўныя паняцці для іншых узроўняў таксама будуць уведзены. Стацца ніякім чынам не прэтэндуе на дасканалае і поўнае апісанне стандартаў. З ім вы можаце азнаёміцца на CCSDS. Аднак яны вельмі цяжкія для ўспрымання, і каб у іх разабрацца мы патрацілі нямала часу, таму тут хачу прывесці базавую інфармацыю, валодаючы якой разабрацца з усім астатнім будзе значна лягчэй. Такім чынам, пачнем.
Высакародная місія CCSDS
Магчыма, у кагосьці ўзнікла пытанне: навошта ўсім прытрымлівацца стандартаў, калі можна распрацаваць свой прапрыентарны стэк пратаколаў радыёсувязі (ці свой стандарт, з блэк-джэкам і новымі фічамі), павысіўшы тым самым бяспеку сістэмы?
Як паказвае практыка, больш выгадна прытрымлівацца стандартам CCSDS па наступным шэрагу прычын:
- У камітэт, які адказвае за публікацыю стандартаў, увайшлі прадстаўнікі ўсіх буйных аэракасмічных агенцтваў свету, прыўнясучы свой бясцэнны вопыт, атрыманы на працягу многіх гадоў праектавання і эксплуатацыі розных місій. Было б вельмі недарэчна ігнараваць гэты досвед і зноў наступаць на іх граблі.
- Гэтыя стандарты падтрымліваюцца ўжо наяўным на рынку абсталяваннем наземных станцый.
- Падчас ухілення якіх-небудзь непаладак заўсёды можна звярнуцца за дапамогай да калег з іншых агенцтваў, каб яны правялі сеанс сувязі з апаратам са сваёй наземнай станцыі. Як бачыце, стандарты - рэч вельмі карысная, таму давайце разбярэмся ў іх ключавых момантах.
Архітэктура
Стандарты ўяўляюць сабой сукупнасць дакументаў, якія адлюстроўваюць самую звычайную мадэль OSI (Open System Interconnection), за выключэннем таго, што на канальным узроўні агульнасць абмяжоўваецца падзелам на тэлеметрыю (канал "уніз" - космас - Зямля) і тэлекаманды (канал "уверх").
Разгледзім некаторыя ўзроўні падрабязней, пачынаючы з фізічнага, і рухаючыся ўверх. Для большай навочнасці будзем разглядаць архітэктуру боку, які прымае. Перадавальная ўяўляе сабой яе люстраное адлюстраванне.
Фізічны ўзровень
На дадзеным узроўні адбываецца пераўтварэнне мадуляванага радыёсігналу ў бітавы струмень. Стандарты тут носяць у асноўным рэкамендацыйны характар, бо на гэтым узроўні складана абстрагавацца ад канкрэтнай рэалізацыі жалеза. Тут ключавая роля CCSDS - вызначыць дапушчальныя мадуляцыі (BPSK, QPSK, 8-QAM і г.д.) і даць некаторыя рэкамендацыі па рэалізацыі механізмаў сімвальнай сінхранізацыі, кампенсацыі доплераўскага зруху і да т.п.
Узровень сінхранізацыі і кадавання
Фармальна з'яўляецца падузроўнем канальнага ўзроўню, аднак вельмі часта вылучаецца ў асобны ўзровень з прычыны сваёй важнасці ў рамках стандартаў CCSDS. Дадзены ўзровень пераўтворыць бітавы струмень у так званыя кадры (тэлеметрыі ці тэлекаманд), пра якія мы пагаворым пазней. У адрозненне ад знакавой сінхранізацыі на фізічным узроўні, якая дазваляе атрымаць карэктны бітавы струмень, тут выконваецца кадравая сінхранізацыя. Разгледзім шлях, які дадзеныя праходзяць на дадзеным узроўні (знізу ўгару):
Аднак перад гэтым варта сказаць пару слоў аб кадаванні. Гэтая працэдура неабходна каб знаходзіць і/або выпраўляць бітавыя памылкі, якія немінуча ўзнікаюць пры адпраўцы дадзеных па радыёканале. Тут мы не будзем разглядаць працэдуры дэкадавання, а толькі атрымаем звесткі, неабходныя для разумення далейшай логікі працы ўзроўню.
Коды бываюць блокавыя і бесперапынныя. Стандарты не змушаюць выкарыстоўваць пэўны тып кадавання, аднак яно як такое павінна прысутнічаць. Да бесперапынных адносяцца скруткавыя (colvolutional) коды. З дапамогай іх кадуецца бесперапынны бітавы струмень. У адрозненне ад блокавых кодаў, дзе дадзеныя дзеляцца на кодавыя блокі (codeblock), і могуць быць дэкадаваны толькі ў рамках суцэльных блокаў. Кодавы блок уяўляе сабою перадаюцца дадзеныя і далучаную залішнюю інфармацыю, неабходную для праверкі правільнасці атрымання дадзеных і выпраўленні магчымых памылак. Да блокавых кодаў ставяцца знакамітыя коды Рыда-Саламона.
Калі выкарыстоўваецца скруткавае кадаваньне, бітавы струмень з пачатку паступае на дэкодэр. Вынікам яго працы (усё гэта, зразумела, адбываецца бесперапынна) становяцца блокі дадзеных 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 перадае каляровы малюнак у бачным дыяпазоне, падзяляючы яго на тры чорна-белых - кожны колер перадаецца ў сваім віртуальным канале асобным пакетам, хоць у структуры яго кадраў ёсць некаторае адхіленне ад стандартаў.
Поле сцяга 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 – Frame Acceptance and Reporting Mechanism.
Сцяг каманды кіравання павінен выкарыстоўвацца для разумення, ці транспартуе поле дадзеных каманду ці дадзеныя. Калі сцяг роўны "0", то поле дадзеных павінна змяшчаць дадзеныя. Калі сцяг роўны "1", то поле дадзеных павінна змяшчаць кантрольную інфармацыю для FARM.
FARM уяўляе сабой канчатковы аўтамат, параметры якога можна наладжваць.
RSVD. SPARE - зарэзерваваныя біты.
Падобна, у CCSDS ёсць на іх планы ў будучыні, і для зваротнай сумяшчальнасці версій пратаколу яны зарэзервавалі гэтыя біты ўжо ў цяперашніх версіях стандарту.
Поле даўжыні кадраў павінна ўтрымоўваць лік у бітавым уяўленні, якое роўна даўжыня кадра ў актэтах мінус адзін.
Поле дадзеных кадра павінна прытрымлівацца пасля загалоўка без пропускаў і змяшчаць цэлы лік актэтаў, якое можа быць даўжынёй максімальна 1019 актэтаў. Дадзенае поле павінна змяшчаць альбо блок дадзеных кадра, альбо інфармацыю каманды кіравання. Блок дадзеных кадра павінен утрымоўваць у сабе:
- цэлы лік актэт карыстацкіх дадзеных
- загаловак сегмента і наступныя за ім цэлы лік актэт карыстацкіх дадзеных
Калі загаловак прадстаўлены, то блок дадзеных павінен утрымоўваць у сабе Пакет, мноства Пакетаў ці яго частка. Блок дадзеных без загалоўка не можа ўтрымоўваць у сабе часткі Пакетаў, але можа ўтрымоўваць блокі дадзеных дзелі фармату. З гэтага варта, што загаловак патрабуецца тады, калі які перадаецца блок дадзеных не змяшчаецца ў адзін кадр. Блок дадзеных які мае загаловак, завецца сегментам
Поле сцягоў памерам два біты павінна змяшчаць:
- «01» - калі першая частка дадзеных знаходзіцца ў блоку дадзеных
- "00" - калі сярэдняя частка дадзеных знаходзіцца ў блоку дадзеных
- "10" - калі апошняя частка дадзеных знаходзіцца ў блоку дадзеных
- "11" - калі няма дзялення і ў блоку дадзеных змяшчаецца цалкам адзін або некалькі пакетаў.
Поле ідэнтыфікатара MAP павінна змяшчаць нулі, калі MAP каналы не выкарыстоўваюцца.
Часам 6 біт, адведзеных на віртуальныя каналы, бывае нядосыць. І калі неабходна мультыплексаваць дадзеныя на большую колькасць каналаў, у ход ідуць яшчэ 6 біт з загалоўка сегмента.
Фарм
Разгледзім падрабязней механізм функцыянавання сістэмы кантролю дастаўкі кадраў. Дадзеная сістэма прадугледжвае толькі працу з кадрамі тэлекаманд з прычыны іх важнасці (тэлеметрыю заўсёды можна запытаць зноў, а КА павінен чуць наземную станцыю выразна, і заўсёды падпарадкоўвацца яе камандам). Такім чынам, выкажам здагадку, мы вырашылі запытаць наш спадарожнік, і адпраўляем на яго борт бінарны файл памерам 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%. Аднак, як толькі ўзнікае неабходнасць рэалізацыі дадзеных стандартаў, становіцца зразумела, што ў кожнага поля, у кожнага загалоўка ёсць свая важная місія, ігнараванне якой прыводзіць да цэлага шэрагу неадназначнасцяў.
Калі хабраграмадства праявіць цікавасць да гэтай тэмы, буду рады апублікаваць яшчэ цэлы шэраг артыкулаў, прысвечаны тэорыі і практыцы касмічнай сувязі. Дзякуй за ўвагу!
крыніцы
PS
Не біце моцна, калі знойдзеце недакладнасці. Паведаміце пра іх, і яны будуць выпраўлены 🙂
Крыніца: habr.com