{"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\/sv\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Lite om standarder f\u00f6r rymdkommunikation","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Lite
\nMeteor Satellite M1
\nK\u00e4lla: vladtime.ru<\/i><\/p>\n

Introduktion<\/h2>\n

\nAnv\u00e4ndningen av rymdteknik \u00e4r om\u00f6jlig utan radiokommunikation, och i denna artikel kommer jag att f\u00f6rs\u00f6ka f\u00f6rklara de grundl\u00e4ggande id\u00e9erna som ligger till grund f\u00f6r standarderna som utvecklats av det Internationella konsultativa kommitt\u00e9n f\u00f6r rymdsystem f\u00f6r datakommunikation (Consultative Committee for Space Data Systems \u2013 CCSDS. F\u00f6rkortningen CCSDS kommer att anv\u00e4ndas h\u00e4refter).<\/p>\n

Denna publikation kommer fr\u00e4mst att handla om kanalniv\u00e5n, men grundl\u00e4ggande begrepp f\u00f6r andra niv\u00e5er kommer ocks\u00e5 att introduceras. Artikeln g\u00f6r inget anspr\u00e5k p\u00e5 att ge en fullst\u00e4ndig och utt\u00f6mmande beskrivning av standarderna. Du kan bekanta dig med dem p\u00e5 webbplats<\/a><\/noindex> CCSDS. Men de \u00e4r mycket sv\u00e5ra att f\u00f6rst\u00e5, och f\u00f6r att f\u00f6rst\u00e5 dem har vi lagt ner en hel del tid, d\u00e4rf\u00f6r vill jag h\u00e4r ge grundl\u00e4ggande information som g\u00f6r det mycket l\u00e4ttare att f\u00f6rst\u00e5 allt annat. S\u00e5, l\u00e5t oss b\u00f6rja.
\n<\/a><\/noindex><\/p>\n

Den \u00e4dla uppgiften CCSDS<\/h2>\n

\nKanske har n\u00e5gon st\u00e4llt sig fr\u00e5gan: varf\u00f6r ska alla h\u00e5lla sig till standarder, n\u00e4r man kan utveckla sin egen propriet\u00e4ra protokollstack f\u00f6r radiokommunikation (eller sin egen standard, med blackjack och nya funktioner), vilket skulle \u00f6ka systemets s\u00e4kerhet?<\/p>\n

Som erfarenhet visar \u00e4r det f\u00f6rdelaktigare att f\u00f6lja CCSDS-standarder av f\u00f6ljande sk\u00e4l:<\/p>\n

    \n
  1. I kommitt\u00e9n som ansvarar f\u00f6r publiceringen av standarderna ingick representanter fr\u00e5n alla stora rymdorganisationer i v\u00e4rlden, som bidrog med sin ov\u00e4rderliga erfarenhet fr\u00e5n m\u00e5nga \u00e5rs design och drift av olika uppdrag. Det skulle vara mycket dumt att ignorera denna erfarenhet och \u00e5terigen trampa i samma fotsp\u00e5r.<\/li>\n
  2. Dessa standarder st\u00f6ds av den redan existerande marknadsutrustningen f\u00f6r markstationer.<\/li>\n
  3. Vid fels\u00f6kning kan man alltid be kollegor fr\u00e5n andra organisationer om hj\u00e4lp f\u00f6r att de ska genomf\u00f6ra en kommunikationssession med enheten fr\u00e5n sin markstation. Som du ser \u00e4r standarder en mycket anv\u00e4ndbar sak, s\u00e5 l\u00e5t oss ta en n\u00e4rmare titt p\u00e5 deras viktigaste punkter.<\/li>\n<\/ol>\n

    <\/p>\n

    Arkitektur<\/h2>\n

    \nStandarderna utg\u00f6r en samling dokument som \u00e5terspeglar den vanliga OSI-modellen (Open System Interconnection), med undantag f\u00f6r att p\u00e5 kanalniv\u00e5n begr\u00e4nsas gemensamheten till uppdelningen mellan telemetri (ned\u00e5triktad kanal \u2013 rymd \u2013 jord) och telekommandon (upp\u00e5triktad kanal).<\/p>\n

    \"Lite
    \n
    \nL\u00e5t oss titta p\u00e5 vissa niv\u00e5er i mer detalj, b\u00f6rja med den fysiska och g\u00e5 upp\u00e5t. F\u00f6r att g\u00f6ra det mer tydligt kommer vi att se p\u00e5 arkitekturen av mottagarsidan. Den \u00f6verf\u00f6rande sidan utg\u00f6r en spegelbild av den.<\/p>\n

    Fysisk niv\u00e5<\/h2>\n

    \nP\u00e5 denna niv\u00e5 sker omvandlingen av den modulering av radiosignalen till en bitstr\u00f6m. Standarderna h\u00e4r \u00e4r huvudsakligen v\u00e4gledande, eftersom det \u00e4r sv\u00e5rt att abstrahera fr\u00e5n den specifika h\u00e5rdvaruimplementationen. H\u00e4r spelar CCSDS en nyckelroll \u2013 att definiera till\u00e5tna moduler, s\u00e5som BPSK, QPSK, 8-QAM osv., och ge vissa rekommendationer om implementeringen av mekanismer f\u00f6r symbolsynkronisering, kompensering av Dopplerskift och liknande.<\/p>\n

    Synkroniserings- och kodningsniv\u00e5<\/h2>\n

    \nFormellt sett \u00e4r det ett delniv\u00e5 inom kanalniv\u00e5n, men det framh\u00e4vs ofta som en egen niv\u00e5 p\u00e5 grund av dess betydelse inom CCSDS-standarderna. Denna niv\u00e5 omvandlar bitstr\u00f6mmen till s\u00e5 kallade ramar (telemetri eller telekommandon), som vi kommer att diskutera senare. Till skillnad fr\u00e5n den symbolsynkronisering som sker p\u00e5 den fysiska niv\u00e5n, vilken g\u00f6r att vi f\u00e5r en korrekt bitstr\u00f6m, utf\u00f6rs h\u00e4r ramsynkronisering. L\u00e5t oss titta p\u00e5 v\u00e4gen som data passerar p\u00e5 denna niv\u00e5 (nedifr\u00e5n och upp):<\/p>\n

    \"Lite
    \n
    \nMen innan vi g\u00f6r det \u00e4r det v\u00e4rt att n\u00e4mna n\u00e5gra ord om kodning. Denna procedur \u00e4r n\u00f6dv\u00e4ndig f\u00f6r att uppt\u00e4cka och\/eller korrigera bitfel som oundvikligen uppst\u00e5r vid s\u00e4ndning av data \u00f6ver radiokanalen. H\u00e4r kommer vi inte att diskutera avkodningsprocedurer, utan endast f\u00e5 information som \u00e4r n\u00f6dv\u00e4ndig f\u00f6r att f\u00f6rst\u00e5 logiken i hur niv\u00e5n fungerar fram\u00f6ver. <\/p>\n

    Koder kan vara block- eller kontinuerliga. Standarderna tvingar inte fram anv\u00e4ndning av en specifik typ av kodning, men den m\u00e5ste som s\u00e5dan finnas. Kontinuerliga koder \u00e4r konvolutionskoder. De anv\u00e4nds f\u00f6r att koda en kontinuerlig bitstr\u00f6m. Till skillnad fr\u00e5n blockkoder, d\u00e4r data delas upp i kodblock och kan bara dekodas inom hela block. Ett kodblock representerar de \u00f6verf\u00f6rda data och den tillagda redundanta informationen som kr\u00e4vs f\u00f6r att kontrollera korrekt mottagande av data och r\u00e4tta till eventuella fel. Bland blockkoderna finns de ber\u00f6mda Reed-Solomon-koderna.<\/p>\n

    Om konvolutionskodning anv\u00e4nds, kommer bitstr\u00f6mmen fr\u00e5n b\u00f6rjan att g\u00e5 till dekodern. Resultatet av dess arbete (allt detta sker f\u00f6rst\u00e5s kontinuerligt) blir CADU-block (channel access data unit). Denna struktur \u00e4r n\u00f6dv\u00e4ndig f\u00f6r ram-synkronisering. I slutet av varje CADU kopplas en synkroniseringsmark\u00f6r (ASM \u2013 attached synch maker) till. Detta \u00e4r fyra f\u00f6rutbest\u00e4mda byte, vilket synkroniseraren anv\u00e4nder f\u00f6r att hitta b\u00f6rjan och slutet av CADU. S\u00e5 n\u00e5s ram-synkronisering.<\/p>\n

    Det n\u00e4sta valfria steget i synkroniserings- och kodningsniv\u00e5n \u00e4r kopplat till egenskaperna hos den fysiska niv\u00e5n. Detta kallas derandomisering. Anledningen \u00e4r att f\u00f6r att uppn\u00e5 symbolsynkronisering kr\u00e4vs frekventa v\u00e4xlingar mellan symboler. Om vi till exempel skulle \u00f6verf\u00f6ra ett kilobyte data som enbart best\u00e5r av ettor, skulle synkroniseringen g\u00e5 f\u00f6rlorad. D\u00e4rf\u00f6r blandas de inkommande data under \u00f6verf\u00f6ringen med en periodisk pseudorandom sekvens f\u00f6r att f\u00f6rdela nollor och ettor j\u00e4mnt.<\/p>\n

    D\u00e4refter sker avkodning av blockkoder, och det som \u00e5terst\u00e5r blir den slutliga produkten av synkronisering- och kodningsniv\u00e5n \u2013 en ram.<\/p>\n

    Kanalniv\u00e5<\/h2>\n

    \n\u00c5 ena sidan tar kanallagret emot ramar, och \u00e5 andra sidan ger det ut paket. Eftersom paketens storlek formellt inte \u00e4r begr\u00e4nsad, m\u00e5ste de delas upp i mindre strukturer \u2013 ramar \u2013 f\u00f6r att s\u00e4kerst\u00e4lla p\u00e5litlig \u00f6verf\u00f6ring. H\u00e4r kommer vi att titta p\u00e5 tv\u00e5 delavsnitt: en f\u00f6r telemetri (TM) och en f\u00f6r telekommandon (TC).<\/p>\n

    Telemetri<\/h3>\n

    \nEnklare sagt, detta \u00e4r de data som markstationen f\u00e5r fr\u00e5n KAs. All \u00f6verf\u00f6rd information delas upp i sm\u00e5 fragment av fast l\u00e4ngd \u2013 ramar, som inneh\u00e5ller de \u00f6verf\u00f6rda data och hj\u00e4lpkonton. L\u00e5t oss titta n\u00e4rmare p\u00e5 ramstrukturen:<\/p>\n

    \"Lite
    \n
    \nOch vi b\u00f6rjar med huvudhuvudet av telemetriramen. Vid vissa tillf\u00e4llen kommer jag att \u00f6vers\u00e4tta standarderna, samtidigt som jag ger n\u00e5gra f\u00f6rklaringar.<\/p>\n

    \"Lite
    \n
    \nF\u00e4ltet f\u00f6r identifiering av huvudkanalen (Master Channel ID) ska inneh\u00e5lla versionsnumret p\u00e5 ramen och identifieraren f\u00f6r enheten.<\/p>\n

    Varje KA, enligt CCSDS-standarder, m\u00e5ste ha sin egen unika identifierare som g\u00f6r det m\u00f6jligt att best\u00e4mma vilket instrument en given ram tillh\u00f6r. Formellt m\u00e5ste en registreringsans\u00f6kan f\u00f6r instrumentet l\u00e4mnas in, och dess namn, tillsammans med identifieraren, kommer att publiceras i \u00f6ppna k\u00e4llor. Dock ignorerar ofta ryska tillverkare denna procedur och tilldelar instrumentet en godtycklig identifierare. Versionsnumret p\u00e5 ramen hj\u00e4lper till att best\u00e4mma vilken version av standarderna som anv\u00e4nds f\u00f6r att korrekt l\u00e4sa ramen. H\u00e4r kommer vi endast att behandla den mest konservativa standarden med version \"0\".<\/i><\/p>\n

    I f\u00e4ltet f\u00f6r identifieraren av den virtuella kanalen (Virtual Channel ID) ska VCID f\u00f6r den kanal fr\u00e5n vilken paketet kom finnas. Det finns inga begr\u00e4nsningar f\u00f6r valet av VCID, och virtuella kanaler beh\u00f6ver inte n\u00f6dv\u00e4ndigtvis numreras sekventiellt.<\/p>\n

    Det uppst\u00e5r ofta ett behov av att multiplexa de \u00f6verf\u00f6rda uppgifterna. F\u00f6r detta finns en mekanism f\u00f6r virtuella kanaler. Till exempel \u00f6verf\u00f6r satelliten Meteor-M2 en f\u00e4rgbild i det synliga spektrumet, genom att dela den i tre svartvita - varje f\u00e4rg \u00f6verf\u00f6rs i sin egen virtuella kanal som ett separat paket, \u00e4ven om det i strukturen av dess ramar finns vissa avvikelser fr\u00e5n standarderna.<\/i><\/p>\n

    F\u00e4ltet f\u00f6r flaggan f\u00f6r operativ kontroll ska vara en indikator p\u00e5 n\u00e4rvaron eller fr\u00e5nvaron av f\u00e4ltet f\u00f6r operativ kontroll i telemetriramen. Dessa 4 byte i slutet av ramen anv\u00e4nds f\u00f6r att uppr\u00e4tth\u00e5lla \u00e5terkoppling vid kontroll av leveransen av telekommandons ramar. Vi kommer att prata om dem lite senare.<\/p>\n

    R\u00e4knare f\u00f6r huvud- och virtuell kanal \u00e4r f\u00e4lt som \u00f6kas med ett vid s\u00e4ndning av varje ram. De fungerar som en indikator p\u00e5 att ingen ram har g\u00e5tt f\u00f6rlorad.<\/i><\/p>\n

    Statusen f\u00f6r datan i telemetriramen best\u00e5r av ytterligare tv\u00e5 byte av flaggor och data, av vilka vi endast kommer att granska n\u00e5gra.<\/p>\n

    \"Lite
    \n
    \nF\u00e4ltet f\u00f6r flaggan f\u00f6r sekund\u00e4r rubrik (Secondary Header) ska vara en indikator p\u00e5 n\u00e4rvaron eller fr\u00e5nvaron av en sekund\u00e4r rubrik (Secondary Header) i telemetriramen.<\/p>\n

    Om s\u00e5 \u00f6nskas kan en sekund\u00e4r rubrik l\u00e4ggas till varje ram och d\u00e4r kan alla typer av data placeras efter eget val.<\/i><\/p>\n

    F\u00e4ltet f\u00f6r pekare till f\u00f6rsta rubriken (First Header Pointer), n\u00e4r synkroniseringsflaggan \u00e4r \"1\", ska inneh\u00e5lla den bin\u00e4ra representationen av positionen f\u00f6r den f\u00f6rsta oktetten i det f\u00f6rsta paketet i dataf\u00e4ltet (Data Field) f\u00f6r telemetrikadret. Positionen r\u00e4knas fr\u00e5n 0 i stigande ordning fr\u00e5n b\u00f6rjan av dataf\u00e4ltet. Om det inte finns n\u00e5got b\u00f6rjan p\u00e5 paketet i dataf\u00e4ltet f\u00f6r telemetrikadret, ska pekaren till f\u00f6rsta rubriken ha v\u00e4rdet i bin\u00e4r representation \"11111111111\" (detta kan h\u00e4nda om ett l\u00e5ngt paket str\u00e4cker sig \u00f6ver mer \u00e4n en ram). <\/p>\n

    Om dataf\u00e4ltet inneh\u00e5ller ett tomt paket (Idle Data), ska pekaren till f\u00f6rsta rubriken ha v\u00e4rdet i bin\u00e4r representation \"11111111110\". Genom detta f\u00e4lt ska mottagaren synkronisera str\u00f6mmen. Detta f\u00e4lt garanterar \u00e5terst\u00e4llning av synkronisering \u00e4ven om ramar missas.<\/p>\n

    Det vill s\u00e4ga att paketet kan, till exempel, b\u00f6rja i mitten av den 4:e ramen och sluta i b\u00f6rjan av den 20:e. F\u00f6r att hitta dess b\u00f6rjan anv\u00e4nds just detta f\u00e4lt. Paket har ocks\u00e5 en rubrik d\u00e4r dess l\u00e4ngd anges, s\u00e5 n\u00e4r pekaren till f\u00f6rsta rubriken hittas, ska l\u00e4nkniv\u00e5hanteraren l\u00e4sa den, vilket p\u00e5 s\u00e5 s\u00e4tt best\u00e4mmer var paketet slutar.<\/i>
    \nOm f\u00e4ltet f\u00f6r felkontroll \u00e4r n\u00e4rvarande, ska det ing\u00e5 i varje telemetrikadr f\u00f6r en viss fysisk kanal under hela uppdraget.<\/p>\n

    Detta f\u00e4lt ber\u00e4knas genom att anv\u00e4nda CRC-metoden. Proceduren ska ta n-16 bitar av telemetrikadr och infoga resultatet av ber\u00e4kningen i de sista 16 bitarna.<\/p>\n

    Telekommandon<\/h4>\n

    \nTelekommandots ram har flera betydande skillnader. Bland dem:<\/p>\n

      \n
    1. En annan struktur f\u00f6r rubriker<\/li>\n
    2. Dynamisk l\u00e4ngd. Det betyder att l\u00e4ngden p\u00e5 ramen inte \u00e4r fastst\u00e4llt h\u00e5rt, som det g\u00f6rs i telemetrin, utan kan \u00e4ndras beroende p\u00e5 de \u00f6verf\u00f6rda paketen.<\/li>\n
    3. Mekanism f\u00f6r att garantera paketleverans. Det vill s\u00e4ga att det ska bekr\u00e4ftas av KA efter mottagandet av korrektheten vid mottagandet av ramar, eller beg\u00e4ra omleverans fr\u00e5n den ram som kan ha mottagits med en of\u00f6rb\u00e4tterlig fel.<\/li>\n<\/ol>\n

      \n\"Lite
      \n
      \n\"Lite
      \n
      \nM\u00e5nga f\u00e4lt \u00e4r redan bekanta f\u00f6r oss fr\u00e5n rubriken f\u00f6r telemetrikadr. De har samma syfte, s\u00e5 h\u00e4r kommer vi att diskutera endast nya f\u00e4lt.<\/p>\n

      En bit av flaggan f\u00f6r omdirigering ska anv\u00e4ndas f\u00f6r att kontrollera ramverifieringen p\u00e5 mottagaren. V\u00e4rdet \"0\" f\u00f6r denna flagga ska indikera att denna ram \u00e4r av typ A och att dess verifiering ska genomf\u00f6ras enligt FARM. V\u00e4rdet \"1\" f\u00f6r denna flagga ska indikera f\u00f6r mottagaren att denna ram \u00e4r av typ B och ska kringg\u00e5 verifieringen enligt FARM.<\/p>\n

      Denna flagga informerar mottagaren om huruvida mekanismen f\u00f6r bekr\u00e4ftelse av ramleverans, kallad FARM \u2014 Frame Acceptance and Reporting Mechanism, ska anv\u00e4ndas.<\/i><\/p>\n

      Kontrollflaggans flagga ska anv\u00e4ndas f\u00f6r att f\u00f6rst\u00e5 om datapaketet transporterar ett kommando eller data. Om flaggan \u00e4r \"0\", ska datapaketet inneh\u00e5lla data. Om flaggan \u00e4r \"1\", ska datapaketet inneh\u00e5lla kontrollinformation f\u00f6r FARM.
      \nFARM \u00e4r en finit automat vars parametrar kan anpassas.<\/i><\/p>\n

      RSVD. SPARE \u2013 reserverade bitar.<\/p>\n

      Det verkar som om CCSDS har planer f\u00f6r dem i framtiden, och f\u00f6r att s\u00e4kerst\u00e4lla bak\u00e5tkompatibilitet har de redan reserverat dessa bitar i de nuvarande versionerna av standarden.<\/i><\/p>\n

      F\u00e4ltet f\u00f6r raml\u00e4ngd ska inneh\u00e5lla ett nummer i bitform som motsvarar l\u00e4ngden p\u00e5 ramen i oktetter minus ett.<\/p>\n

      Datapaketet efter ramen ska f\u00f6lja efter headern utan mellanrum och inneh\u00e5lla ett helt antal oktetter som maximalt kan vara 1019 oktetter. Detta f\u00e4lt ska inneh\u00e5lla antingen ett datapaket eller kontrollinformation. Datapaketet ska inneh\u00e5lla:<\/p>\n