Meteor M1 satellite
Pinagmulan: vladtime.ru
Pagpapakilala
Ang pagpapatakbo ng teknolohiya sa espasyo ay imposible nang walang mga komunikasyon sa radyo, at sa artikulong ito ay susubukan kong ipaliwanag ang mga pangunahing ideya na naging batayan ng mga pamantayan na binuo ng International Advisory Committee para sa Space Data Systems (CCSDS. Ang pagdadaglat na ito ay gagamitin sa ibaba) .
Ang post na ito ay pangunahing tututuon sa layer ng data link, ngunit ang mga pangunahing konsepto para sa iba pang mga layer ay ipakikilala din. Ang artikulong ito sa anumang paraan ay hindi naglalayong maging isang masusing at kumpletong paglalarawan ng mga pamantayan. Maaari mong tingnan ito sa CCSDS. Gayunpaman, napakahirap nilang maunawaan, at gumugol kami ng maraming oras sa pagsisikap na maunawaan ang mga ito, kaya narito nais kong magbigay ng pangunahing impormasyon, kung saan ito ay magiging mas madaling maunawaan ang lahat ng iba pa. Kaya, magsimula tayo.
Noble Mission ng CCSDS
Marahil may isang tao na may tanong: bakit dapat sumunod ang lahat sa mga pamantayan kung maaari kang bumuo ng iyong sariling proprietary radio protocol stack (o sarili mong pamantayan, na may blackjack at mga bagong feature), at sa gayon ay madaragdagan ang seguridad ng system?
Tulad ng ipinapakita ng kasanayan, mas kumikita ang pagsunod sa mga pamantayan ng CCSDS para sa sumusunod na bilang ng mga kadahilanan:
- Ang komite na responsable sa paglalathala ng mga pamantayan ay kinabibilangan ng mga kinatawan mula sa bawat pangunahing ahensya ng aerospace sa mundo, na nagdadala ng napakahalagang karanasang natamo sa loob ng maraming taon ng disenyo at pagpapatakbo ng iba't ibang misyon. Napakawalang katotohanan na huwag pansinin ang karanasang ito at muling tumapak sa kanilang kalaykay.
- Ang mga pamantayang ito ay sinusuportahan ng kagamitan sa ground station na nasa merkado na.
- Kapag nag-troubleshoot ng anumang mga problema, maaari kang palaging humingi ng tulong sa mga kasamahan mula sa ibang mga ahensya upang makapagsagawa sila ng sesyon ng komunikasyon sa device mula sa kanilang ground station. Tulad ng nakikita mo, ang mga pamantayan ay isang lubhang kapaki-pakinabang na bagay, kaya tingnan natin ang kanilang mga pangunahing punto.
arkitektura
Ang mga pamantayan ay isang hanay ng mga dokumento na sumasalamin sa pinakakaraniwang modelo ng OSI (Open System Interconnection), maliban na sa antas ng data link ang pagkakapareho ay limitado sa paghahati sa telemetry (downlink - space - Earth) at telecommands (uplink).
Tingnan natin ang ilan sa mga antas nang mas detalyado, simula sa pisikal at pataas. Para sa higit na kalinawan, isasaalang-alang namin ang arkitektura ng receiving side. Ang nagpapadala ay ang mirror image nito.
Pisikal na layer
Sa antas na ito, ang modulated radio signal ay na-convert sa isang bit stream. Ang mga pamantayan dito ay higit sa lahat ay nagpapayo sa kalikasan, dahil sa antas na ito ay mahirap i-abstract mula sa partikular na pagpapatupad ng hardware. Dito, ang pangunahing tungkulin ng CCSDS ay tukuyin ang mga katanggap-tanggap na modulasyon (BPSK, QPSK, 8-QAM, atbp.) at magbigay ng ilang rekomendasyon sa pagpapatupad ng mga mekanismo ng pag-synchronize ng simbolo, kompensasyon ng Doppler, atbp.
Antas ng pag-synchronize at pag-encode
Sa pormal, ito ay isang sublayer ng layer ng data link, ngunit madalas na pinaghihiwalay sa isang hiwalay na layer dahil sa kahalagahan nito sa loob ng mga pamantayan ng CCSDS. Ang layer na ito ay nagko-convert ng bit stream sa tinatawag na mga frame (telemetry o telecommands), na pag-uusapan natin mamaya. Hindi tulad ng pag-synchronize ng simbolo sa pisikal na layer, na nagbibigay-daan sa iyong makuha ang tamang bit stream, ang frame synchronization ay ginaganap dito. Isaalang-alang ang landas na tinatahak ng data sa antas na ito (mula sa ibaba hanggang sa itaas):
Gayunpaman, bago iyon, ito ay nagkakahalaga ng pagsasabi ng ilang mga salita tungkol sa coding. Ang pamamaraang ito ay kinakailangan upang mahanap at/o itama ang mga bit error na hindi maiiwasang mangyari kapag nagpapadala ng data sa isang radio channel. Dito hindi namin isasaalang-alang ang mga pamamaraan ng pag-decode, ngunit kukunin lamang ang impormasyong kinakailangan upang maunawaan ang karagdagang lohika ng antas.
Maaaring block o tuloy-tuloy ang mga code. Hindi pinipilit ng mga pamantayan ang paggamit ng isang partikular na uri ng pag-encode, ngunit dapat itong naroroon bilang ganoon. Kasama sa mga tuluy-tuloy na code ang mga convolutional code. Ginagamit ang mga ito upang mag-encode ng tuluy-tuloy na bit stream. Ito ay kaibahan sa mga block code, kung saan ang data ay nahahati sa mga codeblock at maaari lamang i-decode sa loob ng kumpletong mga bloke. Kinakatawan ng bloke ng code ang ipinadalang data at ang kalakip na kalabisan na impormasyong kinakailangan upang i-verify ang kawastuhan ng data na natanggap at itama ang mga posibleng pagkakamali. Kasama sa mga block code ang sikat na Reed-Solomon code.
Kung ginamit ang convolutional encoding, ang bitstream ay pumapasok sa decoder mula sa simula. Ang resulta ng trabaho nito (lahat ng ito, siyempre, ay patuloy na nangyayari) ay mga bloke ng data ng CADU (channel access data unit). Ang istraktura na ito ay kinakailangan para sa pag-synchronize ng frame. Sa dulo ng bawat CADU ay may kalakip na synch maker (ASM). Ang mga ito ay 4 na byte na kilala nang maaga, kung saan nahanap ng synchronizer ang simula at pagtatapos ng CADU. Ito ay kung paano nakakamit ang frame synchronization.
Ang susunod na opsyonal na yugto ng synchronization at encoding layer ay nauugnay sa mga kakaibang katangian ng pisikal na layer. Ito ay derandomization. Ang katotohanan ay upang makamit ang pag-synchronize ng simbolo, ang madalas na paglipat sa pagitan ng mga simbolo ay kinakailangan. Kaya, kung ipapadala namin, sabihin, isang kilobyte ng data na binubuo ng kabuuan ng mga iyon, mawawala ang pag-synchronize. Samakatuwid, sa panahon ng paghahatid, ang data ng pag-input ay halo-halong may isang pana-panahong pseudo-random na pagkakasunud-sunod upang ang density ng mga zero at isa ay pare-pareho.
Susunod, ang mga block code ay na-decode, at ang natitira ay ang pangwakas na produkto ng antas ng pag-synchronize at pag-encode - isang frame.
Layer ng Data Link
Sa isang panig, ang processor ng link layer ay tumatanggap ng mga frame, at sa kabilang panig ay naglalabas ito ng mga packet. Dahil ang laki ng mga packet ay hindi pormal na limitado, para sa kanilang maaasahang paghahatid ay kinakailangan upang hatiin ang mga ito sa mas maliit na mga istraktura - mga frame. Dito ay titingnan natin ang dalawang subsection: magkahiwalay para sa telemetry (TM) at telecommands (TC).
Telemetry
Sa madaling salita, ito ang data na natatanggap ng ground station mula sa spacecraft. Ang lahat ng ipinadalang impormasyon ay nahahati sa maliliit na fragment ng isang nakapirming haba - mga frame na naglalaman ng ipinadalang data at mga field ng serbisyo. Tingnan natin ang istraktura ng frame:
At simulan natin ang ating pagsasaalang-alang sa pangunahing header ng telemetry frame. Dagdag pa, hahayaan ko ang aking sarili na isalin lamang ang mga pamantayan sa ilang lugar, na nagbibigay ng ilang paglilinaw sa daan.
Ang field ng Master Channel ID ay dapat maglaman ng numero ng bersyon ng frame at ang identifier ng device.
Ang bawat spacecraft, ayon sa mga pamantayan ng CCSDS, ay dapat magkaroon ng sarili nitong natatanging identifier, kung saan, sa pagkakaroon ng isang frame, matutukoy ng isa kung saang device ito kabilang. Sa pormal na paraan, kinakailangang magsumite ng aplikasyon para irehistro ang device, at ang pangalan nito, kasama ang identifier nito, ay mai-publish sa mga open source. Gayunpaman, madalas na binabalewala ng mga tagagawa ng Russia ang pamamaraang ito, na nagtatalaga ng isang di-makatwirang identifier sa device. Nakakatulong ang numero ng bersyon ng frame na matukoy kung aling bersyon ng mga pamantayan ang ginagamit upang mabasa nang tama ang frame. Dito ay isasaalang-alang lamang namin ang pinakakonserbatibong pamantayan na may bersyon na "0".
Ang field ng Virtual Channel ID ay dapat maglaman ng VCID ng channel kung saan nanggaling ang packet. Walang mga paghihigpit sa pagpili ng VCID sa partikular, ang mga virtual na channel ay hindi kinakailangang binibilang nang sunud-sunod.
Kadalasan mayroong pangangailangan sa multiplex na ipinadalang data. Para sa layuning ito, mayroong isang mekanismo ng mga virtual na channel. Halimbawa, ang satellite ng Meteor-M2 ay nagpapadala ng isang kulay na imahe sa nakikitang hanay, na hinahati ito sa tatlong itim at puti - ang bawat kulay ay ipinapadala sa sarili nitong virtual na channel sa isang hiwalay na pakete, bagaman mayroong ilang paglihis mula sa mga pamantayan sa istraktura ng mga frame nito.
Ang patlang ng watawat ng Operational Control ay dapat maging tagapagpahiwatig ng presensya o kawalan ng field ng Operational Control sa frame ng telemetry. Ang 4 na byte na ito sa dulo ng frame ay nagsisilbing magbigay ng feedback kapag kinokontrol ang paghahatid ng mga telecommand frame. Pag-uusapan natin sila mamaya.
Ang pangunahing at virtual na channel frame counter ay mga field na dinaragdagan ng isa sa bawat oras na magpapadala ng frame. Magsilbing indicator na walang isang frame ang nawala.
Ang status ng data ng telemetry frame ay dalawa pang byte ng mga flag at data, kung saan titingnan natin ang ilan lamang.
Ang field ng bandila ng Secondary Header ay dapat na isang indicator ng presensya o kawalan ng Secondary Header sa telemetry frame.
Kung gusto mo, maaari kang magdagdag ng karagdagang header sa bawat frame at ilagay ang anumang data doon sa iyong paghuhusga.
Ang field ng First Header Pointer, kapag ang flag ng synchronization ay nakatakda sa "1", ay dapat maglaman ng binary na representasyon ng posisyon ng unang octet ng unang Packet sa Data Field ng telemetry frame. Ang posisyon ay binibilang mula 0 sa pataas na pagkakasunud-sunod mula sa simula ng field ng data. Kung walang pagsisimula ng packet sa field ng data ng telemetry frame, dapat na ang pointer field sa unang header ay may value sa binary na representasyon na "11111111111" (maaaring mangyari ito kung ang isang mahabang packet ay kumalat sa higit sa isang frame ).
Kung ang field ng data ay naglalaman ng isang walang laman na packet (Idle Data), kung gayon ang pointer sa unang header ay dapat mayroong value sa binary na representasyon na "11111111110". Gamit ang field na ito, dapat i-synchronize ng receiver ang stream. Tinitiyak ng field na ito na maibabalik ang pag-synchronize kahit na nalaglag ang mga frame.
Iyon ay, ang isang packet ay maaaring, sabihin, magsimula sa gitna ng ika-4 na frame at magtatapos sa simula ng ika-20. Ang field na ito ay ginagamit upang mahanap ang simula nito. Ang mga packet ay mayroon ding header na tumutukoy sa haba nito, kaya kapag may nakitang pointer sa unang header, dapat itong basahin ng link-layer processor, at sa gayon ay matukoy kung saan magtatapos ang packet.
Kung mayroong field ng error control, dapat itong nasa bawat telemetry frame para sa isang partikular na pisikal na channel sa buong misyon.
Kinakalkula ang field na ito gamit ang CRC method. Ang pamamaraan ay dapat tumagal ng n-16 bits ng telemetry frame at ipasok ang resulta ng pagkalkula sa huling 16 bits.
mga TV team
Ang TV command frame ay may ilang makabuluhang pagkakaiba. Sa kanila:
- Iba't ibang istraktura ng heading
- Dynamic na haba. Nangangahulugan ito na ang haba ng frame ay hindi nakatakda nang mahigpit, tulad ng ginagawa sa telemetry, ngunit maaaring mag-iba depende sa ipinadala na mga packet.
- Mekanismo ng garantiya sa paghahatid ng packet. Iyon ay, ang spacecraft ay dapat, pagkatapos matanggap ito, kumpirmahin ang kawastuhan ng pagtanggap ng frame, o humiling ng pagpapasa mula sa isang frame na maaaring natanggap na may hindi naitatama na error.
Maraming field ang pamilyar na sa amin mula sa telemetry frame header. Sila ay may parehong layunin, kaya dito ay isasaalang-alang lamang ang mga bagong larangan.
Dapat gamitin ang isang bit ng bypass flag para kontrolin ang pag-check ng frame sa receiver. Ang halaga ng "0" para sa flag na ito ay dapat magpahiwatig na ang frame ay isang Type A na frame at dapat ma-verify ayon sa FARM. Ang halaga ng "1" para sa flag na ito ay dapat magpahiwatig sa receiver na ang frame na ito ay isang Type B na frame at dapat na lampasan ang FARM checking.
Ang flag na ito ay nagpapaalam sa receiver kung gagamit ng isang frame delivery acknowledgement mechanism na tinatawag na FARM - Frame Acceptance and Reporting Mechanism.
Dapat gamitin ang control command flag upang maunawaan kung ang field ng data ay nagdadala ng command o data. Kung ang flag ay "0", kung gayon ang data field ay dapat maglaman ng data. Kung ang flag ay "1", ang field ng data ay dapat maglaman ng impormasyon ng kontrol para sa FARM.
Ang FARM ay isang finite state machine na ang mga parameter ay maaaring i-configure.
RSVD. SPARE β nakareserbang mga piraso.
Tila ang CCSDS ay may mga plano para sa kanila sa hinaharap, at para sa paatras na pagkakatugma ng mga bersyon ng protocol ay inilaan na nila ang mga bit na ito sa kasalukuyang mga bersyon ng pamantayan.
Ang patlang ng haba ng frame ay dapat maglaman ng isang numero sa representasyon ng bit na katumbas ng haba ng frame sa mga octet na bawasan ng isa.
Dapat sundin ng field ng data ng frame ang header nang walang mga puwang at naglalaman ng integer na bilang ng mga octet, na maaaring hanggang 1019 octet ang haba. Ang field na ito ay dapat maglaman ng alinman sa frame data block o control command information. Ang frame data block ay dapat maglaman ng:
- integer na bilang ng mga octet ng data ng user
- header ng segment na sinusundan ng isang integer na bilang ng mga octet ng data ng user
Kung mayroong isang header, kung gayon ang data block ay dapat maglaman ng isang Packet, isang hanay ng mga Packet, o bahagi ng isang Packet. Ang isang data block na walang header ay hindi maaaring maglaman ng mga bahagi ng Packet, ngunit maaaring maglaman ng pribadong format na mga bloke ng data. Ito ay sumusunod mula dito na ang isang header ay kinakailangan kapag ang ipinadala na bloke ng data ay hindi magkasya sa isang frame. Ang isang bloke ng data na may header ay tinatawag na segment
Ang dalawang-bit na field ng flag ay dapat maglaman ng:
- "01" - kung ang unang bahagi ng data ay nasa data block
- "00" - kung ang gitnang bahagi ng data ay nasa data block
- "10" - kung ang huling piraso ng data ay nasa bloke ng data
- "11" - kung walang dibisyon at isa o higit pang mga packet ang ganap na kasya sa data block.
Ang field ng MAP ID ay dapat maglaman ng mga zero kung hindi ginagamit ang mga channel ng MAP.
Minsan hindi sapat ang 6 na bits na nakalaan sa mga virtual na channel. At kung kinakailangan na mag-multipleks ng data sa mas malaking bilang ng mga channel, isa pang 6 na bit mula sa header ng segment ang gagamitin.
FARM
Tingnan natin ang mekanismo ng paggana ng sistema ng kontrol sa paghahatid ng mga tauhan. Ang sistemang ito ay nagbibigay lamang ng pagtatrabaho sa mga frame ng mga telecommand dahil sa kahalagahan ng mga ito (ang telemetry ay palaging maaaring hilingin muli, at ang spacecraft ay dapat marinig nang malinaw ang ground station at palaging sumunod sa mga utos nito). Kaya, ipagpalagay na nagpasya kaming i-reflash ang aming satellite, at magpadala ng binary file na 10 kilobytes ang laki dito. Sa antas ng link, ang file ay nahahati sa 10 mga frame (0, 1, ..., 9), na ipinapadala paitaas nang paisa-isa. Kapag nakumpleto na ang paghahatid, dapat kumpirmahin ng satellite ang kawastuhan ng pagtanggap ng packet, o iulat kung saang frame naganap ang error. Ang impormasyong ito ay ipinadala sa operational control field sa pinakamalapit na telemetry frame (O ang spacecraft ay maaaring simulan ang pagpapadala ng isang idle frame kung wala itong sasabihin). Batay sa natanggap na telemetry, tinitiyak namin na maayos ang lahat, o magpapatuloy kaming ipadala muli ang mensahe. Ipagpalagay natin na hindi narinig ng satellite ang frame #7. Nangangahulugan ito na ipinapadala namin sa kanya ang mga frame 7, 8, 9. Kung walang tugon, ang buong pakete ay ipinadala muli (at iba pa nang maraming beses hanggang sa mapagtanto namin na ang mga pagtatangka ay walang kabuluhan).
Nasa ibaba ang istruktura ng operational control field na may paglalarawan ng ilang field. Ang data na nakapaloob sa field na ito ay tinatawag na CLCW - Communication Link Control Word.
Dahil madali mong mahulaan mula sa larawan ang layunin ng mga pangunahing patlang, at ang iba ay nakakainip tingnan, itinatago ko ang detalyadong paglalarawan sa ilalim ng isang spoiler
Paliwanag ng mga patlang ng CLCWUri ng Control Word:
Para sa ganitong uri, ang control word ay dapat maglaman ng 0
Bersyon ng Control Word (Numero ng Bersyon ng CLCW):
Para sa ganitong uri, ang control word ay dapat na katumbas ng "00" sa bit na representasyon.
Patlang ng Katayuan:
Ang paggamit ng field na ito ay tinutukoy nang hiwalay para sa bawat misyon. Maaaring gamitin para sa mga lokal na pagpapabuti ng iba't ibang ahensya ng kalawakan.
Virtual Channel Identification:
Dapat maglaman ng identifier ng virtual na channel kung saan nauugnay ang control word na ito.
Flag ng pag-access ng pisikal na channel:
Ang bandila ay dapat magbigay ng impormasyon tungkol sa kahandaan ng pisikal na layer ng receiver. Kung ang pisikal na layer ng receiver ay hindi handa na tumanggap ng mga frame, ang field ay dapat maglaman ng "1", kung hindi man ay "0".
Flag ng pagkabigo sa pag-synchronize:
Maaaring ipahiwatig ng flag na ang pisikal na layer ay gumagana sa mahinang antas ng signal at ang bilang ng mga tinanggihang frame ay masyadong mataas. Ang paggamit ng field na ito ay opsyonal kung ginamit, dapat itong naglalaman ng "0" kung magagamit ang pag-synchronize, at "1" kung hindi.
Bina-block ang bandila:
Ang bit na ito ay dapat maglaman ng FARM lock status para sa bawat virtual channel. Ang halaga ng "1" sa field na ito ay dapat magpahiwatig na ang FARM ay hindi pinagana at ang mga frame ay itatapon para sa bawat virtual na layer, kung hindi ay "0".
Wait flag:
Ang bit na ito ay dapat gamitin upang ipahiwatig na ang receiver ay hindi maaaring magproseso ng data sa tinukoy na virtual channel. Ang halaga ng "1" ay nagpapahiwatig na ang lahat ng mga frame ay itatapon sa virtual na channel na ito, kung hindi ay "0".
Pasulong na Bandila:
Ang watawat na ito ay dapat maglaman ng "1" kung ang isa o higit pang uri A na mga frame ay itinapon o may nakitang mga puwang, kaya kailangan ang muling pagpapadala. Ang flag na "0" ay nagpapahiwatig na walang mga nalaglag na frame o paglaktaw.
Halaga ng tugon:
Frame number na hindi natanggap. Tinutukoy ng counter sa header ng telecommand frame
layer ng network
Ating hawakan nang kaunti ang antas na ito. Mayroong dalawang mga opsyon dito: alinman sa gamitin ang space packet protocol, o i-encapsulate ang anumang iba pang protocol sa CCSDS packet.
Ang isang pangkalahatang-ideya ng space packet protocol ay isang paksa para sa isang hiwalay na artikulo. Ito ay idinisenyo upang payagan ang mga tinatawag na application na walang putol na pagpapalitan ng data. Ang bawat application ay may sariling address at pangunahing pag-andar para sa pakikipagpalitan ng data sa iba pang mga application. Mayroon ding mga serbisyong nagruruta ng trapiko, nagkokontrol sa paghahatid, atbp.
Sa encapsulation ang lahat ay mas simple at mas malinaw. Ginagawang posible ng mga pamantayan na i-encapsulate ang anumang mga protocol sa mga CCSDS packet sa pamamagitan ng pagdaragdag ng karagdagang header.
Kung saan ang header ay may iba't ibang kahulugan depende sa haba ng protocol na naka-encapsulated:
Narito ang pangunahing patlang ay ang haba ng haba. Maaari itong mag-iba mula 0 hanggang 4 na byte. Gayundin sa header na ito dapat mong ipahiwatig ang uri ng encapsulated protocol gamit ang talahanayan .
Gumagamit ang IP encapsulation ng isa pang add-on upang matukoy ang uri ng packet.
Kailangan mong magdagdag ng isa pang header, isang octet ang haba:
Kung saan ang PID ay isa pang protocol identifier na kinuha
Konklusyon
Sa unang sulyap, maaaring mukhang labis na kalabisan ang mga header ng CCSDS at maaaring itapon ang ilang field. Sa katunayan, ang kahusayan ng nagresultang channel (hanggang sa antas ng network) ay halos 40%. Gayunpaman, sa sandaling lumitaw ang pangangailangan upang ipatupad ang mga pamantayang ito, nagiging malinaw na ang bawat larangan, bawat heading ay may sariling mahalagang misyon, na hindi pinapansin na humahantong sa isang bilang ng mga kalabuan.
Kung ang habrasociety ay nagpapakita ng interes sa paksang ito, ikalulugod kong mag-publish ng isang buong serye ng mga artikulo na nakatuon sa teorya at kasanayan ng mga komunikasyon sa kalawakan. Salamat sa iyong atensyon!
pinagmumulan
PS
Huwag pindutin ang masyadong malakas kung makakita ka ng anumang mga kamalian. I-report sila at sila ay aayusin :)
Pinagmulan: www.habr.com