{"id":35921,"date":"2019-10-31T22:07:35","date_gmt":"2019-10-31T19:07:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nemnogo-o-standartah-kosmicheskoj-svyazi\/"},"modified":"2019-10-31T22:07:35","modified_gmt":"2019-10-31T19:07:35","slug":"nemnogo-o-standartah-kosmicheskoj-svyazi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Een beetje over standaarden voor ruimtecommunicatie","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Een
\nMeteor M1
\nBron: vladtime.ru<\/i><\/p>\n

Inleiding<\/h2>\n

\nHet gebruik van ruimtevaartuigen is onmogelijk zonder radiocommunicatie, en in dit artikel zal ik proberen de belangrijkste idee\u00ebn 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.<\/p>\n

Deze publicatie zal voornamelijk gericht zijn op de datalinklaag, maar de belangrijkste concepten voor andere lagen zullen ook worden ge\u00efntroduceerd. Dit artikel pretendeert op geen enkele manier een volledige en grondige beschrijving van de normen te zijn. U kunt deze vinden op website<\/a><\/noindex> 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.
\n<\/a><\/noindex><\/p>\n

De Nobele missie van CCSDS<\/h2>\n

\nMisschien heeft iemand de vraag: waarom zou iedereen zich aan de normen moeten houden, als men ook een eigen propri\u00ebtaire radiocommunicatieprotocolstack (of een eigen standaard, met blackjack en nieuwe functies) kan ontwikkelen, waardoor de veiligheid van het systeem zou toenemen?<\/p>\n

De praktijk toont aan dat het voordeliger is om de CCSDS-normen aan te houden om de volgende redenen:<\/p>\n

    \n
  1. In het comit\u00e9 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.<\/li>\n
  2. Deze normen worden ondersteund door bestaande apparatuur van grondstations op de markt.<\/li>\n
  3. 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.<\/li>\n<\/ol>\n

    <\/p>\n

    Architectuur<\/h2>\n

    \nDe 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).<\/p>\n

    \"Een
    \n
    \nLaten 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.<\/p>\n

    Fysiek niveau<\/h2>\n

    \nOp 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\u00ebren en enkele aanbevelingen geven voor de implementatie van mechanismen voor symbolensynchronisatie, compensatie van Dopplerverschuiving en dergelijke.<\/p>\n

    Synchronisatie- en coderingsniveau<\/h2>\n

    \nFormeel 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):<\/p>\n

    \"Een
    \n
    \nEchter, 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. <\/p>\n

    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\u00ebren en eventuele fouten te corrigeren. Onder de blokcodes vallen de beroemde Reed-Solomon-codes.<\/p>\n

    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.<\/p>\n

    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.<\/p>\n

    Vervolgens vindt de decodering van blokcodes plaats, en wat overblijft is het eindproduct van de synchronisatie- en coderingslaag - het frame.<\/p>\n

    Kanaallaag<\/h2>\n

    \nAan 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: \u00e9\u00e9n voor telemetrie (TM) en \u00e9\u00e9n voor telecommando's (TC).<\/p>\n

    Telemetrie<\/h3>\n

    \nIn 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:<\/p>\n

    \"Een
    \n
    \nEn we beginnen met de basisheader van het telemetrie-frame. Verder zal ik op sommige plaatsen gewoon de standaarden vertalen, terwijl ik ook uitleg geef.<\/p>\n

    \"Een
    \n
    \nHet veld voor de identificatie van het hoofdkanaal (Master Channel ID) moet het versienummer van het frame en de identificatie van het apparaat bevatten.<\/p>\n

    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'.<\/i><\/p>\n

    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.<\/p>\n

    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.<\/i><\/p>\n

    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.<\/p>\n

    De tellingen van hoofd- en virtuele kanaal-kaders zijn velden die worden verhoogd met \u00e9\u00e9n bij het verzenden van elk kader. Ze dienen als indicator dat geen enkel kader is verloren gegaan.<\/i><\/p>\n

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

    \"Een
    \n
    \nHet 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.<\/p>\n

    Indien gewenst kan aan elk kader een aanvullende header worden toegevoegd, waarin naar eigen inzicht allerlei gegevens kunnen worden geplaatst.<\/i><\/p>\n

    Het veld voor de aanwijzer naar de eerste kop (First Header Pointer), wanneer de synchronisatiefunctie op \u00ab1\u00bb 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 \u00ab11111111111\u00bb hebben (dit kan gebeuren als \u00e9\u00e9n lang pakket zich over meer dan \u00e9\u00e9n frame verspreidt). <\/p>\n

    Als het dataveld echter een leeg pakket (Idle Data) bevat, moet de aanwijzer naar de eerste kop de binaire waarde \u00ab11111111110\u00bb 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.<\/p>\n

    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.<\/i>
    \nAls het foutcontroleveld aanwezig is, moet het in elk telemetrieframe voor een bepaalde fysieke kanaal tijdens de hele missie worden opgenomen.<\/p>\n

    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.<\/p>\n

    Telecommando's<\/h4>\n

    \nHet frame voor telecommando's heeft enkele belangrijke verschillen. Onder deze verschillen bevinden zich:<\/p>\n

      \n
    1. Een andere structuur van de koppen<\/li>\n
    2. 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.<\/li>\n
    3. 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.<\/li>\n<\/ol>\n

      \n\"Een
      \n
      \n\"Een
      \n
      \nVeel velden zijn al bekend uit de kop van het telemetrieframe. Ze hebben hetzelfde doel, dus we zullen hier alleen nieuwe velden bespreken.<\/p>\n

      E\u00e9n 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.<\/p>\n

      Deze vlag informeert de ontvanger of het bevestigingsmechanisme voor framelevering, dat FARM - Frame Acceptance and Reporting Mechanism wordt genoemd, moet worden gebruikt.<\/i><\/p>\n

      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.
      \nFARM is een eindige automaat waarvan de parameters configureerbaar zijn.<\/i><\/p>\n

      RSVD. SPARE - gereserveerde bits.<\/p>\n

      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.<\/i><\/p>\n

      Het lengtevak van de frames moet een getal bevatten in bitrepresentatie dat gelijk is aan de lengte van het frame in octetten min \u00e9\u00e9n.<\/p>\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:<\/p>\n