Meteor M1 palydovas
Šaltinis: vladtime.ru
įvedimas
Kosmoso technologijų veikimas neįmanomas be radijo ryšio, todėl šiame straipsnyje pabandysiu paaiškinti pagrindines idėjas, kurios sudarė Tarptautinio kosminių duomenų sistemų patariamojo komiteto (CCSDS) sukurtų standartų pagrindą. Ši santrumpa bus naudojama toliau. .
Šiame įraše daugiausia dėmesio bus skiriama duomenų ryšio sluoksniui, tačiau taip pat bus pristatytos pagrindinės kitų sluoksnių sąvokos. Šis straipsnis jokiu būdu nepretenduoja į išsamų ir išsamų standartų aprašymą. Jį galite peržiūrėti adresu CCSDS. Tačiau juos labai sunku suprasti, be to, stengdamiesi jas suprasti skyrėme daug laiko, todėl čia noriu pateikti pagrindinę informaciją, kurią turint bus daug lengviau suprasti visa kita. Taigi, pradėkime.
Kilni CCSDS misija
Galbūt kas nors turi klausimą: kodėl visi turėtų laikytis standartų, jei galite sukurti savo patentuotą radijo protokolų rinkinį (arba savo standartą su „blackjack“ ir naujomis funkcijomis), taip padidindami sistemos saugumą?
Kaip rodo praktika, pelningiau laikytis CCSDS standartų dėl šių priežasčių:
- Komitetas, atsakingas už standartų paskelbimą, apima visų didžiausių pasaulio aviacijos ir kosmoso agentūrų atstovus, kurie atsineša neįkainojamos patirties, įgytos per daugelį metų projektuojant ir vykdant įvairias misijas. Būtų labai absurdiška ignoruoti šią patirtį ir vėl užlipti ant grėblio.
- Šiuos standartus palaiko jau rinkoje esanti antžeminių stočių įranga.
- Šalindami bet kokias problemas, visada galite kreiptis pagalbos į kolegas iš kitų agentūrų, kad jie galėtų susisiekti su įrenginiu iš savo antžeminės stoties. Kaip matote, standartai yra labai naudingas dalykas, todėl pažvelkime į pagrindinius jų dalykus.
Architektūra
Standartai yra dokumentų rinkinys, atspindintis labiausiai paplitusią OSI (Open System Interconnection) modelį, išskyrus tai, kad duomenų ryšio lygiu bendrumas apsiriboja skirstymu į telemetriją (žemyn nukreipta – erdvė – Žemė) ir telekomandas (aukštyn).
Pažvelkime į kai kuriuos lygius išsamiau, pradėdami nuo fizinio ir kildami aukštyn. Siekiant didesnio aiškumo, apsvarstysime priimančiosios pusės architektūrą. Perduodantis yra jo veidrodinis vaizdas.
Fizinis sluoksnis
Šiame lygyje moduliuotas radijo signalas paverčiamas bitų srautu. Čia pateikti standartai daugiausia yra patariamojo pobūdžio, nes šiame lygmenyje sunku abstrahuotis nuo konkretaus aparatinės įrangos įgyvendinimo. Čia pagrindinis CCSDS vaidmuo yra apibrėžti priimtinas moduliacijas (BPSK, QPSK, 8-QAM ir kt.) ir pateikti keletą rekomendacijų dėl simbolių sinchronizavimo mechanizmų įgyvendinimo, Doplerio kompensavimo ir kt.
Sinchronizavimo ir kodavimo lygis
Formaliai tai yra duomenų ryšio sluoksnio posluoksnis, tačiau dažnai yra atskirtas į atskirą sluoksnį dėl jo svarbos CCSDS standartuose. Šis sluoksnis bitų srautą paverčia vadinamaisiais rėmeliais (telemetrija arba telekomandomis), apie kuriuos kalbėsime vėliau. Skirtingai nuo simbolių sinchronizavimo fiziniame lygmenyje, kuris leidžia gauti teisingą bitų srautą, čia atliekamas kadrų sinchronizavimas. Apsvarstykite kelią, kuriuo eina duomenys šiame lygyje (iš apačios į viršų):
Tačiau prieš tai verta pasakyti keletą žodžių apie kodavimą. Ši procedūra reikalinga norint rasti ir (arba) ištaisyti bitų klaidas, kurios neišvengiamai atsiranda siunčiant duomenis radijo kanalu. Čia mes nenagrinėsime dekodavimo procedūrų, o tik gausime informaciją, reikalingą tolesnei lygio logikai suprasti.
Kodai gali būti blokuoti arba tęstiniai. Standartai neprivalo naudoti konkretaus tipo kodavimo, tačiau jis turi būti toks. Ištisiniai kodai apima konvoliucinius kodus. Jie naudojami nuolatiniam bitų srautui koduoti. Tai priešingai nei blokiniai kodai, kai duomenys yra suskirstyti į kodų blokus ir gali būti dekoduojami tik ištisuose blokuose. Kodų blokas vaizduoja perduodamus duomenis ir pridedamą perteklinę informaciją, reikalingą gautų duomenų teisingumui patikrinti ir galimoms klaidoms ištaisyti. Blokuoti kodai apima garsiuosius Reed-Solomon kodus.
Jei naudojamas konvoliucinis kodavimas, bitų srautas į dekoderį patenka nuo pat pradžių. Jos darbo rezultatas (visa tai, žinoma, vyksta nuolat) yra CADU (channel access data unit) duomenų blokai. Ši struktūra reikalinga kadrų sinchronizavimui. Kiekvieno CADU gale yra prijungtas sinchronizavimo kūrimo įrenginys (ASM). Tai yra 4 iš anksto žinomi baitai, pagal kuriuos sinchronizatorius suranda CADU pradžią ir pabaigą. Taip pasiekiamas kadrų sinchronizavimas.
Kitas pasirenkamas sinchronizavimo ir kodavimo sluoksnio etapas yra susijęs su fizinio sluoksnio ypatumais. Tai yra derandomizacija. Faktas yra tas, kad norint pasiekti simbolių sinchronizavimą, būtina dažnai perjungti simbolius. Taigi, jei perduosime, tarkime, kilobaitą duomenų, sudarytų tik iš vienetų, sinchronizavimas bus prarastas. Todėl perdavimo metu įvesties duomenys sumaišomi su periodine pseudoatsitiktine seka, kad nulių ir vienetų tankis būtų vienodas.
Toliau blokiniai kodai iššifruojami, o lieka galutinis sinchronizavimo ir kodavimo lygio produktas – kadras.
Duomenų nuorodos sluoksnis
Vienoje pusėje nuorodų sluoksnio procesorius priima kadrus, o iš kitos pusės išduoda paketus. Kadangi paketų dydis formaliai nėra ribojamas, jų patikimam perdavimui būtina juos suskaidyti į smulkesnes struktūras – rėmelius. Čia apžvelgsime du poskyrius: atskirai telemetrijai (TM) ir telekomandoms (TC).
Telemetrija
Paprasčiau tariant, tai yra duomenys, kuriuos antžeminė stotis gauna iš erdvėlaivio. Visa perduodama informacija yra padalinta į mažus fiksuoto ilgio fragmentus – kadrus, kuriuose yra perduodami duomenys ir paslaugų laukai. Pažvelkime atidžiau į rėmo struktūrą:
Ir pradėkime nuo pagrindinės telemetrijos rėmo antraštės. Be to, kai kuriose vietose leisiu sau tiesiog išversti standartus, pakeliui pateikdamas kai kuriuos paaiškinimus.
Pagrindinio kanalo ID lauke turi būti kadro versijos numeris ir įrenginio identifikatorius.
Kiekvienas erdvėlaivis, pagal CCSDS standartus, turi turėti savo unikalų identifikatorių, pagal kurį, turint rėmelį, būtų galima nustatyti, kuriam įrenginiui jis priklauso. Formaliai būtina pateikti paraišką registruoti įrenginį, o jo pavadinimas kartu su identifikatoriumi bus paskelbtas atviruosiuose šaltiniuose. Tačiau Rusijos gamintojai dažnai nepaiso šios procedūros, priskirdami įrenginiui savavališką identifikatorių. Rėmelio versijos numeris padeda nustatyti, kuri standarto versija naudojama norint teisingai nuskaityti rėmelį. Čia mes apsvarstysime tik patį konservatyviausią standartą su „0“ versija.
Lauke Virtual Channel ID turi būti kanalo, iš kurio buvo gautas paketas, VCID. Nėra jokių apribojimų renkantis VCID, virtualūs kanalai nebūtinai sunumeruoti nuosekliai.
Labai dažnai reikia multipleksuoti perduodamus duomenis. Tam tikslui yra virtualių kanalų mechanizmas. Pavyzdžiui, palydovas Meteor-M2 perduoda spalvotą vaizdą matomame diapazone, suskirstydamas jį į tris nespalvotus - kiekviena spalva perduodama savo virtualiu kanalu atskiru paketu, nors yra tam tikrų nukrypimų nuo standartų. jos rėmų struktūra.
Operatyvinės kontrolės vėliavėlės laukas rodo, ar telemetrijos rėmelyje yra arba nėra operatyvinio valdymo lauko. Šie 4 kadro pabaigoje esantys baitai padeda pateikti grįžtamąjį ryšį valdant telekomandų kadrų pristatymą. Apie juos pakalbėsime šiek tiek vėliau.
Pagrindinio ir virtualaus kanalo kadrų skaitikliai yra laukai, kurie kiekvieną kartą siunčiami padidinami vienu. Tarnauti kaip indikatorius, kad nebuvo prarastas nė vienas kadras.
Telemetrijos kadro duomenų būsena yra dar du vėliavėlių ir duomenų baitai, iš kurių apžvelgsime tik keletą.
Antrinės antraštės vėliavėlės laukas turi rodyti antrinės antraštės buvimą ar nebuvimą telemetrijos rėmelyje.
Jei norite, prie kiekvieno kadro galite pridėti papildomą antraštę ir savo nuožiūra įdėti bet kokius duomenis.
Pirmosios antraštės rodyklės lauke, kai sinchronizavimo vėliavėlė nustatyta į „1“, turi būti dvejetainis pirmojo paketo okteto padėties telemetrijos kadro duomenų lauke vaizdas. Pozicija skaičiuojama nuo 0 didėjimo tvarka nuo duomenų lauko pradžios. Jei telemetrijos kadro duomenų lauke nėra paketo pradžios, tada rodyklės laukas į pirmąją antraštę turi turėti dvejetainę reikšmę „11111111111“ (taip gali nutikti, jei vienas ilgas paketas yra paskirstytas daugiau nei viename kadre ).
Jei duomenų lauke yra tuščias paketas (neaktyvūs duomenys), tada rodyklė į pirmąją antraštę turėtų turėti dvejetainę reikšmę „11111111110“. Naudodamas šį lauką imtuvas turi sinchronizuoti srautą. Šis laukas užtikrina, kad sinchronizavimas būtų atkurtas net ir atmetus kadrus.
Tai yra, paketas gali prasidėti 4-ojo kadro viduryje ir baigtis 20-ojo pradžioje. Šis laukas naudojamas jo pradžiai rasti. Paketai taip pat turi antraštę, nurodančią jos ilgį, todėl kai randama žymeklis į pirmąją antraštę, nuorodų sluoksnio procesorius turi ją perskaityti, taip nustatydamas, kur paketas baigsis.
Jei yra klaidų valdymo laukas, jis turi būti kiekviename konkretaus fizinio kanalo telemetrijos kadre per visą misiją.
Šis laukas apskaičiuojamas naudojant CRC metodą. Procedūra turi paimti n-16 bitų telemetrijos kadro ir įterpti skaičiavimo rezultatą į paskutinius 16 bitų.
TV komandos
TV komandų rėmelis turi keletą reikšmingų skirtumų. Tarp jų:
- Skirtinga antraštės struktūra
- Dinaminis ilgis. Tai reiškia, kad kadro ilgis nėra griežtai nustatytas, kaip tai daroma telemetrijoje, bet gali skirtis priklausomai nuo perduodamų paketų.
- Paketų pristatymo garantijos mechanizmas. Tai yra, erdvėlaivis, gavęs jį, turi patvirtinti kadro priėmimo teisingumą arba prašyti persiuntimo iš kadro, kuris galėjo būti priimtas su nepataisoma klaida.
Daugelis laukų mums jau žinomi iš telemetrijos rėmelio antraštės. Jie turi tą pačią paskirtį, todėl čia nagrinėsime tik naujas sritis.
Kadrų tikrinimui imtuve valdyti turi būti naudojamas vienas apėjimo vėliavėlės bitas. Šios vėliavėlės reikšmė „0“ rodo, kad rėmelis yra A tipo rėmelis ir turi būti patikrintas pagal FARM. Šios vėliavėlės reikšmė „1“ turėtų rodyti imtuvui, kad šis kadras yra B tipo kadras ir turėtų apeiti FARM patikrą.
Ši vėliavėlė informuoja imtuvą, ar naudoti kadrų pristatymo patvirtinimo mechanizmą, vadinamą FARM – kadrų priėmimo ir ataskaitų teikimo mechanizmu.
Valdymo komandos vėliavėlė turi būti naudojama norint suprasti, ar duomenų laukas perduoda komandą ar duomenis. Jei vėliavėlė yra „0“, duomenų lauke turi būti duomenų. Jei vėliavėlė yra „1“, duomenų lauke turi būti FARM kontrolės informacija.
FARM yra baigtinės būsenos mašina, kurios parametrus galima konfigūruoti.
RSVD. SPARE – rezervuoti bitai.
Atrodo, kad CCSDS turi planų su jais ateityje, o dėl atgalinio protokolo versijų suderinamumo jie rezervavo šiuos bitus jau dabartinėse standarto versijose.
Kadro ilgio lauke turi būti nurodytas bitų skaičius, lygus kadro ilgiui oktetais atėmus vieną.
Rėmelio duomenų laukas turi būti po antrašte be tarpų ir jame turi būti sveikasis oktetų skaičius, kuris gali būti daugiausiai 1019 oktetų. Šiame lauke turi būti arba kadro duomenų bloko, arba valdymo komandos informacija. Rėmelio duomenų bloke turi būti:
- sveikasis vartotojo duomenų oktetų skaičius
- segmento antraštė, po kurios nurodomas sveikasis naudotojo duomenų oktetų skaičius
Jei yra antraštė, duomenų bloke turi būti paketas, paketų rinkinys arba paketo dalis. Duomenų bloke be antraštės negali būti paketų dalių, bet gali būti privataus formato duomenų blokų. Iš to išplaukia, kad antraštė reikalinga tada, kai perduodamas duomenų blokas netelpa į vieną kadrą. Duomenų blokas, turintis antraštę, vadinamas segmentu
Dviejų bitų vėliavėlių lauke turi būti:
- „01“ – jei pirmoji duomenų dalis yra duomenų bloke
- „00“ – jei duomenų bloke yra vidurinė duomenų dalis
- „10“ – jei duomenų bloke yra paskutinė duomenų dalis
- „11“ - jei nėra padalijimo ir vienas ar keli paketai visiškai telpa duomenų bloke.
MAP ID lauke turi būti nuliai, jei MAP kanalai nenaudojami.
Kartais 6 bitų, skirtų virtualiems kanalams, nepakanka. Ir jei reikia multipleksuoti duomenis į didesnį kanalų skaičių, naudojami dar 6 bitai iš segmento antraštės.
ŪKIS
Pažvelkime atidžiau į personalo pristatymo kontrolės sistemos veikimo mechanizmą. Ši sistema numato dirbti tik su telekomandų rėmeliais dėl jų svarbos (telemetrijos visada galima prašyti dar kartą, o erdvėlaivis turi aiškiai girdėti antžeminę stotį ir visada paklusti jos komandoms). Taigi, tarkime, kad nusprendžiame atnaujinti savo palydovą ir nusiųsti į jį 10 kilobaitų dvejetainį failą. Nuorodos lygiu failas yra padalintas į 10 kadrų (0, 1, ..., 9), kurie po vieną siunčiami aukštyn. Kai siuntimas baigtas, palydovas turi patvirtinti paketo priėmimo teisingumą arba pranešti, kuriame kadre įvyko klaida. Ši informacija siunčiama į operatyvinio valdymo lauką artimiausiame telemetrijos kadre (arba erdvėlaivis gali inicijuoti tuščiosios eigos kadro perdavimą, jei neturi ką pasakyti). Remdamiesi gauta telemetrija, mes arba įsitikiname, kad viskas gerai, arba siunčiame pranešimą iš naujo. Tarkime, kad palydovas negirdėjo 7 kadro. Tai reiškia, kad siunčiame jam 7, 8, 9 kadrus. Jei atsakymo nėra, visas paketas siunčiamas dar kartą (ir taip kelis kartus, kol suprantame, kad bandymai yra bergždi).
Žemiau pateikiama veiklos valdymo lauko struktūra su kai kurių laukų aprašymu. Šiame lauke esantys duomenys vadinami CLCW – komunikacijos jungties valdymo žodis.
Kadangi iš nuotraukos nesunkiai atspėsite pagrindinių laukelių paskirtį, o į kitus nuobodu žiūrėti, detalų aprašymą slepiu po spoileriu
CLCW laukų paaiškinimasValdymo žodžio tipas:
Šio tipo kontroliniame žodyje turi būti 0
„Control Word“ versija (CLCW versijos numeris):
Šio tipo kontrolinis žodis bitų atvaizde turi būti lygus „00“.
Būsenos laukas:
Šio lauko naudojimas nustatomas kiekvienai misijai atskirai. Gali būti naudojamas įvairių kosmoso agentūrų vietiniams patobulinimams.
Virtualaus kanalo identifikavimas:
Turi būti virtualaus kanalo, su kuriuo susietas šis kontrolinis žodis, identifikatorius.
Fizinės prieigos prie kanalo vėliavėlė:
Vėliava turi pateikti informaciją apie imtuvo fizinio sluoksnio parengtį. Jei fizinis imtuvo sluoksnis nėra paruoštas priimti kadrų, lauke turi būti „1“, kitu atveju „0“.
Sinchronizavimo trikties vėliavėlė:
Vėliava gali rodyti, kad fizinis sluoksnis veikia prastu signalo lygiu ir atmestų kadrų skaičius yra per didelis. Šio lauko naudojimas yra neprivalomas, jame turi būti „0“, jei galima sinchronizuoti, ir „1“, jei jo nėra.
Blokuojanti vėliava:
Šiame bite turi būti kiekvieno virtualaus kanalo FARM užrakto būsena. Vertė „1“ šiame lauke turėtų reikšti, kad FARM išjungta ir kadrai bus atmesti kiekviename virtualiame sluoksnyje, kitu atveju „0“.
Laukimo vėliavėlė:
Šis bitas turi būti naudojamas nurodyti, kad imtuvas negali apdoroti duomenų nurodytu virtualiuoju kanalu. Vertė „1“ rodo, kad visi šio virtualaus kanalo kadrai bus išmesti, kitu atveju „0“.
Pirmyn vėliava:
Šioje vėliavėlėje turi būti „1“, jei vienas ar keli A tipo kadrai buvo išmesti arba rasta spragų, todėl būtina siųsti iš naujo. Vėliava „0“ rodo, kad nebuvo numestų kadrų ar praleidimų.
Atsako reikšmė:
Negautas kadro numeris. Nustatoma pagal skaitiklį telekomandos kadro antraštėje
Tinklo sluoksnis
Šiek tiek palieskime šį lygį. Čia yra dvi parinktys: arba naudoti erdvės paketo protokolą, arba į CCSDS paketą įtraukti bet kurį kitą protokolą.
Erdvinio paketo protokolo apžvalga yra atskiro straipsnio tema. Jis sukurtas taip, kad vadinamosios programos galėtų sklandžiai keistis duomenimis. Kiekviena programa turi savo adresą ir pagrindines funkcijas, skirtas keistis duomenimis su kitomis programomis. Taip pat yra paslaugų, kurios nukreipia eismą, kontroliuoja pristatymą ir kt.
Su inkapsuliavimu viskas yra paprasčiau ir aiškiau. Standartai leidžia įtraukti bet kokius protokolus į CCSDS paketus, pridedant papildomą antraštę.
Kai antraštė turi skirtingas reikšmes, atsižvelgiant į įterpto protokolo ilgį:
Čia pagrindinis laukas yra ilgio ilgis. Jis gali svyruoti nuo 0 iki 4 baitų. Taip pat šioje antraštėje, naudodami lentelę, turite nurodyti įkapsuliuoto protokolo tipą .
IP inkapsuliavimas naudoja kitą priedą, kad nustatytų paketo tipą.
Turite pridėti dar vieną okteto ilgio antraštę:
Kur PID yra paimtas kitas protokolo identifikatorius
išvada
Iš pirmo žvilgsnio gali atrodyti, kad CCSDS antraštės yra labai perteklinės ir kai kurie laukai gali būti išmesti. Iš tiesų, gauto kanalo efektyvumas (iki tinklo lygio) yra apie 40%. Tačiau vos tik atsiranda poreikis diegti šiuos standartus, tampa aišku, kad kiekviena sritis, kiekviena antraštė turi savo svarbią misiją, kurios ignoravimas sukelia nemažai neaiškumų.
Jei ši tema susidomės habrasociacija, mielai paskelbsiu visą seriją straipsnių, skirtų kosminių ryšių teorijai ir praktikai. Ačiū už dėmesį!
Informacijos šaltiniai
PS
Nemuškite per stipriai, jei pastebėsite netikslumų. Praneškite apie juos ir jie bus pataisyti :)
Šaltinis: www.habr.com