{"id":35921,"date":"2019-10-31T22:07:35","date_gmt":"2019-10-31T19:07:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nemnogo-o-standartah-kosmicheskoj-svyazi\/"},"modified":"2019-10-31T22:07:35","modified_gmt":"2019-10-31T19:07:35","slug":"nemnogo-o-standartah-kosmicheskoj-svyazi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Lidt om standarder for rumkommunikation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Lidt
\nMeteor M1 Satellit
\nKilde: vladtime.ru<\/i><\/p>\n

Introduktion<\/h2>\n

\nDrift af rummeteknologi er umulig uden radiokommunikation, og i denne artikel vil jeg fors\u00f8ge at forklare de grundl\u00e6ggende ideer, der ligger til grund for standarderne udviklet af den Internationale R\u00e5dgivende Komit\u00e9 for Rumdataoverf\u00f8rselssystemer (Consultative Committee for Space Data Systems \u2013 CCSDS. Denne forkortelse vil blive brugt fremover).<\/p>\n

Denne publikation vil prim\u00e6rt fokusere p\u00e5 det kanalniveau, men der vil ogs\u00e5 blive introduceret grundl\u00e6ggende begreber for de andre niveauer. Artiklen har ikke ambitioner om en udt\u00f8mmende og fuldst\u00e6ndig beskrivelse af standarderne. Du kan finde dem p\u00e5 websitet<\/a><\/noindex> CCSDS. Men de er meget sv\u00e6re at forst\u00e5, og for at finde ud af dem har vi brugt en hel del tid, derfor vil jeg her give basal information, som g\u00f8r det meget lettere at forst\u00e5 det \u00f8vrige. S\u00e5 lad os begynde.
\n<\/a><\/noindex><\/p>\n

Den \u00e6dle mission CCSDS<\/h2>\n

\nM\u00e5ske har nogen spurgt: hvorfor skal alle f\u00f8lge standarder, hvis man kan udvikle sin egen propriet\u00e6re protokolstak til radiokommunikation (eller sin egen standard, med blackjack og nye funktioner), hvilket dermed vil \u00f8ge systemets sikkerhed?<\/p>\n

Praksis viser, at det er mere fordelagtigt at f\u00f8lge CCSDS-standarderne af f\u00f8lgende grunde:<\/p>\n

    \n
  1. I komit\u00e9en, der er ansvarlig for offentligg\u00f8relsen af standarder, indg\u00e5r repr\u00e6sentanter fra alle de store rumfartsorganisationer i verden, som bringer deres uvurderlige erfaringer fra mange \u00e5rs design og drift af forskellige missioner. Det ville v\u00e6re meget absurd at ignorere denne erfaring og tr\u00e6de ind i de samme f\u00e6lder igen.<\/li>\n
  2. Disse standarder underst\u00f8ttes af alt det eksisterende udstyr til jorden.<\/li>\n
  3. Under fejlfinding kan man altid henvende sig til kolleger fra andre agenturer, s\u00e5 de kan gennemf\u00f8re en kommunikationssession med apparatet fra deres jordstation. Som du kan se, er standarder ekstremt nyttige, s\u00e5 lad os se p\u00e5 deres n\u00f8glepunkter.<\/li>\n<\/ol>\n

    <\/p>\n

    Arkitektur<\/h2>\n

    \nStandarderne udg\u00f8r et s\u00e6t dokumenter, der afspejler den meget almindelige OSI-model (Open System Interconnection), bortset fra at f\u00e6llesskabet p\u00e5 kanalniveau er begr\u00e6nset til opdelingen mellem telemetri (nedadg\u00e5ende kanal \u2014 rum \u2013 Jorden) og telekommandoer (opadg\u00e5ende kanal).<\/p>\n

    \"Lidt
    \n
    \nLad os se n\u00e6rmere p\u00e5 nogle niveauer, startende med det fysiske og bev\u00e6ge os opad. For st\u00f8rre klarhed vil vi overveje arkitekturen p\u00e5 modtagersiden. Den overf\u00f8rende repr\u00e6senterer dens spejlvendte billede.<\/p>\n

    Fysisk niveau<\/h2>\n

    \nP\u00e5 dette niveau finder omdannelsen af den modulerede radiosignal til en bitstr\u00f8m sted. Standarderne her er hovedsageligt anbefalende, da det er sv\u00e6rt at abstrahere fra den specifikke hardwareimplementering p\u00e5 dette niveau. Her spiller CCSDS en n\u00f8gle rolle - at definere tilladte modulationsformer (BPSK, QPSK, 8-QAM osv.) og give nogle anbefalinger til implementering af mekanismer til symbolsynkronisering, kompensering for Doppler-forskydning osv.<\/p>\n

    Synkroniserings- og kodningsniveauet<\/h2>\n

    \nFormelt set er det et underniveau af datalink niveauet, men det fremh\u00e6ves ofte som et selvst\u00e6ndigt niveau p\u00e5 grund af dets betydning inden for CCSDS-standarderne. Dette niveau konverterer bitstr\u00f8mmen til s\u00e5kaldte rammer (telemetri eller telekommandoer), som vi senere vil tale om. I mods\u00e6tning til symbolsynkronisering p\u00e5 det fysiske niveau, som muligg\u00f8r korrekt bitstr\u00f8m, udf\u00f8res der p\u00e5 dette niveau rammesynkronisering. Lad os se p\u00e5 den vej, som dataene passerer p\u00e5 dette niveau (nedenfra og op):<\/p>\n

    \"Lidt
    \n
    \nMen f\u00f8r dette er det v\u00e6rd at sige et par ord om kodning. Denne procedure er n\u00f8dvendig for at finde og\/eller rette bitfejl, der uundg\u00e5eligt opst\u00e5r ved overf\u00f8rsel af data via radiokanalen. Her vil vi ikke overveje dekodingsprocedurer, men blot f\u00e5 oplysninger, der er n\u00f8dvendige for at forst\u00e5 den videre logik i niveauets funktion. <\/p>\n

    Koderne kan v\u00e6re blok- og kontinuerlige. Standarderne tvinger ikke brugen af en specifik type kodning, men den skal som s\u00e5dan v\u00e6re til stede. Kontinuerlige koder inkluderer konvolutionelle koder. Med dem kodes en kontinuerlig bitstr\u00f8m. I mods\u00e6tning til blokkoder, hvor data opdeles i kodeblokke og kun kan dekodes inden for hele blokke. En kodeblok repr\u00e6senterer de overf\u00f8rte data og den tilknyttede redundante information, der er n\u00f8dvendig for at kontrollere korrekt modtagelse af dataene og rette eventuelle fejl. De ber\u00f8mte Reed-Solomon-koder h\u00f8rer til blokkodernes kategori.<\/p>\n

    Hvis der anvendes konvolutionel kodning, sendes bitstr\u00f8mmen fra starten til dekoderen. Resultatet af dens arbejde (det sker naturligvis kontinuerligt) bliver blokke af CADU (channel access data unit). Denne struktur er n\u00f8dvendig for rammesynkronisering. I slutningen af hver CADU er der tilknyttet en synkroniseringsmark\u00f8r (ASM \u2013 attached synch marker). Dette er forudkendte 4 bytes, som synkronisatoren bruger til at finde begyndelsen og slutningen af CADU. P\u00e5 denne m\u00e5de opn\u00e5s rammesynkronisering.<\/p>\n

    Det n\u00e6ste valgfrie trin i synkroniserings- og kodningsniveauet er relateret til de specifikke forhold i det fysiske niveau. Det er derandomisering. Problemet er, at for at opn\u00e5 symbolsynkronisering er hyppige skift mellem symboler n\u00f8dvendige. S\u00e5 hvis vi f.eks. skal overf\u00f8re en kilobyte data best\u00e5ende udelukkende af \u00e9t-tal, vil synkroniseringen g\u00e5 tabt. Derfor blandes inputdataene under overf\u00f8rslen med en periodisk pseudorandom sekvens, s\u00e5 t\u00e6theden af nuller og \u00e9t-tal er j\u00e6vn.<\/p>\n

    Dern\u00e6st finder dekodningen af blokke koder sted, og det, der er tilbage, bliver det endelige produkt af synkroniserings- og kodningsniveauet \u2013 en ramme.<\/p>\n

    Kanalniveau<\/h2>\n

    \nP\u00e5 den ene side modtager kanalniveauets behandler rammer, og p\u00e5 den anden side udgiver den pakker. Eftersom pakkenes st\u00f8rrelse formelt ikke er begr\u00e6nset, er det n\u00f8dvendigt at opdele dem i mindre strukturer \u2013 rammer \u2013 for at sikre p\u00e5lidelig transmission. Her vil vi se p\u00e5 to underafsnit: separat for telemetri (TM) og telekommandoer (TC).<\/p>\n

    Telemetri<\/h3>\n

    \nKort sagt er dette de data, som jorden station modtager fra rumfart\u00f8jet. Alle overf\u00f8rte oplysninger opdeles i sm\u00e5 fragmenter af fast l\u00e6ngde \u2013 rammer, der indeholder de overf\u00f8rte data og kontrolfelter. Lad os se n\u00e6rmere p\u00e5 rammestrukturen:<\/p>\n

    \"Lidt
    \n
    \nVi begynder vores gennemgang med hovedoverskriften for telemetrirammen. Derefter vil jeg tillade mig at overs\u00e6tte standarderne flere steder, mens jeg giver nogle forklaringer.<\/p>\n

    \"Lidt
    \n
    \nFeltet for den prim\u00e6re kanalidentifikator (Master Channel ID) skal indeholde versionsnummeret p\u00e5 rammen og apparatets identifikator.<\/p>\n

    Hver KA skal, i henhold til CCSDS-standarderne, have sin egen unikke identifikator, som g\u00f8r det muligt at bestemme, hvilken enhed det tilh\u00f8rer, n\u00e5r man har en ramme. Formelt skal der indgives en ans\u00f8gning om registrering af enheden, og dens navn sammen med identifikatoren vil blive offentliggjort i \u00e5bne kilder. Dog ignorerer russiske producenter ofte denne procedure og tildeler enheden en vilk\u00e5rlig identifikator. Versionsnummeret p\u00e5 rammen hj\u00e6lper med at bestemme, hvilken version af standarderne der anvendes, for korrekt at kunne l\u00e6se rammen. Her vil vi kun se p\u00e5 den mest konservative standard med version \"0\".<\/i><\/p>\n

    I feltet for identifikatoren for den virtuelle kanal (Virtual Channel ID) skal VCID for den kanal, som pakken er modtaget fra, v\u00e6re indeholdt. Der er ingen begr\u00e6nsninger for valget af VCID, og de virtuelle kanaler beh\u00f8ver ikke at blive nummereret sekventielt.<\/p>\n

    Der opst\u00e5r ofte behov for at multiplexere de data, der sendes. Der findes en mekanisme for virtuelle kanaler til dette form\u00e5l. For eksempel sender satellitten Meteor-M2 farvebilleder i det synlige spektrum ved at opdele dem i tre sort-hvide billeder \u2013 hver farve sendes i sin egen virtuelle kanal som en separat pakke, selvom der i strukturen af dens rammer er en vis afvigelse fra standarderne.<\/i><\/p>\n

    Feltet for flaget Operational Control skal v\u00e6re en indikator for tilstedev\u00e6relsen eller frav\u00e6ret af feltet Operational Control i telemetrirammen. Disse 4 byte i slutningen af rammen bruges til at opretholde feedback i kontrollen af leveringen af telesignalrammer. Vi vil tale mere om dem senere.<\/p>\n

    T\u00e6llerne for rammerne i hoved- og virtuel kanal \u2013 er felter, der \u00f8ges med \u00e9n enhed ved hver afsendelse af en ramme. De fungerer som indikator for, at ingen rammer er g\u00e5et tabt.<\/i><\/p>\n

    Status for data i telemetrirammen \u2013 er yderligere to byte flag og data, hvor vi kun vil se p\u00e5 nogle af dem.<\/p>\n

    \"Lidt
    \n
    \nFeltet for flaget for den sekund\u00e6re header (Secondary Header) skal v\u00e6re en indikator for tilstedev\u00e6relsen eller frav\u00e6ret af den sekund\u00e6re header i telemetrirammen.<\/p>\n

    Hvis \u00f8nskes, kan man tilf\u00f8je en sekund\u00e6r header til hver ramme og placere enhver data der efter eget valg.<\/i><\/p>\n

    Indikatoren for den f\u00f8rste headerpeger (First Header Pointer), n\u00e5r synkroniseringsflaget er \"1\", skal indeholde den bin\u00e6re repr\u00e6sentation af positionen for det f\u00f8rste oktet i det f\u00f8rste paket i datadelen (Data Field) af telemetrikaden. Positionen t\u00e6lles fra 0 i stigende r\u00e6kkef\u00f8lge fra begyndelsen af datadelen. Hvis der ikke er begyndelse p\u00e5 pakken i datadelen af telemetrikaden, skal headerpegeren have v\u00e6rdien i bin\u00e6r repr\u00e6sentation \"11111111111\" (dette kan ske, hvis et langt paket str\u00e6kker sig over mere end en kadre). <\/p>\n

    Hvis datadelen indeholder et tomt paket (Idle Data), skal pointeren til den f\u00f8rste header have v\u00e6rdien i bin\u00e6r repr\u00e6sentation \"11111111110\". Modtageren skal synkronisere str\u00f8mmen baseret p\u00e5 dette felt. Dette felt sikrer genoprettelse af synkronisering selv i tilf\u00e6lde af tabte kadrer.<\/p>\n

    Det vil sige, at pakken kan for eksempel begynde i midten af den 4. kadre og slutte i starten af den 20. For at finde dens begyndelse er dette felt netop form\u00e5let. Pakker har ogs\u00e5 en header, hvor dens l\u00e6ngde er angivet, s\u00e5 n\u00e5r pointeren til den f\u00f8rste header findes, skal linklaget behandler den og derved bestemme, hvor pakken slutter.<\/i>
    \nHvis fejlkontrolfeltet er til stede, skal det v\u00e6re indeholdt i hver telemetrikade for en bestemt fysisk kanal gennem hele missionen.<\/p>\n

    Dette felt beregnes ved hj\u00e6lp af CRC-metoden. Proceduren skal tage n-16 bit telemetrikaden og inds\u00e6tte resultatet af beregningen i de sidste 16 bit.<\/p>\n

    Telekommander<\/h4>\n

    \nTelekommandkadre har flere v\u00e6sentlige forskelle. Blandt dem:<\/p>\n

      \n
    1. En anden headerstruktur<\/li>\n
    2. Dynamisk l\u00e6ngde. Det betyder, at l\u00e6ngden af kadrer ikke er fastsat som i telemetri, men kan variere afh\u00e6ngigt af de transmitterede pakker.<\/li>\n
    3. Mekanismen for garanteret levering af pakker. Det vil sige, at K\u0410 skal bekr\u00e6fte korrekt modtagelse af kadrer, efter modtagelse, eller anmode om at gensende fra den kadre, der muligvis er modtaget med en ukorrigerbar fejl.<\/li>\n<\/ol>\n

      \n\"Lidt
      \n
      \n\"Lidt
      \n
      \nMange felter er allerede kendte for os fra telemetricaden header. De har det samme form\u00e5l, s\u00e5 her vil vi kun se p\u00e5 de nye felter.<\/p>\n

      En bit af flaget for omg\u00e5else skal bruges til at kontrollere modtagelsen af rammer hos modtageren. V\u00e6rdien \"0\" af dette flag skal angive, at den p\u00e5g\u00e6ldende ramme er af type A, og dens kontrol skal udf\u00f8res i henhold til FARM. V\u00e6rdien \"1\" af dette flag skal informere modtageren om, at den p\u00e5g\u00e6ldende ramme er af type B og skal omg\u00e5 kontrollen if\u00f8lge FARM.<\/p>\n

      Dette flag informerer modtageren om, hvorvidt mekanismen til bekr\u00e6ftelse af leveringen af rammer, kaldet FARM \u2014 Frame Acceptance and Reporting Mechanism, skal anvendes.<\/i><\/p>\n

      Kontrolkommandomerket skal bruges til at forst\u00e5, om datakildens felt transporterer en kommando eller data. Hvis flaget er lig med \"0\", skal datakildens felt indeholde data. Hvis flaget er lig med \"1\", skal datakildens felt indeholde kontrolinformation til FARM.
      \nFARM er en endelig automat, hvis parametre kan konfigureres.<\/i><\/p>\n

      RSVD. SPARE \u2013 reserverede bits.<\/p>\n

      Det synes at CCSDS har planer for dem i fremtiden, og for tilbagekompatibiliteten af protokolversioner har de allerede reserveret disse bits i nuv\u00e6rende versioner af standarden.<\/i><\/p>\n

      Rammens l\u00e6ngdefelt skal indeholde et tal i bitrepr\u00e6sentation, som svarer til l\u00e6ngden af rammen i oktetter minus \u00e9n.<\/p>\n

      Datakildens felt skal f\u00f8lge efter overskriften uden mellemrum og indeholde et helt antal oktetter, som maksimalt kan v\u00e6re 1019 oktetter. Dette felt skal indeholde enten en blok af datarammer eller kontrolinformation. Datablokken skal indeholde:<\/p>\n