Meteor M1 satellit
Kilde: vladtime.ru
Indledning
Driften af rumteknologi er umulig uden radiokommunikation, og i denne artikel vil jeg forsøge at forklare de hovedideer, der dannede grundlaget for standarderne udviklet af International Advisory Committee for Space Data Systems (CCSDS. Denne forkortelse vil blive brugt nedenfor) .
Dette indlæg vil primært fokusere på datalinklaget, men grundlæggende koncepter for andre lag vil også blive introduceret. Denne artikel foregiver på ingen måde at være en grundig og fuldstændig beskrivelse af standarderne. Du kan se den på CCSDS. De er dog meget svære at forstå, og vi brugte meget tid på at forsøge at forstå dem, så her vil jeg gerne give grundlæggende information, hvorved det vil være meget lettere at forstå alt andet. Så lad os begynde.
CCSDS Noble Mission
Måske har nogen et spørgsmål: hvorfor skulle alle overholde standarder, hvis du kan udvikle din egen proprietære radioprotokolstak (eller din egen standard med blackjack og nye funktioner), og derved øge systemets sikkerhed?
Som praksis viser, er det mere rentabelt at overholde CCSDS-standarder af følgende årsager:
- Det udvalg, der er ansvarligt for at offentliggøre standarderne, omfatter repræsentanter fra alle større luft- og rumfartsagenturer i verden, hvilket bringer uvurderlig erfaring opnået gennem mange års design og drift af forskellige missioner. Det ville være meget absurd at ignorere denne oplevelse og træde på deres rake igen.
- Disse standarder understøttes af jordstationsudstyr, der allerede er på markedet.
- Ved fejlfinding af eventuelle problemer kan du altid søge hjælp fra kolleger fra andre bureauer, så de kan gennemføre en kommunikationssession med enheden fra deres jordstation. Som du kan se, er standarder en yderst nyttig ting, så lad os se på deres nøglepunkter.
arkitektur
Standarderne er et sæt dokumenter, der afspejler den mest almindelige OSI-model (Open System Interconnection), bortset fra at på datalink-niveauet er fællestrækket begrænset til opdelingen i telemetri (downlink - rum - Earth) og telekommandoer (uplink).
Lad os se på nogle af niveauerne mere detaljeret, begyndende med det fysiske og rykke op. For større klarhed vil vi overveje arkitekturen på den modtagende side. Den transmitterende er dens spejlbillede.
Fysisk lag
På dette niveau konverteres det modulerede radiosignal til en bitstrøm. Standarderne her er hovedsageligt af rådgivende karakter, da det på dette niveau er svært at abstrahere fra den specifikke implementering af hardwaren. Her er nøglerollen for CCSDS at definere de acceptable modulationer (BPSK, QPSK, 8-QAM osv.) og give nogle anbefalinger om implementering af symbolsynkroniseringsmekanismer, Doppler-kompensation osv.
Synkroniserings- og kodningsniveau
Formelt er det et underlag af datalinklaget, men er ofte adskilt i et separat lag på grund af dets betydning inden for CCSDS-standarderne. Dette lag konverterer bitstrømmen til såkaldte frames (telemetri eller telekommandoer), som vi vil tale om senere. I modsætning til symbolsynkronisering på det fysiske lag, som giver dig mulighed for at opnå den korrekte bitstrøm, udføres rammesynkronisering her. Overvej den vej, som data tager på dette niveau (fra bund til top):
Før det er det dog 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, når der sendes data over en radiokanal. Her vil vi ikke overveje afkodningsprocedurer, men vil kun indhente den information, der er nødvendig for at forstå niveauets videre logik.
Koder kan være blokerede eller kontinuerlige. Standarderne tvinger ikke brugen af en bestemt type kodning, men den skal være til stede som sådan. Kontinuerlige koder inkluderer foldningskoder. De bruges til at kode en kontinuerlig bitstrøm. Dette er i modsætning til blokkoder, hvor data er opdelt i kodeblokke og kun kan afkodes inden for komplette blokke. Kodeblokken repræsenterer de transmitterede data og den vedhæftede redundante information, der er nødvendig for at verificere rigtigheden af de modtagne data og rette mulige fejl. Blokkoder inkluderer de berømte Reed-Solomon-koder.
Hvis der anvendes foldningskodning, kommer bitstrømmen ind i dekoderen fra begyndelsen. Resultatet af dets arbejde (alt dette sker selvfølgelig kontinuerligt) er CADU (channel access data unit) datablokke. Denne struktur er nødvendig for rammesynkronisering. For enden af hver CADU er der en tilknyttet synch maker (ASM). Disse er 4 bytes kendt på forhånd, hvormed synkroniseringen finder begyndelsen og slutningen af CADU. Sådan opnås rammesynkronisering.
Det næste valgfrie trin i synkroniserings- og kodningslaget er forbundet med det fysiske lags særegenheder. Dette er derandomisering. Faktum er, at for at opnå symbolsynkronisering er hyppig skift mellem symboler nødvendig. Så hvis vi sender f.eks. en kilobyte data, der udelukkende består af enere, vil synkronisering gå tabt. Derfor blandes inputdataene under transmissionen med en periodisk pseudo-tilfældig sekvens, således at tætheden af nuller og ettaller er ensartet.
Dernæst afkodes blokkoderne, og tilbage er slutproduktet af synkroniserings- og kodningsniveauet - en ramme.
Data Link Layer
På den ene side modtager linklagsprocessoren frames, og på den anden side udsteder den pakker. Da størrelsen af pakker ikke er formelt begrænset, er det for deres pålidelige transmission nødvendigt at opdele dem i mindre strukturer - rammer. Her vil vi se på to underafsnit: separat for telemetri (TM) og telekommandoer (TC).
Telemetri
Kort sagt er dette de data, som jordstationen modtager fra rumfartøjet. Al transmitteret information er opdelt i små fragmenter af en fast længde - rammer, der indeholder transmitterede data og servicefelter. Lad os se nærmere på rammestrukturen:
Og lad os starte vores overvejelse med hovedhovedet for telemetrirammen. Yderligere vil jeg tillade mig blot at oversætte standarderne nogle steder og give nogle præciseringer undervejs.
Feltet Master Channel ID skal indeholde rammeversionsnummeret og enhedsidentifikatoren.
Hvert rumfartøj skal ifølge CCSDS-standarder have sin egen unikke identifikator, hvorved man, med en ramme, kan bestemme, hvilken enhed den tilhører. Formelt er det nødvendigt at indsende en ansøgning om at registrere enheden, og dens navn, sammen med dens identifikator, vil blive offentliggjort i åbne kilder. Russiske producenter ignorerer dog ofte denne procedure og tildeler en vilkårlig identifikator til enheden. Rammens versionsnummer hjælper med at bestemme, hvilken version af standarderne der bruges til at læse rammen korrekt. Her vil vi kun overveje den mest konservative standard med version "0".
Feltet Virtual Channel ID skal indeholde VCID'et for den kanal, hvorfra pakken kom. Der er ingen begrænsninger for valget af VCID; især er virtuelle kanaler ikke nødvendigvis nummereret sekventielt.
Meget ofte er der behov for at multiplekse overførte data. Til dette formål er der en mekanisme med virtuelle kanaler. For eksempel transmitterer Meteor-M2-satellitten et farvebillede i det synlige område og opdeler det i tre sorte og hvide - hver farve transmitteres i sin egen virtuelle kanal i en separat pakke, selvom der er en vis afvigelse fra standarderne i strukturen af dens rammer.
Operational Control-flagfeltet skal være en indikator for tilstedeværelsen eller fraværet af Operational Control-feltet i telemetrirammen. Disse 4 bytes i slutningen af rammen tjener til at give feedback ved styring af leveringen af telekommando-rammer. Vi taler om dem lidt senere.
Hoved- og virtuelle kanalrammetællere er felter, der øges med én, hver gang en ramme sendes. Tjen som en indikator for, at ikke en enkelt ramme gik tabt.
Telemetrirammedatastatus er yderligere to bytes af flag og data, hvoraf vi kun vil se på nogle få.
Flagfeltet Sekundær Header skal være en indikator for tilstedeværelsen eller fraværet af en Sekundær Header i telemetrirammen.
Hvis du ønsker det, kan du tilføje en ekstra header til hver ramme og placere alle data der efter eget skøn.
First Header Pointer-feltet, når synkroniseringsflaget er sat til "1", skal indeholde en binær repræsentation af positionen af den første oktet af den første pakke i datafeltet i telemetrirammen. Positionen tælles fra 0 i stigende rækkefølge fra begyndelsen af datafeltet. Hvis der ikke er nogen start på pakken i telemetrirammens datafelt, så skal markøren til det første headerfelt have værdien i binær repræsentation "11111111111" (dette kan ske, hvis en lang pakke er spredt over mere end én frame ).
Hvis datafeltet indeholder en tom pakke (Idle Data), så skal markøren til den første header have værdien i binær repræsentation "11111111110". Ved at bruge dette felt skal modtageren synkronisere streamen. Dette felt sikrer, at synkroniseringen gendannes, selvom frames droppes.
Det vil sige, at en pakke for eksempel kan starte i midten af 4. frame og slutte i begyndelsen af den 20.. Dette felt bruges til at finde sin begyndelse. Pakker har også en header, der specificerer dens længde, så når en pointer til den første header er fundet, skal link-layer-processoren læse den og derved bestemme, hvor pakken ender.
Hvis et fejlkontrolfelt er til stede, skal det være indeholdt i hver telemetriramme for en bestemt fysisk kanal under hele missionen.
Dette felt beregnes ved hjælp af CRC-metoden. Proceduren skal tage n-16 bit af telemetrirammen og indsætte resultatet af beregningen i de sidste 16 bit.
TV-hold
TV-kommandorammen har flere væsentlige forskelle. Blandt dem:
- Forskellig overskriftsstruktur
- Dynamisk længde. Det betyder, at framelængden ikke er fast indstillet, som man gør i telemetri, men kan variere afhængigt af de transmitterede pakker.
- Pakkeleveringsgarantimekanisme. Det vil sige, at rumfartøjet, efter at have modtaget det, skal bekræfte rigtigheden af rammemodtagelsen, eller anmode om videresendelse fra en ramme, der kunne være modtaget med en ukorrigerbar fejl.
Mange felter kender os allerede fra telemetrirammehovedet. De har samme formål, så her vil vi kun overveje de nye felter.
En bit af bypass-flaget skal bruges til at kontrollere rammekontrol ved modtageren. En værdi på "0" for dette flag skal indikere, at rammen er en type A-ramme og skal verificeres i henhold til FARM. En værdi på "1" for dette flag bør indikere over for modtageren, at denne ramme er en type B-ramme og bør omgå FARM-kontrol.
Dette flag informerer modtageren om, hvorvidt der skal bruges en rammeleveringsbekræftelsesmekanisme kaldet FARM - Frame Acceptance and Reporting Mechanism.
Kontrolkommandoplaget skal bruges til at forstå, om datafeltet transporterer en kommando eller data. Hvis flaget er "0", skal datafeltet indeholde data. Hvis flaget er "1", skal datafeltet indeholde kontrolinformation for FARM.
FARM er en finite state-maskine, hvis parametre kan konfigureres.
RSVD. SPAR - reserverede bits.
Det ser ud til, at CCSDS har planer for dem i fremtiden, og for bagudkompatibilitet af protokolversioner har de reserveret disse bits allerede i nuværende versioner af standarden.
Rammelængdefeltet skal indeholde et tal i bitrepræsentation, der er lig med rammelængden i oktetter minus en.
Rammedatafeltet skal følge overskriften uden mellemrum og indeholde et helt antal oktetter, som maksimalt kan være 1019 oktetter i længden. Dette felt skal indeholde enten rammedatablok eller kontrolkommandoinformation. Rammedatablokken skal indeholde:
- heltal antal brugerdataoktetter
- segmentoverskrift efterfulgt af et helt antal brugerdataoktetter
Hvis en header er til stede, skal datablokken indeholde en pakke, et sæt pakker eller en del af en pakke. En datablok uden en header kan ikke indeholde dele af pakker, men kan indeholde private formatdatablokke. Det følger heraf, at der kræves en header, når den transmitterede datablok ikke passer ind i én ramme. En datablok, der har en header, kaldes et segment
To-bit flagfeltet skal indeholde:
- "01" - hvis den første del af data er i datablokken
- "00" - hvis den midterste del af data er i datablokken
- "10" - hvis det sidste stykke data er i datablokken
- "11" - hvis der ikke er nogen opdeling, og en eller flere pakker passer helt ind i datablokken.
MAP ID-feltet skal indeholde nuller, hvis der ikke bruges MAP-kanaler.
Nogle gange er 6 bit allokeret til virtuelle kanaler ikke nok. Og hvis det er nødvendigt at multiplekse data på et større antal kanaler, bruges yderligere 6 bits fra segmentheaderen.
FARM
Lad os se nærmere på funktionsmekanismen for personaleleveringskontrolsystemet. Dette system giver kun mulighed for at arbejde med rammer af telekommandoer på grund af deres betydning (telemetri kan altid anmodes om igen, og rumfartøjet skal høre jordstationen klart og altid adlyde dens kommandoer). Så antag, at vi beslutter os for at relashe vores satellit og sende en binær fil på 10 kilobytes til den. På linkniveau er filen opdelt i 10 frames (0, 1, ..., 9), som sendes opad én efter én. Når transmissionen er afsluttet, skal satellitten bekræfte rigtigheden af pakkemodtagelsen, eller rapportere om hvilken frame fejlen opstod. Denne information sendes til det operationelle kontrolfelt i den nærmeste telemetriramme (eller rumfartøjet kan starte transmissionen af en ledig ramme, hvis det ikke har noget at sige). Baseret på den modtagne telemetri sørger vi enten for, at alt er i orden, eller vi fortsætter med at sende beskeden igen. Lad os antage, at satellitten ikke hørte ramme #7. Det betyder, at vi sender ham frames 7, 8, 9. Hvis der ikke er noget svar, sendes hele pakken igen (og så videre flere gange, indtil vi indser, at forsøgene er forgæves).
Nedenfor er strukturen af det operationelle kontrolfelt med en beskrivelse af nogle felter. Dataene i dette felt kaldes CLCW - Communication Link Control Word.
Da du nemt kan gætte formålet med hovedfelterne ud fra billedet, og de andre er kedelige at se på, gemmer jeg den detaljerede beskrivelse under en spoiler
Forklaring af CLCW-felterKontrolordstype:
For denne type skal styreordet indeholde 0
Kontrolord-version (CLCW-versionsnummer):
For denne type skal styreordet være lig med "00" i bitrepræsentationen.
Statusfelt:
Brugen af dette felt bestemmes for hver mission separat. Kan bruges til lokale forbedringer af forskellige rumbureauer.
Virtuel kanalidentifikation:
Skal indeholde identifikatoren for den virtuelle kanal, som dette styreord er knyttet til.
Fysisk kanaladgangsflag:
Flaget skal give information om beredskabet af modtagerens fysiske lag. Hvis modtagerens fysiske lag ikke er klar til at modtage frames, skal feltet indeholde "1", ellers "0".
Synkroniseringsfejl flag:
Flaget kan indikere, at det fysiske lag fungerer på et dårligt signalniveau, og at antallet af afviste frames er for højt. Brugen af dette felt er valgfrit; hvis det bruges, skal det indeholde "0", hvis synkronisering er tilgængelig, og "1", hvis det ikke er det.
Blokerende flag:
Denne bit skal indeholde FARM-låsestatus for hver virtuel kanal. En værdi på "1" i dette felt skulle indikere, at FARM er deaktiveret, og rammer vil blive kasseret for hvert virtuelt lag, ellers "0".
Vent flag:
Denne bit skal bruges til at indikere, at modtageren ikke kan behandle data på den specificerede virtuelle kanal. En værdi på "1" angiver, at alle frames vil blive kasseret på denne virtuelle kanal, ellers "0".
Videresend flag:
Dette flag skal indeholde et "1", hvis en eller flere type A-rammer er blevet kasseret, eller der er fundet huller, så gensending er nødvendig. "0"-flaget angiver, at der ikke var nogen tabte rammer eller overspringninger.
Svarværdi:
Rammenummer, der ikke blev modtaget. Bestemt af tælleren i telekommando-rammeoverskriften
netværkslag
Lad os berøre dette niveau lidt. Der er to muligheder her: enten brug rumpakkeprotokollen, eller indkapsl enhver anden protokol i CCSDS-pakken.
En oversigt over rumpakkeprotokollen er et emne for en separat artikel. Det er designet til at give såkaldte applikationer mulighed for problemfrit at udveksle data. Hver applikation har sin egen adresse og grundlæggende funktionalitet til udveksling af data med andre applikationer. Der er også tjenester, der dirigerer trafik, kontrollerer levering mv.
Med indkapsling er alt enklere og klarere. Standarderne gør det muligt at indkapsle alle protokoller i CCSDS-pakker ved at tilføje en ekstra header.
Hvor overskriften har forskellige betydninger afhængigt af længden af protokollen, der indkapsles:
Her er hovedfeltet længden af længden. Det kan variere fra 0 til 4 bytes. Også i denne overskrift skal du angive typen af indkapslet protokol ved hjælp af tabellen .
IP-indkapsling bruger en anden tilføjelse til at bestemme typen af pakke.
Du skal tilføje en overskrift mere, en oktet lang:
Hvor PID er en anden protokolidentifikation taget
Konklusion
Ved første øjekast kan det se ud til, at CCSDS-headerne er ekstremt overflødige, og nogle felter kan blive kasseret. Faktisk er effektiviteten af den resulterende kanal (op til netværksniveau) omkring 40%. Men så snart behovet opstår for at implementere disse standarder, bliver det klart, at hvert felt, hver overskrift har sin egen vigtige mission, idet man ignorerer, hvilket fører til en række uklarheder.
Hvis habrasamfundet viser interesse for dette emne, vil jeg med glæde udgive en hel række artikler om teori og praksis for rumkommunikation. Tak for din opmærksomhed!
kilder
PS
Slå ikke for hårdt, hvis du finder nogle unøjagtigheder. Meld dem og de vil blive rettet :)
Kilde: www.habr.com