🥇Lidt om standarder for rumkommunikation

Meteor M1 Satellit
Kilde: vladtime.ru

Introduktion

Drift af rummeteknologi er umulig uden radiokommunikation, og i denne artikel vil jeg forsøge at forklare de grundlæggende ideer, der ligger til grund for standarderne udviklet af den Internationale Rådgivende Komité for Rumdataoverførselssystemer (Consultative Committee for Space Data Systems – CCSDS. Denne forkortelse vil blive brugt fremover).

Denne publikation vil primært fokusere på det kanalniveau, men der vil også blive introduceret grundlæggende begreber for de andre niveauer. Artiklen har ikke ambitioner om en udtømmende og fuldstændig beskrivelse af standarderne. Du kan finde dem på websitet CCSDS. Men de er meget svære at forstå, og for at finde ud af dem har vi brugt en hel del tid, derfor vil jeg her give basal information, som gør det meget lettere at forstå det øvrige. Så lad os begynde.

Den ædle mission CCSDS

Måske har nogen spurgt: hvorfor skal alle følge standarder, hvis man kan udvikle sin egen proprietære protokolstak til radiokommunikation (eller sin egen standard, med blackjack og nye funktioner), hvilket dermed vil øge systemets sikkerhed?

Praksis viser, at det er mere fordelagtigt at følge CCSDS-standarderne af følgende grunde:

I komitéen, der er ansvarlig for offentliggørelsen af standarder, indgår repræsentanter fra alle de store rumfartsorganisationer i verden, som bringer deres uvurderlige erfaringer fra mange års design og drift af forskellige missioner. Det ville være meget absurd at ignorere denne erfaring og træde ind i de samme fælder igen.
Disse standarder understøttes af alt det eksisterende udstyr til jorden.
Under fejlfinding kan man altid henvende sig til kolleger fra andre agenturer, så de kan gennemføre en kommunikationssession med apparatet fra deres jordstation. Som du kan se, er standarder ekstremt nyttige, så lad os se på deres nøglepunkter.

Arkitektur

Standarderne udgør et sæt dokumenter, der afspejler den meget almindelige OSI-model (Open System Interconnection), bortset fra at fællesskabet på kanalniveau er begrænset til opdelingen mellem telemetri (nedadgående kanal — rum – Jorden) og telekommandoer (opadgående kanal).

Lad os se nærmere på nogle niveauer, startende med det fysiske og bevæge os opad. For større klarhed vil vi overveje arkitekturen på modtagersiden. Den overførende repræsenterer dens spejlvendte billede.

Fysisk niveau

På dette niveau finder omdannelsen af den modulerede radiosignal til en bitstrøm sted. Standarderne her er hovedsageligt anbefalende, da det er svært at abstrahere fra den specifikke hardwareimplementering på dette niveau. Her spiller CCSDS en nøgle 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.

Synkroniserings- og kodningsniveauet

Formelt set er det et underniveau af datalink niveauet, men det fremhæves ofte som et selvstændigt niveau på grund af dets betydning inden for CCSDS-standarderne. Dette niveau konverterer bitstrømmen til såkaldte rammer (telemetri eller telekommandoer), som vi senere vil tale om. I modsætning til symbolsynkronisering på det fysiske niveau, som muliggør korrekt bitstrøm, udføres der på dette niveau rammesynkronisering. Lad os se på den vej, som dataene passerer på dette niveau (nedenfra og op):

Men før dette er det værd at sige et par ord om kodning. Denne procedure er nødvendig for at finde og/eller rette bitfejl, der uundgåeligt opstår ved overførsel af data via radiokanalen. Her vil vi ikke overveje dekodingsprocedurer, men blot få oplysninger, der er nødvendige for at forstå den videre logik i niveauets funktion.

Koderne kan være blok- og kontinuerlige. Standarderne tvinger ikke brugen af en specifik type kodning, men den skal som sådan være til stede. Kontinuerlige koder inkluderer konvolutionelle koder. Med dem kodes en kontinuerlig bitstrøm. I modsætning til blokkoder, hvor data opdeles i kodeblokke og kun kan dekodes inden for hele blokke. En kodeblok repræsenterer de overførte data og den tilknyttede redundante information, der er nødvendig for at kontrollere korrekt modtagelse af dataene og rette eventuelle fejl. De berømte Reed-Solomon-koder hører til blokkodernes kategori.

Hvis der anvendes konvolutionel kodning, sendes bitstrømmen fra starten til dekoderen. Resultatet af dens arbejde (det sker naturligvis kontinuerligt) bliver blokke af CADU (channel access data unit). Denne struktur er nødvendig for rammesynkronisering. I slutningen af hver CADU er der tilknyttet en synkroniseringsmarkør (ASM – attached synch marker). Dette er forudkendte 4 bytes, som synkronisatoren bruger til at finde begyndelsen og slutningen af CADU. På denne måde opnås rammesynkronisering.

Det næste 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å symbolsynkronisering er hyppige skift mellem symboler nødvendige. Så hvis vi f.eks. skal overføre en kilobyte data bestående udelukkende af ét-tal, vil synkroniseringen gå tabt. Derfor blandes inputdataene under overførslen med en periodisk pseudorandom sekvens, så tætheden af nuller og ét-tal er jævn.

Dernæst finder dekodningen af blokke koder sted, og det, der er tilbage, bliver det endelige produkt af synkroniserings- og kodningsniveauet – en ramme.

Kanalniveau

På den ene side modtager kanalniveauets behandler rammer, og på den anden side udgiver den pakker. Eftersom pakkenes størrelse formelt ikke er begrænset, er det nødvendigt at opdele dem i mindre strukturer – rammer – for at sikre pålidelig transmission. Her vil vi se på to underafsnit: separat for telemetri (TM) og telekommandoer (TC).

Telemetri

Kort sagt er dette de data, som jorden station modtager fra rumfartøjet. Alle overførte oplysninger opdeles i små fragmenter af fast længde – rammer, der indeholder de overførte data og kontrolfelter. Lad os se nærmere på rammestrukturen:

Vi begynder vores gennemgang med hovedoverskriften for telemetrirammen. Derefter vil jeg tillade mig at oversætte standarderne flere steder, mens jeg giver nogle forklaringer.

Feltet for den primære kanalidentifikator (Master Channel ID) skal indeholde versionsnummeret på rammen og apparatets identifikator.

Hver KA skal, i henhold til CCSDS-standarderne, have sin egen unikke identifikator, som gør det muligt at bestemme, hvilken enhed det tilhører, når man har en ramme. Formelt skal der indgives en ansøgning om registrering af enheden, og dens navn sammen med identifikatoren vil blive offentliggjort i åbne kilder. Dog ignorerer russiske producenter ofte denne procedure og tildeler enheden en vilkårlig identifikator. Versionsnummeret på rammen hjælper med at bestemme, hvilken version af standarderne der anvendes, for korrekt at kunne læse rammen. Her vil vi kun se på den mest konservative standard med version "0".

I feltet for identifikatoren for den virtuelle kanal (Virtual Channel ID) skal VCID for den kanal, som pakken er modtaget fra, være indeholdt. Der er ingen begrænsninger for valget af VCID, og de virtuelle kanaler behøver ikke at blive nummereret sekventielt.

Der opstår ofte behov for at multiplexere de data, der sendes. Der findes en mekanisme for virtuelle kanaler til dette formål. For eksempel sender satellitten Meteor-M2 farvebilleder i det synlige spektrum ved at opdele dem i tre sort-hvide billeder – 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.

Feltet for flaget Operational Control skal være en indikator for tilstedeværelsen eller fraværet 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.

Tællerne for rammerne i hoved- og virtuel kanal – er felter, der øges med én enhed ved hver afsendelse af en ramme. De fungerer som indikator for, at ingen rammer er gået tabt.

Status for data i telemetrirammen – er yderligere to byte flag og data, hvor vi kun vil se på nogle af dem.

Feltet for flaget for den sekundære header (Secondary Header) skal være en indikator for tilstedeværelsen eller fraværet af den sekundære header i telemetrirammen.

Hvis ønskes, kan man tilføje en sekundær header til hver ramme og placere enhver data der efter eget valg.

Indikatoren for den første headerpeger (First Header Pointer), når synkroniseringsflaget er "1", skal indeholde den binære repræsentation af positionen for det første oktet i det første paket i datadelen (Data Field) af telemetrikaden. Positionen tælles fra 0 i stigende rækkefølge fra begyndelsen af datadelen. Hvis der ikke er begyndelse på pakken i datadelen af telemetrikaden, skal headerpegeren have værdien i binær repræsentation "11111111111" (dette kan ske, hvis et langt paket strækker sig over mere end en kadre).

Hvis datadelen indeholder et tomt paket (Idle Data), skal pointeren til den første header have værdien i binær repræsentation "11111111110". Modtageren skal synkronisere strømmen baseret på dette felt. Dette felt sikrer genoprettelse af synkronisering selv i tilfælde af tabte kadrer.

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ålet. Pakker har også en header, hvor dens længde er angivet, så når pointeren til den første header findes, skal linklaget behandler den og derved bestemme, hvor pakken slutter.
Hvis fejlkontrolfeltet er til stede, skal det være indeholdt i hver telemetrikade for en bestemt fysisk kanal gennem hele missionen.

Dette felt beregnes ved hjælp af CRC-metoden. Proceduren skal tage n-16 bit telemetrikaden og indsætte resultatet af beregningen i de sidste 16 bit.

Telekommander

Telekommandkadre har flere væsentlige forskelle. Blandt dem:

En anden headerstruktur
Dynamisk længde. Det betyder, at længden af kadrer ikke er fastsat som i telemetri, men kan variere afhængigt af de transmitterede pakker.
Mekanismen for garanteret levering af pakker. Det vil sige, at KА skal bekræfte korrekt modtagelse af kadrer, efter modtagelse, eller anmode om at gensende fra den kadre, der muligvis er modtaget med en ukorrigerbar fejl.

Mange felter er allerede kendte for os fra telemetricaden header. De har det samme formål, så her vil vi kun se på de nye felter.

En bit af flaget for omgåelse skal bruges til at kontrollere modtagelsen af rammer hos modtageren. Værdien "0" af dette flag skal angive, at den pågældende ramme er af type A, og dens kontrol skal udføres i henhold til FARM. Værdien "1" af dette flag skal informere modtageren om, at den pågældende ramme er af type B og skal omgå kontrollen ifølge FARM.

Dette flag informerer modtageren om, hvorvidt mekanismen til bekræftelse af leveringen af rammer, kaldet FARM — Frame Acceptance and Reporting Mechanism, skal anvendes.

Kontrolkommandomerket skal bruges til at forstå, 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.
FARM er en endelig automat, hvis parametre kan konfigureres.

RSVD. SPARE – reserverede bits.

Det synes at CCSDS har planer for dem i fremtiden, og for tilbagekompatibiliteten af protokolversioner har de allerede reserveret disse bits i nuværende versioner af standarden.

Rammens længdefelt skal indeholde et tal i bitrepræsentation, som svarer til længden af rammen i oktetter minus én.

Datakildens felt skal følge efter overskriften uden mellemrum og indeholde et helt antal oktetter, som maksimalt kan være 1019 oktetter. Dette felt skal indeholde enten en blok af datarammer eller kontrolinformation. Datablokken skal indeholde:

et helt antal oktetter af brugerdata
segmentoverskriften efterfulgt af et helt antal oktetter af brugerdata

Hvis overskriften er til stede, skal datablokken indeholde en pakke, et sæt pakker eller en del af den. En datablok uden overskrift kan ikke indeholde dele af pakker, men kan indeholde datablokke af privat format. Det betyder, at overskriften kræves, når den overførte datablok ikke kan være i én ramme. En datablok, der har en overskrift, kaldes et segment.

Flagsfeltet på to bits skal indeholde:

"01" — hvis den første del af dataene er i datablokken
"00" — hvis den mellemste del af dataene er i datablokken
"10" — hvis den sidste del af dataene er i datablokken
«11» — hvis der ikke er deling, og i datablokken placeres en eller flere pakker helt.

Identifikationsfeltet MAP skal indeholde nuller, hvis MAP-kanaler ikke er i brug.
Nogle gange er 6 bit, der er afsat til virtuelle kanaler, ikke tilstrækkeligt. Hvis det er nødvendigt at multiplexere data på et større antal kanaler, bruges yderligere 6 bit fra segmentoverskriften.

FARM

Lad os se nærmere på mekanismen for, hvordan systemet til kontrol af dataoverførsel fungerer. Dette system er kun designet til at arbejde med telekommando-rammer på grund af deres vigtighed (telemetri kan altid anmodes om igen, men rumfartøjet skal tydeligt høre jordstationen og altid følge deres kommandoer). Lad os forestille os, at vi beslutter at genprogrammere vores satellit og sender en binær fil på 10 kilobyte til dens ombordcomputer. På kanaleniveau opdeles filen i 10 rammer (0, 1, …, 9), som sendes op af gangen. Når overførslen er afsluttet, skal rumfartøjet bekræfte korrekt modtagelse af pakken, eller informere om hvilken ramme der opstod en fejl i. Denne information sendes i kontrolfeltet i den nærmeste telemetriramme (eller rumfartøjet kan initiere overførslen af en tom ramme (idle frame), hvis det ikke har noget at sige). Baseret på den modtagne telemetri, bekræfter vi enten, at alt er i orden, eller vi går videre med at sende meddelelsen igen. Antag, at satellitten ikke hørte ramme nr. 7. Så sender vi rammerne 7, 8, 9 til den. Hvis der ikke kom noget svar, sendes pakken helt igen (og så videre flere gange, indtil vi forstår, at forsøgene er forgæves).

Nedenfor findes strukturen af kontrolfeltet med en beskrivelse af nogle felter. De data, der findes i dette felt, kaldes CLCW – Communication Link Control Word.

Da det er muligt at gætte formålene med de grundlæggende felter ud fra billedet, og det er kedeligt at se på de andre, gemmer jeg den detaljerede beskrivelse bag en spoiler.

Dekodning af CLCW-felterType kontrolord (Control Word Type):
For denne type kontrolord skal det indeholde 0.

Version af kontrolordet (CLCW Version Number):
For denne type kontrolord skal den være lig med «00» i bitrepræsentation.

Statusfelt (Status Field):
Brugen af dette felt bestemmes for hver mission individuelt. Det kan bruges til lokale forbedringer af forskellige rumfartsagenturer.

Identifikation af virtuel kanal (Virtual Channel Identification):
Skal indeholde identifikatoren for den virtuelle kanal, som dette kontrolord er knyttet til.

Adgangsflag for den fysiske kanal:
Flaget skal give information om, hvorvidt den fysiske modtager er klar. Hvis den fysiske modtager ikke er klar til at modtage rammer, skal feltet indeholde «1», ellers «0».

Synkroniseringsfejlflag:
Flaget kan indikere, at den fysiske niveau arbejder under dårlige signalforrhold, og antallet af afviste rammer er for højt. Anvendelse af dette felt er valgfrit; hvis det bruges, skal det indeholde «0» ved synkronisering og «1» ved mangel på synkronisering.

Låseflag:
Dette bit skal indeholde status for FARM-låsningen for hver virtuel kanal. Værdien «1» i dette felt skal angive, at FARM er låst, og rammer vil blive afvist for hver virtuel niveau, ellers «0».

Venteflag:
Dette bit skal bruges til at indikere, at modtageren ikke kan behandle dette på den angivne virtuelle kanal. Værdien «1» angiver, at alle rammer vil blive afvist på denne virtuelle kanal, ellers «0».

Genudsendelsesflag:
Dette flag skal indeholde «1», hvis en eller flere rammer af type A er blevet afvist eller der er fundet huller, hvorfor en genudsendelse er nødvendig. Flaget «0» indikerer, at der ikke er blevet afvist rammer eller huller.

Svarværdi:
Nummeret på den ramme, der ikke blev modtaget. Bestemt af tælleren i headeren af telecommandrammen.

Netværksniveau

Lad os kort berøre dette niveau. Der er to muligheder: enten at bruge rumpakkeprotokollen eller at indkapsle enhver anden protokol i en CCSDS-pakke.

Oversigt over rumpakkeprotokollen – et emne for en separat artikel. Den er designet til at muliggøre, at såkaldte applikationer kan udveksle data gnidningsløst. Hver applikation har sin egen adresse, samt grundlæggende funktioner til dataudveksling med andre applikationer. Der er også tjenester, der udfører trafikstyring, leveringsovervågning osv.

Indkapsling er enklere og mere forståeligt. Standarderne giver mulighed for at indkapsle enhver protokol i CCSDS-pakker ved at tilføje en ekstra header.

Hvor overskriften har forskellige betydninger afhængigt af længden af det indkapslede protokol:

Her er hovedfeltet – længden af længden. Den kan variere fra 0 til 4 byte. I denne overskrift er det også nødvendigt at angive typen af den indkapslede protokol ved hjælp af tabellen from here.

Ved indkapsling af IP bruges der endnu et lag for at bestemme typen af pakken.
Det er nødvendigt at tilføje endnu en overskrift, der er fra én oktet lang:

Hvor PID er endnu en protokolidentifikator taget from here

Konklusion

Ved første øjekast kan det se ud til, at CCSDS-overskrifterne er ekstremt overflødige, og nogle felter kunne være droppet. Faktisk er effektiviteten af den resulterende kanal (op til netværksniveau) omkring 40%. Men så snart der opstår et behov for at implementere disse standarder, bliver det klart, at hvert felt, hver overskrift har sin vigtige mission, hvis ignorering fører til en række tvetydigheder.

Hvis hub-samfundet viser interesse for dette emne, vil jeg være glad for at publicere en række artikler, der omhandler teorien og praksis inden for rumkommunikation. Tak for opmærksomheden!