Meteor M1 satellitt
Kilde: vladtime.ru
Innledning
Driften av romteknologi er umulig uten radiokommunikasjon, og i denne artikkelen vil jeg prøve å forklare hovedideene som lå til grunn for standardene utviklet av International Advisory Committee for Space Data Systems (CCSDS. Denne forkortelsen vil bli brukt nedenfor) .
Dette innlegget vil først og fremst fokusere på datalinklaget, men grunnleggende konsepter for andre lag vil også bli introdusert. Denne artikkelen gir seg på ingen måte ut til å være en grundig og fullstendig beskrivelse av standardene. Du kan se den på CCSDS. Imidlertid er de veldig vanskelige å forstå, og vi brukte mye tid på å prøve å forstå dem, så her vil jeg gi grunnleggende informasjon, som har som det vil være mye lettere å forstå alt annet. Så la oss begynne.
Noble Mission of CCSDS
Kanskje noen har et spørsmål: hvorfor skal alle følge standarder hvis du kan utvikle din egen proprietære radioprotokollstabel (eller din egen standard, med blackjack og nye funksjoner), og dermed øke sikkerheten til systemet?
Som praksis viser, er det mer lønnsomt å følge CCSDS-standarder av følgende årsaker:
- Komiteen som er ansvarlig for å publisere standardene inkluderer representanter fra alle store romfartsbyråer i verden, og bringer uvurderlig erfaring opparbeidet gjennom mange år med design og drift av ulike oppdrag. Det ville være veldig absurd å ignorere denne opplevelsen og tråkke på raken deres igjen.
- Disse standardene støttes av bakkestasjonsutstyr som allerede er på markedet.
- Når du feilsøker eventuelle problemer, kan du alltid søke hjelp fra kolleger fra andre byråer slik at de kan gjennomføre en kommunikasjonsøkt med enheten fra bakkestasjonen. Som du kan se, er standarder en ekstremt nyttig ting, så la oss se på hovedpunktene deres.
arkitektur
Standardene er et sett med dokumenter som gjenspeiler den vanligste OSI-modellen (Open System Interconnection), bortsett fra at på datalinknivå er fellesskapet begrenset til inndelingen i telemetri (nedlink - rom - jord) og telekommandoer (opplink).
La oss se på noen av nivåene mer detaljert, og starter med det fysiske og går oppover. For større klarhet vil vi vurdere arkitekturen til mottakersiden. Den som overfører er speilbildet.
Fysisk lag
På dette nivået konverteres det modulerte radiosignalet til en bitstrøm. Standardene her er hovedsakelig av rådgivende natur, siden det på dette nivået er vanskelig å abstrahere fra den spesifikke implementeringen av maskinvaren. Her er nøkkelrollen til CCSDS å definere de akseptable modulasjonene (BPSK, QPSK, 8-QAM, etc.) og gi noen anbefalinger om implementering av symbolsynkroniseringsmekanismer, Doppler-kompensasjon, etc.
Synkroniserings- og kodingsnivå
Formelt sett er det et underlag av datalinklaget, men er ofte separert i et eget lag på grunn av dets betydning innenfor CCSDS-standardene. Dette laget konverterer bitstrømmen til såkalte rammer (telemetri eller telekommandoer), som vi skal snakke om senere. I motsetning til symbolsynkronisering på det fysiske laget, som lar deg få riktig bitstrøm, utføres rammesynkronisering her. Tenk på banen data tar på dette nivået (fra bunn til topp):
Men før det er det verdt å si noen ord om koding. Denne prosedyren er nødvendig for å finne og/eller korrigere bitfeil som uunngåelig oppstår ved sending av data over en radiokanal. Her vil vi ikke vurdere dekodingsprosedyrer, men vil bare innhente informasjonen som er nødvendig for å forstå den videre logikken til nivået.
Koder kan være blokkerte eller kontinuerlige. Standardene tvinger ikke bruk av en bestemt type koding, men den må være til stede som sådan. Kontinuerlige koder inkluderer konvolusjonskoder. De brukes til å kode en kontinuerlig bitstrøm. Dette i motsetning til blokkkoder, hvor data er delt inn i kodeblokker og kun kan dekodes innenfor komplette blokker. Kodeblokken representerer de overførte dataene og den vedlagte redundante informasjonen som er nødvendig for å verifisere riktigheten av de mottatte dataene og korrigere mulige feil. Blokkkoder inkluderer de berømte Reed-Solomon-kodene.
Hvis konvolusjonskoding brukes, går bitstrømmen inn i dekoderen fra begynnelsen. Resultatet av arbeidet (alt dette skjer selvfølgelig kontinuerlig) er CADU (channel access data unit) datablokker. Denne strukturen er nødvendig for rammesynkronisering. På slutten av hver CADU er det en vedlagt synch maker (ASM). Dette er 4 byte kjent på forhånd, hvorved synkroniseringen finner begynnelsen og slutten av CADU. Dette er hvordan rammesynkronisering oppnås.
Det neste valgfrie trinnet i synkroniserings- og kodingslaget er assosiert med det fysiske lagets særegenheter. Dette er derandomisering. Faktum er at for å oppnå symbolsynkronisering, er hyppig veksling mellom symboler nødvendig. Så hvis vi overfører for eksempel en kilobyte med data som utelukkende består av enere, vil synkroniseringen gå tapt. Derfor, under overføring, blir inngangsdataene blandet med en periodisk pseudo-tilfeldig sekvens slik at tettheten av nuller og enere er jevn.
Deretter dekodes blokkkodene, og det som gjenstår er sluttproduktet av synkroniserings- og kodingsnivået - en ramme.
Datalinklag
På den ene siden mottar lenkelagsprosessoren rammer, og på den andre siden utsteder den pakker. Siden størrelsen på pakker ikke er formelt begrenset, for deres pålitelige overføring er det nødvendig å bryte dem ned i mindre strukturer - rammer. Her skal vi se på to underseksjoner: separat for telemetri (TM) og telekommandoer (TC).
Telemetri
Enkelt sagt er dette dataene som bakkestasjonen mottar fra romfartøyet. All overført informasjon er delt inn i små fragmenter med fast lengde - rammer som inneholder overførte data og tjenestefelt. La oss se nærmere på rammestrukturen:
Og la oss starte vår vurdering med hovedoverskriften til telemetrirammen. Videre vil jeg tillate meg å bare oversette standardene noen steder, og gi noen avklaringer underveis.
Master Channel ID-feltet må inneholde rammeversjonsnummeret og enhetsidentifikatoren.
Hvert romfartøy, i henhold til CCSDS-standarder, må ha sin egen unike identifikator, som, med en ramme, kan bestemme hvilken enhet den tilhører. Formelt er det nødvendig å sende inn en søknad for å registrere enheten, og navnet, sammen med identifikatoren, vil bli publisert i åpne kilder. Imidlertid ignorerer russiske produsenter ofte denne prosedyren, og tildeler en vilkårlig identifikator til enheten. Rammeversjonsnummeret hjelper til med å bestemme hvilken versjon av standardene som brukes for å kunne lese rammen korrekt. Her vil vi kun vurdere den mest konservative standarden med versjon "0".
Feltet Virtual Channel ID må inneholde VCID-en til kanalen som pakken kom fra. Det er ingen begrensninger på valg av VCID; Spesielt er virtuelle kanaler ikke nødvendigvis nummerert sekvensielt.
Svært ofte er det behov for å multiplekse overførte data. For dette formålet er det en mekanisme med virtuelle kanaler. For eksempel sender Meteor-M2-satellitten et fargebilde i det synlige området, og deler det inn i tre sorte og hvite - hver farge sendes i sin egen virtuelle kanal i en separat pakke, selv om det er noe avvik fra standardene i strukturen til rammene.
Driftskontrollflaggfeltet skal være en indikator på tilstedeværelse eller fravær av operasjonskontrollfeltet i telemetrirammen. Disse 4 bytene på slutten av rammen tjener til å gi tilbakemelding når du kontrollerer leveringen av telekommandorammer. Vi skal snakke om dem litt senere.
Hoved- og virtuelle kanalrammetellere er felt som økes med én hver gang en ramme sendes. Tjen som en indikator på at ikke en eneste ramme gikk tapt.
Telemetrirammedatastatusen er ytterligere to byte med flagg og data, som vi bare skal se på noen få.
Sekundær topptekstflaggfeltet må være en indikator på tilstedeværelse eller fravær av en sekundær topptekst i telemetrirammen.
Hvis du ønsker det, kan du legge til en ekstra overskrift til hver ramme og plassere eventuelle data der etter eget skjønn.
First Header Pointer-feltet, når synkroniseringsflagget er satt til "1", skal inneholde en binær representasjon av posisjonen til den første oktetten av den første pakken i datafeltet til telemetrirammen. Posisjonen telles fra 0 i stigende rekkefølge fra begynnelsen av datafeltet. Hvis det ikke er noen start på pakken i datafeltet til telemetrirammen, må pekeren til det første overskriftsfeltet ha verdien i binær representasjon "11111111111" (dette kan skje hvis en lang pakke er spredt over mer enn én ramme ).
Hvis datafeltet inneholder en tom pakke (Idle Data), skal pekeren til den første overskriften ha verdien i binær representasjon "11111111110". Ved å bruke dette feltet må mottakeren synkronisere strømmen. Dette feltet sørger for at synkroniseringen gjenopprettes selv om rammer droppes.
Det vil si at en pakke kan for eksempel starte i midten av den 4. rammen og slutte i begynnelsen av den 20. Dette feltet brukes til å finne begynnelsen. Pakker har også en overskrift som spesifiserer lengden, så når en peker til den første overskriften blir funnet, må lenkelagsprosessoren lese den, og dermed bestemme hvor pakken vil ende.
Hvis et feilkontrollfelt er tilstede, må det finnes i hver telemetriramme for en bestemt fysisk kanal gjennom hele oppdraget.
Dette feltet beregnes ved hjelp av CRC-metoden. Prosedyren må ta n-16 biter av telemetrirammen og sette inn resultatet av beregningen i de siste 16 bitene.
TV-team
TV-kommandorammen har flere betydelige forskjeller. Blant dem:
- Ulik overskriftsstruktur
- Dynamisk lengde. Dette betyr at rammelengden ikke stilles stivt, slik det gjøres i telemetri, men kan variere avhengig av de overførte pakkene.
- Pakkeleveringsgarantimekanisme. Det vil si at romfartøyet må, etter å ha mottatt det, bekrefte riktigheten av rammemottak, eller be om videresending fra en ramme som kunne blitt mottatt med en ukorrigerbar feil.
Mange felt er allerede kjent for oss fra telemetrirammeoverskriften. De har samme formål, så her vil vi kun vurdere de nye feltene.
Én bit av bypass-flagget må brukes til å kontrollere rammekontroll på mottakeren. En verdi på "0" for dette flagget skal indikere at rammen er en type A-ramme og må verifiseres i henhold til FARM. En verdi på "1" for dette flagget skal indikere for mottakeren at rammen er en type B-ramme og bør omgå FARM-kontroll.
Dette flagget informerer mottakeren om den skal bruke en rammeleveringsbekreftelsesmekanisme kalt FARM - Frame Acceptance and Reporting Mechanism.
Kontrollkommandoflagget må brukes for å forstå om datafeltet transporterer en kommando eller data. Hvis flagget er "0", må datafeltet inneholde data. Hvis flagget er "1", må datafeltet inneholde kontrollinformasjon for FARM.
FARM er en finite state-maskin hvis parametere kan konfigureres.
RSVD. SPARE – reserverte biter.
Det ser ut til at CCSDS har planer for dem i fremtiden, og for bakoverkompatibilitet av protokollversjoner har de reservert disse bitene allerede i gjeldende versjoner av standarden.
Rammelengdefeltet må inneholde et tall i bitrepresentasjon som er lik rammelengden i oktetter minus én.
Rammedatafeltet må følge overskriften uten mellomrom og inneholde et heltall av oktetter, som maksimalt kan være 1019 oktetter i lengde. Dette feltet må inneholde enten rammedatablokk eller kontrollkommandoinformasjon. Rammedatablokken må inneholde:
- heltall antall brukerdataoktetter
- segmentoverskrift etterfulgt av et heltall antall brukerdataoktetter
Hvis en header er til stede, må datablokken inneholde en pakke, et sett med pakker eller en del av en pakke. En datablokk uten overskrift kan ikke inneholde deler av pakker, men kan inneholde private formatdatablokker. Det følger av dette at en header er nødvendig når den overførte datablokken ikke passer inn i en ramme. En blokk med data som har en overskrift kalles et segment
To-bits flaggfeltet må inneholde:
- "01" - hvis den første delen av dataene er i datablokken
- "00" - hvis den midtre delen av dataene er i datablokken
- "10" - hvis den siste databiten er i datablokken
- "11" - hvis det ikke er noen divisjon og en eller flere pakker passer helt inn i datablokken.
MAP ID-feltet må inneholde nuller hvis MAP-kanaler ikke brukes.
Noen ganger er 6 bits allokert til virtuelle kanaler ikke nok. Og hvis det er nødvendig å multiplekse data på et større antall kanaler, brukes ytterligere 6 biter fra segmentoverskriften.
FARM
La oss se nærmere på funksjonsmekanismen til kontrollsystemet for personelllevering. Dette systemet sørger kun for arbeid med rammer av telekommandoer på grunn av deres betydning (telemetri kan alltid forespørres igjen, og romfartøyet må høre bakkestasjonen tydelig og alltid adlyde dens kommandoer). Så anta at vi bestemmer oss for å relashe satellitten vår og sende en binær fil på 10 kilobyte til den. På lenkenivå er filen delt inn i 10 rammer (0, 1, ..., 9), som sendes oppover en etter en. Når overføringen er fullført, må satellitten bekrefte riktigheten av pakkemottaket, eller rapportere om hvilken ramme feilen oppstod. Denne informasjonen sendes til det operasjonelle kontrollfeltet i nærmeste telemetriramme (Eller romfartøyet kan starte overføringen av en ledig ramme hvis det ikke har noe å si). Basert på den mottatte telemetrien forsikrer vi oss enten om at alt er i orden, eller vi fortsetter med å sende meldingen på nytt. La oss anta at satellitten ikke hørte ramme #7. Dette betyr at vi sender ham frames 7, 8, 9. Hvis det ikke er noe svar, sendes hele pakken på nytt (og så videre flere ganger til vi innser at forsøkene er forgjeves).
Nedenfor er strukturen til det operative kontrollfeltet med beskrivelse av noen felt. Dataene i dette feltet kalles CLCW - Communication Link Control Word.
Siden du enkelt kan gjette formålet med hovedfeltene fra bildet, og de andre er kjedelige å se på, skjuler jeg den detaljerte beskrivelsen under en spoiler
Forklaring av CLCW-feltKontrollordtype:
For denne typen må kontrollordet inneholde 0
Kontrollord-versjon (CLCW-versjonsnummer):
For denne typen må kontrollordet være lik "00" i bitrepresentasjonen.
Statusfelt:
Bruken av dette feltet bestemmes for hvert oppdrag separat. Kan brukes til lokale forbedringer av ulike rombyråer.
Virtuell kanalidentifikasjon:
Må inneholde identifikatoren til den virtuelle kanalen som dette kontrollordet er knyttet til.
Fysisk kanaltilgangsflagg:
Flagget skal gi informasjon om beredskapen til mottakerens fysiske lag. Hvis det fysiske laget til mottakeren ikke er klart til å motta rammer, må feltet inneholde "1", ellers "0".
Synkroniseringsfeilflagg:
Flagget kan indikere at det fysiske laget opererer på et dårlig signalnivå og antallet avviste rammer er for høyt. Bruken av dette feltet er valgfritt; hvis det brukes, må det inneholde "0" hvis synkronisering er tilgjengelig, og "1" hvis det ikke er det.
Blokkerende flagg:
Denne biten skal inneholde FARM-låsstatus for hver virtuell kanal. En verdi på "1" i dette feltet skal indikere at FARM er deaktivert og rammer vil bli forkastet for hvert virtuelle lag, ellers "0".
Vent flagg:
Denne biten skal brukes til å indikere at mottakeren ikke kan behandle data på den angitte virtuelle kanalen. En verdi på "1" indikerer at alle rammer vil bli forkastet på denne virtuelle kanalen, ellers "0".
Videresend flagg:
Dette flagget skal inneholde en "1" hvis en eller flere type A-rammer har blitt forkastet eller hull er funnet, så omsending er nødvendig. "0"-flagget indikerer at det ikke var noen droppede rammer eller hopp.
Responsverdi:
Rammenummer som ikke ble mottatt. Bestemmes av telleren i telekommando-rammeoverskriften
nettverkslaget
La oss berøre dette nivået litt. Det er to alternativer her: enten bruk rompakkeprotokollen, eller kapsle inn en hvilken som helst annen protokoll i CCSDS-pakken.
En oversikt over rompakkeprotokollen er et tema for en egen artikkel. Den er designet for å tillate såkalte applikasjoner å sømløst utveksle data. Hver applikasjon har sin egen adresse og grunnleggende funksjonalitet for utveksling av data med andre applikasjoner. Det finnes også tjenester som ruter trafikk, kontrollerer levering m.m.
Med innkapsling er alt enklere og klarere. Standardene gjør det mulig å kapsle inn alle protokoller i CCSDS-pakker ved å legge til en ekstra header.
Hvor overskriften har forskjellige betydninger avhengig av lengden på protokollen som er innkapslet:
Her er hovedfeltet lengden på lengden. Det kan variere fra 0 til 4 byte. Også i denne overskriften må du angi typen innkapslet protokoll ved hjelp av tabellen .
IP-innkapsling bruker et annet tillegg for å bestemme pakketypen.
Du må legge til en overskrift til, en oktett lang:
Der PID er en annen protokollidentifikator tatt
Konklusjon
Ved første øyekast kan det virke som om CCSDS-overskriftene er ekstremt overflødige og enkelte felt kan bli forkastet. Faktisk er effektiviteten til den resulterende kanalen (opp til nettverksnivået) omtrent 40%. Men så snart behovet oppstår for å implementere disse standardene, blir det klart at hvert felt, hver overskrift har sitt eget viktige oppdrag, og ignorerer noe som fører til en rekke uklarheter.
Hvis habrasamfunnet viser interesse for dette emnet, vil jeg gjerne publisere en hel serie artikler viet teori og praksis for romkommunikasjon. Takk for din oppmerksomhet!
kilder
PS
Ikke slå for hardt hvis du finner noen unøyaktigheter. Gi beskjed og de blir fikset :)
Kilde: www.habr.com