🥇Een beetje over de standaarden voor ruimtecommunicatie

Meteor M1
Bron: vladtime.ru

Inleiding

Het gebruik van ruimtevaartuigen is onmogelijk zonder radiocommunicatie, en in dit artikel zal ik proberen de belangrijkste ideeën uit te leggen die de basis vormen voor de normen ontwikkeld door het Consultative Committee for Space Data Systems (CCSDS). In het vervolg zal deze afkorting worden gebruikt.

Deze publicatie zal voornamelijk gericht zijn op de datalinklaag, maar de belangrijkste concepten voor andere lagen zullen ook worden geïntroduceerd. Dit artikel pretendeert op geen enkele manier een volledige en grondige beschrijving van de normen te zijn. U kunt deze vinden op website CCSDS. Echter, deze zijn zeer ingewikkeld te begrijpen, en om ze te doorgronden hebben we veel tijd besteed; daarom wil ik hier basisinformatie geven die het gemakkelijker zal maken om de rest te begrijpen. Laten we beginnen.

De Nobele missie van CCSDS

Misschien heeft iemand de vraag: waarom zou iedereen zich aan de normen moeten houden, als men ook een eigen propriëtaire radiocommunicatieprotocolstack (of een eigen standaard, met blackjack en nieuwe functies) kan ontwikkelen, waardoor de veiligheid van het systeem zou toenemen?

De praktijk toont aan dat het voordeliger is om de CCSDS-normen aan te houden om de volgende redenen:

In het comité dat verantwoordelijk is voor de publicatie van normen, zitten vertegenwoordigers van alle grote ruimtevaartagentschappen ter wereld, die hun onschatbare ervaring hebben ingebracht, opgedaan tijdens vele jaren van ontwerp en gebruik van verschillende missies. Het zou zeer ongepast zijn om deze ervaring te negeren en opnieuw in dezelfde valkuilen te trappen.
Deze normen worden ondersteund door bestaande apparatuur van grondstations op de markt.
Bij het oplossen van eventuele problemen kan men altijd collega's van andere agentschappen om hulp vragen zodat zij een communicatiesessie met het apparaat vanuit hun grondstation kunnen uitvoeren. Zoals u ziet, zijn normen uiterst nuttig, dus laten we de belangrijkste aspecten ervan doornemen.

Architectuur

De normen vertegenwoordigen een verzameling documenten die het meest gebruikelijke model van OSI (Open System Interconnection) weerspiegelen, met uitzondering van het feit dat op datalinkniveau de gemeenschappelijkheid beperkt is tot de scheiding tussen telemetrie (de "downward" kanaal - ruimte - Aarde) en telecommandos (het "upward" kanaal).

Laten we enkele niveaus in detail bekijken, te beginnen met het fysieke niveau en omhoog bewegend. Voor meer duidelijkheid zullen we de architectuur van de ontvangende kant beschouwen. De verzendende kant is het spiegelbeeld daarvan.

Fysiek niveau

Op dit niveau vindt de omzetting van het gemoduleerde radiosignaal naar een bitstroom plaats. De normen zijn hier voornamelijk aanbevelend van aard, omdat het lastig is om abstractie te maken van de specifieke implementatie van de hardware. Hier speelt CCSDS een cruciale rol - het moet de toegestane modulaties (BPSK, QPSK, 8-QAM, enz.) definiëren en enkele aanbevelingen geven voor de implementatie van mechanismen voor symbolensynchronisatie, compensatie van Dopplerverschuiving en dergelijke.

Synchronisatie- en coderingsniveau

Formeel gezien is dit een sub-niveau van het kanaalniveau, maar het wordt vaak als een apart niveau beschouwd vanwege het belang binnen de CCSDS-normen. Dit niveau zet de bitstroom om in zogenaamde frames (telemetrie of telecommandos), waar we later op zullen terugkomen. In tegenstelling tot de symbolensynchronisatie op fysiek niveau, die een correcte bitstroom mogelijk maakt, wordt hier frame-synchronisatie uitgevoerd. Laten we de route bekijken die de gegevens op dit niveau volgen (van onder naar boven):

Echter, voordat we dit doen, is het goed om een paar woorden over codering te zeggen. Deze procedure is noodzakelijk om bitfouten te ontdekken en/of te corrigeren die onvermijdelijk optreden tijdens het verzenden van gegevens via het radiokanaal. Hier zullen we de decoderingprocedures niet bespreken, maar alleen de informatie verkrijgen die nodig is om de verdere logica van het niveau te begrijpen.

Er zijn blokcodes en continue codes. De normen verplichten niet om een specifiek type codering te gebruiken, maar codering moet wel aanwezig zijn. Onder de continue codes vallen convolutionele codes. Deze worden gebruikt om een continue bitstroom te coderen. In tegenstelling tot blokcodes, waarbij gegevens in codeblokken worden verdeeld en alleen binnen de samenhangende blokken kunnen worden gedecodeerd. Een codeblok bestaat uit de verzonden gegevens en de bijgevoegde redundante informatie die nodig is om de correctheid van de ontvangen gegevens te verifiëren en eventuele fouten te corrigeren. Onder de blokcodes vallen de beroemde Reed-Solomon-codes.

Als er convolutionele codering wordt gebruikt, komt de bitstroom direct van het begin naar de decoder. Het resultaat van dit proces (dit gebeurt natuurlijk continu) zijn de CADU-gegevensblokken (channel access data unit). Deze structuur is noodzakelijk voor frame-synchronisatie. Aan het einde van elke CADU is een synchronisatiemarkering (ASM - attached synch marker) toegevoegd. Dit zijn eerder bekende 4 bytes, waarmee de synchronisator het begin en het einde van de CADU vindt. Op deze manier wordt frame-synchronisatie bereikt.

De volgende optionele fase van de synchronisatie- en coderingslaag heeft te maken met de kenmerken van de fysieke laag. Dit is derandomisatie. Het komt erop neer dat voor het bereiken van symbolische synchronisatie frequent moeten worden geschakeld tussen symbolen. Als we bijvoorbeeld een kilobyte gegevens zouden verzenden die uitsluitend uit enen bestaat, zou de synchronisatie verloren gaan. Daarom worden de ingevoerde gegevens tijdens de overdracht gemengd met een periodieke pseudowillekeurige reeks, zodat de dichtheid van nullen en enen gelijkmatig is.

Vervolgens vindt de decodering van blokcodes plaats, en wat overblijft is het eindproduct van de synchronisatie- en coderingslaag - het frame.

Kanaallaag

Aan de ene kant ontvangt de kanaallaagverwerker frames, en aan de andere kant levert deze pakketten af. Aangezien de formele grootte van pakketten niet beperkt is, moeten ze voor een betrouwbare verzending worden verdeeld in kleinere structuren - frames. Hier zullen we twee subsectoren bekijken: één voor telemetrie (TM) en één voor telecommando's (TC).

Telemetrie

In eenvoudigere bewoordingen zijn dit de gegevens die het grondstation ontvangt van het ruimtevaartuig. Alle verzonden informatie wordt verdeeld in kleine fragmenten van vaste lengte - frames, die de verzonden gegevens en functievakken bevatten. Laten we de frame-structuur nader bekijken:

En we beginnen met de basisheader van het telemetrie-frame. Verder zal ik op sommige plaatsen gewoon de standaarden vertalen, terwijl ik ook uitleg geef.

Het veld voor de identificatie van het hoofdkanaal (Master Channel ID) moet het versienummer van het frame en de identificatie van het apparaat bevatten.

Elke KA moet, volgens de CCSDS-normen, een unieke identificator hebben, waarmee kan worden bepaald aan welk apparaat het kader toebehoort. Formeel moet een aanvraag voor de registratie van het apparaat worden ingediend, en de naam ervan, samen met de identificator, zal in openbare bronnen worden gepubliceerd. Vaak negeren Russische producenten echter deze procedure en wijzen ze een willekeurige identificator toe aan het apparaat. Het versienummer van het kader helpt te bepalen welke versie van de normen wordt gebruikt, om het kader correct te kunnen lezen. Hier bekijken we alleen de meest conservatieve standaard met versie '0'.

In het veld voor de identificator van het virtuele kanaal (Virtual Channel ID) moet de VCID van het kanaal dat het pakket heeft ontvangen, worden vermeld. Er zijn geen beperkingen aan de keuze van VCID; virtuele kanalen hoeven niet noodzakelijkerwijs opeenvolgend te worden genummerd.

Vaak is er behoefte om de verzonden gegevens te multiplexen. Hiervoor bestaat er een mechanisme van virtuele kanalen. Bijvoorbeeld, de meteorologische satelliet Meteor-M2 verzendt een kleurafbeelding in het zichtbare spectrum, waarbij deze wordt opgedeeld in drie zwart-witte beelden - elke kleur wordt in zijn eigen virtuele kanaal als een afzonderlijk pakket verzonden, hoewel er in de structuur van zijn kaders enige afwijking van de normen is.

Het veld voor de vlag voor operationele controle moet een indicator zijn voor de aanwezigheid of afwezigheid van het veld voor operationele controle in het telemetrie-kader. Deze 4 bytes aan het einde van het kader dienen voor het ondersteunen van feedback bij de controle van de levering van telecommando-kaders. Hierover zullen we later meer bespreken.

De tellingen van hoofd- en virtuele kanaal-kaders zijn velden die worden verhoogd met één bij het verzenden van elk kader. Ze dienen als indicator dat geen enkel kader is verloren gegaan.

De status van de gegevens in het telemetrie-kader bestaat uit nog twee bytes van vlaggen en gegevens, waarvan we slechts enkele zullen bespreken.

Het veld voor de vlag van de aanvullende header (Secondary Header) moet een indicator zijn voor de aanwezigheid of afwezigheid van een aanvullende header (Secondary Header) in het telemetrie-kader.

Indien gewenst kan aan elk kader een aanvullende header worden toegevoegd, waarin naar eigen inzicht allerlei gegevens kunnen worden geplaatst.

Het veld voor de aanwijzer naar de eerste kop (First Header Pointer), wanneer de synchronisatiefunctie op «1» staat, moet de binaire voorstelling van de positie van het eerste octet van het eerste Pakket in het dataveld (Data Field) van het telemetrieframe bevatten. De positie telt vanaf 0 in oplopende volgorde vanaf het begin van het dataveld. Als er geen begin van het pakket in het dataveld van het telemetrieframe is, moet het veld voor de aanwijzer naar de eerste kop de binaire waarde «11111111111» hebben (dit kan gebeuren als één lang pakket zich over meer dan één frame verspreidt).

Als het dataveld echter een leeg pakket (Idle Data) bevat, moet de aanwijzer naar de eerste kop de binaire waarde «11111111110» hebben. Op basis van dit veld moet de ontvanger de stroom synchroniseren. Dit veld garandeert het herstel van synchronisatie, zelfs in het geval van gemiste frames.

Dat wil zeggen, het pakket kan bijvoorbeeld beginnen in het midden van het 4e frame en eindigen aan het begin van het 20e. Dit veld dient om het begin te vinden. Pakketten hebben ook een kop waarin de lengte is vastgelegd, dus wanneer de aanwijzer naar de eerste kop wordt gevonden, moet de schakelloggingleverancier deze lezen, zodat kan worden vastgesteld waar het pakket eindigt.
Als het foutcontroleveld aanwezig is, moet het in elk telemetrieframe voor een bepaalde fysieke kanaal tijdens de hele missie worden opgenomen.

Dit veld wordt berekend met behulp van de CRC-methode. De procedure moet de n-16 bits van het telemetrieframe aannemen en het resultaat van de berekening invoegen in de laatste 16 bits.

Telecommando's

Het frame voor telecommando's heeft enkele belangrijke verschillen. Onder deze verschillen bevinden zich:

Een andere structuur van de koppen
Dynamische lengte. Dit betekent dat de lengte van het frame niet rigide is vastgesteld, zoals in de telemetrie, maar kan veranderen afhankelijk van de verzonden pakketten.
Een mechanisme voor de garantie van pakketlevering. Dit betekent dat de KA na ontvangst de correctheid van de ontvangst van frames moet bevestigen, of om retransmissie moet vragen vanaf dat frame dat mogelijk met een onverholpen fout is ontvangen.

Veel velden zijn al bekend uit de kop van het telemetrieframe. Ze hebben hetzelfde doel, dus we zullen hier alleen nieuwe velden bespreken.

Eén bit van de omleidingsvlag moet worden gebruikt om te controleren of frames door de ontvanger zijn ontvangen. Een waarde van "0" voor deze vlag geeft aan dat dit frame van type A is en dat de controle moet plaatsvinden volgens FARM. Een waarde van "1" geeft de ontvanger aan dat dit frame van type B is en dat de controle op basis van FARM moet worden overgeslagen.

Deze vlag informeert de ontvanger of het bevestigingsmechanisme voor framelevering, dat FARM - Frame Acceptance and Reporting Mechanism wordt genoemd, moet worden gebruikt.

De controlecommando-vlag moet worden gebruikt om te begrijpen of het gegevensveld een opdracht of gegevens transporteert. Als de vlag "0" is, moet het gegevensveld gegevens bevatten. Als de vlag "1" is, moet het gegevensveld controle-informatie voor FARM bevatten.
FARM is een eindige automaat waarvan de parameters configureerbaar zijn.

RSVD. SPARE - gereserveerde bits.

CCSDS lijkt hier in de toekomst plannen voor te hebben, en voor de achterwaartse compatibiliteit van protocolversies hebben ze deze bits al in de huidige versies van de standaard gereserveerd.

Het lengtevak van de frames moet een getal bevatten in bitrepresentatie dat gelijk is aan de lengte van het frame in octetten min één.

Het gegevensveld van het frame moet onmiddellijk na de header komen zonder hiaten en moet een geheel aantal octetten bevatten, dat maximaal 1019 octetten kan zijn. Dit veld moet ofwel een gegevensblok van het frame bevatten of controle-informatie van het commando. Het gegevensblok van het frame moet bevatten:

een geheel aantal octetten gebruikersgegevens
segmentheader en de daaropvolgende geheel aantal octetten gebruikersgegevens

Als de header aanwezig is, moet het gegevensblok een Pakket, een set van Pakketten of een deel daarvan bevatten. Een gegevensblok zonder header kan geen delen van Pakketten bevatten, maar kan gegevensblokken van een specifiek formaat bevatten. Dit betekent dat een header vereist is wanneer het overgedragen gegevensblok niet in één frame past. Een gegevensblok met een header wordt een segment genoemd.

Het vlaggenveld van twee bits moet bevatten:

„01” — als het eerste deel van de gegevens zich in het gegevensblok bevindt
„00” — als het middelste deel van de gegevens zich in het gegevensblok bevindt
„10” — als het laatste deel van de gegevens zich in het gegevensblok bevindt
«11» - als er geen deling is en in het gegevensblok één of meerdere pakketten volledig worden geplaatst.

Het MAP-identificatieveld moet nullen bevatten als MAP-kanalen niet worden gebruikt.
Soms zijn 6 bits, toegewezen aan virtuele kanalen, niet voldoende. En als het nodig is om gegevens over een groter aantal kanalen te multiplexen, worden er nog eens 6 bits uit de segmentheader gebruikt.

FARM

Laten we het mechanisme van het functioneren van het systeem voor de aflevering van frames in meer detail bekijken. Dit systeem is uitsluitend bedoeld voor het werken met telecommando-frames vanwege hun belang (telemetrie kan altijd opnieuw worden opgevraagd, maar het ruimtevaartuig moet de grondstation duidelijk horen en altijd voldoen aan de opdrachten). Laten we aannemen dat we besluiten ons satelliet opnieuw te programmeren, en we sturen een binaire bestand van 10 kilobyte aan boord. Op het kanaalniveau wordt het bestand in 10 frames (0, 1, …, 9) verdeeld, die vervolgens één voor één worden verzonden. Wanneer de overdracht is voltooid, moet het ruimtevaartuig bevestigen dat het pakket correct is ontvangen of aangeven op welk frame de fout is opgetreden. Deze informatie wordt naar het operationele controleveld verzonden in het dichtstbijzijnde telemetrie-frame (of het ruimtevaartuig kan het verzenden van een leeg frame (idle frame) initiëren als het niets te zeggen heeft). Op basis van de ontvangen telemetrie kunnen we ofwel bevestigen dat alles goed is, of beginnen met het opnieuw verzenden van het bericht. Stel dat de satelliet frame №7 niet heeft gehoord. Dan sturen we frames 7, 8, 9 opnieuw. Als er geen antwoord is gekomen, wordt het pakket volledig opnieuw verzonden (en zo meerdere keren, totdat we begrijpen dat de pogingen tevergeefs zijn).

Hieronder volgt de structuur van het operationele controleveld met de beschrijving van enkele velden. De gegevens in dit veld worden CLCW – Communication Link Control Word genoemd.

Omdat je op de afbeelding gemakkelijk kunt afleiden wat de belangrijkste velden betekenen, en het saai is om naar de andere te kijken, verberg ik de gedetailleerde beschrijving onder een spoiler.

Ontsleuteling van CLCW-veldenType controlewoord (Control Word Type):
Voor dit type controlewoord moet 0 bevatten.

Versie van het controlewoord (CLCW Version Number):
Voor dit type controlewoord moet het gelijk zijn aan «00» in binaire weergave.

Statusveld (Status Field):
Het gebruik van dit veld wordt voor elke missie afzonderlijk bepaald. Het kan worden gebruikt voor lokale verbeteringen door verschillende ruimteagentschappen.

Identificatie van het virtuele kanaal (Virtual Channel Identification):
Moet de identificatie van het virtuele kanaal bevatten waarmee deze controlewoord is verbonden.

Toegangsflag voor het fysieke kanaal:
De vlag moet informatie verstrekken over de gereedheid van het fysieke ontvanger niveau. Als het fysieke ontvanger niveau niet klaar is om frames te ontvangen, moet het veld '1' bevatten, anders '0'.

Synchronisatie foutflag:
De vlag kan aangeven dat het fysieke niveau functioneert met een slecht signaalniveau en dat het aantal verworpen frames te hoog is. Gebruik van dit veld is optioneel; als het wordt gebruikt, moet het '0' bevatten bij synchronisatie en '1' bij het ontbreken daarvan.

Blokkeringsflag:
Dit bit moet de blokkeringsstatus van de FARM voor elk virtueel kanaal bevatten. Een waarde van '1' in dit veld moet aangeven dat de FARM geblokkeerd is en frames zullen worden weggelaten voor elk virtueel niveau, anders '0'.

Wachtflag:
Dit bit moet worden gebruikt om aan te geven dat de ontvanger deze op het aangegeven virtuele kanaal niet kan verwerken. Een waarde van '1' geeft aan dat alle frames op dit virtuele kanaal zullen worden weggelaten, anders '0'.

Doorstuurflag:
Deze vlag moet '1' bevatten als één of meer frames van type A zijn verworpen of er zijn hiaten gevonden, dus doorgifte is nodig. Vlag '0' geeft aan dat er geen verworpen frames en hiaten zijn.

Antwoordwaarde:
Het nummer van het frame dat niet is ontvangen. Gedefinieerd door de teller in de header van het telecommando frame.

Netwerklaag

Laten we ook deze laag kort behandelen. Hier zijn twee mogelijkheden: of gebruik het ruimtepakketprotocol, of verpak een ander protocol in een CCSDS-pakket.

Een overzicht van het ruimtepakketprotocol is een onderwerp voor een apart artikel. Het is ontworpen zodat zogenaamde applicaties naadloos gegevens kunnen uitwisselen. Elke applicatie heeft een eigen adres en basisfunctionaliteit voor gegevensuitwisseling met andere applicaties. Er zijn ook diensten die het verkeer routeren, de aflevering controleren, enzovoort.

Met encapsulatie is het eenvoudiger en duidelijker. De standaarden bieden de mogelijkheid om elk protocol in CCSDS-pakketten te encapsuleren door een extra header toe te voegen.

Waar de header verschillende betekenissen heeft, afhankelijk van de lengte van het ingekapselde protocol:

Hier is het belangrijkste veld - de lengte. Deze kan variëren van 0 tot 4 bytes. Ook moet in deze header het type van het ingekapselde protocol worden aangegeven, met behulp van de tabel hier.

Bij het inkapselen van IP wordt nog een extra laag gebruikt om het type pakket te bepalen.
Een andere header moet worden toegevoegd, met een lengte van minimaal één octet:

Waar PID - nog een protocolidentificator is, genomen hier

Conclusie

Op het eerste gezicht kan het lijken alsof de CCSDS-headers extreem redundant zijn, en dat sommige velden weggelaten kunnen worden. In feite is de efficiëntie van het resulterende kanaal (tot aan netwerkniveau) ongeveer 40%. Echter, zodra de noodzaak ontstaat om deze normen toe te passen, wordt het duidelijk dat elk veld, elke header zijn eigen belangrijke functie heeft, waarvan het negeren leidt tot een reeks onduidelijkheden.

Als de hubgemeenschap interesse toont in dit onderwerp, ben ik blij om nog een reeks artikelen te publiceren die gewijd zijn aan de theorie en praktijk van ruimtecommunicatie. Bedankt voor uw aandacht!