🥇Lite om standarder för rymdkommunikation

Meteor Satellite M1
Källa: vladtime.ru

Introduktion

Användningen av rymdteknik är omöjlig utan radiokommunikation, och i denna artikel kommer jag att försöka förklara de grundläggande idéerna som ligger till grund för standarderna som utvecklats av det Internationella konsultativa kommittén för rymdsystem för datakommunikation (Consultative Committee for Space Data Systems – CCSDS. Förkortningen CCSDS kommer att användas härefter).

Denna publikation kommer främst att handla om kanalnivån, men grundläggande begrepp för andra nivåer kommer också att introduceras. Artikeln gör inget anspråk på att ge en fullständig och uttömmande beskrivning av standarderna. Du kan bekanta dig med dem på webbplats CCSDS. Men de är mycket svåra att förstå, och för att förstå dem har vi lagt ner en hel del tid, därför vill jag här ge grundläggande information som gör det mycket lättare att förstå allt annat. Så, låt oss börja.

Den ädla uppgiften CCSDS

Kanske har någon ställt sig frågan: varför ska alla hålla sig till standarder, när man kan utveckla sin egen proprietära protokollstack för radiokommunikation (eller sin egen standard, med blackjack och nya funktioner), vilket skulle öka systemets säkerhet?

Som erfarenhet visar är det fördelaktigare att följa CCSDS-standarder av följande skäl:

I kommittén som ansvarar för publiceringen av standarderna ingick representanter från alla stora rymdorganisationer i världen, som bidrog med sin ovärderliga erfarenhet från många års design och drift av olika uppdrag. Det skulle vara mycket dumt att ignorera denna erfarenhet och återigen trampa i samma fotspår.
Dessa standarder stöds av den redan existerande marknadsutrustningen för markstationer.
Vid felsökning kan man alltid be kollegor från andra organisationer om hjälp för att de ska genomföra en kommunikationssession med enheten från sin markstation. Som du ser är standarder en mycket användbar sak, så låt oss ta en närmare titt på deras viktigaste punkter.

Arkitektur

Standarderna utgör en samling dokument som återspeglar den vanliga OSI-modellen (Open System Interconnection), med undantag för att på kanalnivån begränsas gemensamheten till uppdelningen mellan telemetri (nedåtriktad kanal – rymd – jord) och telekommandon (uppåtriktad kanal).

Låt oss titta på vissa nivåer i mer detalj, börja med den fysiska och gå uppåt. För att göra det mer tydligt kommer vi att se på arkitekturen av mottagarsidan. Den överförande sidan utgör en spegelbild av den.

Fysisk nivå

På denna nivå sker omvandlingen av den modulering av radiosignalen till en bitström. Standarderna här är huvudsakligen vägledande, eftersom det är svårt att abstrahera från den specifika hårdvaruimplementationen. Här spelar CCSDS en nyckelroll – att definiera tillåtna moduler, såsom BPSK, QPSK, 8-QAM osv., och ge vissa rekommendationer om implementeringen av mekanismer för symbolsynkronisering, kompensering av Dopplerskift och liknande.

Synkroniserings- och kodningsnivå

Formellt sett är det ett delnivå inom kanalnivån, men det framhävs ofta som en egen nivå på grund av dess betydelse inom CCSDS-standarderna. Denna nivå omvandlar bitströmmen till så kallade ramar (telemetri eller telekommandon), som vi kommer att diskutera senare. Till skillnad från den symbolsynkronisering som sker på den fysiska nivån, vilken gör att vi får en korrekt bitström, utförs här ramsynkronisering. Låt oss titta på vägen som data passerar på denna nivå (nedifrån och upp):

Men innan vi gör det är det värt att nämna några ord om kodning. Denna procedur är nödvändig för att upptäcka och/eller korrigera bitfel som oundvikligen uppstår vid sändning av data över radiokanalen. Här kommer vi inte att diskutera avkodningsprocedurer, utan endast få information som är nödvändig för att förstå logiken i hur nivån fungerar framöver.

Koder kan vara block- eller kontinuerliga. Standarderna tvingar inte fram användning av en specifik typ av kodning, men den måste som sådan finnas. Kontinuerliga koder är konvolutionskoder. De används för att koda en kontinuerlig bitström. Till skillnad från blockkoder, där data delas upp i kodblock och kan bara dekodas inom hela block. Ett kodblock representerar de överförda data och den tillagda redundanta informationen som krävs för att kontrollera korrekt mottagande av data och rätta till eventuella fel. Bland blockkoderna finns de berömda Reed-Solomon-koderna.

Om konvolutionskodning används, kommer bitströmmen från början att gå till dekodern. Resultatet av dess arbete (allt detta sker förstås kontinuerligt) blir CADU-block (channel access data unit). Denna struktur är nödvändig för ram-synkronisering. I slutet av varje CADU kopplas en synkroniseringsmarkör (ASM – attached synch maker) till. Detta är fyra förutbestämda byte, vilket synkroniseraren använder för att hitta början och slutet av CADU. Så nås ram-synkronisering.

Det nästa valfria steget i synkroniserings- och kodningsnivån är kopplat till egenskaperna hos den fysiska nivån. Detta kallas derandomisering. Anledningen är att för att uppnå symbolsynkronisering krävs frekventa växlingar mellan symboler. Om vi till exempel skulle överföra ett kilobyte data som enbart består av ettor, skulle synkroniseringen gå förlorad. Därför blandas de inkommande data under överföringen med en periodisk pseudorandom sekvens för att fördela nollor och ettor jämnt.

Därefter sker avkodning av blockkoder, och det som återstår blir den slutliga produkten av synkronisering- och kodningsnivån – en ram.

Kanalnivå

Å ena sidan tar kanallagret emot ramar, och å andra sidan ger det ut paket. Eftersom paketens storlek formellt inte är begränsad, måste de delas upp i mindre strukturer – ramar – för att säkerställa pålitlig överföring. Här kommer vi att titta på två delavsnitt: en för telemetri (TM) och en för telekommandon (TC).

Telemetri

Enklare sagt, detta är de data som markstationen får från KAs. All överförd information delas upp i små fragment av fast längd – ramar, som innehåller de överförda data och hjälpkonton. Låt oss titta närmare på ramstrukturen:

Och vi börjar med huvudhuvudet av telemetriramen. Vid vissa tillfällen kommer jag att översätta standarderna, samtidigt som jag ger några förklaringar.

Fältet för identifiering av huvudkanalen (Master Channel ID) ska innehålla versionsnumret på ramen och identifieraren för enheten.

Varje KA, enligt CCSDS-standarder, måste ha sin egen unika identifierare som gör det möjligt att bestämma vilket instrument en given ram tillhör. Formellt måste en registreringsansökan för instrumentet lämnas in, och dess namn, tillsammans med identifieraren, kommer att publiceras i öppna källor. Dock ignorerar ofta ryska tillverkare denna procedur och tilldelar instrumentet en godtycklig identifierare. Versionsnumret på ramen hjälper till att bestämma vilken version av standarderna som används för att korrekt läsa ramen. Här kommer vi endast att behandla den mest konservativa standarden med version "0".

I fältet för identifieraren av den virtuella kanalen (Virtual Channel ID) ska VCID för den kanal från vilken paketet kom finnas. Det finns inga begränsningar för valet av VCID, och virtuella kanaler behöver inte nödvändigtvis numreras sekventiellt.

Det uppstår ofta ett behov av att multiplexa de överförda uppgifterna. För detta finns en mekanism för virtuella kanaler. Till exempel överför satelliten Meteor-M2 en färgbild i det synliga spektrumet, genom att dela den i tre svartvita - varje färg överförs i sin egen virtuella kanal som ett separat paket, även om det i strukturen av dess ramar finns vissa avvikelser från standarderna.

Fältet för flaggan för operativ kontroll ska vara en indikator på närvaron eller frånvaron av fältet för operativ kontroll i telemetriramen. Dessa 4 byte i slutet av ramen används för att upprätthålla återkoppling vid kontroll av leveransen av telekommandons ramar. Vi kommer att prata om dem lite senare.

Räknare för huvud- och virtuell kanal är fält som ökas med ett vid sändning av varje ram. De fungerar som en indikator på att ingen ram har gått förlorad.

Statusen för datan i telemetriramen består av ytterligare två byte av flaggor och data, av vilka vi endast kommer att granska några.

Fältet för flaggan för sekundär rubrik (Secondary Header) ska vara en indikator på närvaron eller frånvaron av en sekundär rubrik (Secondary Header) i telemetriramen.

Om så önskas kan en sekundär rubrik läggas till varje ram och där kan alla typer av data placeras efter eget val.

Fältet för pekare till första rubriken (First Header Pointer), när synkroniseringsflaggan är "1", ska innehålla den binära representationen av positionen för den första oktetten i det första paketet i datafältet (Data Field) för telemetrikadret. Positionen räknas från 0 i stigande ordning från början av datafältet. Om det inte finns något början på paketet i datafältet för telemetrikadret, ska pekaren till första rubriken ha värdet i binär representation "11111111111" (detta kan hända om ett långt paket sträcker sig över mer än en ram).

Om datafältet innehåller ett tomt paket (Idle Data), ska pekaren till första rubriken ha värdet i binär representation "11111111110". Genom detta fält ska mottagaren synkronisera strömmen. Detta fält garanterar återställning av synkronisering även om ramar missas.

Det vill säga att paketet kan, till exempel, börja i mitten av den 4:e ramen och sluta i början av den 20:e. För att hitta dess början används just detta fält. Paket har också en rubrik där dess längd anges, så när pekaren till första rubriken hittas, ska länknivåhanteraren läsa den, vilket på så sätt bestämmer var paketet slutar.
Om fältet för felkontroll är närvarande, ska det ingå i varje telemetrikadr för en viss fysisk kanal under hela uppdraget.

Detta fält beräknas genom att använda CRC-metoden. Proceduren ska ta n-16 bitar av telemetrikadr och infoga resultatet av beräkningen i de sista 16 bitarna.

Telekommandon

Telekommandots ram har flera betydande skillnader. Bland dem:

En annan struktur för rubriker
Dynamisk längd. Det betyder att längden på ramen inte är fastställt hårt, som det görs i telemetrin, utan kan ändras beroende på de överförda paketen.
Mekanism för att garantera paketleverans. Det vill säga att det ska bekräftas av KA efter mottagandet av korrektheten vid mottagandet av ramar, eller begära omleverans från den ram som kan ha mottagits med en oförbätterlig fel.

Många fält är redan bekanta för oss från rubriken för telemetrikadr. De har samma syfte, så här kommer vi att diskutera endast nya fält.

En bit av flaggan för omdirigering ska användas för att kontrollera ramverifieringen på mottagaren. Värdet "0" för denna flagga ska indikera att denna ram är av typ A och att dess verifiering ska genomföras enligt FARM. Värdet "1" för denna flagga ska indikera för mottagaren att denna ram är av typ B och ska kringgå verifieringen enligt FARM.

Denna flagga informerar mottagaren om huruvida mekanismen för bekräftelse av ramleverans, kallad FARM — Frame Acceptance and Reporting Mechanism, ska användas.

Kontrollflaggans flagga ska användas för att förstå om datapaketet transporterar ett kommando eller data. Om flaggan är "0", ska datapaketet innehålla data. Om flaggan är "1", ska datapaketet innehålla kontrollinformation för FARM.
FARM är en finit automat vars parametrar kan anpassas.

RSVD. SPARE – reserverade bitar.

Det verkar som om CCSDS har planer för dem i framtiden, och för att säkerställa bakåtkompatibilitet har de redan reserverat dessa bitar i de nuvarande versionerna av standarden.

Fältet för ramlängd ska innehålla ett nummer i bitform som motsvarar längden på ramen i oktetter minus ett.

Datapaketet efter ramen ska följa efter headern utan mellanrum och innehålla ett helt antal oktetter som maximalt kan vara 1019 oktetter. Detta fält ska innehålla antingen ett datapaket eller kontrollinformation. Datapaketet ska innehålla:

ett helt antal oktetter av användardata
segmentheadern och följande hela antal oktetter av användardata

Om headern är närvarande, ska datapaketet innehålla ett paket, en mängd paket eller en del av dem. Ett datapaket utan header kan inte innehålla delar av paket, men kan innehålla datapaket av privat format. Detta innebär att headern krävs när det överförda datapaketet inte får plats i en enda ram. Ett datapaket som har en header kallas ett segment.

Fältet för flaggor med två bitar ska innehålla:

"01" — om första delen av data finns i datapaketet
"00" — om den medelstora delen av data finns i datapaketet
"10" — om den sista delen av data finns i datapaketet
"11" — om det inte finns någon uppdelning och en eller flera paket placeras helt i datablocket.

MAP-ID-fältet ska innehålla nollor om MAP-kanaler inte används.
Ibland räcker inte 6 bitar som avsatts för virtuella kanaler. Om det är nödvändigt att multiplexera data på fler kanaler används ytterligare 6 bitar från segmenthuvudet.

FARM

Låt oss titta närmare på mekanismen för hur systemet för övervakning av ramleverans fungerar. Detta system är endast avsett att hantera telekommandon på grund av deras vikt (telemetri kan alltid begäras igen, men satelliten måste höra markstationen tydligt och alltid lyda dess kommandon). Anta att vi har beslutat att flasha om vår satellit och skickar en binär fil på 10 kilobyte till dess ombord. På länknivå delas filen upp i 10 ramar (0, 1, …, 9), som skickas upp en i taget. När överföringen är klar måste satelliten bekräfta att paketet mottagits korrekt, eller rapportera vilket ram som det inträffade ett fel på. Denna information skickas i fältet för operativ övervakning i den närmaste telemetriramen (eller så kan satelliten initiera överföring av en tom ram (idle frame) om den inte har något att säga). Baserat på den mottagna telemetrin antingen bekräftar vi att allt är bra, eller så går vi vidare med att omförsända meddelandet. Anta att satelliten inte hörde ram #7. Då skickar vi ram 7, 8 och 9. Om inget svar kommer skickas paketet om i sin helhet igen (och så vidare flera gånger, tills vi förstår att försöken varit fruktlösa).

Nedan presenteras strukturen för fältet för operativ övervakning med beskrivning av vissa fält. Data som ingår i detta fält kallas CLCW – Communication Link Control Word.

Eftersom man ganska lätt kan gissa syftet med de grundläggande fälten från bilden och andra är tråkiga att titta på, döljer jag den detaljerade beskrivningen bakom en spoiler.

Dekryptering av CLCW-fältTyp av kontrollord (Control Word Type):
För denna typ av kontrollord måste det innehålla 0.

Versionsnummer för kontrollord (CLCW Version Number):
För denna typ av kontrollord ska det vara "00" i bitsystemet.

Statusfält (Status Field):
Användningen av detta fält definieras separat för varje uppdrag. Det kan användas för lokala förbättringar av olika rymdbyråer.

Identifikator för virtuell kanal (Virtual Channel Identification):
Måste innehålla identifieraren för den virtuella kanal som detta kontrollord är kopplat till.

Åtkomstflagga för den fysiska kanalen:
Flaggan ska ge information om den fysiska nivån hos mottagaren är redo. Om den fysiska nivån hos mottagaren inte är redo att ta emot paket ska fältet innehålla "1", annars "0".

Synkroniseringsfel-flagga:
Flaggan kan indikera att den fysiska nivån fungerar vid dålig signalstyrka och antalet avvisade paket är för högt. Användning av detta fält är valfritt, om det används bör det innehålla "0" vid synkronisering och "1" vid avsaknad av synkronisering.

Blockeringsflagga:
Denna bit ska innehålla status för FARM-blockeringen för varje virtuell kanal. Värdet "1" i detta fält ska indikera att FARM är blockerat och att paket kommer att avvisas för varje virtuell nivå, annars "0".

Väntande flagga:
Denna bit ska användas för att indikera att mottagaren inte kan bearbeta detta på den angivna virtuella kanalen. Värdet "1" innebär att alla paket kommer att avvisas på denna virtuella kanal, annars "0".

Ompekarflagga:
Denna flagga ska innehålla "1" om ett eller flera paket av typ A har avvisats eller om det har upptäckts förluster, vilket innebär att ompekning är nödvändig. Flaggan "0" indikerar att det inte har funnits några avvisade paket eller förluster.

Svarsvärde:
Numret på paketet som inte mottogs. Bestäms av räknaren i paketets kommandohuvud.

Nätverksnivå

Lite om detta nivå också. Här finns det två alternativ: antingen använda rymdpaketprotokollet eller inkapsla något annat protokoll i ett CCSDS-paket.

Översikt över rymdpaketprotokollet – ett ämne för en separat artikel. Det är utformat så att så kallade applikationer kan sömlöst utbyta data. Varje applikation har sin egen adress och en grundläggande funktion för datakommunikation med andra applikationer. Det finns också tjänster som hanterar trafikdirigering, leveranskontroll etc.

Med inkapsling är det enklare och tydligare. Standarderna ger möjlighet att inkapsla vilket protokoll som helst i CCSDS-paket genom att lägga till en extra header.

Där rubriken har olika betydelser beroende på längden av det inkapslade protokollet:

Här är huvudfältet – längden på längden. Den kan variera från 0 till 4 byte. I detta huvudfällt måste typen av det inkapslade protokollet anges med hjälp av tabellen härifrån.

Vid inkapsling av IP används en annan överbyggnad för att definiera typen av paket.
Det är nödvändigt att lägga till ytterligare en rubrik, med en längd av minst ett oktett:

Där PID är en annan protokollidentifierare, hämtad härifrån

Slutsats

Vid första anblick kan det verka som att CCSDS-rubrikarna är extremt överflödiga och att vissa fält skulle kunna utelämnas. Faktiskt ligger effektiviteten hos den resulterande kanalen (upp till nätverksnivå) runt 40 %. Men så fort det blir nödvändigt att implementera dessa standarder blir det tydligt att varje fält, varje rubrik har sitt viktiga syfte, vars ignorering leder till en rad oklarheter.

Om hub-communityn visar intresse för detta ämne skulle jag gärna publicera en rad artiklar som är dedikerade till teorin och praktiken av rymdkommunikation. Tack för uppmärksamheten!