🥇Natuke kosmose side standarditest

Satelliit Meteor M1
Allikas: vladtime.ru

Sissejuhatus

Kosmosetehnika ei saa eksisteerida ilma raadioside, ja selles artiklis püüan ma selgitada põhiteemasid, mis on aluseks standarditele, mille arendas välja Rahvusvaheline Kosmosesüsteemide Andmete Edastamise Konsultatiivkomitee (Consultative Committee for Space Data Systems – CCSDS). Edaspidi kasutatakse seda akronüümi.

See publikatsioon keskendub peamiselt kanali tasemele, kuid tutvustatakse ka põhikontseptsioone teistel tasanditel. Artikkel ei pretendeeri mingil moel standardite kõikehõlmavale ja täielikule kirjeldamisele. Sellega saate tutvuda veebisaidil CCSDS. Siiski on need standardsed dokumendid väga keerulised ja nende mõistmiseks kulus meil märkimisväärselt aega, seega soovin siin esitada põhiteavet, mille najal saate teistega lihtsamalt hakkama. Nii et alustame.

CCSDS koolituse missioon

Võib-olla on kellegil küsimus: miks kõigil peaks olema standarditest kinni pidada, kui saaks arendada oma patenteeritud raadioside protokollide komplekti (või oma standardit, koos blackjacki ja uute funktsioonidega), suurendades seega süsteemi turvalisust?

Praktika näitab, et CCSDS standardite järgimine on kasulikum järgmiste põhjuste tõttu:

Standardite avaldamise komiteesse kuuluvad kõikide suurte kosmoseagentuuride esindajad üle maailma, kes toovad kaasa oma väärtusliku kogemuse, mis on saadud aastatepikkuse erinevate missioonide projekteerimise ja toimimise käigus. Oleks äärmiselt tobe ignoreerida seda kogemust ja uuesti nende konksude peale astuda.
Need standardid toetavad juba turul olemasolevaid maapealseid seadmeid.
Praeguste tõrgete kõrvaldamisel on alati võimalik pöörduda kolleegide poole teistest agentuuridest, et nad saaksid oma maapealt seadmest seanssi teostada. Nagu näete, on standardsed lahendused äärmiselt kasulikud, seega vaatame nende peamisi punkte.

Arhitektuur

Standardid on dokumentide kogum, mis kajastab kõige tavalist OSI (Open System Interconnection) mudelit, välja arvatud see, et kanali tasemel on üldistus piiratud telemeetria (kanal „alla“ – kosmos – Maa) ja telekäskude (kanal „üles“) jagunemisega.

Vaatame mõningaid tasemeid lähemalt, alustades füüsilisest ja liikudes ülespoole. Parema selguse huvides vaatame vastuvõtupoolt. Edastav pool on selle peegelpilt.

Füüsiline tase

Selles tasemes toimub moduleeritud raadiolainete muundamine bittide vooguks. Standardid on siin enamasti soovituslikku laadi, kuna sellel tasemel on raske abstraktida konkreetsest riistvara rakendusest. Siin on CCSDSi peamine roll määrata lubatud modulaarsused (BPSK, QPSK, 8-QAM jne) ja anda soovitusi sümbolite sünkroniseerimise ja doppleri nihke kompenseerimise mehhanismide rakendamiseks.

Sünkroniseerimise ja kodeerimise tase

Formaalsetel alustel on see kanalitaseme alamtaseme osa, kuid see eristatakse tihti eraldi tasemena oma tähtsuse tõttu CCSDSi standardites. See tasand muundab bittide voogu nn kaadriteks (telemetria või telekäsklused), millest räägime hiljem. Erinevalt sümbolite sünkroniseerimisest füüsilisel tasemel, mis võimaldab saada korrektse bittide voogu, toimub siin kaadrite sünkroniseerimine. Vaatame teed, mida andmed sellel tasemel läbivad (alt üles):

Kuid enne seda tasub öelda paar sõna kodeerimise kohta. See protseduur on vajalik, et tuvastada ja/või parandada bitivigu, mis paratamatult tekivad andmete edastamisel raadiokanalil. Siin me dekodeerimisprotseduure ei käsitle, vaid saame vaid teavet, mis on vajalik taseme edasise toimimise mõistmiseks.

Koodid võivad olla plokilised ja pidevad. Standardid ei nõua konkreetse kodeerimistüübi kasutamist, kuid see peab kindlasti olemas olema. Pidevaid koodide hulka kuuluvad konvolutsioonikoodid. Nende abil kodeeritakse pidev bittide voog. Erinevalt plokikoodidest, kus andmed jaotatakse koodiblokkideks ja neid saab dekodeerida ainult täiskestustega. Koodiblokk on edastatav teave ja sellele lisatud üleliigne info, mis on vajalik andmete õige vastuvõtu kontrollimiseks ja võimalike vigade parandamiseks. Plokikoodide alla kuuluvad kuulsad Reed-Solomoni koodid.

Kui kasutatakse konvolutsioonikodeerimist, edastatakse bitivool algusest dekooderisse. Selle töö tulemuseks (kõik see toimub pidevalt) on CADU (kanali juurdepääsudate üksus) andmeblokkide loomine. See struktuur on vajalik kaadri sünkroniseerimiseks. Iga CADU lõpus on sünkroniseerimismarker (ASM – külge kinnitatud sünkroniseerimismarker). Need on eelnevalt tuntud 4 bitti, mille abil sünkronisaator leiab CADU alguse ja lõpu. Nii saavutatakse kaadri sünkroniseerimine.

Järgmine valikuline etapp sünkrooni ja kodeerimise tasemel on seotud füüsilise taseme tööomadustega. See on de-randomiseerimine. Probleem seisneb selles, et sümboolse sünkroniseerimise saavutamiseks on vajalikud sagedased üleminekud sümbolite vahel. Nii et kui edastame oletatavasti kilobaiti andmeid, mis koosnevad ainult ühtedest, kaotatakse sünkroniseerimine. Seetõttu segatakse sisse tulevad andmed perioodilise pseudo-juhusliku järjestusega, et nullide ja ühtede tihedus oleks ühtlane.

Seejärel toimub plokkide koodide dekodeerimine, ja see, mis on jäänud, on sünkroniseerimise ja kodeerimise taseme lõpptooteks – kaader.

Kanali tase

Ühelt poolt saab kanali taseme töötleja kaadreid, teiselt poolt väljastab ta pakette. Kuna formaalselt ei ole pakettide suurusele mingeid piiranguid, on nende usaldusväärseks edastamiseks vajalik need jagada väiksemateks struktuurteks – kaadriteks. Siin vaatame kahte alamjaotust: eraldi telemetria (TM) ja telekäskude (TC) jaoks.

Telemetria

Lihtsalt öeldes on need andmed, mida maapealne jaam saab satelliidilt. Kõik edastatav teave jagatakse väikesteks fikseeritud pikkusega fragmentideks – kaadriteks, mis sisaldavad edastatavaid andmeid ja teenusvälju. Vaatame kaadri struktuuri lähemalt:

Ja alustame telemeetriakaadri peamise päise uurimist. Edasi luban endal mõnes kohas lihtsalt standardeid tõlkida, samal ajal andes mõningaid selgitusi.

Peamise kanalite tuvastaja (Master Channel ID) väli peab sisaldama kaadri versiooninumbrit ja seadme tunnust.

Iga KА, vastavalt CCSDS standarditele, peab olema unikaalne identifikaator, mille alusel saab teada, millisele seadmele see kuulub. Formaalset registreerimist nõutakse seadme registreerimiseks, mille nimi koos identifikaatoriga avaldatakse avalikes allikates. Kuid sageli ignoreerivad Venemaa tootjad seda protseduuri ja määravad seadmele suvalise identifikaatori. Raami versiooninumber aitab määrata, millist standardversiooni kasutatakse, et asjakohaselt raami lugeda. Siin vaatleme ainult kõige konservatiivsemat standardit versiooniga „0”.

Virtuaalse kanali identifikaatori (Virtual Channel ID) väljas peab olema VCID, milliselt kanalilt pakett tuli. VCID valimisele ei ole mingeid piiranguid, eriti ei pea virtuaalsed kanalid olema järjestikku numereeritud.

Väga sageli on vajalik edastatavate andmete multipliitmine. Selleks on olemas virtuaalsete kanalite mehhanism. Näiteks satelliit Meteor-M2 edastab värvilisi pilte nähtavas spektris, jagades need kolmeks mustvalgeks – iga värv edastatakse oma virtuaalses kanalis eraldi paketina, kuigi tema raamide struktuuris on mingisugune kõrvalekalle standarditest.

Operational Control lipuvälja peab olema indikaator, mis näitab, kas telemeetriaraamis on Operational Control väli või mitte. Need 4 bitti raami lõpupoole teenivad tagasiside säilitamise eesmärki, et kontrollida käsu raamide edastamise jälgimist. Räägime neist natuke hiljem.

Pea- ja virtuaalkanali kaadriarvestid on väljad, mis suurenevad ühe võrra iga edastatud raami puhul. Need näitavad, et ükski raami ei ole kadunud.

Telemeetriaraami andmete staatus on veel kaks bitti lipupõhiseid ja andmeid, millest vaatame ainult mõningaid.

Lisapealkirja (Secondary Header) lipp peab olema indikaator, mis näitab, kas telemeetriaraamis on olemas või puudub lisapealkiri.

Soovi korral võib igale raami lisada lisapealkirja ja paigutada sinna mis tahes andmed oma äranägemise järgi.

Esimese pealkirja näidiku väli (First Header Pointer), kui sünkroonimise lipp on väärtusega „1“, peab sisaldama esimest paketti andmeväljas (Data Field). Asetust loetakse alates 0 suurenevas järjestuses andmevälja algusest. Kui telemeetria kaadris ei ole paketi algust, peab esimese pealkirja näidiku väli olema väärtusega binaarrepresentatsioon „11111111111“ (see võib juhtuda, kui üks pikk pakett katab rohkem kui ühe kaadri).

Kui andmeväljas on tühi pakett (Idle Data), siis peab esimese pealkirja näidiku väärtus olema binaarrepresentatsioon „11111111110“. Selle välja põhjal peab vastuvõtja saavutama vooge sünkroniseerimise. See väli tagab sünkroniseerimise taastumise isegi juhul, kui kaadreid on vahele jäänud.

See tähendab, et pakett võib näiteks alata 4. kaadri keskel ja lõppeda 20. kaadri alguses. Just selle välja eesmärk on leida paketi algus. Pakettidel on samuti pealkiri, kus on märgitud selle pikkus, seega peab kanalitöötleja esimese pealkirja näidiku leidmisel selle läbi lugema, et määrata, kus pakett lõpeb.
Kui vigade kontrolli väli on olemas, peab see sisalduma igas telemeetria kaadris konkreetse füüsilise kanali jaoks kogu missiooni jooksul.

See väli arvutatakse CRC meetodi kohaselt. Protseduur peab võtma n-16 bitti telemeetria kaadrist ja sisestama arvutustulemuse viimasesse 16 bittidesse.

Telekomandod

Telekomandide kaadril on mitu olulist erinevust. Nende hulgas:

Teine pealkirjade struktuur
Dünaamiline pikkus. See tähendab, et kaadri pikkus ei ole kindlaks määratud nagu see on telemeetriaga, vaid võib varieeruda sõltuvalt edastatud paketidest.
Pakettide kohaletoimetamise garantii mehhanism. See tähendab, et KА peab pärast vastuvõttu kinnitama kaadrite õige vastuvõtu või küsima edastamist seal, kus pakk, millel võis olla parandamata viga, vastu võeti.

Palju välju on meile juba tuttavad telemeetria kaadrilt. Neil on sama eesmärk, seega käsitleme siin ainult uusi valdkondi.

Ühe käsu lipu bitti tuleks kasutada raami vastuvõtmisel kontrollimiseks. „0“ väärtus selle lipu korral peaks tähendama, et antud raami tüüp on A ja selle kontrollimine peab toimuma vastavalt FARM-ile. „1“ väärtus selle lipu korral annab vastuvõtjale teada, et antud raam on tüüp B ja peab FARM-i kontrollist kõrvale hiilima.

See lipp teavitab vastuvõtjat, kas kasutada raamide edastamise kinnitamise mehhanismi, mida nimetatakse FARM-iks – Raami Vastuvõtmise ja Teavitamise Mehhanismiks.

Juhtimiskäsu lipp tuleks kasutada selleks, et mõista, kas andmeväli edastab käsu või andmed. Kui lipp on „0“, siis peaks andmeväli sisaldama andmeid. Kui lipp on „1“, siis peaks andmeväli sisaldama FARM-i jaoks kontrollteavet.
FARM on lõpmatu automaat, mille parameetreid on võimalik seadistada.

RSVD. SPARE – reserveeritud bitid.

Tundub, et CCSDS-l on nende suhtes tulevikus plaanid, ja tagasimakse ühilduvuse nimel on nad juba praegustes standardi versioonides need bitid reserveerinud.

Raami pikkuse väli peaks sisaldama bitti, mis on raami pikkus oktetides miinus üks.

Raami andmeväli peaks järgima pealkirja ilma vahekohtadeta ja sisaldama kokkulepitud arvu oktette, maksimaalselt 1019 oktetti. See väli peab sisaldama kas andmeplokki või juhtimisteavet. Andmeplokk peab sisaldama endas:

kasutajate andmete oktette
segmenti pealkirja ja sellele järgnevate kasutajate andmete oktette

Kui pealkiri on esitatud, peab andmeplokk sisaldama Paketti, mitut Paketti või selle osa. Pealkirjata andmeplokk ei tohi sisaldada Pakettide osi, kuid võib sisaldada privaatformaadi andmeplokke. Seega on pealkiri vajalik, kui edastatav andmeplokk ei mahu ühte raami. Pealkirjaga andmeplokki nimetatakse segmentiks.

Kahest bitist koosnev lipuväli peaks sisaldama:

„01“ – kui andmete esimene osa asub andmeplokis
„00“ – kui andmete keskmine osa asub andmeplokis
„10“ – kui andmete viimane osa asub andmeplokis
«11» — kui jagunemist ei toimu ja andmablokki mahub tervikuna üks või mitu paketti.

MAP-i identifikaatori väli peab sisaldama nullide seeriat, kui MAP-kanaleid ei kasutata.
Mõnikord võib 6 bitti, mis on eraldatud virtuaalsetele kanalitele, osutuda ebapiisavaks. Kui andmeid tuleb multiplexerida suuremale kanalite arvule, kasutatakse veel 6 bitti segmentide pealkirjast.

FARM

Vaadakem lähemalt süsteemi, mis kontrollib kaadrite edastamise protsessi. See süsteem eeldab, et töö toimub ainult käskude kaadritega, arvestades nende tähtsust (telemeetri on alati võimalik uuesti küsida, kuid KА peab rääkima maapealse jaama käskudega selgelt ja alati neid kuulama). Olgu pealegi, oleme otsustanud meie satelliiti ümber programmeerida ja saadame sellele 10 kilobaiti binaarfaili. Kanalitasemel jaguneb fail 10 kaadriks (0, 1, …, 9), mis saadetakse järjestikku üles. Kui edastamine on lõpetatud, peab KА kinnitama paketi õige vastuvõtu või teatama, kus kaadris viga toimus. See teave saadetakse operatiivsesse jälgimisvälja lähimas telemeetria kaadris (või KА võib algatada tühja kaadri (idle frame) edastamise, kui tal pole midagi öelda). Saadud telemeetriast veendume, et kõik on korras, või alustame teate edastamise kordamist. Oletame, et satelliit ei kuulnud kaadrit nr 7. Seega saadame talle kaadrid 7, 8, 9. Kui vastust ei tule, saadetakse pakett tervikuna veelkord (ja nii mitu korda, kuni mõistame, et katsetest ei piisa).

Allpool on esitatud operatiivse jälgimise välja struktuur koos mõne välja kirjeldusega. Sellel väljal sisalduvaid andmeid nimetatakse CLCW – Communication Link Control Word.

Kuna pildilt on piisavalt lihtne aru saada põhiväljade tähendust ja teised on igavad, peidan detailse kirjelduse spoilerisse

CLCW väljade dešifreerimineKontrollsõna tüüp (Control Word Type):
Selle kontrollsõna tüübi puhul peab sisaldama 0

Kontrollsõna versioon (CLCW Version Number):
Selle kontrollsõna tüübi puhul peab olema bitivormis «00».

Oleku väli (Status Field):
Selle väli kasutamine määratakse iga missiooni jaoks eraldi. Seda võivad kasutada kohalike paranduste jaoks erinevad kosmoseagentuurid.

Virtuaalkanali identifitseerimine (Virtual Channel Identification):
Peab sisaldama virtuaalkanali identifitseerimist, millega see kontrollsõna seondub.

Füüsilise kanali juurdepääsu lipp:
Lipp peab andma teavet füüsilise tasandi vastuvõtja valmiduse kohta. Kui füüsilise tasandi vastuvõtja ei ole kaadrite vastuvõtmiseks valmis, peab välja sisaldama "1", vastasel juhul "0".

Sünkroonimise tõrke lipp:
Lipp võib näidata, et füüsiline tase töötab kehva signaali tasemega ja tagasilükatud kaadrite arv on liiga suur. Selle välja kasutamine on valikuline; kui seda kasutatakse, peab see sisaldama "0" sünkroonimise olemasolul ja "1" selle puudumisel.

Blokeerimise lipp:
See bit peab sisaldama FARM-i blokeerimise staatust iga virtuaalkanali jaoks. Väärtus "1" sellises väljas peab näitama, et FARM on blokeeritud ja kaadrid hakatakse igas virtuaaltasandis tagasi lükkama, vastasel juhul "0".

Ootamise lipp:
See bit peab olema kasutada, et näidata, et vastuvõtja ei saa antud virtuaalkanalis andmeid töödelda. Väärtus "1" näitab, et kõik kaadrid tagasi lükatakse antud virtuaalkanalis, vastasel juhul "0".

Uuesti edastamise lipp:
See lipp peab sisaldama "1", kui üks või rohkem A-tüüpi kaadrit on tagasi lükatud või puuduvad kaadrid, mistõttu on vajalik uuesti edastamine. Lipp "0" näitab, et ei ole tagasi lükatud kaadreid ega puudusi.

Vastuse väärtus:
Kaader, mis ei olnud vastuvõetud. Määratakse telekommando päises olevast loendurist.

Võrgutasand

Kitsendame veidi ka seda taset. Siin on võimalikud kaks valikut: kasutada kas kosmosepaketi protokolli või kapseldada mõni muu protokoll CCSDS paketti.

Kosmosepaketi protokolli ülevaade on eraldi artikli teema. See on loodud selleks, et niiöelda rakendused saaksid sujuvalt andmeid vahetada. Igal rakendusel on oma aadress ja põhifunktsionaalsus andmete vahetamiseks teiste rakendustega. Samuti on olemas teenused, mis suunavad liiklust, tagavad kohaletoimetamise järelevalve ja nii edasi.

Kapseldamine on lihtsam ja arusaadavam. Standardsed võimalused annavad võimaluse kapseldada CCSDS pakettidesse mis tahes protokolle, lisades täiendava päise.

Kus pealkirjal on erinevad tähendused sõltuvalt pakendatud protokolli pikkusest:

Siin on peamine väli – pikkuse pikkus. See võib varieeruda 0 kuni 4 baitini. Samuti tuleb sellel pealkirjal märkida, milline on pakendatud protokoll, kasutades tabelit. siit.

IP pakendamise puhul kasutatakse veel ühte kihti, et määrata paketi tüüp.
Peab lisama veel ühe pealkirja, mille pikkus on üks oktet:

Kus PID on veel üks protokolli identifikaator, mis on saadud siit

Kokkuvõte

Esmapilgul võib tunduda, et CCSDS pealkirjad on ülimalt üleliigsed ja teatud väljad võiksid olla välistatud. Tõepoolest, saadud kanali efektiivsus (kuni võrgu tasemeni) on umbes 40%. Kuid niipea, kui tekib vajadus nende standardite rakendamiseks, on selge, et igal väljal, igal pealkirjal on oma tähtis missioon, mille ignoreerimine toob kaasa terve rea ebaselgusi.

Kui habraühing huvitub sellest teemast, oleksin rõõmus avaldada veel terve rida artikleid, mis käsitlevad kosmose side teooriat ja praktikat. Aitäh tähelepanu eest!